RAGAS vs TruLens vs DeepEval lequel choisir ?

Pour choisir entre RAGAS, TruLens et DeepEval, je regarde d’abord ce qu’on veut mesurer dans le RAG. La recherche, la réponse, ou le système complet en production. Le piège, c’est de juger une réponse sans savoir si le bon contexte a été récupéré.

Pourquoi le RAG se mesure autrement ?

Le RAG se mesure autrement parce qu’il mélange deux systèmes qui peuvent échouer séparément : le retriever, donc le moteur qui va chercher les bons morceaux de documents, et le générateur, donc le modèle qui rédige la réponse à partir de ce contexte.

C’est ça qui rend l’évaluation plus délicate qu’un simple test de qualité de texte. Un pipeline RAG peut donner une mauvaise réponse pour des raisons très différentes. Le moteur de recherche peut remonter des chunks hors sujet, trop courts, incomplets, ou juste pas assez solides pour répondre. Et parfois, c’est l’inverse. Le bon contexte est bien là, mais le modèle l’ignore, le résume mal, le déforme, ou hallucine quand même avec beaucoup d’assurance.

J’ai vu ça plusieurs fois chez des clients. Des réponses très propres, bien écrites, presque convaincantes. Mais quand on cherche dans les sources, impossible de retrouver ce qui justifie l’affirmation. C’est exactement le genre de problème qu’une évaluation RAG doit faire ressortir. Pas juste “la réponse semble bonne”, mais “la réponse est-elle vraiment traçable dans les documents récupérés ?”.

Les métriques NLP classiques comme BLEU ou ROUGE deviennent vite limitées ici. BLEU et ROUGE comparent surtout une réponse générée à une réponse de référence, en regardant les mots ou les séquences de mots en commun. C’est utile pour certaines tâches de traduction ou de résumé, mais ça ne dit pas vraiment si la réponse est grounded, c’est-à-dire ancrée dans le contexte fourni au modèle.

Pour évaluer correctement un RAG, je sépare toujours trois niveaux :

• La récupération : Est-ce que les bons chunks sont retrouvés ? Est-ce qu’ils sont pertinents, complets, exploitables ?
• La génération : Est-ce que le modèle répond correctement à partir du contexte ? Est-ce qu’il évite d’inventer ?
• L’expérience utilisateur : Est-ce que la réponse est utile, claire, fiable, et suffisamment sourcée pour être utilisée ?

Si on mélange tout, on ne sait plus où agir. On peut changer le prompt alors que le vrai problème vient de l’indexation. Ou réentraîner un retriever alors que le modèle hallucine malgré un bon contexte. On ne peut pas améliorer proprement un système si on ne sait pas où il casse.

Quelles couches faut-il évaluer ?

Il faut évaluer trois couches : la récupération, la génération et le résultat bout en bout. Si vous ne regardez qu’une seule couche, vous risquez de corriger le mauvais problème. Je l’ai vu plusieurs fois chez des clients : le modèle était accusé d’halluciner, alors que le vrai souci venait juste du moteur de recherche qui remontait les mauvais passages.

La première couche, c’est la récupération. On veut savoir si les bons chunks ont été retrouvés. Un chunk, c’est simplement un morceau de document découpé pour être indexé puis envoyé au modèle. Là, les bonnes questions sont simples : Est-ce que les passages utiles sont présents dans le top K ? Est-ce qu’ils sont bien classés ? Est-ce qu’ils arrivent assez haut pour être réellement utilisés ?

C’est là qu’on retrouve des métriques comme Precision@K, Recall@K, MRR et NDCG. Precision@K regarde la qualité des résultats dans les K premiers. Recall@K vérifie si on a bien récupéré les éléments attendus. MRR mesure à quelle position apparaît le premier bon résultat. NDCG ajoute une idée de classement, avec plus de poids pour les bons résultats placés très haut.

La deuxième couche, c’est la génération. Ici, on ne juge plus seulement les documents retrouvés, mais la façon dont le modèle s’en sert. Est-ce qu’il répond vraiment à la question ? Est-ce qu’il reste fidèle aux sources ? Est-ce qu’il invente des éléments absents du contexte ?

Les notions importantes sont faithfulness, answer relevancy et groundedness. Faithfulness mesure si la réponse respecte les informations fournies. Answer relevancy mesure si la réponse colle bien à la demande utilisateur. Groundedness vérifie si chaque affirmation importante peut être rattachée au contexte.

La troisième couche, c’est l’évaluation bout en bout. Elle vérifie si la réponse finale satisfait vraiment l’utilisateur, même si les composants internes semblent corrects. Certains frameworks automatisent ça avec un LLM judge, c’est-à-dire un modèle qui évalue un autre modèle. D’autres acceptent des références humaines. D’autres sont meilleurs pour suivre la qualité en continu, en production, avec du monitoring.

Couche	Questions à se poser	Signaux utiles	Risque si on ne mesure pas
Récupération	Est-ce que les bons chunks remontent assez haut ?	Precision@K, Recall@K, MRR, NDCG	Le modèle répond mal avec un mauvais contexte.
Génération	Est-ce que la réponse est fidèle, utile et sans hallucination ?	Faithfulness, answer relevancy, groundedness	La réponse paraît correcte mais invente des faits.
Bout en bout	Est-ce que l’utilisateur obtient une réponse satisfaisante ?	LLM judge, références humaines, feedback utilisateur	Le système semble bon techniquement, mais déçoit en usage réel.

Comment lire les métriques de retrieval ?

Les métriques de retrieval servent à vérifier si le moteur récupère les bons chunks, dans le bon ordre, sans demander à un LLM de juger la réponse. Un chunk, c’est simplement un morceau de document découpé pour être indexé puis retrouvé au moment de répondre.

Precision@K mesure la proportion de chunks pertinents dans les K premiers résultats. La formule est simple : chunks pertinents dans le top K divisé par K. Si je regarde un top 5 et que 3 chunks sont vraiment pertinents, alors Precision@5 vaut 3/5, donc 0,6. C’est utile quand je veux savoir si le contexte envoyé au LLM est propre. Un K plus grand augmente parfois les chances de tomber sur les bons documents, mais il peut aussi ajouter du bruit. Et le bruit, dans un RAG, ça finit souvent en réponse floue.

Recall@K mesure l’exhaustivité. La formule : chunks pertinents retrouvés dans le top K divisé par le total des chunks pertinents dans le corpus. Si 4 chunks pertinents existent dans toute la base, et que le moteur en retrouve 2 dans le top 5, alors Recall@5 vaut 2/4, donc 0,5. Là, je regarde surtout si le moteur rate des preuves importantes.

MRR, pour Mean Reciprocal Rank, regarde à quelle position arrive le premier chunk pertinent. Pour chaque requête, on prend l’inverse du rang du premier bon résultat. Si le premier chunk pertinent est en position 1, le score vaut 1. S’il arrive en position 4, le score vaut 1/4. J’aime bien cette métrique parce qu’elle favorise les systèmes qui mettent vite la bonne preuve en haut.

NDCG va un cran plus loin. Toutes les sources ne se valent pas. Certaines sont centrales, d’autres juste utiles. NDCG prend en compte ce niveau de pertinence, tout en pénalisant les bons résultats placés trop bas. C’est pratique quand vous notez les preuves avec plusieurs niveaux, par exemple “très pertinent”, “utile”, “faible”.

Métrique	Ce qu’elle mesure	Quand l’utiliser	Piège fréquent
Precision@K	La qualité des K premiers chunks	Quand le contexte doit rester propre	Choisir un K trop grand et injecter du bruit
Recall@K	La capacité à retrouver toutes les preuves	Quand il ne faut pas rater d’information clé	Optimiser le recall sans contrôler la précision
MRR	La position du premier bon chunk	Quand la première preuve compte beaucoup	Ignorer les autres bons chunks plus bas
NDCG	La pertinence pondérée par le rang	Quand les preuves ont des niveaux de valeur différents	Mal définir les scores de pertinence au départ

Que valent RAGAS TruLens et DeepEval ?

RAGAS, TruLens et DeepEval ne répondent pas exactement au même besoin, même s’ils peuvent tous servir à évaluer un système RAG. Un RAG, pour faire simple, c’est une application qui va chercher du contexte dans vos documents avant de demander à un LLM de répondre. Le vrai sujet, ce n’est pas juste “est-ce que la réponse a l’air bonne ?”. C’est “est-ce qu’elle est fidèle aux sources, pertinente, complète, et stable dans le temps ?”.

RAGAS est plutôt orienté évaluation automatisée des pipelines RAG. Je l’utilise surtout quand je veux comparer vite plusieurs variantes : un autre retriever, une taille de chunk différente, un prompt modifié, un reranker ajouté. Il mesure des dimensions comme la faithfulness, donc la fidélité de la réponse au contexte, l’answer relevancy, donc la pertinence de la réponse, la context precision, qui vérifie si les passages récupérés sont utiles, et la context recall, qui regarde si on a bien récupéré les bons éléments. C’est pratique pour benchmarker sans annoter tout à la main.

TruLens, lui, est très intéressant pour l’observabilité et le monitoring d’applications LLM. L’observabilité, c’est la capacité à comprendre ce qui se passe dans une application qui tourne vraiment, pas juste dans un notebook. Avec TruLens, on ajoute des feedback functions, c’est-à-dire des fonctions qui évaluent automatiquement des signaux comme la pertinence du contexte, la pertinence de la réponse ou le groundedness, donc le fait que la réponse soit bien ancrée dans les sources. J’ai vu ça devenir utile chez un client dès que les utilisateurs internes ont commencé à poser des questions imprévisibles.

DeepEval parle plus aux équipes qui veulent tester leurs applications LLM comme du vrai logiciel. On est proche d’une logique de tests unitaires et d’intégration continue. La CI/CD, c’est le pipeline qui teste et déploie automatiquement votre code. DeepEval permet de poser des garde-fous sur la faithfulness, l’answer relevancy, la contextual precision, la contextual recall ou d’autres critères évalués automatiquement.

Mon avis est assez simple :

• RAGAS est souvent le plus pratique pour expérimenter sur un RAG.
• TruLens est plus fort quand il faut observer et monitorer une application en production.
• DeepEval colle bien aux équipes qui veulent industrialiser les tests dans leur workflow de développement.

Le meilleur choix dépend surtout de votre maturité, du volume de tests, du besoin de monitoring, et de votre tolérance aux juges LLM. Parce que oui, quand un LLM évalue un autre LLM, ça reste utile, mais ça mérite d’être surveillé.

Outil	Usage principal	Points forts	Limites	Meilleur cas d’usage
RAGAS	Évaluation offline de pipelines RAG	Rapide pour benchmarker des variantes de retrieval, chunking et prompts	Dépend des métriques et parfois de juges LLM	Comparer plusieurs expériences RAG avant mise en production
TruLens	Observabilité et monitoring LLM	Suivi des feedback functions, groundedness, contexte et réponses	Demande une vraie intégration dans l’application	Surveiller un système RAG utilisé par de vrais utilisateurs
DeepEval	Tests automatisés pour applications LLM	Bonne logique CI/CD, tests reproductibles, garde-fous qualité	Demande de bien définir les cas de test et seuils	Industrialiser les tests LLM dans une équipe produit ou data

Comment choisir sans se tromper ?

Pour choisir sans se tromper, il faut partir du problème actuel, pas du framework le plus populaire. C’est le piège classique avec RAGAS, TruLens et DeepEval. On compare les outils avant d’avoir clarifié ce qu’on veut vraiment mesurer.

Si votre problème principal, c’est la qualité de recherche, je commence par instrumenter les métriques de retrieval. Precision@K mesure si les K premiers résultats sont pertinents. Recall@K mesure si on retrouve bien les bons documents. MRR regarde à quelle position apparaît le premier bon résultat. NDCG mesure la qualité du classement, en donnant plus de poids aux bons résultats placés haut. Tant que cette partie est floue, juger la génération ne sert pas à grand-chose. Le modèle peut très bien répondre mal parce qu’on lui donne les mauvais chunks.

Si le problème, c’est l’hallucination, je regarde plutôt la faithfulness ou le groundedness. En clair, est-ce que la réponse reste fidèle aux sources fournies ? Est-ce que chaque affirmation importante est bien ancrée dans le contexte ? Chez un client, on avait un modèle “convaincant”, mais il inventait des détails dès que le document source était incomplet. La métrique de génération seule donnait une impression trop positive.

Si le problème, c’est la satisfaction finale, il faut ajouter une évaluation bout en bout. Là, on regarde la réponse complète du point de vue utilisateur : est-ce utile, correct, clair, actionnable ? C’est souvent ce qui parle le plus aux équipes métier.

Situation	Choix raisonnable
Équipe en expérimentation	RAGAS peut être un bon point de départ pour tester vite des métriques RAG.
Application déjà en production	TruLens devient intéressant avec son angle observabilité et suivi réel.
Équipe produit ou engineering	DeepEval colle bien à une logique de tests automatisés et de blocage des régressions.

Dans les faits, je ne recommande pas forcément de choisir un seul outil pour toujours. On peut très bien utiliser des métriques de retrieval classiques, un framework pour les évaluations offline, puis un outil de monitoring pour la production. Le vrai sujet, c’est d’avoir des métriques lisibles, répétables et reliées à des décisions concrètes.

• Définir les questions critiques
• Créer un jeu de requêtes représentatif
• Annoter les chunks pertinents si possible
• Mesurer la récupération avec Precision@K, Recall@K, MRR et NDCG
• Mesurer la génération avec faithfulness, groundedness et qualité de réponse
• Suivre les régressions dans le temps

Et maintenant vous mesurez quoi en premier ?

Je retiens une chose simple : un RAG ne s’évalue pas comme une réponse générée classique. Il faut regarder la récupération, la génération, puis le résultat final. Precision@K, Recall@K, MRR et NDCG aident à comprendre si les bons chunks remontent. RAGAS aide bien pour comparer des variantes RAG. TruLens devient précieux quand on veut observer ce qui se passe en production. DeepEval est pratique pour automatiser les tests et éviter les régressions. Le bénéfice pour vous, c’est clair : vous arrêtez de corriger au hasard et vous savez exactement où améliorer votre système.

FAQ

• Pourquoi BLEU et ROUGE ne suffisent pas pour évaluer un RAG ?
  Parce qu’ils comparent surtout une réponse à une référence textuelle. Ils ne disent pas si les bons chunks ont été récupérés, ni si la réponse est vraiment ancrée dans les sources. Un RAG peut produire une phrase proche d’une référence tout en utilisant un mauvais contexte, ou l’inverse.
• Quelle est la différence entre retrieval et génération dans un RAG ?
  Le retrieval correspond à la recherche des chunks utiles dans la base documentaire. La génération correspond à la réponse produite par le modèle à partir de ces chunks. Les deux doivent être évalués séparément, sinon on ne sait pas si l’erreur vient du moteur de recherche ou du modèle.
• Quand utiliser RAGAS plutôt que TruLens ?
  J’utiliserais plutôt RAGAS pour comparer rapidement plusieurs versions d’un pipeline RAG, par exemple un changement de chunking, de retriever ou de prompt. TruLens est plus intéressant quand on veut observer une application LLM dans la durée, avec des feedback functions et du monitoring.
• DeepEval sert à quoi dans une équipe IA ?
  DeepEval est utile quand on veut transformer l’évaluation LLM en tests automatisés. Il colle bien à une logique engineering, avec des tests qui peuvent aider à détecter les régressions avant qu’un changement parte en production.
• Quelle métrique de retrieval regarder en premier ?
  Je commence souvent par Recall@K si le risque principal est de manquer l’information utile. Ensuite je regarde Precision@K pour limiter le bruit, puis MRR ou NDCG si l’ordre des chunks est important. Dans un RAG, l’ordre compte beaucoup, parce que le modèle exploite mieux les preuves bien placées.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent rendre leurs données, leurs automatisations et leurs systèmes IA plus fiables, pas juste plus impressionnants en démo. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer, évaluer ou industrialiser vos projets IA et data, contactez-moi.