ENTRY TYPE · definition

Retrieval-augmented generation (RAG)

By Marius Bughiu Last updated 2026-07-27 RevOpsLegal OpsRecruiting & TACustomer Success

Le retrieval-augmented generation (RAG) est le schéma dans lequel un outil AI cherche dans un ensemble de documents avant de répondre, puis rédige sa réponse à partir des passages trouvés plutôt qu’à partir de ce que le modèle a absorbé pendant son entraînement. Une question arrive, une étape de recherche remonte une poignée de passages qu’elle juge pertinents, ces passages sont collés dans le prompt du modèle, et le modèle répond dessus. Cela compte pour un acheteur parce que le RAG est la mécanique derrière presque toute affirmation d’éditeur sur le fait d’être « sourcé », de « citer ses sources » ou d’être « entraîné sur vos données » — et laquelle de ces trois l’éditeur veut réellement dire change ce que vous devez tester avant de signer.

Le RAG n’est pas de l’entraînement. Vos documents n’entrent jamais dans les poids du modèle ; ils sont lus au moment de la question puis abandonnés. Un éditeur qui dit « le modèle apprend vos contrats » décrit soit le RAG de façon approximative, soit fait quelque chose qui mérite une question directe sur l’endroit où vos données finissent. Le RAG ne corrige pas non plus les hallucinations, et ce n’est pas du tout une propriété du modèle — c’est un pipeline enroulé autour d’un modèle qui reste par ailleurs inchangé. Deux produits qui font tourner le même modèle se comportent de manière complètement différente selon la qualité avec laquelle ce pipeline trouve les choses.

Les deux moitiés, et une seule figure dans la démo

Tout système RAG a une moitié de recherche — indexer le corpus, le découper en chunks, chercher, classer ce qui remonte — et une moitié de génération, où le modèle rédige à partir de ce que la première moitié lui a remis.

Les démos d’éditeurs sollicitent la moitié génération. C’est la partie qui impressionne, et ce n’est pas là que les erreurs commencent. Quand l’étape de recherche rate, le modèle ne sait pas qu’elle a raté : il rédige une réponse fluide et bien citée à partir des trois mauvais passages, et ne signale aucun problème. Le modèle ne peut pas vous dire que le passage dont il avait besoin ne lui a jamais été remis. Ce seul fait devrait refaçonner votre manière de mener un pilote, car il signifie que tester la qualité des réponses sur des questions que l’outil traite bien ne vous apprend presque rien.

« Sourcé » est une affirmation sur la plomberie, pas sur l’exactitude

Les preuves publiques les plus solides viennent du droit, là où les affirmations étaient les plus bruyantes et où quelqu’un a mesuré. Le RegLab de Stanford a mené une évaluation préenregistrée des outils de recherche juridique fondés sur le RAG vendus par LexisNexis et Thomson Reuters — Lexis+ AI, Westlaw AI-Assisted Research et Ask Practical Law AI — et a constaté qu’ils hallucinent entre 17 % et 33 % du temps. LexisNexis avait vanté des citations liées « sans hallucination » ; Thomson Reuters affirmait que ses outils évitaient les hallucinations en s’appuyant sur du contenu de confiance. Les deux affirmations étaient exagérées. La lecture honnête n’est pas que le RAG a échoué : ces outils ont bel et bien battu un GPT-4 généraliste sur les mêmes questions. La lecture est que la recherche sur un corpus curé fait baisser le taux d’erreur sans jamais l’amener à zéro, donc « sourcé » décrit une architecture, pas une garantie.

Deux formes de défaillance en découlent, et elles ne sont pas également dangereuses. L’une est une réponse franchement fausse, qu’un expert du domaine intercepte. L’autre est une réponse mal sourcée — le fond est faux mais une vraie citation y est accrochée, pointant vers un vrai document qui ne dit pas ce que la réponse affirme. Celle-là survit à la relecture, parce que la citation est exactement le signal qu’un relecteur pressé utilise pour décider que la réponse a déjà été vérifiée.

Questions de diagnostic à poser à un éditeur

Elles sont ordonnées de sorte que les deux premières fassent l’essentiel du travail.

Montrez-moi une question que l’outil rate, et dites-moi si la cause est la recherche ou la génération. Un éditeur qui n’a jamais caractérisé ses propres échecs de recherche n’a pas évalué le système, seulement la démo.
Une citation pointe-t-elle vers un passage ou vers un document ? Les citations au niveau du document sont invérifiables à volume réel — personne ne lit un MSA de 60 pages pour confirmer une phrase. La citation au niveau du passage ou de la clause est ce qui rend la relecture assez peu coûteuse pour avoir vraiment lieu.
Que fait-il quand la réponse n’est pas dans le corpus ? Les deux comportements sont « je n’ai pas cela » et un repli silencieux sur les connaissances générales du modèle de base. C’est par le second qu’entrent les âneries assurées, et il figure rarement sur une page de tarifs.
Les permissions sont-elles appliquées à la recherche ou après la génération ? La bonne réponse est à la recherche : le modèle ne voit que des documents que l’utilisateur qui pose la question a déjà le droit de consulter. Glean a bâti son indexation autour d’une recherche filtrée par permissions exactement pour cela. Filtrer la réponse après que le modèle a lu un document restreint n’est pas du contrôle d’accès, c’est du caviardage qui fuit.
Combien de temps après la modification d’un document la nouvelle version devient-elle celle qui répond ? Quelques minutes, chaque heure ou chaque nuit sont toutes défendables. Ne pas le savoir, non.
Puis-je voir ce qui a été récupéré, et pas seulement ce qui a été rédigé ? Sans ce panneau, vous ne pouvez pas déboguer une mauvaise réponse, et leur support non plus.

Une fenêtre de contexte plus grande rend-elle le RAG inutile ?

Non, et les éditeurs qui vendent des fenêtres de contexte d’un million de tokens ne l’affirment pas. Trois choses maintiennent la recherche dans l’architecture : un corpus de dizaines de milliers de documents ne tient dans aucune fenêtre de contexte du marché ; le coût d’entrée croît avec les tokens, donc pousser une base de connaissances entière dans le modèle à chaque question se facture à la question ; et un corpus qui change toutes les heures coûte moins cher à réindexer qu’à renvoyer.

Ce qui a changé d’ici 2026, c’est le dosage. Le schéma qui fonctionne est récupérer puis raisonner — tirer une tranche généreuse de matériau pertinent plutôt que les trois chunks les plus serrés possibles, et laisser un modèle à long contexte travailler sur l’ensemble. Cela détend l’exigence de précision sur l’étape de recherche sans la supprimer. Traitez tout argumentaire bâti sur « notre fenêtre de contexte est si grande que nous n’avons pas besoin de recherche » comme une affirmation sur la taille de votre corpus qu’ils n’ont pas menée à son terme.

Pièges courants

Mener le pilote sur le corpus de l’éditeur. Une démo réglée pendant des mois sur un jeu de documents d’exemple vous dit à quel point leur exemple est bon.

Garde-fou : Fournissez vos propres documents et rédigez 30 à 50 vraies questions avant la première démo. Incluez-en 5 dont les réponses sont délibérément absentes du corpus, et notez le comportement de refus sur celles-là comme un point réussi/échoué à part entière.

Lire une citation comme une vérification. La citation est précisément ce qui fait qu’une réponse mal sourcée a l’air relue.

Garde-fou : Pendant le pilote, ouvrez le passage cité sur un échantillon fixe — 20 réponses par semaine suffisent — et suivez le taux de réponses mal sourcées séparément du taux de réponses fausses. Un outil à 5 % de fausses et 15 % de mal sourcées est pire pour votre équipe qu’un outil à 15 % de fausses et 2 % de mal sourcées.

Supposer que les permissions suivent depuis les systèmes source. L’indexation par connecteurs copie du contenu ; savoir si elle a aussi copié la liste de contrôle d’accès est une question distincte, avec une réponse distincte par connecteur.

Garde-fou : Pendant le pilote, lancez les trois mêmes requêtes sensibles en tant que deux utilisateurs de niveaux de permission différents et comparez les résultats. Faites-le par connecteur, pas une seule fois pour le produit.

Laisser le corpus pourrir après la mise en production. La qualité de recherche se dégrade à mesure que s’accumulent politiques périmées, contrats expirés et vieux playbooks, car l’étape de recherche n’a aucun moyen de savoir quelle version fait foi.

Garde-fou : Nommez un responsable du corpus avant le lancement et donnez-lui un mandat de suppression, pas seulement d’ajout. Retestez chaque trimestre avec un document modifié le matin même et un document qui aurait dû être retiré.