RAGAS vs TruLens vs DeepEval lequel choisir en RAG ?

Je choisis selon votre besoin réel : diagnostiquer vite, surveiller en continu, ou automatiser des tests. Un RAG peut rater côté retrieval ou côté génération. Si vous mélangez tout, vous corrigez au mauvais endroit. Je vous montre comment lire les métriques et choisir le bon framework.

Pourquoi un RAG se juge autrement ?

Un RAG se juge autrement parce qu’il combine deux systèmes qui peuvent échouer séparément, le retriever et le générateur.

Le retriever, c’est la partie qui va chercher les bons documents dans votre base. Le générateur, souvent un LLM, c’est la partie qui rédige la réponse à partir de ces documents. Et c’est là que les métriques NLP classiques montrent vite leurs limites.

Des métriques comme BLEU ou ROUGE mesurent surtout une proximité de surface avec une réponse attendue. En gros, elles regardent si les mots, les morceaux de phrases ou les formulations ressemblent à une référence. C’est utile dans certains cas, mais ça ne me dit pas si le bon contexte a été récupéré. Ça ne me dit pas non plus si le LLM est resté fidèle à ce contexte.

Dans un RAG, le vrai sujet, c’est le diagnostic. Si la réponse est mauvaise, je dois savoir où ça casse. Est-ce que les documents remontés sont mauvais ? Est-ce que le bon document existe mais il est mal classé ? Est-ce que le prompt pousse le modèle à trop improviser ? Est-ce que le modèle ignore une partie du contexte ?

Les erreurs reviennent souvent dans deux grandes familles :

• Le retrieval est incomplet ou bruité. Le système ne remonte pas le bon document, ou il remonte trop de contenu inutile autour. Le modèle part alors avec une mauvaise matière première.
• La génération hallucine ou ignore le contexte. Le bon document est là, mais le LLM invente, simplifie trop, mélange deux infos, ou répond avec ses connaissances générales au lieu de suivre la source.

Un exemple très simple. Vous avez une base documentaire pour le support client. Un utilisateur demande comment résilier une option. Le retriever remonte une ancienne procédure, encore présente dans la base, mais plus valide. Le LLM rédige une réponse propre, claire, bien formulée. Sauf qu’elle est fausse. Si je regarde seulement la qualité du texte, je peux croire que tout va bien.

Chez les clients, je vois souvent ce piège. Le problème n’est pas seulement d’avoir une mauvaise réponse. Le vrai problème, c’est de ne pas savoir pourquoi elle est mauvaise.

C’est pour ça qu’avant de comparer RAGAS, TruLens et DeepEval, il faut découper l’évaluation en couches. Sinon on mélange tout, et on finit avec des scores qui rassurent mais qui n’aident pas à améliorer le système.

Quelles métriques pour le retrieval ?

Les métriques utiles pour le retrieval sont Precision@K, Recall@K, MRR et NDCG, parce qu’elles mesurent ce que le retriever met vraiment sous les yeux du LLM.

Precision@K mesure la part de documents pertinents dans les K premiers résultats. Si je demande les 5 meilleurs chunks et que seulement 2 sont utiles, j’ai un problème de précision. Le modèle reçoit du bruit. Et le bruit, en RAG, c’est souvent le début des réponses molles ou carrément fausses.

Recall@K mesure la part des documents pertinents retrouvés parmi tous ceux qui existent dans le corpus. Là, la question est simple : Est-ce que mon système retrouve assez de bonnes preuves ? Un faible Recall@K veut dire que le LLM n’a même pas les bons éléments pour répondre. Il peut être très bon, il va quand même improviser.

MRR, pour Mean Reciprocal Rank, valorise la position du premier résultat pertinent. Si le premier bon document arrive en position 1, c’est très bien. S’il arrive en position 7, c’est moins bon. En pratique, ça compte beaucoup, parce que certains pipelines ne lisent pas tout avec la même attention, surtout quand le contexte est long.

NDCG regarde la qualité du classement avec des niveaux de pertinence. Un document peut être un peu utile, utile, ou très utile. L’idée du DCG et du NDCG est simple : Un document très pertinent en position 1 vaut plus qu’un document très pertinent en position 8. C’est souvent la métrique qui révèle que le retriever trouve les bons documents, mais les range mal.

Ces métriques demandent souvent une vérité terrain, donc des annotations humaines ou un jeu d’évaluation fiable. C’est coûteux, oui. Mais quand on veut améliorer le chunking, les embeddings, le reranking, les filtres metadata ou la recherche hybride, ça évite de piloter au feeling. J’ai vu des équipes changer de modèle d’embedding alors que le vrai souci venait juste d’un découpage de documents trop agressif.

Métrique	Ce que ça mesure	Ce que ça révèle	Quand je l’utilise
Precision@K	La part de documents pertinents dans les K premiers résultats.	Un faible score injecte du bruit dans le contexte.	Quand je veux réduire les hallucinations causées par de mauvais chunks.
Recall@K	La part des documents pertinents retrouvés parmi tous ceux du corpus.	Un faible score prive le modèle des bonnes preuves.	Quand je vérifie si le retriever couvre bien la connaissance disponible.
MRR	La position du premier résultat pertinent.	Un mauvais score ralentit ou dégrade la réponse.	Quand le premier bon résultat doit arriver très haut.
NDCG	La pertinence graduée et l’ordre des résultats.	Un mauvais score montre que le ranking respecte mal la pertinence.	Quand je compare le reranking, l’hybride ou plusieurs stratégies de recherche.

Comment juger la génération ?

Je juge la génération sur sa fidélité au contexte, sa pertinence pour la question, sa complétude et sa capacité à ne pas inventer.

Un RAG ne se juge pas juste à la réponse finale qui “sonne bien”. Ça, c’est le piège classique. Une réponse peut être fluide, polie, bien structurée… et complètement fausse. À l’inverse, une réponse courte peut être excellente si elle reprend exactement le bon élément du contexte, sans broder autour.

Dans la pratique, je sépare toujours l’évaluation en trois couches.

Qualité de récupération	Est-ce que le système a récupéré les bons documents ou passages ?
Qualité de génération	Est-ce que le modèle a bien utilisé ce contexte pour répondre, sans ajouter d’infos inventées ?
Qualité bout en bout	Est-ce que l’utilisateur obtient une réponse utile, correcte et exploitable ?

Les frameworks modernes comme RAGAS, TruLens ou DeepEval tournent souvent autour des mêmes notions.

• Faithfulness ou groundedness vérifie si la réponse est bien ancrée dans le contexte fourni. En clair, est-ce que le modèle peut justifier ce qu’il dit avec les passages récupérés ?
• Answer relevancy vérifie si la réponse répond vraiment à la question posée. Pas à une question voisine, pas à ce que le modèle aurait aimé répondre.
• Context relevance vérifie si les passages récupérés servent réellement à répondre. Parce qu’un contexte long mais inutile, ça reste du bruit.
• Answer correctness compare la réponse générée à une réponse de référence, quand on en a une. C’est très utile sur des jeux de tests maîtrisés.

Le point intéressant, c’est que certaines métriques peuvent fonctionner sans réponse de référence, grâce à un LLM juge. Un LLM juge, c’est un modèle qui évalue un autre modèle. Pratique, oui. Magique, non. Je le versionne, je le contrôle, et je le teste sur des cas connus. Sinon, on remplace juste une incertitude par une autre.

Prenons un assistant interne RH. Un salarié demande combien de jours de congés il peut poser d’affilée. Si le bon document RH est récupéré, mais que la réponse ajoute une règle absente du document, c’est un problème de génération. Si la réponse est vide ou vague parce que le système n’a pas récupéré la bonne politique RH, c’est un problème de retrieval, donc de récupération.

C’est pour ça que le choix entre RAGAS, TruLens et DeepEval dépend du moment où vous voulez mesurer. Ils ne servent pas exactement le même moment du cycle de vie d’un RAG.

RAGAS TruLens DeepEval lequel choisir ?

Je choisis RAGAS pour évaluer rapidement la qualité RAG, TruLens pour tracer et surveiller une application dans le temps, DeepEval pour industrialiser des tests comme on le ferait avec du logiciel.

RAGAS, c’est souvent mon premier réflexe quand je veux comparer vite plusieurs versions d’un pipeline RAG. Un pipeline RAG, c’est toute la chaîne qui récupère des documents, les donne au modèle, puis génère une réponse. RAGAS est open source, très centré sur cette logique, avec des métriques comme faithfulness, answer relevancy, context precision, context recall ou answer correctness selon les cas. Le gros intérêt, c’est de benchmarker du chunking, du retrieval ou des prompts sans passer trois semaines à construire une usine à gaz. Certaines métriques peuvent même fonctionner sans réponse de référence, ce qui aide beaucoup au début.

TruLens devient plus intéressant quand l’application sort du notebook. Là, je veux voir ce qui se passe requête par requête. Quel contexte a été récupéré ? Quelle réponse a été générée ? Où ça décroche ? TruLens sert à instrumenter les appels LLM, inspecter les traces et suivre des feedback functions comme groundedness, context relevance et answer relevance. Sur un projet client, c’est souvent là qu’on arrête de dire “le RAG marche mal” et qu’on voit enfin où il marche mal.

DeepEval, lui, est plus proche d’une logique de tests automatisés. Je l’utilise quand je veux éviter qu’une nouvelle version casse un comportement qui fonctionnait hier. Il est open source, orienté CI, donc intégration continue. Ses métriques couvrent des besoins comme G-Eval, answer relevancy, faithfulness, contextual precision, contextual recall, hallucination, bias ou toxicity. C’est adapté quand je veux bloquer une régression avant déploiement.

Outil	Meilleur usage	Besoin de référence	Point fort	Limite à surveiller
RAGAS	Benchmarker vite un pipeline RAG	Pas toujours, selon les métriques	Très pratique pour comparer chunking, retrieval et prompts	Moins orienté observabilité applicative
TruLens	Tracer et surveiller une app LLM	Variable selon les feedback functions	Très utile pour comprendre les erreurs requête par requête	Demande une vraie instrumentation
DeepEval	Automatiser des tests avant déploiement	Souvent utile, mais pas systématique	S’intègre bien dans une logique CI et tests logiciels	Il faut maintenir les jeux de tests

Ma règle simple : début de projet, je mesure vite ; préproduction, je trace ; production, je teste et je surveille.

Et maintenant vous testez quoi en premier ?

Pour évaluer un RAG proprement, je ne regarde pas juste si la réponse me plaît. Je sépare le retrieval, la génération et le résultat final. Precision@K, Recall@K, MRR et NDCG m’aident à comprendre si les bons documents remontent au bon endroit. Les métriques de faithfulness, relevancy et correctness m’aident à voir si le LLM répond sans broder. RAGAS va bien pour comparer vite, TruLens pour observer dans le temps, DeepEval pour automatiser des tests. Le vrai bénéfice pour vous, c’est simple : corriger la bonne brique, plus vite, sans piloter votre RAG à l’intuition.

FAQ

• Pourquoi BLEU et ROUGE ne suffisent pas pour évaluer un RAG ? Parce qu’ils comparent surtout la forme d’une réponse à une référence. Un RAG demande aussi de vérifier si les bons documents ont été récupérés et si la réponse reste fidèle au contexte. Une réponse peut être proche lexicalement et pourtant mal sourcée.
• Quelle est la différence entre faithfulness et answer relevancy ? Faithfulness vérifie si la réponse est bien supportée par le contexte récupéré. Answer relevancy vérifie si la réponse répond vraiment à la question. Les deux sont nécessaires, parce qu’une réponse peut être pertinente mais inventée, ou fidèle au contexte mais hors sujet.
• Quand utiliser RAGAS ? J’utilise RAGAS quand je veux évaluer vite plusieurs versions d’un pipeline RAG : changement de chunking, modèle d’embedding, reranker, prompt ou modèle génératif. C’est très utile en phase d’expérimentation et de benchmark.
• Quand TruLens devient intéressant ? TruLens devient intéressant quand l’application RAG tourne vraiment et qu’on veut observer les traces, les appels, les contextes récupérés et les scores dans le temps. C’est moins un simple benchmark qu’un outil d’observabilité et de diagnostic continu.
• DeepEval sert à quoi dans un projet RAG ? DeepEval sert surtout à automatiser les tests d’évaluation, un peu comme des tests unitaires pour une application IA. Je l’utilise quand je veux éviter les régressions avant un déploiement, par exemple si un nouveau prompt dégrade la faithfulness ou augmente les hallucinations.

 

 

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. Avec mon agence webAnalyste et l’organisme Formations Analytics, j’accompagne des équipes qui veulent passer de la démo IA sympa à des systèmes mesurables, fiables et exploitables. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer, évaluer ou industrialiser vos projets IA et RAG, contactez-moi.