Déboguer RAG en trouvant la première étape qui a échoué

Lorsqu’un assistant de connaissances donne une réponse médiocre, changer la demande est une réaction facile. Cela n’est utile que si le modèle a reçu des éléments de preuve suffisants mais les a mal traités.

Un document manquant, un extrait incomplet et une conclusion non étayée représentent des échecs différents. Les traiter comme un seul score de qualité ralentit le débogage, car ce score ne vous indique pas quelle partie modifier.

Un cycle d’évaluation pratique doit conserver le parcours allant du matériel source jusqu’à la réponse affichée à l’utilisateur.

Créez des exemples avec des preuves, et non seulement des réponses

Pour chaque question de test, enregistrez les passages qui soutiennent une réponse acceptable. Indiquez également les conditions que la réponse doit respecter et les affirmations qu’elle doit éviter.

Un cas illustratif pourrait ressembler à ceci :

{
  "question": "When should this deployment be rolled back?",
  "required_evidence": ["handbook-v3:section-8"],
  "must_include": ["the failed health-check condition"],
  "must_not_claim": ["every warning requires rollback"],
  "answerable": true
}

Cet enregistrement est plus utile qu’une seule phrase attendue. Il permet plusieurs réponses bien rédigées tout en conservant les conditions qui les rendent correctes.

Ajoutez des questions que le corpus ne peut pas répondre. Sinon, un système qui génère toujours quelque chose peut sembler plus performant qu’un autre qui reconnaît correctement l’absence de preuves.

Vérifiez d’abord l’échec le plus précoce

Commencez par la source. L’information requise existe-t-elle dans le texte indexé, et appartient-elle au document indiqué ? Si ce n’est pas le cas, corrigez l’ingestion des sources.

Ensuite, examinez le processus de récupération. Les preuves pertinentes sont-elles entrées dans la liste des candidats ? Si oui, ont-elles survécu au filtrage, au réclassement et à l’assemblage contextuel ? Ce sont des points de contrôle distincts. Un passage trouvé par la recherche mais supprimé avant la génération ne peut pas servir de base à la réponse finale.

Finalement, examinez la réponse. A-t-elle représenté avec précision les éléments de preuve, conservé les exceptions et évité des affirmations non étayées ? Si le contexte était suffisant mais que la réponse a échoué, le comportement de sollicitation ou de génération devient une cible raisonnable.

Cet ordre empêche un modèle puissant de masquer des résultats faibles sur des questions simples, pour ensuite échouer de manière imprévisible sur des questions auxquelles il ne peut pas répondre grâce à ses connaissances antérieures.

Utilisez des métriques qui mettent en évidence différents types d’erreurs

Le taux de rappel à un seuil choisi mesure la fraction des éléments pertinents étiquetés qui ont été récupérés. La précision mesure la fraction des éléments retournés qui sont effectivement pertinents. Un taux de réussite vérifie simplement s’au moins un élément pertinent est apparu ; cela est moins strict que la récupération de toutes les preuves nécessaires pour une réponse à plusieurs parties.

Les métriques de classement aident à distinguer les éléments de preuve en première position de ceux enfouis près du seuil. Cependant, les étiquettes de pertinence exigent prudence : un texte peut mentionner le sujet, tandis qu’un autre répond directement à la question. Les considérer comme également utiles peut récompenser un comportement erroné.

Pour la génération, évaluez séparément le niveau de soutien, la justesse, l’exhaustivité et l’alignement des citations. Une réponse peut reprendre avec précision une source obsolète. Elle peut également contenir une affirmation correcte que les éléments de preuve fournis ne viennent pas étayer. Ces cas nécessitent des corrections différentes.

Préserver la qualité opérationnelle dans le même experiment

Enregistrez le temps de réponse, les échecs et l’utilisation des ressources en même temps que les jugements de qualité. Conservez la version du corpus, les paramètres de recherche, la version de l’instruction et l’identifiant du modèle afin que les comparaisons soient interprétables.

Lors du diagnostic d’une régression, modifiez une seule variable majeure à la fois. Par exemple, comparez l’activation et la désactivation du reranking tout en maintenant le pool de candidats constant. Modifier en même temps la segmentation des données, le processus de récupération et les instructions fournies peut améliorer la note sans clarifier la cause du problème.

Les juges automatisés peuvent aider à examiner de nombreux résultats, mais il convient d’examiner manuellement les désaccords et les cas limites sensibles. La note attribuée par un juge n’est qu’une autre mesure ayant ses limites, et ne remplace pas une grille d’évaluation explicite.

Évaluer ce qui parvient à l’utilisateur

Même une réponse backend correcte peut apparaître pour la mauvaise requête si l’interface accepte des demandes obsolètes. Intégrez l’interaction de recherche React dans les vérifications bout en bout.

Le résultat utile de l’évaluation est une action concrète à entreprendre : extraire les corrections nécessaires, améliorer la récupération des informations, préserver le contexte, réviser la génération du contenu ou corriger sa présentation. C’est un résultat bien plus solide que de se contenter de savoir qu’une réponse « semblait incorrecte ».