RAG : la seule architecture qui tienne en entreprise

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, qu'on appelle RAG, 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.

Le point que je vois le plus souvent inversé, et qui coûte le plus cher à corriger : le filtrage des droits se fait avant la recherche, jamais après.

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.

Je ne vends pas le RAG comme une solution universelle, et il faut être clair sur ses 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é.

L'architecture décrite ici a peu bougé. Ce qui a changé, c'est ce qu'on met autour : l'évaluation continue, la journalisation, la supervision humaine explicite.

Autrement dit, 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 souvent la moitié des échecs de récupération, pour une journée de travail. 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.

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.