Diagnostic des échecs RAG : une carte des étapes et un juge de fondement au niveau des affirmations.

Lorsqu’un bot RAG commence à donner de mauvaises réponses

Le déploiement d’une application RAG ne termine pas le travail, surtout en environnement de production. Avec le temps, elle commence à répondre incorrectement, et la première étape consiste à identifier la cause. Le système présente au moins sept points où des dysfonctionnements peuvent survenir : le découpage des données, les embeddings, la récupération des informations, le réclassement des résultats, l’assemblage du contexte, la génération des réponses, ainsi que le prompt qui les coordonne. Une mauvaise réponse finale ne révèle presque rien sur l’élément qui a échoué. Certains ingénieurs ont passé une semaine à affiner un prompt de génération alors qu’un bug de découpage en était la cause réelle.

Il existe une méthode assez mécanique pour localiser une panne. Ensuite se pose un second problème : mesurer le degré de fiabilité à grande échelle, car lire chaque transcription devient irréalisable une fois la phase de preuve de concept terminée. Un LLM agissant en tant que juge peut accomplir cette tâche, mais les juges ont eux-mêmes des modes de défaillance, tout aussi facilement à manquer que les défauts du RAG qu’ils sont censés détecter. Ces deux aspects sont abordés ci-dessous : retracer les pannes à leur source et créer un juge de fiabilité digne de confiance.

Localisez d’abord le lien défectueux

Un pipeline RAG est une chaîne, et la première étape consiste à identifier quel lien a échoué avant que quiconque ne modifie une instruction. La carte ci-dessous constitue un cadre pour localiser le problème. Elle n’est pas exhaustive et peut être étendue pour s’adapter à un système ou un cas d’usage particulier.

Le choix de cet ordre est délibéré : la récupération des informations est résolue avant la génération. L’ingénierie des prompts ne peut pas réparer une fenêtre de contexte qui n’a jamais contenu le fait approprié. Les équipes travaillent souvent à l’envers, réécrivant le prompt système cinq fois tandis que le réordonneur dégrade le passage pertinent. Les solutions peu coûteuses mais très efficaces, comme une meilleure segmentation des données ou une recherche hybride, devraient être privilégiées par rapport à celles qui sont coûteuses, comme le réglage fin d’un réordonneur ou un reconditionnement quelconque.

Trois symptômes réalistes montrent comment la méthode est utilisée :

1. Les réponses semblent assurées même si les documents ne traitent jamais du sujet. Il ne s’agit pas de récupération d’informations, car rien de pertinent n’existe à extraire. C’est une défaillance de génération ou d’abstention : le modèle ne considère pas « Je n’ai pas cette information » comme une réponse acceptable.
2. Le bot fournit des informations plausibles mais obsolètes. Le découpage en blocs n’est presque jamais la cause du problème. L’index est dépassé, car les documents ont changé et personne ne les a réinsérés.
3. Les questions reposant sur un seul fait fonctionnent, tandis que celles nécessitant deux faits provenant de deux documents échouent. Il s’agit d’une défaillance de récupération propre aux requêtes à plusieurs étapes, car une seule passe de récupération dense ne peut pas obtenir deux éléments qui ne correspondent pas chacun à la requête.

La prochaine étape consiste à récupérer le contexte réellement obtenu pour un exemple qui a échoué et à le lire avant de modifier quoi que ce soit. Si le fait n’y est pas, le problème réside dans la récupération. S’il y est et que le modèle se trompe malgré tout, le problème réside dans la génération. Ce simple contrôle peut économiser des jours de travail.

Que signifie la groundedness

La lecture des transcriptions convient pour un petit nombre de cas, mais est inefficace pour des milliers. C’est là que intervient un juge basé sur un modèle de langage, plus précisément un juge chargé d’évaluer le principe de fondement, également appelé fidélité. Sa question est de savoir si chaque affirmation contenue dans la réponse peut être retrouvée dans le contexte extrait.

Un point subtil qui trompe souvent les gens : le fondement et la justesse sont deux concepts distincts. Une réponse correcte peut ne pas être fondée, par exemple lorsque le modèle connaît le fait grâce à son entraînement et non à partir des documents. Une réponse fondée peut être fausse, si le passage extrait est lui-même obsolète ou incorrect. Lors de l’évaluation de RAG, c’est le principe de fondement qui doit être pris en compte, car il indique si la récupération des informations a bien fonctionné, quel que soit la qualité des documents de base.

Un juge au niveau des affirmations

Une seule instruction demandant une évaluation du degré de fondement sur une échelle de 1 à 5 semble raisonnable mais se révèle généralement presque inutile. Elle fournit un chiffre sans aucune explication, et c’est justement dans l’évaluation complète de la réponse que les LLM montrent leur incohérence. Diviser la réponse en affirmations élémentaires et vérifier chacune d’elles fonctionne bien mieux.

L’instruction de départ définit le modèle comme un évaluateur du degré de fondement, fournit une question, le contexte récupéré ainsi que la réponse générée, et précise dès le début que la tâche n’est pas de déterminer si la réponse est vraie en général. Elle demande ensuite que des affirmations soient extraites et vérifiées une par une par rapport au contexte, avec un verdict et un extrait de preuve pour chacune :

SYSTEM:
You are a groundedness evaluator. You will be given a QUESTION, a CONTEXT
(retrieved passages), and an ANSWER generated by an AI assistant. Your job
is NOT to judge whether the answer is true in general, or well-written, or
relevant — only whether it is fully supported by the CONTEXT.

Do the following:

1. Decompose the ANSWER into a list of atomic claims (each claim = one
   discrete factual statement, not a compound sentence).
2. For each claim, decide:
   - SUPPORTED: directly stated or reasonably entailed by CONTEXT
   - CONTRADICTED: conflicts with CONTEXT
   - UNSUPPORTED: not addressed by CONTEXT at all (NOT the same as "false")
3. Quote the exact span of CONTEXT used as evidence for each claim
   (or "none" if UNSUPPORTED/CONTRADICTED).
4. Give a one-sentence rationale per claim.
5. groundedness_score = (# SUPPORTED) / (# total claims).

Be strict: a claim that adds specificity not in CONTEXT (context says "a
discount applies," answer says "a 20% discount applies") is UNSUPPORTED.

Return valid JSON only:
{
  "claims": [{"claim": "...", "verdict": "...", "evidence_span": "...", "rationale": "..."}],
  "groundedness_score": 0.0,
  "num_claims": 0
}

QUESTION: {question}
CONTEXT: {context}
ANSWER: {answer}

Certaines choix de conception doivent être explicites, car ils ne sont pas évidents au premier abord :

• Évaluation au niveau des affirmations. Il est difficile de déboguer une seule note globale. Les verdicts par affirmation indiquent précisément quelle affirmation a échoué, ce qui est important lorsque quelqu’un doit corriger la cause sous-jacente.
• Intervalle d’éléments de preuve obligatoire. Exiger que le juge cite le texte de soutien pousse ce dernier à baser ses verdicts sur les preuves et non sur la plausibilité, et cela permet à un réviseur humain de vérifier rapidement un jugement sans avoir à relire tout le contexte.
• NON SOUTENU contre CONTRADICTÉ. Contredire les preuves et ne pas disposer de soutien sont deux échecs distincts nécessitant des solutions différentes. Fusionner les deux sous une seule étiquette de « mauvais » fait perdre des détails diagnostiques importants.
• Une instruction explicite d’être strict. Les juges des LLM ont tendance à être indulgents dans les cas limites, surtout lorsque la réponse semble plausible, et demander de la rigueur diminue ce phénomène.

Valider le juge par rapport aux humains

C’est l’étape qui est toujours sautée, et c’est elle qui détermine si le reste a de la valeur : un juge doit être validé par rapport aux humains avant d’être fiable.

Le processus est simple. Prenez de 100 à 200 exemples, faites évaluer de manière indépendante le degré de fondement par une personne, puis calculez le degré de concordance avec le kappa de Cohen. La précision brute est trompeuse lorsque la plupart des réponses sont fondées, car un juge qui affirme toujours « fondé » obtient de bons scores mais est inutile. Vérifiez également les biais habituels des juges :

• Biais de position : le verdict change-t-il si les passages de contexte sont réordonnés ?
• Biais de verbosité : le juge favorise-t-il des réponses plus longues, que celles-ci soient réellement mieux fondées ou non ?
• Biais d’autopréférence : si le juge appartient à la même famille de modèles que le générateur, il peut évaluer plus favorablement les sorties de cette famille.
• Dérive vers la clémence : l’accord s’effrite-t-il progressivement au fil des semaines à mesure que le modèle du juge ou la version de l’instruction change ?

Un kappa faible dans une catégorie est un signe qu’il faut ajuster le critère d’évaluation pour cette catégorie. Cela ne signifie pas pour autant que le système RAG est défectueux dans ce domaine. Les gens confondent constamment ces deux notions, et la section suivante aborde cette distinction.

Lire un tableau de bord en tant qu’opérateur

Imaginez un tableau de bord organisé par type de requête. L’attitude appropriée est celle d’un opérateur, et non celle d’un simple observateur des scores.

La moyenne globale montre une légère baisse, ce qui peut être trompeur. Légèrement différente ligne par ligne, la tendance est la suivante.

1. Recherche factuelle simple reste stable et élevée tant en termes de pertinence que d’accord. Le système et le juge la trouvent aisée. En soi, elle est ennuyeuse, mais une baisse indiquerait qu’un élément de base a défailli : l’indexation, la récupération des données de base ou les indications fournies au juge, et non le raisonnement ou l’ambiguïté.
2. Multi-hop et comparaison : ces performances ont chuté fortement. Avec κ=0,71, l’accord est seulement modéré, ce qui suggère que le bruit présent dans les réponses longues difficiles à décomposer pourrait en être en partie responsable. Avant de conclure à une régression, sélectionnez cinq transcriptions défaillantes et vérifiez si les deux passages nécessaires à la réponse se trouvent bien dans le contexte. Lorsqu’un seul passage est fourni, il s’agit d’un problème de récupération et de rappel, car la récupération dense en une seule étape manque souvent deux faits qui ne ressemblent pas tous deux à la requête ; la solution réside dans la décomposition de la requête ou dans une récupération multi-requêtes, et non dans des ajustements du prompt. Lorsque les deux passages sont fournis mais que la comparaison échoue encore, c’est la synthèse qui en est la cause, l’effet « perdu au milieu » étant le principal suspect : le modèle s’appuie sur le premier passage et accorde trop peu d’importance au second.
3. Les chiffres numériques et financiers indiquent κ=0,52. Il s’agit d’une concordance faible, mais c’est le signal le plus marqué dans le tableau, car cela signifie que l’on ne peut pas encore faire confiance au juge dans ce cas. L’équivalence numérique est véritablement difficile pour un juge basé sur un LLM : « 20 % », « environ un cinquième » et « 20 $ de réduction sur un article à 100 $ » ne sont qu’une même affirmation présentée sous différentes formes. L’instinct le plus judicieux est de laisser le système RAG de côté tant que les critères d’évaluation ne seront pas fixés, car essayer de travailler avec des chiffres peu fiables est une perte de temps en termes d’ingénierie.
4. Les aspects liés aux politiques et aux procédures restent stables et bons, tout comme dans la première ligne, mais pour une raison différente : les réponses proviennent généralement d’un seul document bien structuré et n’ont pas besoin d’une synthèse à partir de plusieurs documents. Si ce score diminue, le raisonnement n’est pas la première cause suspectée. Il est plus probable que la liste numérotée soit fragmentée entre les différentes parties du texte, ce qui amène le modèle à ne retenir que les étapes 1 à 3 et à inventer les étapes 4 et 5.
5. Hors champ mérite d’être corrigé en premier, même si n=20 en fait le plus petit segment. Avec κ=0,90, le juge est très fiable ici, car détecter une réponse inventée sans contexte de soutien est bien plus facile que d’évaluer des affirmations numériques subtiles ou à plusieurs étapes. Cette fiabilité rend la baisse crédible, et c’est l’échec le plus dangereux de ce tableau. Le système est passé de l’admission correcte de « Je ne sais pas » à l’invention de réponses avec assurance, ce qui est pire qu’une valeur erronée, car son ton est indiscernable de celui d’une réponse correcte. Deux causes probables : la récupération renvoie des passages proches qui sont interprétés par le modèle comme une autorisation de répondre, ou une modification récente de la requête ou du modèle a supprimé silencieusement l’instruction d’abstention. Commencez par examiner les scores de similarité de récupération pour ce segment.
Si elles se situent près du niveau de bruit et que le modèle répond quand même, c’est que le filtre de seuil de pertinence avant la génération fait défaut.

La méthode en cinq étapes

Toute l’opération se résume à ceci :

• ne pas faire confiance à la moyenne
• vérifier la fiabilité du juge avant de croire au score
• segmenter par catégorie
• hypothéser, à partir des preuves réelles, quelle étape a échoué
• donner la priorité en fonction de la gravité multipliée par la confiance, et non de l’amplitude de mouvement du seuil

Conseils pratiques pour les nouveaux évaluateurs

1. Chaque réponse évaluée entraîne une appel supplémentaire au LLM. À une échelle importante, évaluez un échantillon plutôt que tout le contenu, et stratifiez-le par catégorie de requête afin que des segments rares mais critiques, comme ceux hors champ, ne soient pas submergés par des requêtes faciles en grande quantité.
2. Revalidez le kappa chaque fois que le modèle du juge ou son prompt change. Chacun de ces changements crée un nouveau juge.
3. Un juge adapté aux particularités numériques ou au jargon d’un domaine ne s’applique pas automatiquement à un autre ; il convient donc de le calibrer pour chaque domaine et non une fois de manière globale.

Tous les exemples et illustrations présentés ici sont à des fins pédagogiques et ne proviennent pas d’un système en production réel. Le cadre et la structure des prompts constituent un point de départ raisonnable.

Où cela s’arrête

Le matériel ci-dessus couvre la localisation des échecs, l’écart entre ancrage et exactitude, un juge au niveau des affirmations, ainsi que l’étape de calibration souvent négligée. Une limite reste : tout cela part du principe qu’il existe un bloc de contexte récupéré propre. Ce postulat échoue dès qu’un système fait appel à des outils, enchaîne des étapes de récupération ou raisonne à partir de ses propres résultats intermédiaires, comme le font les systèmes agents. Définir l’ancrage sans bloc de contexte unique sur lequel s’appuyer, et adapter en conséquence le juge, constitue un problème distinct.

Lectures complémentaires

• Notes pratiques : Où apprendre RAG à partir de zéro en 2026 : Les cours — Guide détaillé des Notes pratiques : Où apprendre RAG à partir de zéro en 2026 : Les cours, y compris les contrats, les vérifications et les espaces prévus pour insérer du code destinés aux équipes qui mettent en œuvre ce modèle.
• RAG avec LangChain à partir de zéro : Chargeurs, morceaux de texte, embeddings, évaluation — Construire pas à pas un système de questions-réponses sur des documents : chargement des fichiers, segmentation en morceaux, génération d’embeddings, phases d’indexation et de récupération, ainsi que la manière d’évaluer la qualité des réponses obtenues.

Le Cross-Encoder en tant que juge : contrôlez votre pipeline RAG avec des indices de pertinence — Comment l’attention croisée permet à un cross-encoder d’évaluer la pertinence entre une requête et un document sur une échelle de 0 à 1, et comment un seuil peut empêcher les résultats peu pertinents d’atteindre le LLM.