RAG : la seule architecture qui tienne en entreprise

Le RAG, ou récupération documentaire, consiste à aller chercher dans le corpus de l’entreprise les passages utiles au moment de chaque question, puis à les fournir au modèle pour qu’il réponde à partir d’eux. Le sigle vient de l’anglais retrieval-augmented generation, génération augmentée par récupération.

Pendant toute l’année, la même question m’a été posée dans presque chaque cadrage : faut-il entraîner un modèle sur nos données, ou aller chercher les documents au moment de la question.

La deuxième approche, la récupération documentaire, a gagné. Pas parce qu’elle donne les meilleures réponses dans l’absolu, mais parce qu’elle est la seule qui survive aux contraintes réelles d’une organisation : des documents qui changent, des droits d’accès qui existent, des réponses qui doivent être vérifiables, et des modèles qui seront remplacés.

L’alternative, l’affinage (fine-tuning), consiste à poursuivre l’entraînement d’un modèle sur des exemples propres à l’organisation. Elle modifie le comportement du modèle ; elle ne lui donne pas un accès fiable et à jour aux documents. La confusion entre les deux est à l’origine de nombreux cadrages ratés. Le point de départ technique, la taille limitée de la fenêtre de contexte, est expliqué dans pourquoi une fenêtre de 8 000 jetons impose la récupération.

Le choix entre RAG et affinage se fait selon ce qu’on veut changer : le RAG apporte des connaissances à jour et traçables, l’affinage modifie un style, un format ou un comportement. Les deux ne répondent pas au même besoin, et la plupart des projets documentaires relèvent du premier.

Un exemple générique : un service juridique qui veut interroger ses contrats relève du RAG ; une équipe qui veut que le modèle produise toujours une fiche de synthèse au même format peut envisager l’affinage, ou plus simplement une consigne bien écrite. Avant tout entraînement, il faut aussi vérifier ce qu’on a le droit de mettre dans un prompt, car la même question de confidentialité se pose pour les données d’entraînement.

Dans une chaîne RAG, le filtrage des droits d’accès se fait avant la recherche, jamais après, sans quoi le système lit des documents interdits avant de masquer le résultat. C’est le point que je vois le plus souvent inversé, et qui coûte le plus cher à corriger.

Filtrer après revient à laisser le système lire des documents auxquels l’utilisateur n’a pas accès, puis à masquer le résultat. La fuite s’est déjà produite : dans les journaux, dans le cache, parfois dans le raisonnement affiché. Filtrer avant coûte un peu de performance et supprime la catégorie entière du problème.

Une chaîne RAG qui tient en production se construit dans un ordre précis : corpus, découpage, droits, recherche, consigne, refus, évaluation, journalisation. Inverser cet ordre produit les erreurs les plus coûteuses à corriger.

1. Qualifier le corpus : quels documents font autorité, lesquels sont périmés, qui en décide.
2. Découper chaque type de document selon sa structure, en rattachant titre, date et statut à chaque passage, comme détaillé dans découper un document.
3. Indexer avec les droits d’accès de chaque document, sous une forme exploitable par la machine.
4. Rechercher uniquement dans le périmètre autorisé de l’utilisateur qui pose la question.
5. Fournir peu d’extraits, ceux qui sont les plus pertinents, avec l’instruction de répondre à partir d’eux et de citer leur origine.
6. Autoriser explicitement le refus quand les extraits ne suffisent pas.
7. Constituer un jeu de tests de questions réelles avec leurs réponses attendues, et le rejouer à chaque modification.
8. Journaliser la question, les extraits fournis et la réponse.

Les étapes 1 et 3 ne sont pas techniques : elles demandent des décisions de la part des métiers. C’est pourquoi un audit IA préalable porte d’abord sur l’état du corpus et des droits.

Le RAG ne traite bien ni les questions de synthèse sur tout le corpus, ni les corpus contradictoires, et il ne dispense jamais d’une évaluation régulière. Je ne le vends pas comme une solution universelle, et il faut être clair sur ces limites.

Il ne répond pas bien aux questions qui demandent une synthèse sur l’ensemble du corpus, « quelle est notre position générale sur tel sujet », parce qu’il ne lit que quelques extraits. Il ne compense pas un corpus mal tenu : si trois notes se contredisent, il citera l’une des trois, avec aplomb. Et il ne dispense pas d’évaluation : sans jeu de tests, on ne sait pas qu’il s’est dégradé.

La couche d’accès au modèle a aussi son importance : une chaîne bien conçue isole le modèle derrière une interface qui permet d’en changer, ce que décrit la couche qui rend le modèle remplaçable.

Journaliser les extraits fournis au modèle, et pas seulement la question et la réponse, est ce qui rend une chaîne de récupération réparable. Sans cette trace, chaque incident produit une enquête sans conclusion.

La raison est simple. Devant une réponse fausse, la seule question utile est : l’information correcte figurait-elle dans ce qui a été fourni ? Si oui, le problème est dans le prompt ou le modèle. Si non, il est dans la recherche ou le corpus. Ce sont deux corrections opposées.

Sans le journal des extraits, cette distinction est impossible et l’équipe modifie le prompt par défaut, ce qui installe le cycle où l’on corrige un cas en en cassant deux autres.

Cinq champs suffisent : la question, les extraits fournis, la réponse, la décision humaine et l’horodatage. C’est aussi la trace exigée par ailleurs en conformité, ce qui permet de traiter les deux besoins d’un coup, comme le montre ce qui doit exister avant l’échéance.

L’architecture RAG a peu bougé depuis ; ce qui a changé, c’est ce qu’on met autour : l’évaluation continue, la journalisation, la supervision humaine explicite. Le sujet s’est déplacé de l’architecture vers l’exploitation.

C’est une bonne nouvelle : cela veut dire que la question technique est réglée, et que la difficulté est redevenue une question d’organisation.

Les fenêtres ont été multipliées par cent et la récupération reste nécessaire, pour une raison qui n’est pas technique mais économique. Le débat a été rouvert à chaque annonce et il s’est refermé de la même façon.

Un corpus d’entreprise dépasse toujours la fenêtre, quelle que soit sa taille. Et surtout, ce qui est envoyé est facturé : remplir une très grande fenêtre à chaque requête coûte plusieurs centaines de fois une requête ciblée, pour une réponse souvent moins précise.

Ce calcul est détaillé dans une grande fenêtre reste une facture. Il n’a pas bougé depuis.

Ajouter un index lexical à côté de l’index vectoriel corrige une part importante des échecs de récupération sur les corpus riches en références exactes, pour un effort limité. C’est le chantier que je recommande en premier sur toute chaîne existante.

La recherche par le sens échoue systématiquement sur les références exactes : numéros d’article, codes produit, identifiants de dossier. Elle remonte un passage voisin, plausible et faux.

La recherche par mots-clés attrape ces cas et rate les reformulations, que la recherche vectorielle traite bien. Les deux angles morts sont complémentaires, ce qui rend la combinaison évidente une fois qu’on l’a vue, comme détaillé dans recherche hybride. L’ampleur du gain dépend du corpus ; elle se mesure sur le jeu de tests, avant et après.