RAG en production : pourquoi votre chatbot répond faux malgré vos documents

Votre chatbot connaît vos documents. Vous avez connecté un modèle de langage à une base vectorielle, importé votre documentation et affiché quelques réponses convaincantes en démonstration.

Puis les premiers utilisateurs posent des questions moins propres : une référence produit ancienne, un nom d'offre ambigu, une règle cachée dans une annexe. Le chatbot cite un document qui existe, mais répond à côté. Parfois, il affirme même une information absente de la base.

Le problème n'est pas forcément le modèle. Dans un système RAG, la réponse dépend d'une chaîne complète : la question, la recherche, le classement des passages, le contexte transmis au modèle, puis la génération et le contrôle de la réponse.

RAG signifie Retrieval-Augmented Generation, ou génération augmentée par récupération. Le système recherche des informations dans une base externe au moment de la requête, puis les fournit au modèle pour qu'il produise une réponse ancrée dans ce contexte. ^1

Voici une méthode de diagnostic que j'utiliserais avant de changer de modèle ou d'ajouter une nouvelle couche d'IA.

Une réponse fausse ne signifie pas toujours que le modèle hallucine

Lorsqu'un utilisateur signale une mauvaise réponse, l'équipe accuse souvent le LLM. C'est parfois juste, mais ce diagnostic arrive trop tôt.

Un chatbot RAG peut échouer à plusieurs endroits :

• la question est ambiguë et n'est pas reformulée ;
• le bon document n'a pas été indexé ;
• le découpage a séparé le titre de l'information importante ;
• la recherche sémantique a trouvé un passage proche, mais pas le passage décisif ;
• une version obsolète a été classée avant la version active ;
• les passages récupérés sont trop nombreux ou trop longs ;
• le modèle reçoit le contexte, mais ne sait pas quoi en faire ;
• la réponse n'est soumise à aucun contrôle de fidélité.

Ces causes produisent des symptômes similaires, mais les corrections sont opposées. Changer de modèle ne réparera pas un document absent. Ajouter des documents ne réparera pas un classement qui privilégie une ancienne politique tarifaire.

La première règle est donc simple : ne mesurez pas uniquement la réponse finale, mesurez aussi ce qui lui a été transmis.

Cartographier le trajet complet d'une question

Pour diagnostiquer un RAG, représentez une requête comme une suite d'étapes observables :

1. Question utilisateur, le texte original, la langue et les éventuelles métadonnées ;
2. Reformulation, si le système transforme la question ou ajoute l'historique de conversation ;
3. Recherche, les requêtes envoyées au moteur lexical, vectoriel ou hybride ;
4. Résultats bruts, les documents, passages, scores et métadonnées retournés ;
5. Classement, le filtrage ou le reranking appliqué avant l'appel au modèle ;
6. Contexte final, exactement les passages placés dans la fenêtre de contexte ;
7. Réponse, le texte, les citations, le niveau de confiance et l'éventuelle escalade humaine.

Sans cette trace, vous ne savez pas si le système a échoué par manque de connaissance, par mauvais classement ou par mauvaise utilisation du contexte.

Les conventions d'observabilité GenAI d'OpenTelemetry prévoient notamment de décrire les opérations de récupération et les documents récupérés. Elles constituent un bon point de départ pour nommer les traces, même si le contenu des documents et des prompts doit être protégé lorsqu'il contient des données sensibles. ^2

Tester d'abord la récupération, pas la prose

Construisez un jeu de questions de référence à partir de demandes réelles, anonymisées. Pour chaque question, notez :

• la réponse attendue, ou les éléments qui doivent apparaître ;
• les documents qui font autorité ;
• les documents qui doivent être exclus, notamment les versions obsolètes ;
• les termes équivalents utilisés par les utilisateurs ;
• la décision attendue lorsque l'information n'existe pas.

Le premier test ne demande pas au modèle de rédiger. Il vérifie si le bon élément de preuve apparaît dans les résultats récupérés.

Pour une question sur la résiliation d'un abonnement, le test peut exiger que la politique active soit présente dans les premiers résultats, que sa date de validité soit disponible et qu'une ancienne version ne soit pas sélectionnée à sa place.

Ce test sépare deux problèmes :

• rappel insuffisant, le bon document n'est pas récupéré ;
• précision insuffisante, le bon document est récupéré, mais noyé parmi des résultats moins pertinents.

Cette distinction guide la correction. Le rappel appelle souvent un travail sur le contenu, le découpage, les synonymes ou la stratégie de recherche. La précision appelle plutôt des filtres, des métadonnées, un reranker ou un réglage du nombre de passages transmis.

Le découpage des documents est une décision produit

Le chunking est souvent traité comme un paramètre technique. C'est une erreur. La manière dont vous découpez la documentation détermine les unités de sens que le moteur peut retrouver.

Un passage peut être court, mais inutilisable s'il ne contient ni titre, ni produit, ni période d'application. À l'inverse, un passage trop long peut regrouper plusieurs règles contradictoires et diluer l'information recherchée.

Avant d'ajuster la taille des chunks, observez la structure de vos sources :

• les titres et sous-titres portent-ils le contexte nécessaire ?
• les tableaux sont-ils convertis sans perdre leurs colonnes ?
• les listes de conditions restent-elles attachées à la règle qu'elles précisent ?
• les versions, dates et périmètres sont-ils conservés comme métadonnées ?
• les liens entre une procédure et ses exceptions sont-ils préservés ?

Une pratique utile consiste à enrichir chaque passage avec un contexte court avant son embedding : nom de la source, section, produit, public concerné et période. Anthropic décrit cette approche sous le nom de Contextual Retrieval, en la combinant avec une recherche lexicale BM25 et, lorsque nécessaire, un reranking. ^3

Il ne faut pas copier cette technique mécaniquement. Il faut retenir le principe : un passage doit rester compréhensible lorsqu'il est récupéré en dehors de son document d'origine.

Mélanger recherche sémantique et recherche lexicale

La recherche vectorielle est efficace lorsque l'utilisateur exprime une idée avec des mots différents de ceux de la documentation. Elle peut être moins fiable pour les identifiants, les références, les noms propres, les codes d'erreur ou les termes exacts.

La recherche lexicale, elle, reconnaît bien les mots et les séquences précises. Elle peut manquer une paraphrase.

Pour une base métier, la combinaison des deux est souvent plus robuste :

• le vecteur capte l'intention et la proximité de sens ;
• la recherche lexicale capte les noms, numéros, acronymes et formulations exactes ;
• un classement commun réunit les résultats ;
• un reranker peut ensuite départager les passages les plus proches de la question.

Les mécanismes de retrieval d'OpenAI exposent justement des options de classement, de seuil de score et de recherche hybride. La bonne configuration dépend du corpus et doit être mesurée sur votre jeu de cas, pas choisie parce qu'elle est présentée comme la valeur par défaut. ^4

Ajoutez également des filtres métier lorsqu'ils sont disponibles : langue, produit, version, tenant, région, statut de publication ou date de validité. Un score sémantique ne remplace pas une règle d'accès ou de fraîcheur.

Contrôler ce que le modèle a le droit d'affirmer

Même un contexte pertinent ne garantit pas une réponse fidèle. Le modèle doit recevoir un contrat explicite.

Pour un assistant documentaire, ce contrat peut préciser :

• répondre uniquement à partir du contexte fourni ;
• distinguer un fait trouvé d'une déduction ;
• signaler lorsqu'aucune source ne permet de répondre ;
• citer la source ou la section utilisée ;
• ne pas fusionner deux versions sans expliquer le conflit ;
• demander une précision lorsque plusieurs produits ou contrats correspondent ;
• transférer à un humain les sujets sensibles ou ambigus.

Ce contrat ne doit pas servir à masquer un retrieval défaillant. Une phrase comme « n'hallucinez pas » ne remplace ni un bon corpus ni des contrôles. Elle rend simplement le comportement attendu plus explicite.

Lorsque la réponse est structurée, utilisez aussi des validations déterministes : schéma JSON, identifiant de source obligatoire, statut parmi une liste autorisée ou présence d'une justification. Les contraintes critiques ne doivent pas dépendre uniquement du jugement d'un autre modèle.

Évaluer la fidélité avec des cas négatifs

Un RAG fiable ne doit pas seulement répondre aux questions dont la réponse existe. Il doit aussi savoir ne pas répondre.

Ajoutez des cas où :

• l'information n'est pas présente ;
• deux documents se contredisent ;
• le document pertinent est archivé ;
• la question concerne un autre client ou un autre périmètre ;
• l'utilisateur demande une interprétation juridique ou financière qui nécessite un humain ;
• la source récupérée contient une instruction qui ne doit pas être exécutée.

Pour chaque cas, définissez le comportement attendu : refus, demande de précision, réponse partielle ou escalade.

Un bon signal d'évaluation n'est pas seulement « la réponse ressemble à la référence ». Il vérifie aussi que chaque affirmation importante est soutenue par le contexte, que les citations pointent vers une source réelle et que les informations absentes ne sont pas présentées comme des faits.

Les méthodes d'évaluation de RAG distinguent généralement la qualité de la récupération, la fidélité de la réponse et sa pertinence. Des travaux comme ARES ou eRAG montrent l'intérêt d'évaluer les composants séparément plutôt que de se contenter d'un score de bout en bout. ^5

Versionner les documents comme du code

Un index documentaire n'est pas une poubelle où l'on ajoute chaque export successif.

Pour chaque source, conservez au minimum :

• un identifiant stable ;
• la version ou la date d'effet ;
• le statut, brouillon, active ou archivée ;
• le périmètre d'application ;
• la date d'indexation ;
• le lien vers la source originale ;
• l'empreinte du contenu qui permet de détecter les changements.

Lorsqu'une règle change, testez trois choses : le nouveau document est récupérable, l'ancien ne remonte plus comme autorité et les questions historiques conservent le comportement attendu si votre produit doit les traiter.

Cette discipline facilite aussi le rollback. Si une réindexation dégrade les réponses, vous devez pouvoir identifier le lot concerné et revenir à un index connu, plutôt que reconstruire toute la base dans l'urgence.

Les métriques à suivre en production

Je recommande de suivre des métriques reliées à des décisions d'ingénierie :

• présence du document attendu dans les résultats ;
• rang du premier passage pertinent ;
• taux de réponses sans preuve suffisante ;
• taux de refus ou d'escalade approprié ;
• nombre de sources citées et validées ;
• latence de la recherche et du reranking ;
• coût par requête ;
• taux de correction humaine ;
• évolution par version de l'index, du prompt et du modèle.

Ne mélangez pas tout dans une note unique. Un système peut avoir une bonne pertinence moyenne et un défaut critique sur les demandes de facturation. Les résultats doivent être découpés par intention, risque, langue, produit et version documentaire.

Conservez un échantillon de traces réelles, avec les règles de confidentialité adaptées. Les erreurs observées en production doivent alimenter le jeu de non-régression, après revue humaine et anonymisation.

FAQ : fiabiliser un RAG

Pourquoi mon RAG hallucine-t-il alors que les documents sont présents ?

La présence du document dans l'index ne prouve pas qu'il a été récupéré pour cette question, ni qu'il a été transmis au modèle. Vérifiez successivement les résultats de recherche, le classement, le contexte final et les affirmations de la réponse.

Faut-il changer de modèle pour améliorer un RAG ?

Pas en première intention. Mesurez d'abord la récupération et la fidélité. Si le bon contexte arrive bien dans la fenêtre, mais que le modèle l'interprète mal, un changement de modèle peut être pertinent. S'il manque, il faut d'abord corriger l'ingestion, le découpage, les métadonnées ou la recherche.

Quelle taille choisir pour les chunks ?

Il n'existe pas de taille universelle. Le chunk doit préserver une unité de sens suffisamment autonome pour être retrouvée et comprise. Testez plusieurs stratégies sur vos questions réelles, en observant le rappel, la précision et la qualité du contexte transmis.

La recherche vectorielle suffit-elle ?

Elle peut suffire pour un corpus simple, mais les bases métier contiennent souvent des références, acronymes, noms propres et versions. Une recherche hybride combine généralement mieux la proximité sémantique et la correspondance exacte, à condition de mesurer le résultat.

Comment savoir si un RAG est prêt pour la production ?

Vous devez pouvoir expliquer ses échecs, identifier les sources utilisées, distinguer les documents actifs des documents obsolètes, mesurer la récupération et limiter les actions sensibles. La mise en production dépend ensuite du risque du workflow, pas d'un score universel.

Ce que je recommande, en tant que CTO hands-on

Ne commencez pas par ajouter un agent, un nouveau framework ou un modèle plus cher. Commencez par instrumenter le trajet d'une question et par construire un petit jeu de cas représentatif.

Un RAG devient exploitable lorsque l'équipe sait répondre à quatre questions : qu'avons-nous recherché, qu'avons-nous trouvé, qu'avons-nous transmis au modèle et pourquoi avons-nous accepté sa réponse ?

C'est la démarche que je mets en place dans une mission de structuration d'un projet IA et automatisation : clarifier le cas d'usage, fiabiliser les sources, mesurer la chaîne et définir les limites d'autonomie. Lorsque les défauts viennent de l'architecture ou des intégrations, un audit technique permet de les isoler avant d'investir davantage dans le modèle.

Un chatbot RAG ne devient pas fiable parce qu'il a accès à plus de documents. Il le devient lorsque les bons documents sont récupérés, que leur version est maîtrisée et que chaque réponse peut être vérifiée.

Sources et références

• Anthropic, Glossary, Retrieval-Augmented Generation
• Anthropic, Introducing Contextual Retrieval
• OpenAI, Retrieval
• OpenTelemetry, GenAI semantic conventions
• Saad-Falcon et al., ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems
• Es et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation