Architecture RAG : construire, évaluer et mettre en production

Un système RAG ne devient pas fiable parce qu'il trouve des passages proches d'une question. Il devient exploitable lorsque l'équipe peut expliquer quelle source a été utilisée, pourquoi elle a été classée, si elle autorisait la réponse et comment la qualité est mesurée après chaque changement.

Le RAG, ou génération augmentée par récupération, associe un modèle génératif à une mémoire externe consultée au moment de la requête. L'article fondateur publié à NeurIPS en 2020 mettait déjà en avant deux intérêts : actualiser la connaissance sans réentraîner tout le modèle et conserver une provenance consultable. En production, cette promesse exige davantage qu'une base vectorielle et un prompt.

L'architecture en une vue

Cette séparation est importante : une mauvaise réponse peut venir d'un document absent, d'un mauvais découpage, d'une récupération incomplète, d'un classement imprécis ou d'une génération infidèle. Un score global ne dit pas quel composant réparer.

Vérifier que le RAG est le bon outil

Le RAG convient lorsque la réponse dépend d'un corpus identifiable, évolutif et consultable : documentation produit, procédures internes, contrats, catalogue ou base de connaissances. Il est particulièrement utile lorsque l'utilisateur doit voir les sources et que la connaissance change plus vite qu'un modèle.

Il n'est pas automatiquement adapté à une requête purement transactionnelle ou calculable. Un prix en stock doit souvent venir d'une API ou d'une requête SQL structurée. Une règle critique peut nécessiter un moteur déterministe. Un petit corpus stable peut être servi par une recherche classique. L'architecture peut combiner ces chemins plutôt que forcer chaque demande dans un index vectoriel.

Avant le premier prototype, écrivez dix exemples de questions, la source faisant autorité, la réponse acceptable, les droits nécessaires et le comportement attendu si l'information manque. Cette fiche empêche de confondre une démonstration impressionnante avec un produit vérifiable.

Construire une chaîne traçable de la source à la citation

Chaque document doit conserver un identifiant stable, une version, un propriétaire, une date de validité, une langue et un niveau d'accès. Chaque fragment hérite de ces informations et référence son emplacement dans la source : page, section, paragraphe ou ligne lorsque le format le permet.

L'index n'est pas le système de vérité. Il s'agit d'une projection reconstruisible destinée à la recherche. Le fichier, la base métier ou le référentiel documentaire reste responsable du contenu. Une correction doit pouvoir invalider l'ancienne version et déclencher une réindexation sans laisser de fragments périmés accessibles.

Le pipeline d'ingestion doit enregistrer au minimum : empreinte du document, version du parseur, stratégie de découpage, modèle d'embedding, date d'indexation et résultat des contrôles. Ces métadonnées rendent possible une comparaison entre deux versions du système et un retour arrière.

Notre guide d'architecture data pour l'IA détaille la gouvernance, les pipelines et la responsabilité des sources. Ici, l'objectif est de transformer cette fondation en chaîne de réponse mesurable.

Découper selon la structure, pas avec un nombre magique

Un fragment trop court perd les définitions et les conditions qui donnent du sens à une phrase. Un fragment trop long dilue le signal, augmente le contexte envoyé au modèle et peut mélanger plusieurs sujets. Une valeur fixe de caractères ou de tokens constitue un point de départ, pas une règle universelle.

Préservez d'abord les unités du document : titre et section, article contractuel, procédure, entrée de FAQ, bloc de code ou ligne de tableau. Ajoutez un chevauchement seulement lorsqu'il évite de couper une idée, car un chevauchement systématique augmente les doublons dans les résultats.

Testez au moins deux stratégies sur les mêmes questions. Mesurez si le passage contenant la preuve apparaît dans les premiers résultats, puis observez le volume de contexte et les citations. La meilleure granularité pour une FAQ n'est pas celle d'un manuel de 400 pages.

Le guide sur la qualité documentaire d'un RAG approfondit le nettoyage, le versionnement et les métadonnées avant indexation.

Choisir entre recherche lexicale, vectorielle et hybride

La recherche lexicale retrouve efficacement les mots rares, références, acronymes, noms de produit et messages d'erreur. La recherche vectorielle rapproche des formulations différentes qui expriment un sens voisin. Aucune ne gagne partout.

Une recherche hybride exécute les deux chemins puis fusionne leurs classements. Azure AI Search et Elasticsearch documentent notamment l'usage de Reciprocal Rank Fusion, ou RRF : les scores incompatibles de BM25 et de similarité vectorielle ne sont pas additionnés directement ; la position de chaque résultat dans les listes sert à construire un classement commun.

Commencez par une référence simple : recherche lexicale seule, puis vectorielle seule, puis hybride sur le même jeu de questions. Conservez la solution la moins complexe qui apporte un gain reproductible. Une recherche hybride n'excuse pas un vocabulaire documentaire incohérent ou des filtres manquants.

Une extension comme pgvector permet de démarrer dans PostgreSQL avec recherche exacte puis index approximatifs HNSW ou IVFFlat. Une base spécialisée devient pertinente lorsque le volume, la distribution, les filtres, la latence ou les opérations l'imposent. La décision doit inclure sauvegarde, restauration, supervision et compétences de l'équipe, pas uniquement un benchmark de requêtes.

Filtrer avant de classer, reranker seulement si nécessaire

Les filtres structurés limitent la recherche aux documents autorisés et pertinents : tenant, produit, langue, pays, période de validité ou niveau de confidentialité. Les droits doivent être appliqués avant que le texte entre dans le contexte du modèle. Retirer une citation de l'interface après génération ne répare pas une fuite.

La première récupération doit favoriser le rappel : mieux vaut présenter au classement final un ensemble raisonnable contenant la bonne preuve. Un reranker examine ensuite plus précisément la paire question-passage et remet les candidats dans l'ordre. Il peut améliorer les premières positions, mais ajoute latence et coût.

N'appliquez pas un reranker à tout l'index. Récupérez par exemple quelques dizaines de candidats, filtrez les doublons, puis rerankez avant de ne conserver que les passages utiles au modèle. Mesurez le gain sur MRR ou nDCG et le coût en p95. Si les premières positions étaient déjà correctes, ce composant n'est peut-être pas justifié.

Générer une réponse fondée, citée et capable de s'abstenir

Le prompt doit séparer clairement instructions, question et extraits récupérés. Il doit interdire de suivre des instructions trouvées dans les documents et demander une réponse limitée aux preuves fournies. Chaque passage doit porter un identifiant de citation que l'application peut relier à la source réelle.

Une citation correcte ne signifie pas seulement qu'un document est attaché à la réponse. Le passage cité doit soutenir la proposition précise, être accessible à l'utilisateur et correspondre à la version consultée. Vérifiez les citations au niveau des affirmations importantes, pas uniquement au niveau de la réponse entière.

Prévoyez trois sorties distinctes : réponse soutenue, demande de clarification et absence de preuve suffisante. Forcer le modèle à répondre à chaque fois augmente mécaniquement les réponses inventées. Les questions volontairement impossibles font donc partie du jeu de test.

Mesurer la récupération avant la génération

Un jeu d'évaluation utile associe chaque question à un ou plusieurs passages attendus. Pour chaque variante du pipeline, enregistrez la liste ordonnée des résultats et calculez plusieurs métriques :

• Recall@k : proportion de questions pour lesquelles au moins une preuve attendue apparaît dans les k premiers résultats ;
• Precision@k : part des résultats récupérés qui sont réellement pertinents ;
• MRR : valorise la position du premier résultat pertinent ;
• nDCG : tient compte de l'ordre et de plusieurs niveaux de pertinence.

Le rappel est prioritaire lorsque manquer la bonne source condamne toute génération. La précision devient importante lorsque le contexte est limité ou que des passages hors sujet perturbent le modèle. MRR et nDCG distinguent deux systèmes qui trouvent les mêmes documents mais les présentent dans un ordre différent.

Segmentez les résultats par type de question, langue, source et niveau d'accès. Une moyenne peut masquer un excellent résultat sur la FAQ et un échec complet sur les tableaux ou les documents récents.

Évaluer séparément la réponse et ses preuves

Une fois la récupération satisfaisante, mesurez au moins quatre dimensions :

1. fidélité : chaque affirmation factuelle est-elle soutenue par le contexte ?
2. pertinence : la réponse traite-t-elle réellement la question ?
3. complétude : couvre-t-elle les éléments nécessaires à la tâche ?
4. qualité des citations : les références soutiennent-elles les bonnes affirmations ?

RAGAS a contribué à formaliser des évaluations automatiques de pertinence du contexte, fidélité et pertinence de réponse. Ces scores accélèrent les comparaisons, mais un modèle juge reste un instrument à calibrer. Comparez ses décisions à un échantillon annoté par des humains, gardez les explications et surveillez les désaccords.

Le score produit doit aussi refléter la conséquence de l'erreur. Pour une aide interne à faible risque, une réponse corrigée en un clic peut être acceptable. Pour du juridique, de la santé ou une décision financière, les critères, la validation humaine et les seuils doivent être beaucoup plus stricts. Notre article sur l'évaluation d'un chatbot avant production complète les tests de robustesse et de comportement.

Construire un jeu de test qui ressemble à la production

Commencez par des questions réelles, anonymisées si nécessaire, puis ajoutez les cas qui exposent chaque maillon : synonymes, références exactes, fautes, plusieurs langues, tableaux, documents longs, versions contradictoires et questions nécessitant plusieurs passages.

Incluez aussi :

• des questions sans réponse dans le corpus ;
• des utilisateurs possédant des droits différents ;
• un document supprimé ou arrivé à expiration ;
• une instruction malveillante intégrée dans une source ;
• une question ambiguë qui exige une clarification ;
• une mise à jour dont la fraîcheur doit être visible rapidement.

Versionnez questions, preuves attendues, annotations et seuils avec le code du pipeline. Ajoutez les incidents de production au jeu de non-régression. Un changement de modèle, d'embedding, de découpage, de filtre ou de prompt doit rejouer la même suite.

Sécurité : traiter les documents comme une entrée non fiable

OWASP classe les faiblesses des vecteurs et embeddings parmi les risques des applications LLM. Un corpus peut contenir des données empoisonnées, des instructions de prompt injection, des informations personnelles ou des fragments accessibles au mauvais tenant.

Séparez les index lorsque l'isolation l'exige, appliquez les ACL au moment de la recherche, validez les sources autorisées et journalisez les identifiants récupérés. Analysez les fichiers avant ingestion, limitez les formats et empêchez un document de modifier les instructions système. Testez explicitement les fuites inter-utilisateurs et inter-organisations.

Les logs d'évaluation peuvent eux-mêmes contenir questions sensibles, extraits et réponses. Définissez leur durée de conservation, leur accès et leur anonymisation. L'observabilité ne doit pas devenir une nouvelle copie incontrôlée du corpus.

Observer latence, coût et dérive en production

Tracez séparément le temps de reformulation éventuelle, d'embedding, de recherche, de reranking et de génération. Conservez le nombre de candidats, de passages finaux, de tokens de contexte et de citations. Une latence globale ne permet pas de localiser une régression.

Suivez au minimum : p50 et p95, coût par réponse utile, taux d'abstention, réponses sans citation, clics ou ouverture des sources, escalades humaines, erreurs d'ingestion et âge du document le plus récent. Echantillonnez régulièrement des réponses pour une revue humaine.

Déployez les changements derrière un jeu d'évaluation et, si le volume le permet, un canary ou un test contrôlé. Conservez la version précédente de l'index et du pipeline jusqu'à stabilisation. Le guide d'observabilité des pipelines data détaille les contrôles de fraîcheur et de fonctionnement.

La grille de passage en production

Les seuils exacts dépendent du risque et du processus actuel. L'objectif n'est pas d'obtenir 100 % sur une métrique isolée, mais de rendre explicite le niveau accepté et la conséquence d'un échec.

Un plan de mise en oeuvre progressif

La première itération peut tenir autour d'une source bien comprise et de cinquante questions annotées. Construisez une recherche lexicale de référence, ajoutez la recherche vectorielle, puis mesurez l'hybride. N'introduisez le reranking que si les résultats montrent un problème d'ordre.

La deuxième itération ajoute citations vérifiables, abstention, tests de droits et traces de bout en bout. La troisième ouvre à un groupe limité, collecte les échecs réels et mesure le temps gagné ou la tâche résolue. Les sources et formats supplémentaires arrivent après la stabilité de cette boucle.

Une architecture RAG sérieuse n'est pas celle qui empile le plus de composants. C'est celle qui permet de dire, pour chaque réponse : voici la preuve, voici les droits appliqués, voici la version du pipeline et voici le test qui nous autorise à la servir.