RAG en production : chunking, qualité du retrieval et les problèmes que la démo ne montre pas

Le vrai problème n'apparaît jamais pendant la démo

Une démo RAG donne souvent une impression trompeuse. Les documents ont été choisis, le corpus est propre, les questions sont connues d'avance. En production, les utilisateurs arrivent avec des formulations bancales, des droits d'accès à respecter, et des attentes très simples : si la réponse est mauvaise, le système a tort.

C'est pour cela que je ne vois jamais un assistant RAG comme un simple chatbot amélioré. C'est un produit data complet, avec un LLM au bout de la chaîne.

L'ingestion mérite autant d'attention que le prompt

Quand les sources sont mal versionnées, mal taguées ou découpées de façon mécanique, le retrieval se dégrade sans bruit. On accuse alors le modèle, alors que le problème est bien plus en amont.

Les garde-fous que je pose tout de suite

• un identifiant stable par document et par version
• des métadonnées utiles : langue, droits, date, structure, source
• une ré-ingestion différentielle pour éviter de retraiter tout le corpus
• un découpage adapté au support, pas une règle uniforme appliquée partout

Sur du juridique, je respecte les articles. Sur de la documentation technique, je préserve les titres, les tableaux et les blocs de code. Sur des échanges support, je garde le contexte de la conversation. Le bon chunking dépend du matériau, pas d'une habitude prise trop tôt.

Mesurer le retrieval avant de juger la génération

Beaucoup d'équipes regardent la réponse finale et s'arrêtent là. Pourtant, si la bonne preuve n'est jamais remontée, le modèle n'avait aucune chance de produire quelque chose de propre.

Je commence généralement avec 30 à 50 vraies questions, prises auprès des futurs utilisateurs. Pour chacune, je veux connaître le document ou la section qui aurait dû ressortir. Ce n'est pas un benchmark académique ; c'est juste assez pour repérer les régressions quand on change le chunking, les filtres ou le reranking.

Ce que je surveille en priorité

• est-ce que la bonne preuve apparaît vraiment dans les premiers résultats ?
• est-ce que la réponse sait citer la bonne source ?
• est-ce que le système sait dire "je ne sais pas" quand le corpus ne suffit pas ?

Un assistant qui ne sait pas s'abstenir finira toujours par improviser. Et c'est presque toujours comme ça que le sujet finit au support.

En prod, la recherche marche mieux en deux temps

La recherche vectorielle seule est rarement suffisante. Les éléments exacts comptent : numéro d'article, nom de produit, acronyme interne, identifiant de ticket. Le dense retrieval apporte la proximité sémantique ; la recherche lexicale apporte la précision. En pratique, le mélange des deux me donne de meilleurs résultats que la chasse permanente au "meilleur" modèle d'embedding.

Le schéma que je réutilise le plus souvent :

1. filtrer d'abord par droits, langue, type de document et fraîcheur ;
2. récupérer un ensemble de candidats assez large via une recherche hybride ;
3. reranker avant de construire la fenêtre de contexte finale ;
4. ne garder que les preuves que le modèle pourra vraiment exploiter.

Ce n'est pas la partie la plus spectaculaire d'un produit IA, mais c'est souvent là que se gagne la différence entre une réponse crédible et une réponse fragile.

Une mauvaise réponse doit être explicable vite

Après une mise en ligne, la question utile n'est pas "est-ce que ça marche globalement ?". La vraie question est : si un client envoie une capture d'écran d'une mauvaise réponse, est-ce qu'on peut expliquer ce qui s'est passé sans improviser ?

Pour cela, il faut une trace exploitable : la requête, les chunks récupérés, le prompt, le modèle choisi, les citations renvoyées. Langfuse est pratique pour ça parce qu'il remet un déroulé concret là où beaucoup d'équipes n'ont qu'une impression floue.

Le nom de l'outil m'importe moins que la capacité à répondre rapidement à quatre questions :

• qu'a demandé l'utilisateur ?
• qu'est-ce que le système a effectivement récupéré ?
• quelle consigne a été envoyée au modèle ?
• pour quelle raison cette réponse a-t-elle été autorisée ?

Si une de ces réponses manque, le débogage devient une discussion d'opinions au lieu de rester un sujet d'ingénierie.

Les coûts dérapent après l'adoption, pas avant

Le moment critique n'est généralement pas le pilote. C'est le mois qui suit, quand les équipes commencent à faire confiance à la fonctionnalité et que l'usage se diffuse.

Les trois leviers qui m'aident le plus sont simples :

• mettre en cache les questions proches pour éviter de recalculer inutilement ;
• réserver les modèles plus chers aux demandes réellement complexes ;
• ne relancer les embeddings que sur les documents qui ont vraiment changé.

Un système RAG n'a pas besoin d'être "pas cher" à tout prix. Il doit surtout avoir un coût qu'on sait expliquer avant que l'adoption ne s'emballe.

La base que je remettrais en place en une semaine

1. fiabiliser une seule famille de documents de bout en bout ;
2. ajouter des métadonnées propres avant de raffiner les prompts ;
3. constituer un petit jeu d'évaluation avec preuve attendue ;
4. tracer chaque réponse et conserver les citations ;
5. prévoir un vrai chemin de refus pour les questions hors périmètre ;
6. poser un budget de tokens et un cache minimal avant l'ouverture.

Ce socle suffit à lancer quelque chose de sérieux. Les raffinements peuvent venir ensuite. La confiance, elle, est beaucoup plus dure à reconstruire une fois qu'elle a été entamée.

---

Les systèmes RAG vraiment utiles ont un point commun : ils se comportent comme des logiciels fiables, presque discrets. Ils répondent avec des preuves, montrent leurs sources, et échouent de façon compréhensible. À mes yeux, c'est un objectif bien plus intéressant qu'une démo brillante.