Comment fonctionne la RAG
Un système RAG comporte deux parties.
Avant toute question : l'indexation
Les documents sont collectés là où ils se trouvent, par exemple une base documentaire, un wiki ou un système de tickets. Ils sont découpés en segments, en général de quelques centaines de tokens au plus. Chaque segment est transformé en embedding, une liste de nombres qui en capte le sens, et stocké dans un index de recherche, souvent à côté d'un index par mots-clés.
Quand quelqu'un pose une question : récupération et génération
La question est recherchée dans l'index. Les passages les plus pertinents sont récupérés, souvent reclassés par un second modèle, et placés dans le prompt avec la question et des instructions comme "réponds uniquement à partir de ces passages et cite-les". Le modèle rédige la réponse, et l'application affiche les sources à côté.
Options d'architecture RAG
| Option | Comment ça marche | Quand l'utiliser |
|---|---|---|
| Recherche vectorielle | Trouve les passages proches de la question par le sens, à l'aide d'embeddings | Les questions formulées autrement que les documents. Elle peut manquer des termes exacts comme des codes et des noms |
| Recherche hybride | Exécute ensemble la recherche par mots-clés (BM25) et la recherche vectorielle, puis fusionne les résultats | Un bon choix par défaut pour les contenus d'entreprise, qui mêlent texte, codes, noms et chiffres |
| Reclassement | Un second modèle réordonne les meilleurs résultats par pertinence | Les grandes collections où la première recherche renvoie beaucoup de résultats approchants |
| Récupération contextuelle | Ajoute à chaque segment une courte description de son document avant l'indexation | Les segments qui perdent leur sens hors contexte, comme une clause ou une ligne de tableau |
| Contexte long | Place des documents entiers dans la fenêtre de contexte du modèle au lieu de rechercher | Les ensembles de documents petits et stables. Il coûte plus cher par question |
Dans les tests d'Anthropic, les embeddings contextuels combinés à la recherche par mots-clés BM25 et au reclassement ont réduit de 67 % le taux auquel le bon passage était absent des 20 premiers résultats. Azure AI Search, par exemple, exécute en parallèle des requêtes par mots-clés et vectorielles et les fusionne avec Reciprocal Rank Fusion, une façon courante de construire une recherche hybride.
Avant de construire un index, vérifiez ce que votre plateforme d'IA propose déjà. Claude, par exemple, peut travailler avec des sources connectées comme Google Drive ou Microsoft 365 via des connecteurs, ce qui suffit souvent pour une première étape.
Limites de la RAG et comment les gérer
- Passages manqués. Le découpage des documents peut séparer un passage du contexte qui lui donne son sens, et les embeddings peuvent manquer des correspondances exactes que la recherche par mots-clés trouve. La recherche hybride et la récupération contextuelle réduisent ces deux problèmes.
- Contenus obsolètes. Un index est une copie. Quand les documents changent, eux et leurs embeddings doivent être mis à jour, idéalement de façon automatique et en arrière-plan.
- Droits d'accès. L'index doit respecter qui peut voir quoi, afin qu'une personne ne récupère que les passages qu'elle est autorisée à lire.
- Réponses qui dépassent les sources. La RAG réduit les réponses inventées sans les éliminer. Des instructions demandant de ne répondre qu'à partir des passages, des citations vérifiables et un simple "je ne sais pas" quand rien de pertinent n'est trouvé gardent les réponses honnêtes.
- Trop de contexte. Les modèles peuvent perdre des informations placées au milieu d'un long prompt : des passages moins nombreux et meilleurs valent souvent mieux qu'un plus grand nombre.
Pour savoir si un système RAG fonctionne, il faut le tester : un jeu de questions réelles dont les réponses et les sources sont connues, mesuré sur la qualité de la récupération comme sur celle des réponses, avant et après chaque modification.
RAG, fine-tuning et contexte long
| Approche | Ce qu'elle change | À utiliser pour |
|---|---|---|
| RAG | Ce que le modèle peut voir quand il répond | Des connaissances qui évoluent, sont volumineuses ou exigent des citations |
| Fine-tuning | Le comportement du modèle, par un entraînement supplémentaire | Un style, un format ou une tâche constants, pas des faits qui changent |
| Contexte long | La quantité que le modèle lit en une requête | Quelques documents à la fois, comme un contrat ou un rapport |
Ces approches se combinent bien : un modèle peut être ajusté pour un format, utiliser la RAG pour les connaissances et lire un document entier quand il est joint.
Où les entreprises utilisent la RAG
- Politiques internes et RH : des réponses sur les congés, les notes de frais ou les règles de sécurité, avec un lien vers la politique.
- Support client : des réponses rédigées à partir de la base de connaissances et des tickets passés, qu'une personne envoie.
- Juridique et conformité : des recherches dans les contrats, les clauses et la réglementation, chaque passage étant cité.
- Documentation technique : des réponses pour les ingénieurs et les équipes de terrain à partir des manuels et des spécifications.
- Ventes : des informations produit et des textes de propositions passées, pour une opportunité précise.
Sources
- Lewis et al. : Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020
- Anthropic : Introducing Contextual Retrieval, 19 septembre 2024
- Microsoft : Hybrid search in Azure AI Search
- AWS : What is retrieval-augmented generation?
- Liu et al. : Lost in the Middle: How Language Models Use Long Contexts