RAG : comment faire répondre une IA sur vos propres documents

Un modèle de langage ne connaît pas votre entreprise. Il n'a jamais lu vos procédures, vos contrats types, ni les comptes rendus de vos six derniers comités. La réponse la plus répandue à ce problème s'appelle le RAG, pour retrieval augmented generation : plutôt que de réentraîner un modèle sur vos documents, on va chercher les bons extraits au moment de la question et on les lui donne à lire avant qu'il réponde.

Le principe se résume en une image : vous ne demandez pas à un consultant d'apprendre par cœur vos classeurs, vous lui posez une question en lui tendant les trois pages qui contiennent la réponse. Tout l'enjeu du RAG en intelligence artificielle tient dans la qualité de ces trois pages, et pas dans le choix de la technologie qui les stocke.

C'est le contresens le plus fréquent sur ces projets. On y passe des semaines à comparer des bases vectorielles, alors que l'immense majorité des échecs vient de documents mal découpés, mal tenus, ou contradictoires entre eux. Suivons donc le chemin d'une question, du début à la fin, et regardons où il casse réellement.

Le RAG en intelligence artificielle : le chemin d'une question

Un système RAG fonctionne en deux temps. Un temps de préparation, exécuté à l'avance et rejoué quand les documents changent. Un temps de réponse, exécuté à chaque question, en une à trois secondes.

La préparation. On rassemble les documents, on les convertit en texte, on les découpe en morceaux de taille homogène, puis on calcule pour chaque morceau une représentation numérique, appelée vecteur, qui capture son sens. Ces vecteurs sont rangés dans un index avec, à côté, le texte d'origine et sa provenance.

La réponse. La question de l'utilisateur est transformée en vecteur par le même procédé. On cherche dans l'index les morceaux dont le vecteur est le plus proche, on en retient quelques-uns, on les colle dans une instruction du type « réponds à cette question en t'appuyant uniquement sur les extraits ci-dessous, et cite tes sources », et on envoie le tout au modèle.

Rien d'autre. La partie qui impressionne, la formulation de la réponse, est aussi celle qui pose le moins de problèmes : les modèles savent reformuler. Ce qu'ils ne savent pas faire, c'est deviner ce que vous ne leur avez pas donné, comme nous l'expliquions à propos du fonctionnement d'un modèle de langage.

Le découpage, là où tout se joue

Le découpage, ou chunking, consiste à transformer un document de quarante pages en morceaux exploitables. C'est l'opération la plus déterminante et la plus sous-estimée de la chaîne.

Un découpage aveugle tous les mille caractères produit des morceaux qui commencent au milieu d'une phrase et se terminent avant la conclusion. Le morceau contenant « ce délai est porté à quinze jours » perd la phrase précédente qui disait de quel délai il s'agit. Le système retrouvera l'extrait, et le modèle donnera une réponse fausse avec une source correcte : le pire des deux mondes, puisqu'elle est vérifiable en apparence.

Quatre règles évitent l'essentiel des dégâts :

• Découper sur la structure, pas sur le nombre de caractères : un titre, une section, un article de contrat, une question de FAQ.
• Répéter le contexte dans chaque morceau : nom du document, chapitre, date de version, en tête d'extrait. Cela coûte quelques dizaines de mots et sauve des dizaines de réponses.
• Prévoir un recouvrement de dix à quinze pour cent entre morceaux consécutifs, pour ne pas couper une idée en deux.
• Traiter les tableaux à part. Un tableau converti en texte brut devient illisible ; mieux vaut le transformer en phrases ou le décrire, quitte à le faire une fois pour toutes.

Ordre de grandeur utile : sur des documents rédigés en français, des morceaux de 300 à 800 mots donnent de bons résultats. En dessous, le contexte manque. Au-dessus, la recherche devient imprécise parce qu'un long morceau parle de trop de choses à la fois.

La recherche : vectoriel, mots-clés, et pourquoi il faut les deux

La recherche vectorielle excelle sur le sens : elle retrouve « congé pour événement familial » quand l'utilisateur écrit « absence pour un décès ». Elle est en revanche médiocre sur l'exact : les références de produit, les numéros d'article, les acronymes internes, les noms propres rares. Sur ces termes, une recherche par mots-clés classique reste très supérieure.

D'où une recommandation qui règle beaucoup de déceptions : combinez les deux. On lance les deux recherches, on fusionne les résultats, et on garde les meilleurs des deux listes. Cette approche hybride est souvent ce qui fait passer un prototype décevant à un outil que les équipes utilisent vraiment.

Deux réglages comptent ensuite. Le nombre d'extraits retenus, d'abord : trois à cinq suffisent presque toujours, et en empiler vingt dégrade la réponse autant que le coût. Un seuil de pertinence, ensuite : si aucun extrait ne dépasse un score minimal, le système doit répondre qu'il n'a pas trouvé, pas improviser.

La réponse sourcée, et le refus de répondre

L'instruction envoyée au modèle fait le reste du travail. Trois consignes y sont indispensables : s'appuyer uniquement sur les extraits fournis, citer pour chaque affirmation le document et la section d'origine, et déclarer explicitement quand l'information ne figure pas dans les extraits.

Cette troisième consigne est celle que l'on oublie et celle qui compte le plus. Un système documentaire qui répond « cette information ne figure pas dans les documents que je consulte » est utilisable. Un système qui comble les trous ne l'est pas, quel que soit son taux de réussite par ailleurs. Le RAG réduit fortement les inventions, il ne les supprime pas : les mécanismes en jeu sont détaillés dans notre article sur la façon de limiter les hallucinations d'une IA générative.

Côté interface, affichez les sources en clair, cliquables, avec le passage exact. Les utilisateurs ne vérifient pas systématiquement, mais la simple présence du lien change leur rapport à l'outil : ils savent qu'ils peuvent vérifier, donc ils font confiance de façon raisonnée.

Ce qui rate vraiment en production

Après le prototype, trois problèmes reviennent avec une régularité de métronome, et aucun n'est technique.

1. La base documentaire est sale. Trois versions de la même procédure, dont deux périmées, et le système cite la mauvaise. Aucun réglage ne corrige cela. Il faut désigner un propriétaire par document et supprimer les doublons avant l'indexation.
2. Les droits ne sont pas gérés. Un index unique expose à tous ce qui n'était visible que par quelques-uns. Les autorisations doivent être portées par chaque morceau et filtrées au moment de la recherche, jamais après coup dans la réponse.
3. L'index vieillit en silence. Un document mis à jour et non réindexé produit une réponse fausse avec une source valide. Prévoyez une réindexation déclenchée par la modification, et un indicateur visible de la date de dernière mise à jour.

Ajoutons un ordre de grandeur de coût, souvent surestimé. Pour une base de dix mille pages, le calcul initial des vecteurs se compte en quelques euros, la mise à jour incrémentale en centimes. Le coût réel d'un projet RAG se situe dans le nettoyage documentaire et dans l'interface, pas dans le calcul.

Par où démarrer

Choisissez un corpus étroit, bien tenu, avec un propriétaire identifié : une base de connaissances support, un manuel produit, un référentiel de procédures. Réunissez trente questions réelles posées par de vrais utilisateurs, avec la réponse attendue. Construisez la chaîne la plus simple possible et mesurez : combien de bonnes réponses, combien de réponses fausses, combien de « je ne sais pas ». Ce jeu de trente questions vaut plus que n'importe quel comparatif d'outils, parce qu'il vous dira, lui, si votre RAG progresse.

Si les résultats plafonnent malgré un corpus propre, la question suivante est de savoir si le problème relève de la connaissance ou du comportement du modèle. C'est exactement l'arbitrage que nous examinons dans notre comparatif fine tuning ou RAG.