RAG en production : ce qui casse vraiment (et comment l'éviter)

Un RAG de démo se monte en une journée : un vector store, un prompt, et ça répond. Un RAG en production, avec de vrais documents métier et de vrais utilisateurs, c'est une autre histoire. Voici ce qui casse en premier — vu du terrain, sur des données d'assurance où l'erreur ne pardonne pas.

1. Le découpage des documents

90% des mauvaises réponses viennent du chunking. Découper un contrat ou une notice en blocs de 500 tokens aveugles, c'est détruire le contexte : le tableau de garanties se retrouve séparé de ses conditions. La solution : découper selon la structure réelle du document (titres, articles, tableaux), garder les métadonnées (source, section, date) et injecter un en-tête de contexte dans chaque chunk.

2. La récupération, pas la génération

Quand la réponse est fausse, le réflexe est de blâmer le modèle. Dans la majorité des cas, le problème est en amont : les bons passages ne sont pas remontés. Un reranker, une recherche hybride (vecteurs + mots-clés) et des filtres par métadonnées changent la donne bien plus qu'un meilleur prompt.

3. L'évaluation, sinon rien

Sans jeu d'évaluation, chaque « amélioration » est un pari. Le minimum viable : 50 à 100 questions réelles avec les réponses attendues, rejouées à chaque changement (chunking, modèle, prompt). C'est ce qui permet de dire « cette version est meilleure » avec autre chose que de l'intuition — et de dormir la nuit après une mise en prod.

4. Les garde-fous

En production, il faut prévoir le refus : si les sources récupérées sont faibles, le système doit dire « je ne sais pas » et router vers un humain, plutôt qu'halluciner une garantie qui n'existe pas. Fallback, logs de chaque réponse avec ses sources, et revue régulière des cas refusés : c'est là que se joue la fiabilité, pas dans le choix du modèle.