RAG : au-delà du prototype qui marche en démo
Pourquoi la plupart des systèmes RAG échouent en production, et ce qui distingue un pipeline robuste d'une démo convaincante.
Un système RAG (Retrieval-Augmented Generation) impressionne presque toujours en démo. On pose trois questions bien choisies, le modèle répond avec assurance, et tout le monde est convaincu. Le problème commence quand ce même système rencontre de vrais utilisateurs, avec de vraies questions imparfaites, sur un corpus qui change chaque semaine.
La première erreur est de traiter le découpage des documents (chunking) comme un détail d'implémentation. En réalité, c'est la décision qui détermine si le modèle peut répondre correctement ou non — un mauvais découpage peut séparer une clause de sa condition d'application, et aucun modèle, aussi performant soit-il, ne peut compenser une information tronquée à la source.
La deuxième erreur est de ne jamais mesurer objectivement la qualité de la récupération. Beaucoup d'équipes évaluent uniquement la réponse finale, formulée en langage naturel, sans jamais vérifier si les passages récupérés étaient réellement les bons. On optimise alors le mauvais maillon de la chaîne.
Ce qui distingue un système robuste : un pipeline d'ingestion qui respecte la structure sémantique des documents, une évaluation systématique de la précision d'ancrage avant même de regarder la qualité rédactionnelle, et une boucle de feedback qui permet de corriger le corpus — pas seulement le prompt — quand les réponses dérivent.
En résumé, RAG n'est pas un problème de modèle. C'est un problème de données, d'architecture de récupération et de mesure continue. Les équipes qui le comprennent tôt évitent des mois de itérations sur le mauvais paramètre.