Pourquoi les POC RAG paraissent presque toujours meilleurs que le vrai produit

Un proof of concept est souvent testé sur quelques questions propres avec des reviewers patients. La production, elle, ressemble plutôt à ça :

• documents hétérogènes
• questions plus floues et plus sales
• edge cases retrieval qui apparaissent vite
• latence et coût qui deviennent visibles
• chaque mauvaise réponse qui détruit un peu la confiance

C’est là qu’un bon consultant RAG devient utile : pas pour faire marcher la première démo, mais pour faire tenir le système quand les vrais usages commencent.

Les sept checkpoints qui comptent vraiment

1. L’objectif retrieval est explicite

Il faut définir ce que veut dire “bon retrieval” avant de changer la stack. Exemples :

• recall top-k sur des jeux documentaires critiques
• taux de réponses grounded
• couverture des citations
• taux d’escalade quand le contexte manque

Sans ça, l’équipe change embeddings, chunk size et vector store à l’aveugle.

2. La stratégie de chunking colle à la réalité documentaire

Le chunking générique est souvent médiocre. Il faut décider en fonction de la source :

• longues politiques internes
• tables et procédures finance
• pages opérationnelles type FAQ
• contenus multimodaux avec captures ou schémas

C’est un des premiers points que je revois sur les projets RAG, parce qu’un mauvais chunking dégrade tout le reste.

3. La qualité retrieval est séparée de la qualité génération

Quand la réponse est mauvaise, il faut isoler la cause :

• mauvais retrieval
• retrieval absent
• prompt faible
• synthèse médiocre malgré un bon contexte récupéré

Les équipes qui ne font pas cette séparation debugguent beaucoup trop lentement.

4. Un fallback existe

Un système de prod doit savoir quand il ne doit pas répondre avec assurance. Donc il faut :

• gestion de l’incertitude
• chemin d’escalade
• refus structuré si le contexte est trop faible
• routage humain optionnel sur les flows sensibles

Un “je ne sais pas avec assez de confiance” propre vaut mieux qu’une hallucination fluide.

5. L’évaluation est répétable

Au minimum, garde un jeu de test avec :

• questions représentatives
• edge cases difficiles
• questions ambiguës
• prompts volontairement sous-spécifiés
• scénarios retrieval connus pour être mauvais

Puis mesure les régressions avant release, pas après les plaintes.

L’observabilité n’est pas optionnelle

Une fois le système live, il faut voir :

• quelles sources ont été récupérées
• comment la réponse a été produite
• quel chemin tool ou chain a été utilisé
• où se concentre la latence
• quels types de questions dégradent la qualité

C’est pour ça que j’associe toujours évaluation et observabilité. L’une te dit si la qualité a bougé ; l’autre t’aide à comprendre pourquoi. Pour des exemples concrets, voir DAISI et le RAG Equity Research Agent.

Checklist production

À vérifier avant un rollout plus large :

• Des métriques retrieval sont définies
• La stratégie de chunking est documentée
• Un jeu de test qualité existe
• Un fallback sur mauvaise réponse est implémenté
• Des checks de régression tournent avant release
• Les traces et la visibilité des sources sont activées
• Les owners incident response sont définis

S’il en manque un, le système n’est pas vraiment prêt.

Quand faire intervenir un consultant RAG

Trois moments classiques :

Le prototype répond bien mais de façon instable

Le sujet est souvent retrieval, chunking ou évaluation.

L’équipe produit veut scaler l’usage

C’est là que les mauvais fallbacks et l’absence d’observabilité commencent à coûter cher en confiance.

Le système est live mais la qualité dérive dans le temps

À ce moment-là, le besoin n’est plus “plus de prompts”. Le vrai besoin, c’est la discipline de release, le contrôle des régressions et de meilleures boucles de feedback.

Le point final

Un bon système RAG de prod, ce n’est pas juste un vector store plus un prompt. C’est une stratégie retrieval, un système d’évaluation, une politique de fallback et un vrai operating model. Si tu veux rendre ce passage proprement, commence ici :

• Service RAG
• Vue d’ensemble services
• Contact