RAG (Retrieval-Augmented Generation)

Principe général

Comment fonctionne une architecture RAG

Le RAG répond à une question précise : comment faire parler un modèle de documents qu’il n’a jamais vus à l’entraînement. Au lieu d’espérer qu’il sache, on lui donne à lire les passages utiles avant qu’il rédige.

L’architecture se lit comme une chaîne : collecte, découpage, vectorisation, stockage. À la requête, la question suit le même traitement, l’index remonte les passages proches, un reclassement les ordonne, et le prompt final assemble question, extraits et consignes. Chaque maillon peut céder, et la réponse en portera la trace. Diagnostiquer un RAG consiste à remonter cette chaîne. L’usage côté visiteur relève d’un autre sujet, traité sur la recherche intelligente.

Les deux temps du RAG : indexation hors ligne et retrieval à la requête

L’indexation se fait à froid, la récupération à chaud. Cette séparation gouverne la conception : ce qui coûte cher se fait une fois, en amont ; ce qui se joue pendant la requête reste léger.

Le temps hors ligne couvre l’extraction du texte, la normalisation, le découpage, la vectorisation et l’écriture dans l’index. Il produit aussi les métadonnées de chaque passage : section d’origine, version, périmètre d’accès, statut de validité. Elles deviennent indispensables dès qu’il faut filtrer ou retirer un contenu. Le temps de la requête enchaîne recherche, filtrage, reclassement et appel au modèle : chaque étape y gagne en pertinence ce qu’elle perd en latence.

RAG, fine-tuning ou contexte long : quelle approche pour quel besoin

Ces approches ne traitent pas le même problème. Le RAG s’adresse à un corpus qui change. Le fine-tuning, à un comportement qui doit changer. Le contexte long, à un document que l’on veut faire lire en entier.

Le fine-tuning apprend un style, un format, un vocabulaire métier ; il n’apprend pas des faits mouvants de façon fiable. Le contexte long évite l’indexation mais renvoie le même volume à chaque question. En pratique, elles se combinent : le RAG apporte les faits, le prompt apporte la forme. Cette articulation se décide au niveau applicatif, sujet développé sur l’intégration LLM.

Contrôle qualité

Évaluation, hallucinations et limites du RAG

On n’améliore pas un RAG que l’on ne mesure pas. Séparez deux questions : les bons passages sont-ils remontés, et la réponse leur est-elle fidèle. Ces deux échecs ne se corrigent pas au même endroit.

Le socle reste un jeu de questions représentatives, avec pour chacune le passage attendu, écrit par quelqu’un qui connaît le métier. Le tableau ci-dessous relie les symptômes à leur cause, au levier de correction et à ce qu’il ne règle pas.

Symptôme	Cause probable	Levier de correction	Limite du levier
Le passage attendu ne remonte pas	Extraction, découpage ou requête	Revoir le découpage, ajouter la recherche lexicale	Suppose un jeu de test tenu à la main
Le bon passage remonte, noyé	Défaut de classement	Reclassement dédié, filtrage par métadonnées	Ajoute de la latence et un appel de plus à chaque requête
La réponse dépasse les extraits	Défaut de fidélité à la génération	Consigne stricte, obligation de citer, droit de refuser	Augmente les non-réponses, y compris sur des cas traitables
La source citée ne correspond pas	Défaut de traçabilité	Identifiant par passage, citation contrainte	Une citation ne vaut que si le passage est consultable
Erreurs sur les sujets modifiés	Index désynchronisé du corpus	Réindexation incrémentale à chaque mise à jour	Traite mal les suppressions : un contenu retiré survit

Une limite structurelle demeure : le RAG ne raisonne pas sur l’ensemble du corpus, il répond à partir d’extraits. Le dénombrement et la synthèse exhaustive lui échappent. Une question qui commence par « quels sont tous les » appelle une requête structurée, pas une recherche sémantique.

Exemples concrets

Cas d’usage

• Interroger en langage naturel une documentation technique répartie sur des centaines de PDF
• Répondre aux questions du support client à partir des procédures internes, avec citation des sources
• Retrouver les clauses comparables dans un fonds de contrats avant rédaction d’un nouvel accord
• Alimenter un assistant interne avec les comptes rendus de réunion et les décisions passées

Vos questions

Questions fréquentes

Quelle taille de chunk faut-il choisir pour découper les documents ?

Il n’existe pas de longueur idéale transposable d’un projet à l’autre. Le bon découpage suit la structure logique du document : une section, une clause, une étape de procédure. Le critère se vérifie à l’œil nu : un passage doit rester compréhensible seul.

L’ajustement se fait par essais sur vos propres questions. Des passages trop courts perdent leur contexte ; trop longs, ils diluent l’information dans du bruit. Traitez à part les documents très structurés, comme les tableaux, qui supportent mal un découpage linéaire.

Le RAG supprime-t-il vraiment les hallucinations ?

Non. Il les réduit fortement en donnant au modèle de quoi répondre, il ne les supprime pas. Un modèle peut combler un vide ou fusionner deux passages sans rapport.

Les garde-fous qui tiennent sont opérationnels : imposer la citation du passage utilisé, autoriser la réponse « l’information ne figure pas dans les documents fournis », vérifier par échantillonnage que chaque affirmation se retrouve dans l’extrait cité. Un RAG dont on ne peut pas remonter les sources n’offre pas de garantie.

Comment mesurer la qualité d’un système RAG ?

En mesurant séparément la récupération et la génération. Pour la première, vérifiez si le passage attendu figure parmi ceux remontés, et à quelle position. Pour la seconde, vérifiez si chaque affirmation est soutenue par un extrait fourni.

La difficulté n’est pas le calcul, c’est le jeu de test. Il doit refléter les questions réellement posées, formulations maladroites comprises, et rester vivant : chaque échec en production devient un cas de test.

Faut-il réindexer toute la base à chaque mise à jour documentaire ?

Non, sauf changement de modèle d’embedding ou de découpage : les représentations existantes ne sont plus comparables aux nouvelles. Ailleurs, la mise à jour se fait document par document.

La réindexation incrémentale suppose d’identifier les passages issus d’un document donné, pour les remplacer ou les supprimer d’un bloc. Prévoyez ce mécanisme dès la conception, ainsi que le traitement des suppressions : c’est le cas le plus souvent oublié.