Une carte des champs de RAG : des principes fondamentaux aux échecs en production

La génération augmentée par récupération est facile à présenter mais difficile à maîtriser correctement. Un prototype fonctionnel peut être réalisé en quarante lignes de code en une après-midi. Ensuite vient la tâche ardue de comprendre pourquoi il donne des réponses erronées trois fois sur dix, ou pourquoi un chatbot cite avec assurance une clause de contrat qui n’a jamais été écrite. Ce guide couvre ces deux aspects : il commence sans aucun jargon et se termine par les techniques qui distinguent une démonstration de week-end d’un système en qui les gens ont confiance pour gérer de l’argent.

L’idée en termes simples

Imaginez un modèle de langage comme un diplômé très cultivé qui n’a jamais vu vos fichiers. Il a absorbé une grande partie du contenu accessible sur Internet, mais rien de vos contrats de location, de vos politiques RH, de votre catalogue de produits ou des présentations du conseil d’administration du dernier trimestre.

RAG transforme un examen sans notes en un examen avec notes. Au lieu de compter sur le fait que le modèle ait mémorisé vos données, le système cherche d’abord les pages pertinentes, les lui transmet et lui demande de répondre uniquement à partir d’elles. Le nom désigne trois étapes :

• Récupérer : rechercher dans vos documents et sélectionner les quelques passages importants.
• Améliorer : intégrer ces passages dans la demande accompagnant la question.
• Générer : faire en sorte que le modèle rédige une réponse basée sur ce qui lui a été fourni.

Telle est l’idée principale. Chaque amélioration ultérieure, qu’il s’agisse de systèmes de réclassification ou de graphes, vise simplement à rendre l’une de ces trois étapes moins déficiente.

Pour les lecteurs non techniques, l’avantage réside dans la capacité d’expliquer ce que construit une équipe d’ingénierie, pourquoi elle échoue de la manière dont elle le fait et quels questions poser lors d’une démonstration fournisseur. Pour les ingénieurs, il s’agit des mécanismes, des compromis et des modes de défaillance, ce qui implique de se demander pourquoi la similarité cosinus est un substitut étrange pour la pertinence, pourquoi des blocs de 512 tokens détruisent les tableaux et pourquoi un ensemble d’évaluation compte plus que le choix du modèle. Personne ne trouve dans l’expression « utilisez simplement une base de données vectorielle » une réponse complète.

Deux pipelines, pas un

Un point structurel pose problème à presque tout le monde : un système RAG n’est pas un seul pipeline. Il s’agit de deux pipelines qui ne s’exécutent jamais en même temps.

La voie A effectue l’indexation. Elle est réalisée à l’avance, généralement en tant que tâche par lots. Les documents sont divisés en parties, chacune étant convertie en une liste de nombres représentant son sens, ces nombres étant ensuite intégrés dans un index consultable. C’est la voie la plus lente, et c’est là que se décide approximativement 80 % de la qualité de la réponse finale.

La voie B effectue les requêtes. Elle fonctionne en temps réel chaque fois qu’un utilisateur pose une question. La question est convertie en nombres par exactement la même méthode, les parties stockées les plus proches sont trouvées, elles sont insérées dans une demande et une réponse est renvoyée.

Si les deux voies ne s’accordent pas sur l’encodage, rien ne fonctionne, un peu comme classer des documents par ordre alphabétique puis les rechercher par couleur. Les gens ont tendance à se concentrer sur la Voie B, c’est-à-dire l’instruction, le modèle et la température, tandis que la plupart des problèmes se trouvent dans la Voie A. L’indexation s’exécute une seule fois, les requêtes à chaque fois, et la plupart des bugs se cachent dans l’écart entre les deux.

Les étapes, des bases à la production

Fondements

Le premier sujet concerne l’origine réelle des hallucinations, qui ne vient pas du fait que le modèle soit stupide. Parmi les idées associées figurent ce qu’est une fenêtre de contexte, pourquoi on ne peut pas simplement coller toute une base de données dedans et ce que signifie une date de fin de connaissance. Il y a aussi la question souvent mal comprise : RAG, le fine-tuning et une fenêtre de contexte plus grande sont trois outils distincts destinés à trois problèmes différents, pourtant on les recommande constamment pour remplir les fonctions des uns et des autres.

Une compagnie d’assurance dont les termes de son contrat changent chaque trimestre illustre bien la différence. Ajuster en permanence signifierait de devoir reformerater les documents à chaque trimestre. RAG, quant à lui, consiste simplement à mettre à jour un dossier.

Ingestion et segmentation

Obtenir les documents est déjà une étape complexe : des PDF qui ne sont en réalité que des images scannées, des tableaux, des en-têtes, des pieds de page, ainsi qu’un appendice de 40 pages dont personne n’a besoin. Viennent ensuite la segmentation, c’est-à-dire la décision de savoir comment diviser un document. Cela semble trivial, mais ce n’est pas le cas. Si les segments sont trop petits, on obtient des extraits du type « le dépôt doit être remboursable » sans aucune indication sur les conditions. Si les segments sont trop grands, le modèle est submergé de bruit. Les principales méthodes sont la segmentation à taille fixe, celle tenant compte des phrases et la segmentation récursive, ainsi qu’une technique d’overlap qui empêche les phrases d’être tronquées.

Prenons un bail de 60 pages dont la clause de pénalité dépend d’une définition donnée 40 pages plus tôt. Les limites de segmentation déterminent si ce lien reste intact.

Embeddings et recherche vectorielle

Cette étape semble magique, mais ce n’est pas le cas. Le texte est transformé en une liste de nombres, organisés de telle manière qu’une phrase concernant l’annulation d’une commande se trouve à proximité d’une phrase sur le retour d’un achat, et loin d’une phrase concernant la commande de plus de stock. Les concepts associés incluent les dimensions, la similarité cosinus, ainsi que le fait que la proximité dans l’espace vectoriel ne garantit pas forcément une réponse.

Vient ensuite le stockage : ce qu’une base de données vectorielle fait réellement, pourquoi la recherche par force brute échoue à grande échelle, et ce que la recherche approximative du voisin le plus proche sacrifie en termes de vitesse.

Le cycle de récupération

Ici, les éléments sont assemblés. Le choix de top-k, c’est-à-dire du nombre de fragments à récupérer, fait partie de ce processus, et plus n’est pas toujours mieux. Le filtrage des métadonnées permet à une recherche de couvrir uniquement les documents de 2024 ou uniquement la région de Mumbai. L’assemblage des prompts est également important, car la manière dont le contexte récupéré est organisé et dans quel ordre influence la réponse.

Viennent ensuite les références et les citations. Le modèle doit indiquer quelque chose comme la section 4.2 et ne pas se montrer simplement trop sûr de lui. Tout aussi essentiel est qu’il précise que la réponse n’est pas dans les documents, ce qui est probablement la fonction la moins appréciée de tout système RAG.

Évaluation

Presque tout le monde saute cette étape, ce qui explique pourquoi presque tout le monde livre des RAG défectueux. Un problème qui n’est pas mesuré ne peut pas être résolu. La qualité se divise en deux questions : le bon matériel a-t-il été récupéré, et le modèle est-il resté fidèle à celui-ci ? Chacun d’eux échoue à part entière et nécessite une correction distincte. L’outil de travail comprend un ensemble d’questions de test idéales tirées de vrais utilisateurs, une évaluation de la récupération en termes de précision et de rappel, une évaluation de la génération en fonction de sa fidélité et de sa pertinence par rapport à la question, ainsi qu’un LLM agissant en juge, en surveillant les points où cette approche échoue.

Un système a obtenu 90 % en matière de récupération et 55 % en termes de fidélité. Sa recherche était correcte, mais ses réponses étaient toujours fausses.

Mises à niveau, chacune liée à une défaillance

Récupération améliorée

La recherche hybride combine la recherche basée sur le sens avec la correspondance par mots-clés traditionnelle, car les embeddings gèrent très mal les identifiants exacts tels que les numéros de modèle et les IDs de facture. La réclassification permet de récupérer 50 candidats à moindre coût, puis laisse un modèle plus lent mais plus intelligent choisir les 5 meilleurs. La transformation de la requête réécrit une question vague en une question recherchable, divise une question composée en parties, ou utilise HyDE, qui génère une réponse idéale fictive et effectue une recherche avec celle-ci à la place de la question.

Une demande visant à comparer deux projets de Bangalore en fonction de la date de possession et du prix constitue une seule question nécessitant trois recherches distinctes.

Indexation améliorée

La correction adéquate de la voie A implique plusieurs techniques. Les recherches de type parent-enfant analysent de petits fragments précis, mais fournissent au modèle la section plus large qui les entoure. Le découpage sémantique se fait au niveau des changements de sujet et non en fonction d’un nombre arbitraire de caractères. Les résumés et les index hiérarchiques commencent par rechercher des résumés de documents avant d’approfondir l’analyse. Graph RAG stocke les relations entre les entités et pas seulement du texte, ce qui lui permet de répondre à des questions telles que quels fournisseurs sont également des clients.

Une requête de conformité en est un bon exemple : elle nécessite une règle, son amendement de 2023 ainsi qu’une note d’exemption, soit trois documents pour une seule réponse.

Comportement agent

Après ce stade, RAG n’est plus un processus fixe et commence à prendre des décisions. Le routage dirige une question vers l’index approprié, vers une base de données SQL ou ne provoque aucune recherche du tout. La recherche multi-étapes lit les données, détecte une lacune et effectue une nouvelle recherche. Self-RAG et Corrective RAG permettent au système d’évaluer lui-même le contexte récupéré et de l’éliminer s’il est irrelevant, avant de recourir à une recherche sur le web ou d’admettre honnêtement qu’il n’a pas de réponse.

Prenons l’exemple d’une question sur les raisons pour lesquelles une demande a été rejetée. Pour y répondre, il faut récupérer successivement la politique en vigueur, le dossier de la demande et le code de rejet.

Documents désordonnés

Les véritables connaissances commerciales apparaissent rarement sous forme de paragraphes bien structurés. Elles se présentent sous forme de tableurs, de scans, de plans d’ensemble, d’captures d’écran et de diagrammes. Les compétences requises incluent l’analyse tenant compte du layout, l’extraction de tableaux gérant les cellules fusionnées, l’incorporation d’images, ainsi que la recherche dans des documents où la réponse se trouve dans un graphique. Le cas typique concerne une question de tarification dont le numéro ne figure que sur une fiche tarifaire scannée.

Problématiques de production

Tout tombe en panne après la démonstration. Les budgets de latence montrent où disparaissent les millisecondes. Le coût par requête est important, tout comme le cache qui est véritablement utile. L’index doit rester à jour lorsque les documents changent toutes les heures. Le contrôle d’accès doit garantir que l’utilisateur A ne puisse pas récupérer les données de l’utilisateur B, ce qui constitue une fuite courante et réelle. Des documents corrompus peuvent injecter des instructions. La surveillance et l’enregistrement des événements révèlent quand la qualité s’est dégradée discrètement. Un système qui fonctionnait parfaitement avec 200 documents peut cesser de fonctionner avec 200 000.

Comprendre d’abord les échecs

Si un point doit être retenu, qu’il s’agisse de celui-ci : le RAG avancé n’est pas une version plus sophistiquée du RAG de base. Il s’agit d’un ensemble de correctifs, chacun destiné à un échec spécifique ayant un nom. Une fois l’échec compris, la technique de correspondance devient l’étape évidente suivante.

Trois principes garantissent l’honnêteté de cette approche :

• Aucun culte des frameworks. Les concepts précèdent les outils, et quiconque comprend la segmentation peut l’appliquer n’importe où.
• Aucun code copié-collé non expliqué. Le code n’apparaît que lorsque la raison de sa forme est claire.
• Aucune prétention à son efficacité absolue. Certains cas font du RAG la mauvaise solution, et une approche plus simple s’avère meilleure.

Les débutants devraient aborder les sujets dans l’ordre, car chacun suppose la connaissance du précédent. Ceux qui disposent déjà d’un système qui ne répond pas aux attentes peuvent passer directement à l’étape d’évaluation.

Lectures complémentaires

• Notes pratiques : Mener RAG en production : difficultés sur toute la chaîne issues de cas réels — Guide pas à pas des Notes pratiques : Mener RAG en production : difficultés sur toute la chaîne issues de cas réels : contrats, vérifications et emplacements de code prêts à l’emploi pour les équipes qui mettent en œuvre ce modèle.
• Recherche hybride dans Postgres pour un assistant de santé : schéma, segmentation, RRF et évaluations — Construction de la couche de récupération d’informations pour un assistant de santé dans Postgres : segmentation en fonction de la structure, recherche hybride pgvector avec RRF, quantification binaire, seuils et évaluations.

Pourquoi RAG échoue avec des documents réels : segmentation en chunks, recherche hybride, réclassement et évaluation — Modèles de base pour un pipeline RAG en production : conception en deux phases, choix de la segmentation, embeddings et bases de données vectorielles, recherche hybride, réclassement et évaluation de la récupération.