Évaluation RAG : Tester la récupération avant d'ajuster le LLM

L'évaluation RAG devrait commencer par la récupération. Si les bonnes preuves n'atteignent jamais le modèle, l'ajustement des invites et les mises à jour du modèle ne font que rendre le mauvais contexte plus convaincant. Testez la récupération, la génération et les opérations comme des étapes séparées. Conservez un petit ensemble de régression versionné qui échoue lorsque l'une des étapes s'aggrave.

Niveau de lecteur : Intermédiaire. Ce guide suppose que vous savez que la génération augmentée par récupération, ou RAG, trouve des documents avant de demander à un modèle de langage de répondre.

Dans ce guide

L'évaluation RAG a trois surfaces d'échec séparées

Une application RAG est un pipeline. Un score pour la réponse finale cache quel composant a besoin de travail.

L'ordre est important. La récupération est en amont. Un générateur ne peut pas citer un paragraphe de politique qui n'est jamais entré dans son contexte, et une réponse fluide ne prouve pas que le récupérateur a fonctionné.

La documentation actuelle de l'évaluateur RAG de Microsoft fait la même séparation en termes d'implémentation. Elle fournit des mesures de récupération de documents pour des preuves classées, puis évalue l'ancrage, la pertinence et l'exhaustivité de la réponse au niveau de la réponse. L'évaluateur de récupération de documents inclut la fidélité, le NDCG, le XDCG, la pertinence maximale et les jugements de pertinence manquants.

_Une carte de score RAG utile garde la récupération, la génération et les vérifications opérationnelles visibles comme des couches séparées._

Pourquoi un score de bout en bout donne des preuves de débogage faibles

Plusieurs cadres de recherche atteignent la même conclusion pratique sous différents angles.

RAGChecker évalue le comportement du récupérateur et du générateur séparément. Ses auteurs ont comparé huit systèmes RAG à travers dix domaines. Leurs métriques incluent le rappel des revendications et la précision du contexte pour la récupération, plus l'utilisation du contexte, la sensibilité au bruit, l'hallucination et la fidélité pour la génération. Dans une méta-évaluation de 280 paires, le score d'évaluation globale de RAGChecker avait une corrélation de Spearman de 0.609 avec la préférence humaine. Les deux annotateurs humains ont atteint 0.689. L'évaluation automatisée était utile, mais elle n'a pas éliminé l'écart humain.

Ragas a proposé des mesures sans référence pour la fidélité, la pertinence des réponses et la pertinence du contexte. Dans ses comparaisons WikiEval, l'accord avec les préférences humaines était de 0.95 pour la fidélité, 0.78 pour la pertinence des réponses et 0.70 pour la pertinence du contexte. Les auteurs ont trouvé que la pertinence du contexte était la plus difficile à juger. Considérez ces chiffres comme des résultats de cette étude, et non comme des taux de précision universels pour chaque juge, ensemble de données ou domaine.

Un cadre plus récent, RAGe, ajoute la sélection de composants et la télémétrie matérielle. Il évalue les configurations de pipeline à travers le fractionnement, l'intégration, la récupération, le stockage et la génération tout en élaguant les combinaisons qui dépassent les limites de latence ou de VRAM. Le document utilise par défaut Natural Questions, NewsQA et TriviaQA et prend en charge des ensembles de données CSV ou JSON personnalisés. Sa principale contribution est une manière de comparer la qualité avec des contraintes de ressources ; il n'établit pas une configuration qui gagne à travers les domaines.

Ensemble, ces articles soutiennent une approche diagnostique. Ils ne prouvent pas qu'une métrique ou une bibliothèque particulière est suffisante pour la production.

Construire un ensemble de test avant de choisir des métriques

Commencez avec 40 à 60 questions du domaine que vous servez. Cette plage est un point de départ pratique plutôt qu'une loi statistique. Elle est suffisamment grande pour exposer plusieurs types d'échecs et suffisamment petite pour qu'un humain puisse revoir après chaque changement matériel.

Incluez au moins cinq classes de requêtes :

Les journaux de production peuvent suggérer des questions, mais retirez les données personnelles et les secrets avant d'ajouter des exemples à un ensemble d'évaluation. Une récente discussion de praticiens sur l'évaluation RAG en production souligne également les requêtes fixes, les configurations versionnées et les vérifications de récupération et de génération séparées. Cette discussion est une preuve anecdotiques sur la douleur du flux de travail, pas une preuve que l'approche fonctionne dans chaque système.

Conservez les jugements contre des ID de document stables aux côtés de tout texte copié. Les limites de fractionnement changent lorsque vous ajustez un fractionneur. Un ID de source canonique permet au même test de survivre à ce changement.

{ "query_id": "refund-window-01", "query": "Combien de temps un client a-t-il pour retourner un article non ouvert ?", "relevant_document_ids": ["returns-policy-v4"], "required_claims": ["Les articles non ouverts peuvent être retournés dans les 30 jours."], "must_abstain": false, "allowed_roles": ["customer", "support"], "as_of": "2026-07-01" }

Pour un cas inrépondable, définissez `relevant_document_ids` sur une liste vide et `must_abstain` sur `true`. Pour un cas restreint, exécutez la même requête sous deux rôles. L'utilisateur autorisé devrait récupérer le document ; l'utilisateur non autorisé ne devrait pas apprendre le contenu de ce document.

Les équipes construisant leur propre corpus et couche d'application devraient versionner le contrat de contenu aux côtés de l'ensemble de test. La même règle s'applique aux systèmes de données personnalisés construits avec Next.js et AI : un changement de schéma ou de contenu peut altérer la récupération sans toucher à l'invite.

Étape 1 : évaluer la récupération sans générer de réponse

Exécutez chaque requête à travers le récupérateur et enregistrez les ID de résultats classés, les scores, les horodatages et les décisions d'accès. Ne faites pas encore appel au modèle de langage.

Choisissez des métriques qui correspondent à la forme des preuves

Utilisez taux de réussite@k lorsque un document correct suffit. Cela demande si au moins une source pertinente apparaît dans les premiers `k` résultats.

Utilisez rappel@k lorsque la réponse nécessite plusieurs sources. Cela mesure combien de documents pertinents connus sont apparus dans les premiers `k`.

Utilisez précision@k lorsque le contexte non pertinent est coûteux ou distrayant. Un haut rappel avec une faible précision peut inonder le générateur de bruit.

Utilisez MRR lorsque le premier résultat pertinent est le plus important. Utilisez NDCG lorsque plusieurs résultats notés doivent apparaître dans un ordre utile. Microsoft documente le NDCG et les mesures de récupération classées connexes dans son évaluateur, tandis que RAGChecker utilise le rappel des revendications et la précision du contexte pour relier les preuves récupérées aux revendications dont une réponse a besoin.

Ne collectez pas chaque métrique par défaut. Choisissez une mesure de couverture et une mesure de classement ou de bruit. Ajoutez une métrique uniquement lorsqu'elle change une décision.

Classifiez les échecs avant de changer le modèle

Les échecs de récupération tombent généralement dans un petit ensemble :

Chaque échec a un propriétaire différent. La réintégration ne peut pas réparer un document manquant. Un modèle de langage plus grand ne peut pas réparer un filtre d'autorisations. Un reranker peut aider lorsque la preuve est présente mais mal ordonnée.

Pour les applications connectées aux outils, conservez la demande de récupération, les filtres, les ID de résultats et la réponse de l'outil dans la trace. Cela s'inscrit dans le modèle de contrôle plus large décrit dans les flux de travail des développeurs MCP : inspectez le contrat, la transition d'état et la prose finale.

Étape 2 : évaluer la génération sur des preuves fixes

Une fois que la récupération atteint son seuil, figez les contextes récupérés et rejouez-les contre le générateur. Cela isole les changements d'invite ou de modèle des changements d'index.

Mesurez quatre comportements :

Une réponse de référence peut aider à l'exhaustivité. Elle est moins utile en tant que seule source de vérité car plusieurs formulations peuvent être correctes. Conservez les revendications requises et les ID de documents de soutien lorsque cela est possible.

Exécutez un deuxième test de génération avec un contexte délibérément incomplet. Un système fiable devrait exposer l'incertitude plutôt que de combler les lacunes à partir de la mémoire du modèle. Cela est important lorsque le corpus contient des faits privés, changeants ou spécifiques à un domaine.

Le choix du modèle affecte toujours la qualité de la réponse, la latence et le coût, mais cela vient après les preuves de récupération. Si le même contexte fixe échoue à travers les générateurs, comparez les compromis entre modèles et API. Si le contexte lui-même est incorrect, changer le générateur est un mouvement inutile.

Ajouter des cas de sécurité et de conflit à l'ensemble de récupération

Les tests de pertinence ordinaires manquent de preuves adversariales ou conflictuelles.

Un article de juillet 2026 sur le poisoning sybil polymorphe dans RAG a testé des groupes de passages lexicalement différents qui soutenaient la même réponse sélectionnée par l'attaquant. Dans la configuration d'exposition forcée de l'article, les passages polymorphes ont produit un taux de détournement de 22.8 % contre 4.0 % pour les passages monomorphes répétés. Le filtrage par chevauchement de tokens a capturé tous les clusters monomorphes et aucun des clusters polymorphes.

Le résultat ne mesure pas à quelle fréquence cette attaque réussit en production. Les auteurs ont fixé le mélange récupéré à six passages d'attaque, deux passages d'or et deux remplisseurs pour isoler le comportement du lecteur. Ils rapportent également des limitations autour d'une classe d'attaque, du risque de contamination des ensembles de données, d'une ablation de 500 questions et de vérification basée sur LLM.

La leçon d'évaluation utile est plus étroite : classifiez plus que "correct" et "cible de l'attaquant". L'article suit quatre résultats :

Ajoutez des cas de conflit à votre propre ensemble. Incluez des revendications dupliquées avec des formulations différentes, une source obsolète qui contredit la politique actuelle, et une source de confiance inférieure qui entre en conflit avec une source autoritaire. Enregistrez si le système répond, s'abstient ou dérive.

Calibrer les juges LLM avant de faire confiance à leurs scores

Les juges LLM rendent les tests de régression moins coûteux, surtout pour l'ancrage et la couverture des revendications. Ils restent des dépendances logicielles avec des invites, des versions de modèle, un comportement d'analyse et des angles morts connus.

Utilisez quatre contrôles :

Les études Ragas et RAGChecker montrent toutes deux pourquoi la calibration est importante. L'accord varie selon la dimension, et les corrélations automatisées restent en dessous de l'accord humain. Un score numérique devrait déclencher une inspection, pas la terminer.

Les versions open-source actuelles montrent également un travail actif autour des évaluateurs. DeepEval 4.1.3, publié le 12 juillet 2026, a ajouté des vérifications déterministes pour les boucles d'agents et les autorisations d'outils tout en corrigeant l'intégration de Ragas. TruLens 2.9.0, publié le 23 juillet, a ajouté des ensembles de juges, des tests de critères A/B, une analyse de distribution des scores et une génération d'ensemble d'or. L'activité de publication est une preuve d'un travail d'ingénierie maintenu, pas une preuve que l'une ou l'autre bibliothèque est le bon choix pour votre pile.

Un flux de travail de régression RAG minimal

Utilisez la même séquence pour chaque changement matériel de pipeline :

Un enregistrement de résultats compact peut ressembler à ceci :

{ "run_id": "rag-2026-07-26-b", "test_set": "support-v7", "corpus_snapshot": "2026-07-25T22:00:00Z", "retrieval": { "recall_at_5": 0.91, "ndcg_at_5": 0.84, "unauthorized_hits": 0 }, "generation": { "grounded_pass_rate": 0.94, "complete_pass_rate": 0.87, "abstention_pass_rate": 0.90 }, "operations": { "p95_ms": 1380, "cost_per_query_usd": 0.0042 } }

Ces chiffres sont illustratifs. Définissez des seuils en fonction de votre risque, de votre référence et de votre coût d'erreur. Un assistant de connaissances médicales et un assistant de recherche de produits ne devraient pas partager la même porte de sortie.

Décidez de la solution à partir de la couche échouée

Ce tableau est le point de l'évaluation RAG : un score échoué devrait identifier la prochaine expérience. S'il ne peut pas, la métrique est trop éloignée du composant que vous devez changer.

Ce que les preuves soutiennent

Les articles ont mesuré des systèmes et des ensembles de données spécifiques. RAGChecker a trouvé que les métriques modulaires peuvent corréler avec les préférences humaines et exposer les compromis entre récupérateur et générateur. Ragas a trouvé que l'accord des juges variait selon la fidélité, la pertinence des réponses et la pertinence du contexte. RAGe a démontré un cadre qui combine des métriques de qualité avec des contraintes de latence et de mémoire. Le benchmark de poisoning a montré qu'une configuration d'attaque contrainte produisait des modèles distincts de détournement, d'abstention et de dérive.

Les preuves n'établissent pas de seuils universels, d'évaluateur universellement meilleur, ou de prévalence d'attaques en production. Mon interprétation pratique est de séparer les étapes, de garder une tranche calibrée par des humains et d'exiger que chaque métrique pointe vers une action d'ingénierie.

Vérifications des revendications

Sources