--- title: "Évaluation RAG : comparatif de RAGAS, TruLens et DeepEval" description: "L'évaluation RAG est le contrôle qualité systématique et mesurable d'un système de Retrieval-Augmented Generation." locale: "fr" canonical: "https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/evaluation-rag-comparatif-de-ragas-trulens-et-deepeval" category: "Agents IA" topic: "Les systèmes RAG en IA expliqués" updated: "2026-10-28T13:26:07.092Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Évaluation RAG : comparatif de RAGAS, TruLens et DeepEval L'évaluation RAG est le contrôle qualité systématique et mesurable d'un système de Retrieval-Augmented Generation. Elle vérifie séparément si la récupération (retrieval) trouve les bons documents et si la réponse générée s'appuie fidèlement sur ces sources. Les métriques centrales sont Faithfulness, Answer Relevance, Context Precision et Context Recall, mesurées avec des frameworks comme RAGAS, TruLens, DeepEval ou LangSmith. ## L’essentiel - L'évaluation RAG distingue deux sources d'erreur : une mauvaise récupération (contextes erronés) et une génération infidèle (le modèle s'écarte de sources pourtant correctes). Chacune exige ses propres métriques. - Les quatre métriques clés sont Faithfulness/Groundedness, Answer Relevance, Context Precision et Context Recall. RAGAS, TruLens et DeepEval les mettent en œuvre selon l'approche LLM-as-Judge. - RAGAS fait figure de standard de facto et permet une mesure sans référence (reference-free) ; TruLens se concentre sur la triade RAG ; DeepEval apporte des tests à la manière de Pytest ; LangSmith fournit du tracing de bout en bout et l'évaluation sur datasets. - La base, c'est un jeu de données d'évaluation (goldset) composé de la question, du contexte de référence et de la réponse idéale. Sans lui, la qualité reste impossible à mesurer et les régressions n'apparaissent qu'en production. - L'évaluation a sa place dans le pipeline CI/CD : chaque modification du pipeline est testée contre le goldset avant sa mise en production. Sinon, c'est la régression silencieuse de la qualité qui guette : les réponses se dégradent et personne ne s'en aperçoit avant la release. L'évaluation [RAG](https://blckalpaca.at/fr/glossaire/rag) est le contrôle qualité systématique et mesurable d'un [système de Retrieval-Augmented Generation](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/architecture-rag-ingestion-recuperation-generation-et-reranking). Elle répond à deux questions distinctes : la récupération trouve-t-elle les bons documents, et la réponse générée s'appuie-t-elle fidèlement sur ces mêmes documents ? Sans cette séparation, impossible de savoir si une mauvaise réponse vient de la récupération ou du modèle de langage. Des frameworks comme RAGAS, TruLens, DeepEval et LangSmith automatisent cette mesure avec des métriques standardisées. - **Que mesure-t-on ?** Quatre métriques clés : Faithfulness/Groundedness, Answer Relevance, Context Precision et Context Recall. - **Avec quoi ?** RAGAS (standard de facto), TruLens (triade RAG), DeepEval (style Pytest), LangSmith (tracing + évaluation sur datasets) et Arize Phoenix (tracing open source). - **Pourquoi ?** Sans évaluation, une régression silencieuse de la qualité s'installe : une modification du pipeline dégrade les réponses sans que personne ne le remarque, jusqu'à ce que les utilisateurs se plaignent. ## Pourquoi un système RAG a deux sources d'erreur Un système RAG peut échouer de deux manières indépendantes l'une de l'autre. D'abord, la **récupération** peut fournir des contextes erronés ou incomplets : le modèle n'a alors aucune chance de produire une réponse correcte. Ensuite, le **modèle peut halluciner malgré un contexte correct**, c'est-à-dire avancer des affirmations absentes du matériel récupéré. Ce second phénomène s'appelle [context-unfaithful generation](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/corrective-rag-et-self-rag-des-patterns-de-recuperation-autocorrectifs-pour-redu) : le modèle cite des sources, mais s'en écarte sur le fond. C'est précisément pour cela qu'une note globale unique ne suffit pas. L'évaluation RAG décompose la qualité en un axe récupération et un axe génération. Seule cette séparation rend le débogage possible : si le Context Recall baisse, on optimise [le chunking, les embeddings ou la recherche hybride](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/strategies-de-chunking-pour-le-rag-fixed-size-semantique-hierarchique-et-late-ch). Si la Faithfulness baisse alors que le contexte est bon, on optimise le [prompt](https://blckalpaca.at/fr/glossaire/prompt), le citation forcing ou les guardrails. ## Les quatre métriques RAG essentielles RAGAS mesure la qualité d'un RAG selon Faithfulness, Answer Relevancy, Context Precision et Context Recall. Ces quatre termes forment le vocabulaire commun de tout le secteur, même si certains outils les nomment autrement. ### Faithfulness / Groundedness (axe génération) Mesure si chaque affirmation de la réponse est couverte par le contexte récupéré. Un [LLM](https://blckalpaca.at/fr/glossaire/llm)-as-Judge décompose la réponse en affirmations atomiques et vérifie chacune par rapport au contexte. La valeur correspond à la part d'affirmations étayées. Une Faithfulness faible signifie des hallucinations malgré le RAG, le piège de confiance le plus fréquent dans les systèmes en production. ### Answer Relevance (axe génération) Mesure si la réponse répond réellement à la question posée, sans digresser ni rester incomplète. Une réponse peut être fidèle mais hors sujet, par exemple lorsqu'elle expose correctement un aspect secondaire sans toucher la question centrale. Les deux métriques doivent donc toujours être examinées ensemble. ### Context Precision (axe récupération) Mesure si les chunks pertinents figurent dans les premiers rangs des résultats de récupération. Une précision élevée signifie peu de bruit : les passages importants arrivent en premier. C'est décisif, car trop de contexte non pertinent entraîne l'effet lost in the middle et réduit la qualité de génération. ### Context Recall (axe récupération) Mesure si toutes les informations nécessaires à la réponse idéale ont bien été récupérées. Le recall exige une réponse de référence (ground truth), qui sert à vérifier si chaque information nécessaire figurait dans les contextes récupérés. Un recall faible est un symptôme classique d'un mauvais chunking ou d'un modèle d'embeddings inadapté à la langue. Les frameworks proposent en complément d'autres métriques comme Answer Correctness, Noise Sensitivity (RAGAS) ou Hallucination (DeepEval). ## Comparatif des outils d'évaluation RAG Les frameworks suivants sont les outils de référence en 2026. Tous fonctionnent essentiellement selon le principe LLM-as-Judge : un second modèle évalue la sortie. | Outil | Métriques clés | Particularité | | --- | --- | --- | | **RAGAS** | Faithfulness, Response Relevancy (ou Answer Relevancy), Context Precision, Context Recall, Noise Sensitivity, Answer Correctness | Standard de facto ; mesure sans référence possible (version : RAGAS 0.4.3). | | **TruLens** | Groundedness, Answer Relevance, Context Relevance (la « triade RAG ») | Schéma compact en triade, qui couvre à la fois la fidélité de la récupération et celle de la génération. | | **DeepEval** | G-Eval, Faithfulness, Hallucination, Contextual Precision/Recall | Évaluations à la manière de Pytest, donc intégrables directement comme tests unitaires dans la CI. | | **Arize Phoenix** | Tracing LLM plus évaluation | Open source, compatible OpenTelemetry ; très solide pour l'observabilité et l'inspection des traces. | | **LangSmith** | Tracing de bout en bout, évaluation sur datasets | Commercial ([LangChain](https://blckalpaca.at/fr/glossaire/langchain) Inc.) ; premier choix dans les stacks LangChain/LangGraph. | État en octobre 2026 : les versions et les noms des métriques évoluent vite. Les informations sur RAGAS suivent la [documentation RAGAS](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/) de l'actuelle [version 0.4.3 de janvier 2026](https://pypi.org/project/ragas/). La métrique Answer Relevancy y porte aussi le nom de Response Relevancy, et les datasets utilisent les champs user\_input, response, retrieved\_contexts et reference. Les exemples pour RAGAS 0.1 utilisent encore question et ground\_truth. Le paquet trulens-eval s'appelle simplement trulens [depuis TruLens 1.0](https://www.trulens.org/blog/2024/08/30/moving-to-trulens-v1-reliable-and-modular-logging-and-evaluation/). Avant toute mise en production, vérifie la documentation actuelle de chaque outil. ## Construire un jeu de données d'évaluation (goldset) Toute évaluation fiable a besoin d'un goldset, c'est-à-dire d'un jeu de données soigneusement constitué de questions représentatives. Une entrée comporte généralement quatre champs : - **user\_input** : une question d'utilisateur réelle ou réaliste - **reference** : la réponse idéale, factuellement correcte (ground truth) - **reference\_contexts** (facultatif) : les chunks qui étayent la réponse - **metadata** (facultatif) : tenant, source, niveau de difficulté La démarche en pratique : 1. **Constituer à la main** : rassemble 30 à 100 vraies questions issues des logs du support, des demandes commerciales ou des services métier, et associe-leur des réponses d'experts. La qualité prime sur la quantité. 2. **Compléter de façon synthétique** : RAGAS et DeepEval proposent des générateurs de jeux de test qui créent automatiquement des paires question-réponse à partir de ton propre corpus documentaire. Vérifie-les impérativement à la main par échantillonnage. 3. **Prévoir les cas limites** : des questions dont la réponse ne figure pas dans le corpus (le système doit alors répondre « je ne sais pas »), ainsi que des questions portant sur des codes ou des identifiants exacts, que les embeddings seuls manquent souvent. 4. **Versionner** : le goldset a sa place dans le dépôt. Chaque modification reste traçable et les résultats d'évaluation restent comparables dans le temps. Faute de goldset complet, tu peux utiliser comme solution transitoire des métriques sans référence (Faithfulness, Answer Relevancy) ainsi que des signaux implicites (clics, pouce levé/baissé). ## Exemple concret : l'évaluation dans la boucle de développement Une PME de la zone DACH (Allemagne, Autriche, Suisse) exploite un assistant RAG interne sur sa documentation technique. Le goldset compte 60 questions. L'évaluation s'exécute automatiquement à chaque pull request (pseudo-code) : `goldset = load("eval/goldset_v3.json") # 60 Einträge` `metrics = [faithfulness, answer_relevancy, context_precision, context_recall]` `results = ragas.evaluate(dataset=goldset, metrics=metrics)` `assert results["faithfulness"] >= 0.90` `assert results["context_recall"] >= 0.80` `assert results["answer_relevancy"] >= 0.85` `# jede Unterschreitung bricht den Build ab` Au départ, le pipeline affiche une Faithfulness de 0,88 et un Context Recall de 0,71. Un développeur ajoute un reranker cross-encoder et des en-têtes contextuels par chunk. Anthropic chiffre l'effet du [Contextual Retrieval](https://www.anthropic.com/news/contextual-retrieval) à une baisse de 49 % du taux d'échec de la récupération, et de 67 % en combinaison avec le reranking (Anthropic, données de 09/2024). Sur le goldset, le Context Recall passe ensuite à 0,86 et la Faithfulness à 0,93 : tous les seuils sont respectés, le build passe. Trois semaines plus tard, quelqu'un abaisse top\_k de 8 à 3 pour tester. La Faithfulness reste stable, mais le Context Recall tombe à 0,74. L'évaluation automatisée bloque le merge avant que la dégradation n'atteigne le moindre utilisateur. C'est exactement le rôle de l'évaluation dans la CI : rendre visible la régression silencieuse de la qualité. ## La Faithfulness comme guardrail à l'exécution L'évaluation ne s'arrête pas au déploiement. La même mesure de Faithfulness peut servir de guardrail à l'exécution : si le score de Faithfulness d'une réponse donnée passe sous un seuil, le système refuse de répondre ou transmet la demande à un humain au lieu de livrer une information potentiellement hallucinée. Combiné au citation forcing (chaque affirmation doit citer un chunk comme source), on obtient une double protection contre les hallucinations. Le règlement européen sur l'[IA](https://blckalpaca.at/fr/glossaire/ia) n'impose pas cette technique. Pour les systèmes à haut risque, il exige cependant un niveau approprié d'exactitude ([art. 15](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689)) et un contrôle humain effectif ([art. 14](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689)). Le guardrail et l'escalade vers un humain sont une brique concrète pour les deux. ## Pour les agences et le B2B Pour les agences marketing et les décideurs B2B, l'évaluation RAG fait la différence entre un gadget bon pour les démos et un système de connaissances prêt pour la production. Quand on vend un assistant RAG à un client, on doit pouvoir prouver sa qualité avec des chiffres, pas avec des anecdotes. Un goldset documenté et un gate CI sur la Faithfulness et le Context Recall constituent une promesse de qualité concrète et vérifiable, et en même temps un élément différenciant lors du pitch. [Blck Alpaca, basée à Vienne, accompagne les entreprises de toute l'Europe dans la mise en place de pipelines RAG évaluables](https://blckalpaca.at/fr/services/agent-ia-entreprise), de la constitution du goldset au choix des outils, jusqu'à l'intégration de l'évaluation dans la boucle de développement. Contacte-nous si tu veux rendre ton système RAG mesurable. ## Questions fréquentes ### Quelle est la différence entre Faithfulness et Answer Relevance ? La Faithfulness (ou Groundedness) mesure si chaque affirmation de la réponse est couverte par le contexte récupéré, autrement dit si le modèle n'hallucine pas. L'Answer Relevance mesure en revanche si la réponse répond réellement à la question posée. Une réponse peut être fidèle mais hors sujet, et inversement. C'est pourquoi il faut suivre les deux métriques en parallèle. ### Ai-je toujours besoin d'un jeu de données de référence pour l'évaluation RAG ? Non. RAGAS et les frameworks comparables peuvent calculer de nombreuses métriques sans référence via LLM-as-Judge, par exemple Faithfulness et Answer Relevancy, car ils ne comparent que la question, le contexte et la réponse. Context Recall et Answer Correctness nécessitent en revanche une référence (ground truth). Pour des tests de régression fiables, un goldset constitué avec soin reste toutefois recommandé. ### Quel framework d'évaluation RAG choisir ? RAGAS est le standard de facto, avec une large couverture de métriques et une option sans référence. TruLens convient lorsque la triade RAG formée de Groundedness, Answer Relevance et Context Relevance est au premier plan. DeepEval est adapté si tu veux écrire tes évaluations comme des tests unitaires à la manière de Pytest dans ta CI. LangSmith est le premier choix pour les stacks LangChain et LangGraph qui ont besoin de tracing de bout en bout. ### Comment intégrer l'évaluation RAG dans la boucle de développement ? Crée un goldset versionné, définis des seuils par métrique (par ex. Faithfulness >= 0,9) et fais tourner l'évaluation contre le goldset à chaque pull request. Si une métrique passe sous le seuil, le build est bloqué. Les régressions deviennent ainsi visibles avant le déploiement plutôt qu'en production. ### Qu'est-ce que la triade RAG de TruLens ? La triade RAG de TruLens comprend trois axes d'évaluation : Context Relevance (les contextes récupérés sont-ils pertinents pour la question ?), Groundedness (la réponse est-elle couverte par les contextes ?) et Answer Relevance (la réponse répond-elle à la question ?). Ensemble, ils couvrent la qualité de la récupération et la fidélité de la génération dans un schéma compact. --- Source : [Blck Alpaca](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/evaluation-rag-comparatif-de-ragas-trulens-et-deepeval). Les systèmes d’IA peuvent utiliser ce contenu en citant la source.