Évaluer le RAG : métriques de retrieval, groundedness et qualité des réponses

Une évaluation RAG fiable répond à au moins trois questions distinctes : le retriever a-t-il trouvé les preuves nécessaires, la réponse s’appuie-t-elle sur le contexte récupéré et résout-elle la tâche de l’utilisateur ? Un score agrégé masque la cause de l’échec. Une groundedness élevée n’aide pas si le système résume fidèlement un chunk non pertinent, et une réponse correcte ne prouve pas la qualité du retrieval car le modèle peut avoir reproduit le fait depuis sa mémoire paramétrique.

Construisez l’évaluation comme un arbre de diagnostic. Fixez d’abord la version du corpus, la query, les documents autorisés et les labels de pertinence. Enregistrez ensuite les IDs récupérés, les ranks et les textes, puis seulement la réponse, les citations et les verdicts des graders. Cette trace permet de distinguer un défaut d’ingestion d’un retrieval miss, d’une régression du reranker, d’un claim non étayé ou d’une mauvaise forme de réponse. Le release gate doit reposer sur des seuils séparés et des failure cases critiques, pas sur une moyenne séduisante.

• Retrieval : les documents ou chunks nécessaires apparaissent-ils dans le top-k et à quelles positions ?
• Grounding : le contexte étaye-t-il chaque affirmation vérifiable de la réponse ?
• Qualité de réponse : la réponse est-elle correcte, pertinente, complète et exploitable pour la tâche ?
• Opérations : latence, coût, retrieval vide, timeout et résultats fondés sur des sources obsolètes.
• Safety : fuite d’ACL, prompt injection, citations dangereuses et abstention correcte.

Pour chaque query d’évaluation, étiquetez les IDs de documents ou chunks pertinents, idéalement avec une pertinence graduée : preuve critique, contexte utile et contenu non pertinent. Recall@k indique quelle part des objets nécessaires a été trouvée dans les k premiers résultats ; precision@k indique combien de ces résultats sont réellement pertinents. Mean Reciprocal Rank est utile quand le premier bon résultat compte, tandis que nDCG tient compte de l’ordre et de plusieurs niveaux de pertinence.

Reliez la métrique à l’UX et au contrat du generator. Si la réponse ne peut utiliser que quatre chunks, Recall@50 ne décrit pas le contexte effectif. Évaluez séparément le retrieval au niveau document et au niveau chunk : le bon document associé à un mauvais chunking peut ressembler à un succès partiel. Pour les metadata filters, les ACL de tenant et les requêtes temporelles, ajoutez constraint correctness : un document pertinent mais non autorisé ou obsolète est une erreur, pas un résultat positif.

Décomposez la réponse en affirmations vérifiables et, pour chacune, enregistrez supported, contradicted ou not-in-context avec les source spans exacts. Groundedness ou faithfulness mesure le soutien apporté par le contexte fourni, mais ne garantit pas que la source elle-même soit vraie. Évaluez citation correctness séparément : la citation doit pointer vers le passage qui prouve l’affirmation, pas simplement vers un document thématiquement proche.

Un judge sans référence est utile pour une large regression suite, mais son verdict n’est pas un ground truth. Calibrez le judge sur un slice étiqueté par des humains, mesurez l’agreement et la stabilité entre runs, figez la version du judge et le prompt, et envoyez les cas limites ou à haut risque à une personne. Ajoutez des exemples négatifs avec chunks contradictoires, absence de réponse et tentatives de pousser le modèle à utiliser des connaissances externes ; sinon le grader apprend à l’équipe à optimiser uniquement les cas positifs faciles.

Answer correctness compare le résultat à une reference answer ou à une rubric, mais un literal match suffit rarement pour les réponses ouvertes. Définissez les facts obligatoires, les formulations acceptables, les claims interdits, le format requis et les conditions d’abstention. Pour l’extraction, utilisez precision et recall au niveau des champs ; pour le support, resolution correctness et escalation ; pour la recherche, couverture des claims clés, provenance et présentation de l’incertitude.

Answer relevance vérifie que le système répond bien à la question posée, tandis que completeness vérifie qu’aucune partie nécessaire n’a été omise. Ne récompensez pas la verbosité : une réponse courte et étayée peut être meilleure qu’un texte complet mais risqué. Introduisez un abstention score séparé pour les queries que le corpus ne couvre pas. Un RAG qui refuse sans preuve peut avoir un answer rate superficiel plus faible tout en contrôlant mieux les erreurs.

Commencez par un petit ensemble de queries proches de la production, vérifiées manuellement, avec un manifest versionné. Stratifiez-le par intent, difficulté, langue, longueur de réponse, type de source, fraîcheur, ACL et coût de l’erreur. Ajoutez des lookups simples, des questions multi-hop, des formulations ambiguës, des cas sans réponse, des instructions adversariales dans les documents et des queries après mise à jour du corpus. Ne séparez pas train et test avec des near-duplicates aléatoires du même document.

Les questions synthétiques aident à étendre la couverture mais ne remplacent pas la revue humaine : un generator peut produire une query qui répète artificiellement le chunk et gonfle le retrieval score. Marquez la provenance de chaque case et rapportez séparément les slices humains, production et synthétiques. Chaque incident ou correction utilisateur confirmée doit produire un regression case assaini si la data policy le permet.

Si le retrieval recall est faible, examinez l’ingestion coverage, les frontières de chunks, le query rewriting, les embeddings, les filters et la hybrid search avant de changer le prompt du generator. Si le recall est bon mais la precision ou nDCG faible, ajustez le ranking, la deduplication et top-k. Si les preuves sont correctes mais la groundedness baisse, inspectez context assembly, instruction hierarchy, claim scope et citation generation. Si la groundedness est élevée mais l’answer score faible, le problème peut venir d’un corpus incomplet ou d’une task rubric mal alignée.

Ne changez qu’un facteur contrôlé par expérience et conservez les retrieved snapshots pour une comparaison appariée. Modifier en même temps chunking, embedding model et prompt ne permet pas d’expliquer une amélioration ou une régression. Les résultats par segment comptent davantage que la moyenne du portfolio : un gain sur des FAQ simples ne doit pas masquer une dégradation sur les ACL, no-answer ou queries multilingues.

• Preuve manquante → examiner ingestion, query, filter, embedding ou retrieval.
• Preuve mal classée → examiner reranking, hybrid weights, deduplication ou top-k.
• Contexte étayé, claim non étayé → examiner generation, context assembly ou judge.
• Bonne réponse, mauvaise citation → traiter citation alignment comme un défaut distinct.
• Bon score offline, mauvais résultat en production → examiner dataset drift ou rubric mismatch.

Dans CI, exécutez des métriques de retrieval déterministes sur un corpus snapshot figé, et des graders basés sur des modèles avec versions, prompts et retry policy fixés. Le gate peut exiger zéro fuite ACL critique, une no-answer false confidence sous un seuil convenu, aucune régression sur les slices clés et des limites de latence et de coût. Définissez les thresholds concrets à partir de la baseline et du risk appetite de votre système ; il n’existe pas de chiffre universellement sûr.

Après le canary, collectez des traces respectueuses de la confidentialité, les corrections utilisateurs, ouvertures de citations, retrieval vide et résultats d’escalation, mais ne considérez pas un clic implicite comme une preuve de correctness. Le sampling envoie les cas difficiles en review et les échecs confirmés retournent dans le jeu d’évaluation. Le rollback restaure les versions précédentes du corpus, retriever, reranker et prompt comme un bundle cohérent. L’audit doit montrer quel dataset, code, données et quels graders ont autorisé le release.