Échec du RAG — mais quelle couche a réellement échoué ? Une méthode de diagnostic

Un système RAG renvoie une réponse faible, erronée, incomplète ou non étayée. Le diagnostic habituel est « la récupération a échoué » ou « le modèle a halluciné ». Ces deux étiquettes sont trop larges pour être utiles. Un pipeline RAG en production peut échouer avant la récupération, pendant la récupération, lors du classement, lors de l'assemblage du contexte, pendant la génération, ou après la génération lorsque les preuves et la validité sont vérifiées.

Pourquoi « le RAG a échoué » n'est pas un diagnostic

La génération augmentée par récupération combine plusieurs mécanismes : une requête utilisateur est interprétée, une ou plusieurs recherches sont construites, le matériel candidat est récupéré, les résultats sont filtrés ou reclassés, les preuves sélectionnées sont insérées dans un contexte de modèle, et un modèle génère une réponse. Les systèmes de production peuvent ajouter des autorisations, des filtres de métadonnées, des règles de fraîcheur, des citations, la réécriture de requêtes, la recherche hybride, des appels d'outils, de la mémoire et un état externe.

Une réponse finale erronée ne vous indique donc pas quel composant a échoué. Le modèle a peut-être reçu les mauvaises preuves. Il a peut-être reçu les bonnes preuves mélangées à trop de bruit. Les preuves peuvent être correctes mais obsolètes. La source n'a peut-être jamais contenu la réponse. Ou le modèle a peut-être ignoré un contexte parfaitement adéquat.

Les recommandations d'OpenAI sur le RAG établissent déjà une distinction fondamentale entre l'échec de récupération et l'échec du modèle : un système peut fournir le mauvais contexte, ou fournir le bon contexte et néanmoins générer une réponse erronée. AWS sépare de même l'évaluation de la récupération seule de l'évaluation de la récupération et génération. Pour le diagnostic en production, cette distinction doit être poussée plus loin.

La pile de défaillances RAG

Couche 1 — Couverture des sources : le système peut-il répondre à cela du tout ?

Avant de régler les embeddings, les rerankers ou les prompts, vérifiez que la réponse existe dans l'espace de connaissances que le système est autorisé à utiliser. Cela semble évident, mais de nombreux échecs RAG sont en réalité des échecs de corpus. Le fait demandé peut être absent, caché dans une pièce jointe non indexée, disponible uniquement dans un document plus récent, stocké dans un système extérieur au corpus RAG, ou bloqué par des autorisations.

Une métrique de récupération ne peut pas récupérer une information qui n'a jamais été indexée. Un top-k plus grand ne peut pas récupérer un document que le pipeline ne contient pas. Si le test de couverture des sources échoue, la correction appropriée est l'ingestion, la sélection des sources, les autorisations, ou un comportement explicite de « non répondable à partir des preuves disponibles ».

Couche 2 — Construction de la requête : le système a-t-il posé la bonne question au corpus ?

La requête utilisateur n'est pas toujours la requête de récupération. Les systèmes de production réécrivent les questions, résolvent les pronoms, extraient les entités, traduisent les langues, ajoutent des contraintes de métadonnées, divisent les questions complexes ou génèrent plusieurs recherches. Chaque transformation peut améliorer la récupération, mais chaque transformation peut aussi détruire de l'information.

Une demande telle que « La politique s'applique-t-elle encore aux sous-traitants en Allemagne après la mise à jour de septembre ? » contient au moins une entité, une population, une juridiction et une limite temporelle. Une requête réécrite qui devient « politique des sous-traitants » peut récupérer un texte sémantiquement connexe tout en perdant les variables qui déterminent si la réponse est valide.

Couche 3 — Récupération des candidats : les preuves pertinentes ont-elles été incluses dans l'ensemble ?

La récupération des candidats est avant tout un problème de rappel. La question diagnostique n'est pas encore de savoir si le meilleur résultat est classé premier ; il s'agit de savoir si des preuves pertinentes apparaissent quelque part dans le pool de candidats. Si la source correcte connue n'apparaît pas, examinez l'indexation, le découpage, les embeddings, la correspondance lexicale, les métadonnées, la recherche hybride, la gestion des langues, les synonymes et l'expansion des requêtes.

C'est là que l'évaluation de la récupération seule est précieuse. AWS expose la pertinence du contexte et la couverture du contexte pour l'évaluation RAG en récupération seule. L'habitude de production importante est d'évaluer la récupération avant la génération afin qu'une réponse finale soignée ne puisse pas masquer un ensemble de candidats faible.

Couche 4 — Classement et filtrage : les bonnes preuves ont-elles été écartées ou enfouies ?

Un système peut avoir un bon rappel et échouer quand même parce que les preuves pertinentes se classent en dessous de matériel bruité mais sémantiquement similaire. Les rerankers, les boosts de récence, les pondérations d'autorité, les préférences linguistiques, les filtres de locataires, les contrôles d'accès, les filtres de statut de produit et la déduplication modifient tous ce qui survit dans le contexte final.

Le débogage doit donc conserver la liste complète des candidats, pas seulement le top-k final. Si la preuve de référence a été récupérée au rang 18 et qu'un reranker l'a supprimée, le correctif n'est pas le même qu'un échec de récupération.

Couche 5 — Assemblage du contexte : des preuves utiles sont-elles devenues un contexte utilisable ?

Le succès de la récupération ne garantit pas le succès du contexte. Les segments pertinents peuvent être tronqués, séparés de leurs qualificatifs, dupliqués jusqu'à dominer le prompt, mélangés avec des versions contradictoires, ou entourés de suffisamment de texte non pertinent pour que le passage décisif perde sa saillance.

Les limites des segments sont particulièrement importantes. Une phrase peut contenir la règle tandis que la phrase suivante contient l'exception. Si elles sont indexées séparément et que seule la première est récupérée, le récupérateur peut sembler pertinent alors que le contexte assemblé devient trompeur.

Couche 6 — Génération : le modèle peut-il utiliser correctement des preuves correctes ?

Une fois que le système a démontré qu'il fournissait des preuves suffisantes, la génération devient testable indépendamment. Le modèle peut généraliser à l'excès, combiner des passages incompatibles, ignorer une déclaration négative, ne pas suivre le format de réponse demandé, inventer un pont entre des faits, ou répondre à partir de sa mémoire paramétrique au lieu des preuves récupérées.

C'est pourquoi la seule exactitude de bout en bout est insuffisante pour le diagnostic. OpenAI recommande l'évaluation comme un moyen structuré de comprendre le comportement d'une application, tandis que les conseils d'Anthropic sur l'évaluation des agents mettent l'accent sur les essais multiples, les évaluateurs, les traces et les cas d'échec réalistes. Pour le RAG, le générateur doit être testé à la fois avec une récupération normale et avec un contexte de référence contrôlé.

Couche 7 — Attribution des preuves : la réponse est-elle réellement étayée ?

Une réponse plausible avec des citations peut encore être faiblement fondée. Le document cité peut être pertinent pour le sujet mais ne pas étayer l'affirmation spécifique. Une phrase peut être étayée tandis qu'une autre est inférée. Une citation peut pointer vers une source qui contredit la réponse une fois ses conditions lues.

L'évaluation des citations intervient donc après la génération. AWS distingue la précision des citations de la couverture des citations : si les passages cités sont correctement cités et si la réponse est suffisamment étayée par des citations. En production, le soutien au niveau des affirmations est plus utile que de traiter la présence d'une citation quelconque comme une preuve de qualité.

Couche 8 — Validité et fraîcheur : les preuves étaient-elles correctes pour cette version de la réalité ?

Le RAG peut récupérer une source parfaitement authentique, hautement pertinente et fidèlement citée et produire néanmoins une réponse erronée si la source n'est plus valide pour la question actuelle. Les politiques changent. Les API sont dépréciées. Les prix évoluent. Le comportement des logiciels change entre les versions. L'inventaire des produits change. Les permissions changent. Les correctifs de jeu modifient les mécaniques.

Il s'agit d'une classe d'échec distincte de l'hallucination. La preuve est réelle ; son applicabilité est erronée. Un système robuste a donc besoin d'horodatages, de métadonnées de version ou de juridiction lorsque cela est pertinent, d'autorité de la source, de règles de remplacement et d'un mécanisme explicite pour décider quand les preuves plus anciennes doivent être restreintes ou abandonnées.

La méthode d'isolation la plus rapide : le test du contexte oracle

La première séparation la plus utile est simple : fournissez manuellement au générateur un petit ensemble de preuves que vous savez suffisantes pour répondre à la question. Gardez la tâche et la réponse attendue inchangées.

Une séquence de diagnostic en production

Ne changez pas trois couches à la fois

Une erreur de débogage courante consiste à modifier les embeddings, les tailles de segments, le top-k, les prompts et le modèle en une seule itération. Si le score s'améliore, vous ne savez pas pourquoi. S'il se dégrade, vous ne savez pas quel changement a causé la régression.

Traitez le débogage RAG comme un diagnostic expérimental : maintenez autant de constantes que possible dans le pipeline et remplacez un composant incertain par une entrée contrôlée. Les documents de référence isolent la récupération. Les segments de référence isolent la sélection des segments. Un contexte fixe isole la génération. Un modèle fixe isole les changements de récupération. Un corpus fixe isole les changements d'ingestion et d'indexation.

Une matrice de défaillance pour les symptômes RAG courants

Mesurez chaque couche avec la métrique qu'elle peut réellement influencer

Une réponse correcte peut encore masquer un défaut RAG

Le problème inverse compte aussi. Un système RAG peut produire la réponse correcte alors que la récupération est défaillante. Le modèle peut déjà connaître la réponse grâce à l'entraînement, l'inférer à partir de preuves faibles ou deviner correctement. Si l'évaluation ne regarde que la réponse finale, le système peut sembler sain jusqu'à ce que la question atteigne des informations qui n'existent que dans le corpus privé.

C'est le même problème de fiabilité qui apparaît plus largement dans les systèmes d'agents : l'exactitude du résultat ne suffit pas à prouver que le chemin d'exécution était fiable. Pour le RAG, les traces doivent conserver au moins la requête de récupération, l'ensemble des candidats, le classement, le contexte final, la réponse, les citations, la version du modèle, la version du corpus/index et les filtres pertinents.

Utilisez des hypothèses concurrentes, pas une explication favorite

Si une mauvaise réponse devient immédiatement « un problème d'embedding », l'enquête est déjà biaisée. Une méthode de débogage plus solide consiste à écrire les hypothèses concurrentes avant de modifier le système : source manquante, mauvaise réécriture de requête, faible rappel de récupération, mauvais reranking, troncature du contexte, versions contradictoires, échec de génération, échec de citation ou preuves obsolètes.

Choisissez ensuite un test qui permettrait de départager ces hypothèses. C'est plus efficace que de collecter davantage d'exemples qui confortent la première explication. Le même principe s'applique au raisonnement technique assisté par IA en général : un diagnostic utile est celui qui survit à des tests discriminants, pas celui qui semble simplement plausible.

Qu'est-ce qui changerait cette réponse ?

Les couches de diagnostic exactes changent avec l'architecture. Une application RAG simple à document unique peut ne pas avoir de réécriture de requête, de reranker ou de couche de citation. Un système de récupération agentique peut ajouter de la planification, des recherches multiples, la sélection d'outils, la mémoire, les permissions et la collecte itérative de preuves. Une recherche dans une base de données structurée peut ne pas utiliser du tout de chunks ni d'embeddings.

La méthode fondamentale tient toujours : identifier les composants qui peuvent modifier indépendamment le résultat, construire des tests contrôlés qui remplacent les composants incertains par des entrées fiables, et mesurer chaque composant à l'aide de preuves appropriées à cette couche.

Limites

Les défaillances réelles sont souvent couplées. Une requête faible peut réduire le rappel, ce qui modifie le reranking, ce qui modifie le contexte, ce qui augmente la variance de génération. Le test du contexte oracle est un raccourci de diagnostic, pas la preuve qu'un composant est seul responsable. Les jeux de données d'évaluation peuvent aussi être non représentatifs, et les évaluateurs basés sur des modèles peuvent introduire leurs propres erreurs.

La pile proposée est donc mieux utilisée comme une structure d'enquête : journaliser le pipeline, isoler les variables, reproduire les défaillances, tester des explications concurrentes et maintenir une évaluation de bout en bout après les corrections au niveau des couches.

Conclusion

« Le RAG a échoué » devrait être le début de l'enquête, pas la conclusion. Un diagnostic utile identifie si le système manquait de preuves, a mal cherché, n'a pas réussi à les récupérer, les a mal classées, a assemblé un contexte inutilisable, a généré incorrectement, a mal attribué les affirmations ou a appliqué des preuves en dehors de leur limite de validité.

La règle pratique est simple : remplacer l'incertitude par des preuves contrôlées, une couche à la fois. Commencez par le test du contexte oracle. Séparez l'évaluation de la récupération seule de l'évaluation de la génération. Conservez la trace complète. Corrigez ensuite le composant qui a réellement échoué au lieu de régler toute la pile RAG à l'intuition.

FAQ

Glossaire

Sources primaires et lectures complémentaires