Architecture type de production

Pourquoi cette architecture n'est pas un détail d'implémentation

Un système RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire qui fonctionne en démonstration sur dix documents et un système RAG qui tient la charge en production sur cinquante mille documents partagent le même principe — récupérer puis générer — mais presque aucune des mêmes contraintes opérationnelles. Le passage de l'un à l'autre échoue rarement à cause du modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire choisi. Il échoue à cause de décisions d'architecture prises trop tôt, sans anticipation de ce qu'il faudra mesurer, corriger et faire évoluer une fois le système exposé à des utilisateurs réels et à des documents qui changent.

Ce chapitre assemble les briques vues dans les chapitres précédents — chunkingChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire, embeddingsembeddingIAReprésentation numérique dense d'un texte, d'une image ou d'un objet dans un espace vectoriel, utilisée pour la similarité et la recherche sémantique.Voir dans le glossaire, retrieval, génération augmentée — dans un blueprint complet, et ajoute ce qui manque le plus souvent dans les preuves de concept : l'observabilité et la boucle d'itération. Sans ces deux éléments, un pipeline RAG reste une boîte noire qu'on ne peut ni diagnostiquer ni améliorer durablement.

Vue d'ensemble : les briques d'un pipeline de production

Un pipeline RAG de production se divise en deux flux distincts, qui tournent à des rythmes différents.

Le flux offline (ingestion) prépare la base de connaissances : collecte des documents, nettoyage, découpage en chunks, calcul des embeddings, indexation dans le vector storebase vectorielleIABase spécialisée qui indexe des embeddings pour retrouver rapidement les passages les plus proches d'une requête (cœur du RAG).Voir dans le glossaire. Il s'exécute en tâche de fond, en continu ou par lots, indépendamment des requêtes utilisateur.

Le flux online (runtime) répond à chaque requête : embedding de la question, recherche dans l'index, reranking des candidats, assemblage du contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire, génération de la réponse par le LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire, puis restitution avec citations.

Un troisième axe, transversal, traverse les deux flux : l'observabilité. Elle capture des métriques à chaque étape — temps de réponse, pertinence des documents récupérés, taux de citations vérifiables, coût par requête — pour permettre l'itération.

L'ingestion et la préparation des documents

L'ingestion est la partie la moins spectaculaire du pipeline et la plus souvent sous-investie. Elle détermine pourtant le plafond de qualité de tout ce qui suit : aucun mécanisme de retrieval ne peut compenser un corpus mal nettoyé.

En pratique, cette étape couvre :

• L'extraction du texte depuis des formats hétérogènes (PDF scannés, pages HTML, exports Confluence, tableurs) — avec OCR si nécessaire, et conservation de la structure (titres, tableaux) plutôt qu'un flux de texte brut.
• Le dédoublonnage — les corpus d'entreprise contiennent souvent plusieurs versions du même document ; sans dédoublonnage, le retrieval renvoie des doublons qui saturent le contexte.
• L'enrichissement de métadonnées — date de publication, source, confidentialité, propriétaire. Ces métadonnées serviront de filtres au moment du retrieval, avant même le calcul de similarité vectorielle.
• La détection de contenu obsolète — un document remplacé doit être retiré de l'index, pas seulement archivé côté source.

Un document modifié doit pouvoir être ré-ingéré sans dupliquer ses anciens chunks dans l'index. En pratique, cela suppose un identifiant stable par document, un versionnage des chunks et une purge des versions précédentes avant réinsertion. Sans cette discipline, l'index accumule des chunks obsolètes qui pollueront durablement le retrieval, souvent de manière invisible.

Le chunking : la décision la plus sous-estimée

Le découpage en chunks fixe la granularité à laquelle le système peut « penser ». Un chunk trop long dilue l'information pertinente au milieu de contenu non pertinent, ce qui dégrade la similarité vectorielle et le raisonnement du modèle. Un chunk trop court perd le contexte nécessaire à sa propre compréhension : un paragraphe qui commence par « cette exception s'applique dans les cas suivants » est inutile sans son antécédent.

Trois stratégies dominent en production :

1. Chunking à taille fixe avec chevauchement (typiquement 200 à 500 tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire, chevauchement de 10 à 20 %). Simple, prévisible, mais indifférent à la structure du document.
2. Chunking structurel, qui respecte les frontières naturelles — titres, sections, paragraphes. Il produit des chunks de taille variable mais sémantiquement cohérents, ce qui est presque toujours préférable sur des documents structurés (documentation, contrats, rapports).
3. Chunking sémantique, qui regroupe les phrases selon leur proximité vectorielle plutôt que selon une limite de tokens. Plus coûteux à calculer, il se justifie sur des corpus où la structure explicite est faible (transcriptions, retours utilisateurs).

Le choix n'est jamais définitif : c'est un paramètre qu'il faut évaluer avec un jeu de questions représentatif, pas fixer par intuition en début de projet.

Embeddings et vector store : les compromis structurants

Le modèle d'embedding détermine la géométrie dans laquelle la similarité sera mesurée. Deux paramètres pèsent directement sur le coût et la latence : la dimensionnalité du vecteur (souvent entre 384 et 3072 selon le modèle) et la capacité à représenter le vocabulaire du domaine — un modèle généraliste peine sur un jargon juridique ou médical très spécialisé, d'où l'intérêt, sur ces corpus, d'un modèle fine-tuné ou spécialisé.

Côté index, le choix se joue entre plusieurs familles d'algorithmes de recherche approximative des plus proches voisins (ANN) :

Au-delà de quelques millions de vecteurs, le choix de l'index et de ses paramètres (nombre de voisins par nœud, profondeur de recherche) devient un vrai sujet d'ingénierie, à valider avec des mesures de rappel réel, pas seulement de latence apparente.

Retrieval : au-delà du top-k naïf

La recherche par similarité vectorielle seule (« dense retrieval ») rate systématiquement certaines requêtes : références exactes (numéros de contrat, codes d'erreur, identifiants), acronymes rares, ou requêtes très courtes où le signal sémantique est faible. C'est pourquoi la plupart des pipelines de production combinent recherche dense et recherche lexicale (BM25 ou équivalent) dans un retrieval hybride, avec fusion des scores.

Fixer k = 5 pour toutes les requêtes revient à supposer que chaque question nécessite exactement le même volume de contexte. En pratique, une question factuelle simple peut se satisfaire d'un seul chunk très pertinent, tandis qu'une question comparative en nécessite plusieurs, potentiellement issus de documents différents. Un k trop grand dilue le contexte utile et augmente le risque que le modèle s'appuie sur un passage non pertinent ; un k trop petit prive le modèle d'information nécessaire. Le réglage doit être testé par catégorie de requête, pas fixé une fois pour toutes.

Le filtrage par métadonnées (date, source, périmètre d'accès) doit s'appliquer avant ou pendant la recherche vectorielle, jamais uniquement après — sans quoi le système peut calculer un top-k entier de résultats hors périmètre avant de tout écarter, en pure perte de latence et de pertinence.

Reranking et assemblage du contexte

Le retrieval initial optimise pour le rappel — retrouver rapidement un ensemble de candidats plausibles, sur un grand volume. Il n'optimise pas pour la précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire fine du classement. Un reranker, généralement un cross-encoderCross-encoderIAModèle qui encode conjointement une requête et un document pour produire un score de pertinence, plus précis qu'un bi-encodeur mais plus coûteux à l'inférence.Voir dans le glossaire qui évalue conjointement la requête et chaque document candidat, corrige ce classement au prix d'un coût de calcul plus élevé, appliqué seulement sur les quelques dizaines de candidats déjà présélectionnés par le retrieval.

L'assemblage du contexte final combine ensuite les chunks retenus, dans un ordre qui compte : plusieurs études empiriques sur les modèles de langage montrent une dégradation de l'attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire pour l'information placée au milieu d'un contexte long, un effet parfois désigné comme le « perdu au milieu ». En pratique, cela justifie de placer les passages les plus pertinents en début et en fin de contexte plutôt qu'au centre de la fenêtre.

Génération : prompt, garde-fous et citations

Le promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire de génération n'est pas une simple concaténation de la question et des chunks récupérés. Un prompt de production robuste explicite au minimum :

• L'instruction de ne répondre qu'à partir du contexte fourni, avec un refus explicite si l'information est absente — sans quoi le modèle retombe sur ses connaissances paramétriques, ce qui réintroduit le risque d'hallucinationhallucinationIAProduction par un modèle d'un énoncé faux formulé avec la même assurance qu'un fait établi. Le phénomène est structurel : le modèle optimise la vraisemblance, pas la vérité.Voir dans le glossaire que le RAG est censé limiter.
• Le format de citation attendu, avec un identifiant de source par chunk, pour permettre une vérification traçable de chaque affirmation.
• Les limites de périmètre — langue de réponse, ton attendu, refus explicite des sujets hors domaine.

« Réponds uniquement à partir des extraits fournis ci-dessous, chacun identifié par [S1], [S2], etc. Cite la source de chaque affirmation entre crochets. Si les extraits ne permettent pas de répondre, indique-le explicitement plutôt que de compléter avec des connaissances externes au corpus. »

Ce garde-fou ne supprime pas l'hallucination — un modèle peut toujours mal interpréter un passage pourtant correct — mais il en réduit fortement la fréquence et, surtout, il rend l'erreur détectable : une citation vérifiable permet à l'utilisateur, ou à un contrôle automatisé, de confronter l'affirmation à sa source d'origine.

Observabilité : ce qu'il faut mesurer en production

Un pipeline RAG non instrumenté est indéboguable : quand un utilisateur signale une mauvaise réponse, impossible de savoir si le problème vient de l'ingestion, du chunking, du retrieval, du reranking ou de la génération. La liste minimale de métriques à suivre en production :

• Latence par étape — embedding, recherche vectorielle, reranking, génération — pour identifier le goulot d'étranglement réel plutôt que d'optimiser au hasard.
• Rappel et précision du retrieval, mesurés sur un jeu de questions-réponses annoté (golden datasetdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire), pas seulement observés de manière qualitative.
• Taux de citations vérifiables — proportion de réponses dont chaque affirmation est traçable à un chunk du contexte fourni.
• Taux de refus, à comparer à un taux de faux refus — le système avait l'information nécessaire mais a refusé de répondre par excès de prudence.
• Coût par requête, décomposé entre l'appel d'embedding, l'appel de reranking et l'appel de génération — souvent le poste le plus visible en cas de montée en charge.
• Taux de cache hit, pour les requêtes ou sous-résultats répétés dans le temps.

Un jeu d'une centaine à quelques centaines de paires question-réponse, annotées manuellement avec les sources attendues, permet de mesurer objectivement une régression après chaque changement — nouveau modèle d'embedding, nouvelle stratégie de chunking, nouveau prompt. Sans lui, chaque itération repose sur une impression, pas sur une mesure, et les régressions passent inaperçues jusqu'à ce qu'un utilisateur les signale lui-même.

La boucle d'itération : évaluation continue

Un pipeline RAG de production n'est jamais figé : le corpus évolue, les usages évoluent, et les modèles sous-jacents sont mis à jour par leurs fournisseurs. La boucle d'itération suit un cycle simple, mais qu'il faut discipliner :

1. Exécuter le golden dataset contre la version actuelle du pipeline et enregistrer les métriques de référence.
2. Collecter les retours réels — signalements utilisateurs, échantillon de requêtes en production, cas d'échec remontés par le support.
3. Qualifier chaque échec — problème d'ingestion, de chunking, de retrieval, de reranking ou de génération — avant de corriger, pour éviter de modifier la mauvaise brique.
4. Appliquer un correctif ciblé et le valider sur le golden dataset avant déploiement, en comparant les métriques avant et après.
5. Étendre le golden dataset avec les nouveaux cas d'échec identifiés, pour ne jamais régresser deux fois sur le même problème.

Plutôt que de corriger un incident au cas par cas, ajoutez-le au golden dataset avec la réponse attendue. Le coût marginal est faible et l'effet cumulatif, sur plusieurs mois, transforme un pipeline fragile en système dont chaque évolution est mesurée plutôt que devinée à l'instinct.

Pièges fréquents et anti-patterns

Certaines erreurs reviennent avec une régularité suffisante pour mériter d'être nommées explicitement :

• Confondre similarité vectorielle et pertinence — un chunk peut être proche sémantiquement de la question sans répondre à l'intention réelle de l'utilisateur, notamment sur des questions comparatives ou multi-hop.
• Ignorer la fraîcheur des données — un index jamais purgé accumule des informations contradictoires entre versions d'un même document, sans qu'aucun signal ne le distingue au moment du retrieval.
• Dimensionner le contexte pour le cas moyen — un k réglé sur des requêtes simples échoue silencieusement sur les requêtes complexes, souvent les plus critiques pour l'utilisateur.
• Déployer sans jeu d'évaluation — sans golden dataset, toute amélioration perçue reste une hypothèse non démontrée.
• Traiter le reranking comme optionnel par défaut — il l'est sur un petit corpus homogène, il ne l'est presque jamais sur un corpus hétérogène de plusieurs dizaines de milliers de documents.

Checklist avant mise en production

• Pipeline d'ingestion idempotent, avec purge des versions obsolètes.
• Stratégie de chunking validée par un test comparatif sur un échantillon représentatif de questions.
• Retrieval hybride (dense et lexical) ou justification documentée de son absence.
• Reranking activé si le corpus dépasse quelques milliers de documents hétérogènes.
• Prompt de génération avec consigne de refus explicite et format de citation imposé.
• Golden dataset d'au moins une centaine de paires question-réponse annotées.
• Tableau de bord couvrant latence, rappel, taux de citation et coût par requête.
• Processus documenté de qualification des échecs avant toute correction.

Ce qu'il faut retenir

L'architecture d'un pipeline RAG de production ne se résume pas à brancher un vector store sur un modèle de langage. Chaque brique — ingestion, chunking, embeddings, retrieval, reranking, génération — introduit des compromis qui se répercutent sur les suivantes, et aucune ne peut être optimisée isolément sans un jeu d'évaluation qui mesure l'effet réel sur la qualité des réponses. L'observabilité et la boucle d'itération ne sont pas des ajouts de confort : elles sont ce qui distingue un prototype qui impressionne en démonstration d'un système qui tient dans la durée, face à des documents qui changent et des utilisateurs qui posent des questions imprévues.