Qu'est-ce que le RAG ? La génération augmentée par recherche expliquée aux entreprises

La génération augmentée par recherche, universellement abrégée en RAG, est le schéma le plus déployé de l'intelligence artificielle en entreprise. Presque tout système qui répond à des questions sur les documents, les politiques, les produits ou les dossiers d'une organisation en utilise une variante.

L'idée est simple, et bien la comprendre fait la différence entre un système auquel les gens font confiance et un système qu'ils abandonnent discrètement.

Le problème que le RAG résout :

Un modèle de langage ne connaît que ce qui figurait dans ses données d'entraînement, lesquelles se sont arrêtées à une date fixe et n'ont jamais inclus vos documents internes. Interrogez-le sur votre politique de remboursement et il produira quelque chose qui ressemble à une politique de remboursement, inventé à partir de régularités plutôt que tiré de votre politique réelle.

Vous pourriez réentraîner le modèle sur vos documents, mais c'est coûteux, lent, à recommencer à chaque changement, et cela n'offre toujours aucune garantie que le modèle restituera le texte fidèlement.

Le RAG emprunte une autre voie. Au lieu d'enseigner vos informations au modèle, vous retrouvez les passages pertinents au moment où la question est posée et vous les placez directement dans son contexte. Le modèle répond alors à partir d'un texte qu'il voit réellement, et non de régularités à moitié mémorisées. Cela transforme un problème de mémoire en un problème de compréhension de texte, ce dans quoi ces modèles excellent véritablement.

Comment fonctionne la recherche :

Le système comporte deux phases : la préparation, faite une fois et mise à jour quand le contenu change, et la recherche, faite à chaque question.

À la préparation, les documents sont découpés en fragments de quelques centaines de mots. Chaque fragment passe par un modèle d'embedding, qui convertit le texte en une liste de nombres, un vecteur, positionné de telle sorte que les passages de sens proche se retrouvent voisins. Ces vecteurs sont stockés dans une base conçue pour trouver rapidement les plus proches voisins.

Au moment de la question, celle-ci est encodée de la même façon. Le système trouve les fragments les plus proches, retient les meilleurs et construit une invite : voici la question, voici les passages pertinents, réponds uniquement à partir de ce matériau et dis-le si la réponse n'y figure pas.

Parce qu'on compare du sens et non des mots-clés, une question sur les « congés » peut faire remonter une politique qui ne parle jamais que de « repos annuel ».

Pourquoi la recherche hybride l'emporte en général :

La recherche purement sémantique a une faiblesse prévisible : les identifiants exacts. Codes produits, numéros d'erreur, références de facture et noms de famille sont précisément là où l'appariement par le sens peine, car le vecteur de « SKU-88421 » ne porte guère de signal sémantique.

Les systèmes de production font donc tourner à la fois une recherche sémantique et une recherche classique par mots-clés, puis fusionnent les résultats. La recherche par mots-clés capte les termes exacts ; la recherche sémantique attrape les paraphrases. Leur combinaison surpasse systématiquement chacune prise isolément, et les cas d'échec qu'elles couvrent sont largement complémentaires.

Une seconde étape, le reclassement, améliore encore les résultats. Une recherche peu coûteuse ramène par exemple cinquante fragments candidats, puis un modèle plus lent et plus précis note ces cinquante fragments sur leur pertinence réelle et n'en garde que cinq. Cette approche en deux temps est bien plus exacte que d'en récupérer cinq directement, et coûte peu, car le modèle onéreux ne voit jamais qu'une liste restreinte.

Le découpage décide de plus de choses qu'on ne le croit :

La manière de découper les documents a un effet démesuré sur la qualité, et c'est là que la plupart des systèmes décevants se trompent.

Des fragments trop petits perdent le contexte : un passage disant « ceci ne s'applique pas aux prestataires » devient dangereux séparé de ce à quoi « ceci » renvoie. Des fragments trop grands diluent le sens : l'embedding représente alors une moyenne floue de plusieurs sujets et ne correspond précisément à rien.

Découper selon la structure, par section et par titre plutôt que par un nombre fixe de caractères, fonctionne bien mieux qu'une division mécanique. Un léger chevauchement des fragments évite que des réponses tombent entre deux frontières. Attacher des métadonnées, titre du document, intitulé de section, date et source, permet de filtrer par fraîcheur ou par service et, surtout, de citer d'où vient une réponse.

Les citations ne sont pas facultatives :

La décision de conception la plus importante dans un système RAG est d'exiger du modèle qu'il cite quel passage retrouvé étaye chaque affirmation, avec un lien vers le document source.

Les citations font trois choses à la fois. Elles permettent aux utilisateurs de vérifier les réponses au lieu de leur faire confiance, ce qui rend le système utilisable pour tout ce qui porte à conséquence. Elles rendent l'hallucination visible, puisqu'une affirmation non étayée n'a pas de citation. Et elles transforment l'outil d'oracle en assistant de recherche, une position bien plus défendable.

Les systèmes qui répondent avec assurance sans source traçable sont ceux qui perdent la confiance des utilisateurs après la première erreur sérieuse.

Où les systèmes RAG échouent :

L'échec le plus fréquent ne vient pas du modèle du tout. Il vient de la recherche. Si le bon passage n'a jamais été récupéré, aucun modèle ne peut produire une réponse correcte. Quand un système RAG déçoit, examinez les fragments retrouvés avant d'accuser le modèle ; la faute est généralement là.

Le deuxième échec est le contenu périmé. Si les documents sous-jacents se contredisent parce que des versions obsolètes n'ont jamais été retirées, le système présentera avec assurance une politique dépassée. Le RAG hérite exactement de la qualité du matériau source.

Le troisième concerne les questions exigeant une synthèse à travers de nombreux documents. La recherche trouve des passages semblables à une question, ce qui marche bien pour « quelle est notre politique sur X » et mal pour « résume toutes les réclamations de ce trimestre et dégage des tendances ». C'est un problème d'analyse déguisé en interface de discussion.

RAG, affinage ou contexte plus long :

On les présente souvent comme concurrents. Ils résolvent des problèmes différents.

Le RAG fournit de la connaissance : faits, documents, information actuelle. L'affinage façonne le comportement : ton, format, vocabulaire métier, structure constante. Si le reproche est que le modèle ignore quelque chose, c'est du RAG. S'il sait mais répond dans le mauvais style, c'est de l'affinage.

Les très grandes fenêtres de contexte ont conduit certains à suggérer de tout coller dedans. Pour un ensemble modéré de documents, c'est aujourd'hui réellement viable et beaucoup plus simple. Mais cela coûte plus cher par requête, ralentit à mesure que le contenu grossit, et les modèles prêtent encore une attention inégale au matériau enfoui au milieu de très longues entrées. La recherche reste le choix pratique à grande échelle, et les deux se combinent bien : rechercher largement, puis laisser une grande fenêtre contenir davantage de ce qu'on a trouvé.

En construire un qui fonctionne :

Commencez étroit. Un système couvrant un corpus bien tenu pour un groupe d'utilisateurs clairement défini réussira là où une tentative de tout indexer d'un coup échouera.

Mesurez la recherche séparément de la génération, à partir d'un jeu fixe de vraies questions dont on connaît les bonnes sources. L'essentiel des progrès vient d'un meilleur découpage, de la recherche hybride et du reclassement, plutôt que d'un changement de modèle.

Surtout, gardez la source de vérité propre. Le RAG ne répare pas un fonds documentaire en désordre. Il l'expose.