Évaluation RAG
L'évaluation RAG est la méthodologie permettant de mesurer quantitativement dans quelle mesure un pipeline RAG récupère un bon contexte et génère des réponses exactes. Comme les LLM génèrent librement, vous ne pouvez pas juger la qualité par de simples comparaisons entrée-sortie comme vous testez un logiciel ordinaire : des frameworks d'évaluation dédiés sont devenus la boîte à outils standard du développement RAG en 2026.
L'évaluation RAG est la méthodologie permettant de mesurer quantitativement dans quelle mesure un pipeline RAG récupère un bon contexte et génère des réponses exactes. Comme les LLM génèrent librement, vous ne pouvez pas juger la qualité par de simples comparaisons entrée-sortie comme vous testez un logiciel ordinaire : des frameworks d'évaluation dédiés sont devenus la boîte à outils standard du développement RAG en 2026.
Pourquoi c'est important
Les systèmes RAG se composent de plusieurs étapes (réécriture de requête → recherche vectorielle → reranking → injection de contexte → génération par le LLM → citation) et chaque étape peut échouer indépendamment. Une seule étape défaillante effondre la qualité des réponses, mais se contenter de regarder "la réponse finale était-elle bonne ?" ne vous dit pas quelle étape a échoué. Une recherche de Stanford HAI estime qu'environ 35 % des systèmes RAG en production souffrent d'hallucinations, de recherches manquées ou de citations défaillantes, impossibles à corriger sans une évaluation systématique.
Métriques principales
Qualité de la recherche
- Context Precision : proportion des fragments récupérés qui sont réellement pertinents
- Context Recall : proportion des fragments réellement pertinents (vérité terrain) qui ont été récupérés
- MRR (Mean Reciprocal Rank) : rang réciproque moyen du premier fragment pertinent
- NDCG (Normalized DCG) : métrique RI standard combinant pertinence et rang
Qualité de la génération
- Faithfulness : la réponse découle-t-elle réellement du contexte fourni ? L'opposé de l'hallucination.
- Answer Relevance : dans quelle mesure la réponse correspond-elle à la question ?
- Answer Correctness : la réponse est-elle réellement juste (par rapport à la vérité terrain) ?
- Answer Completeness : a-t-elle traité tous les aspects de la question ?
Qualité des citations
- Citation Precision : les sources citées soutiennent-elles réellement l'affirmation ?
- Citation Recall : proportion des affirmations de la réponse qui sont accompagnées de citations de sources.
Principaux frameworks d'évaluation
Ragas : bibliothèque open source pour l'évaluation RAG. Mesure automatiquement Context Precision, Faithfulness, Answer Relevance et plus encore, selon une approche "LLM-as-Judge".
TruLens : traçage et évaluation intégrés pour les applications RAG et LLM, couvrant du développement à la surveillance en production.
LangSmith : outil d'évaluation et d'observation de LangChain avec comparaison d'expériences, débogage de traces et gestion de jeux de données.
ARES : framework d'évaluation de niveau académique utilisant des données synthétiques pour un benchmarking automatique.
Jeux d'évaluation personnalisés : les plus importants en pratique. Rassemblez 50 à 500 requêtes utilisateur réelles avec des réponses de vérité terrain et utilisez-les comme jeu de tests de non-régression.
Limites du LLM-as-Judge
La plupart des frameworks modernes s'appuient sur "demander à un autre LLM de noter la qualité de la réponse" (LLM-as-Judge). C'est rapide et peu coûteux, mais comporte des réserves.
- Biais du juge : les LLM juges privilégient certains styles, certaines longueurs ou certaines familles de modèles.
- Écarts de cohérence : la même entrée peut ne pas produire le même score. Atténuez avec une température de 0 et en moyennant sur plusieurs exécutions.
- Factualité complexe : les jugements nécessitant une expertise du domaine requièrent encore une vérification humaine.
Associez toujours les décisions critiques à une relecture humaine.
Conseils pratiques
Évaluer étape par étape : n'évaluez pas tout le pipeline d'un coup. Mesurez séparément la recherche, le reranking et la génération pour localiser les goulots d'étranglement.
Tests de non-régression : remesurez avec le même jeu d'évaluation chaque fois que le code, les prompts ou les modèles changent afin de détecter les régressions.
Surveillance en production : évaluez en continu un échantillon aléatoire de réponses réelles avec le LLM-as-Judge pour détecter la dérive.
Connecter aux retours utilisateur : corrélez les pouces levés/baissés et les clics de régénération avec les métriques d'évaluation.
Sources :