Comment l’analyse des défaillances d’un RAG fait passer la part des réponses non étayées de 34 % à 9 %

Lorsqu’un système RAG annonce avec assurance un délai, un prix ou une règle erronés, le premier réflexe consiste généralement à modifier le prompt. On ajoute la phrase « répondez uniquement à partir des documents », on durcit la formulation des instructions, puis on relance le test. Cela fonctionne parfois. Mais si le fait nécessaire n’est jamais entré dans le contexte, aucune instruction ne permettra au modèle de l’utiliser.

L’idée centrale de cet article est simple : une même réponse erronée peut résulter de défaillances différentes. La recherche peut ne pas avoir trouvé le document. Le découpage en chunks peut avoir scindé une affirmation importante. Le reranker peut avoir placé en tête un fragment similaire, mais inadapté. Enfin, le modèle peut avoir reçu le bon contexte, l’avoir ignoré et avoir répondu de mémoire. Chaque cas exige une correction différente.

Une réponse, trois défaillances possibles

Imaginons un assistant consacré à la documentation d’un service cloud. L’utilisateur demande s’il est possible de restaurer un topic Kafka supprimé. La documentation indique que la suppression est irréversible, même si les données restent physiquement stockées pendant sept jours supplémentaires. Le système répond : « Le topic peut être restauré gratuitement depuis la console dans un délai de sept jours. »

Cette réponse contient d’emblée trois affirmations non confirmées : la possibilité d’une restauration, la méthode et le prix. Pourtant, le nombre « sept jours » figure bien dans la source. Une vérification superficielle fondée sur la correspondance des mots pourrait donc considérer la réponse comme étayée.

Il faut commencer par examiner les fragments renvoyés par la recherche. Si le paragraphe indiquant le caractère irréversible de la suppression n’a pas été retrouvé, le problème se situe dans la récupération : il faut vérifier le découpage en chunks, les embeddings, les filtres, la recherche hybride et le reranking. Si le bon fragment était présent, mais que le modèle a tout de même inventé la restauration, la défaillance se situe dans la génération ou dans un conflit entre le contexte et les connaissances internes du modèle.

L’ablation révèle ce qui a réellement influencé la réponse

Une technique utile consiste à relancer la requête en retirant du prompt certains fragments. Si, après la suppression du chunk relatif à la conservation pendant sept jours, le modèle cesse de parler de restauration, c’est qu’il a construit à tort un lien causal : il a transformé une durée de stockage physique en période pendant laquelle une opération serait accessible à l’utilisateur.

La réponse est ensuite décomposée en affirmations vérifiables distinctes. Chaque nombre, délai, prix et action doit être appuyé par un fragment précis. La simple mention d’une entité ne suffit pas : un document contenant le mot « Berlin » ne prouve pas encore que Berlin y est présenté comme la capitale de l’Allemagne.

Enfin, il convient de retirer tout le contexte pertinent. Si la réponse ne change presque pas, le modèle l’a probablement générée de mémoire et n’a utilisé le document récupéré que comme citation décorative. Un contrôle classique de cohérence logique entre le texte et la source peut ne pas détecter cette substitution, car il répond à la question « les affirmations sont-elles compatibles ? », sans montrer si la source a réellement influencé la génération.

Ce qu’il faut mettre en œuvre dans un RAG en production

Le socle minimal d’observabilité consiste à journaliser la requête, le top-k des fragments récupérés, leurs scores et le prompt final. Pour les requêtes annotées, il est utile de calculer Recall@k : le fragment nécessaire figurait-il parmi les résultats de la recherche ? Cette métrique doit de préférence être mesurée sur du trafic réel, et pas uniquement sur des exemples synthétiques bien calibrés.

Pour les réponses critiques, il faut exiger un fragment justificatif pour chaque affirmation importante. En l’absence d’appui direct, la réponse honnête « ce n’est pas indiqué dans la documentation » est plus sûre qu’une supposition formulée avec assurance. Les nombres, les délais et les prix peuvent être automatiquement soumis à une vérification supplémentaire.

La méthode présente des limites. Les ablations nécessitent des appels supplémentaires au modèle, augmentent la latence et le coût, et une modification de la réponse ne démontre pas toujours sans ambiguïté un lien de causalité. Il est donc raisonnable de les exécuter de manière sélective : sur une faible part du trafic, sur les réponses comportant des citations et dans les scénarios à haut risque.

Le résultat pratique est que l’équipe cesse de traiter toutes les erreurs avec un seul prompt. Si la source n’a pas été trouvée, elle corrige la recherche et le découpage en chunks. Si le contexte a été trouvé, mais ignoré, elle travaille sur les instructions et l’architecture de génération. Si une référence a été ajoutée après coup, elle renforce la vérification de l’attribution. Dans l’exemple décrit par l’auteur, l’ensemble de ces mesures a fait passer la part des affirmations non étayées de 34 % à 9 %.