Pourquoi la plupart des démos RAG cassent en production

Beaucoup de démos fonctionnent parce que les données sont petites, propres et préparées à la main. En entreprise, les données sont souvent l'inverse : documents bruités, mise en page cassée, versions contradictoires, métadonnées manquantes et règles d'accès différentes selon les équipes. Le but n'est pas “le système répond une fois”. Le but est d'obtenir des réponses régulières, explicables et contrôlables sous contraintes de latence, de coût et de gouvernance.

Architecture de référence

Un RAG de production demande plus qu'une base vectorielle et un prompt. Mon architecture de base contient six couches :

• Registre des sources — quelles sources sont autorisées, qui les possède, à quelle fréquence elles sont rafraîchies.
• Pipeline d'ingestion — parsing, OCR si nécessaire, normalisation des métadonnées et exports versionnés.
• Stratégie de chunking — frontières adaptées au type de document, pas un seul nombre magique partout.
• Retrieval — recherche hybride, reranking, filtres et contexte récupéré traçable.
• Couche réponse — prompt fondé sur les sources, règles de citation, refus et escalade.
• Boucle d'évaluation — jeux de tests offline, feedback online, traces et revue qualité régulière.

Si une couche manque, les problèmes de qualité deviennent difficiles à diagnostiquer.

Quality gates du retrieval

Avant de faire confiance à un RAG, je teste le retrieval directement. Une bonne génération ne compense pas un mauvais contexte. Les gates que je vérifie :

• Couverture des sources : les bons documents sont-ils dans le corpus ?
• Qualité des chunks : chaque chunk contient-il assez de contexte sans absorber tout le document ?
• Recall : le retriever retrouve-t-il la bonne source pour des questions connues ?
• Précision : évite-t-il de noyer le modèle avec du texte inutile ?
• Validité des citations : les sources citées soutiennent-elles vraiment la réponse ?

Ces contrôles sont souvent plus rentables que changer de modèle trop tôt. Dans beaucoup de systèmes, un meilleur chunking et un meilleur reranking font plus qu'un modèle plus gros.

Taxonomie des échecs

Quand la qualité baisse, je classe les erreurs avant de corriger :

• Source manquante : la réponse est impossible parce que le document n'existe pas dans le corpus.
• Parsing cassé : le document existe, mais les tableaux, titres ou sections sont abîmés.
• Retrieval faible : la source existe, mais la requête ne la retrouve pas.
• Synthèse incorrecte : le contexte est bon, mais le modèle interprète mal ou généralise trop.
• Politique de réponse mauvaise : le système répond alors qu'il devrait refuser, ou refuse alors qu'il devrait répondre.

Cette taxonomie évite de réécrire des prompts pour des problèmes d'ingestion.

Séquence de mise en production

Ma séquence de rollout est volontairement prudente :

• Construire un jeu d'évaluation à partir de vraies questions utilisateurs.
• Valider ingestion et retrieval avant la génération.
• Ajouter le format de réponse et les exigences de citation.
• Lancer des évaluations offline et relire les erreurs manuellement.
• Ouvrir à un petit groupe pilote avec capture du feedback.
• Surveiller qualité, latence, coût et raisons de fallback.
• Étendre seulement quand les modes d'échec sont compris.

Un RAG gagne la confiance par une fiabilité ennuyeuse, pas par une démo spectaculaire.

Cas liés

• RAG Equity Research Agent — retrieval hybride avec reranking et orchestration multi-agent.
• DAISI – Assistant IA entreprise — RAG de production sur procédures internes avec guardrails stricts.
• OpsBot – Assistant opérationnel — assistant RAG dans Google Chat avec synchronisation de sources gouvernée et règles de réponse.