Le RAG sans le battage :quand ça marche vraiment

Presque toutes les démos de RAG que nous avons vues ces deux dernières années ont l’air magiques, et presque tous les systèmes RAG en production qu’on nous a demandé de réparer ces douze derniers mois avaient les mêmes problèmes. L’écart entre la démo et la production ne tient pas au modèle : il tient à tout ce qu’il y a autour.

Quand nous livrons un système de génération augmentée par récupération, la première chose que nous construisons, c’est le banc d’évaluation. Pas le prompt. Pas le pipeline d’embeddings. Le banc d’évaluation : en général 200 à 2 000 exemples de référence qui couvrent les questions auxquelles le système doit répondre, avec les réponses dont nous savons qu’elles sont justes.

Sans ce banc, chaque modification du système est un pari. Avec lui, chaque modification se mesure. Six mois plus tard, quand le modèle est mis à jour, vous savez en un clic si la mise à jour a amélioré ou dégradé les choses.

La deuxième chose que nous construisons, c’est la recherche hybride. BM25 trouve ce que la recherche vectorielle rate. Le reclassement (re-ranking) rattrape ce que la recherche hybride laisse passer. La réécriture des requêtes compense les questions mal formulées. Chacune de ces couches apporte un gain de rappel mesurable, et il faut savoir laquelle fait réellement le travail.

La troisième, et c’est l’étape que la plupart des équipes sautent, c’est l’observabilité. Chaque recherche, chaque prompt, chaque réponse est journalisé avec l’identifiant de trace qui le relie à la question d’origine de l’utilisateur. Le jour où quelque chose déraille, dans six mois, vous voulez pouvoir répondre à « pourquoi a-t-il répondu ça ? » en moins d’une minute.

Le RAG est l’une des choses les plus utiles que l’on puisse construire aujourd’hui. C’est aussi l’une des plus faciles à montrer en démo et des plus difficiles à maintenir en vie en production. Ne faites pas l’impasse sur les parties ingrates.