Quel framework d’évaluation RAG choisir ?

Je choisirais selon votre maturité RAG. RAGAS va vite pour scorer un pipeline, TruLens aide à surveiller en continu, DeepEval parle bien aux équipes qui testent comme du logiciel. Le vrai sujet, c’est de mesurer séparément retrieval, génération et qualité finale.

Pourquoi un RAG se teste à part ?

Un RAG ne se teste pas comme un simple appel LLM. Je le teste à part parce qu’il combine deux systèmes qui peuvent se planter chacun à leur façon : le retriever, qui va chercher les bons passages dans vos documents, et le générateur, souvent un LLM, qui transforme ce contexte en réponse.

Quand une réponse est mauvaise, le réflexe naturel c’est de regarder le prompt ou le modèle. Je le vois souvent chez les clients. L’équipe ajuste trois fois le prompt, change la température, teste un modèle plus gros… alors que le vrai problème vient du retrieval. Le bon document n’est jamais remonté. Ou il est remonté trop bas. Ou le chunk, c’est-à-dire le morceau de texte indexé, coupe l’information au mauvais endroit.

Une mauvaise réponse peut venir de plusieurs endroits, et c’est exactement pour ça qu’il faut séparer les métriques :

• Le mauvais contexte est récupéré. Le LLM répond avec ce qu’on lui donne, mais ce qu’on lui donne est hors sujet.
• Le contexte est incomplet. Une partie de la réponse est dans les sources, mais pas assez pour répondre proprement.
• Le ranking est faible. La bonne source existe, mais elle arrive derrière des passages moins utiles.
• Le LLM hallucine. Il invente une information qui n’est pas dans le contexte.
• Le LLM utilise mal le bon contexte. Et ça, c’est plus subtil, parce que le retrieval a fait son job.

C’est aussi pour ça que les métriques NLP classiques comme BLEU ou ROUGE ne suffisent pas. Ces métriques comparent surtout des similarités de texte avec une réponse de référence. Ça peut être utile dans certains cas, mais ça ne dit pas si la réponse est factuelle, si elle est bien ancrée dans les sources, ni si le système complet fonctionne vraiment.

Pour évaluer un RAG proprement, je pose trois couches dès le départ. La qualité de récupération : est-ce que je récupère les bons chunks. La qualité de génération : est-ce que le LLM répond correctement avec le contexte fourni. La qualité end-to-end : est-ce que l’utilisateur obtient une réponse fiable, utile, sourcée, et exploitable.

Avant de comparer RAGAS, TruLens et DeepEval, il faut donc savoir ce qu’on mesure vraiment. Sinon on choisit un framework au feeling, et on finit avec des dashboards propres qui ne détectent pas les vrais problèmes.

Quelles métriques mesurer côté retrieval ?

Côté retrieval, je mesure si les bons chunks remontent, s’ils remontent assez haut, et si le top K contient assez d’information utile pour répondre. K, c’est juste le nombre de résultats qu’on garde, par exemple les 5 premiers chunks récupérés.

Ces métriques ne demandent pas forcément un juge LLM. C’est même souvent mieux de commencer sans. Par contre, il faut un petit jeu de questions avec, pour chaque question, les documents ou chunks attendus. C’est la vérité terrain. Sans ça, on mesure un peu au doigt mouillé, et je l’ai vu chez plusieurs clients, ça donne vite des débats interminables.

Precision@K mesure la proportion de chunks pertinents dans les K premiers résultats. Si je regarde les 5 premiers résultats, combien sont vraiment utiles ?

• Precision@5 : J’ai 3 chunks pertinents sur 5 chunks remontés, donc le score vaut 0,6.

Recall@K mesure la proportion de chunks pertinents retrouvés parmi tous les chunks pertinents qui existent dans le corpus. C’est utile quand je veux savoir si mon retrieval rate des éléments importants.

• Recall@5 : J’ai retrouvé 3 chunks pertinents sur 4 chunks pertinents dans le corpus, donc le score vaut 0,75.

MRR, pour Mean Reciprocal Rank, regarde la position du premier chunk pertinent. Plus il arrive tôt, mieux c’est. Si le premier chunk pertinent arrive en position 1, le score vaut 1. En position 2, il vaut 0,5. En position 4, il vaut 0,25. Ensuite, je moyenne ce score sur plusieurs requêtes.

NDCG est utile quand la pertinence est graduée. Par exemple, un chunk peut être très pertinent, partiellement pertinent, ou peu pertinent. Cette métrique pénalise aussi un document utile placé trop bas dans la liste. C’est pratique quand un simple pertinent ou non pertinent ne suffit pas.

Métrique	Ce qu’elle mesure	Quand je l’utilise
Precision@K	La part de chunks pertinents dans les K premiers résultats.	Quand je veux limiter le bruit envoyé au LLM.
Recall@K	La part des chunks attendus qui ont bien été retrouvés.	Quand je veux éviter de rater une information clé.
MRR	La position du premier chunk pertinent.	Quand le premier bon résultat compte beaucoup.
NDCG	La qualité du classement avec des niveaux de pertinence.	Quand tous les chunks utiles n’ont pas la même valeur.

Ces métriques ne disent pas encore si la réponse finale est bonne. Elles disent seulement si le système a donné au LLM de quoi bien répondre.

Comment comparer RAGAS TruLens et DeepEval ?

Je compare RAGAS, TruLens et DeepEval avec trois questions simples. Ce que je veux mesurer. Si je cherche un audit ponctuel ou une surveillance continue. Et si mon équipe préfère des métriques plutôt data science, ou des tests automatisés proches du développement logiciel.

RAGAS est souvent mon premier choix quand je veux scorer rapidement un dataset d’évaluation RAG. Il mesure des choses très utiles comme la pertinence du contexte récupéré, la fidélité de la réponse au contexte, la pertinence de la réponse, parfois sans dépendre systématiquement d’une réponse de référence écrite par un humain. Je reste prudent là-dessus. Le “sans ground truth”, donc sans vérité de référence, marche bien sur certains cas, moins sur d’autres. Mais pour comparer deux versions d’un retriever, d’un prompt ou d’un modèle, c’est très pratique.

TruLens, je le mets plutôt côté observabilité. Il sert à instrumenter une application LLM ou RAG, tracer ce qui se passe pendant l’exécution, puis surveiller avec des feedback functions. Une feedback function, c’est simplement une fonction qui donne un score ou un avis sur un élément précis : contexte récupéré, réponse générée, alignement entre les deux, toxicité, pertinence. C’est utile quand on veut comprendre pourquoi une réponse est mauvaise, pas juste voir qu’elle est mauvaise.

DeepEval parle bien aux équipes qui aiment les tests. Sa logique ressemble à des tests unitaires ou d’intégration, mais appliqués aux applications LLM. Je le trouve adapté quand l’évaluation RAG doit entrer dans une CI/CD, donc dans le pipeline qui teste et déploie le code. On peut tester l’hallucination, la faithfulness, l’answer relevancy, la contextual precision ou la contextual recall selon les cas.

Framework	Meilleur usage	Point fort	Attention
RAGAS	Audit rapide d’un dataset RAG	Métriques RAG claires et utiles pour comparer des versions	Le sans ground truth n’est pas magique dans tous les cas
TruLens	Observabilité et amélioration continue	Traces, feedback functions, suivi pendant l’exécution	Demande une vraie instrumentation de l’application
DeepEval	Tests automatisés dans une CI/CD	Approche proche des pratiques de développement logiciel	Il faut bien définir les seuils et les cas de test

Je ne fais pas de classement absolu. Le bon framework dépend moins du logo que du moment où votre équipe se trouve : POC, pré-production ou production. C’est souvent là que le choix devient évident.

Quel choix selon votre maturité RAG ?

Si vous êtes en POC, je vais au plus simple. Si vous préparez la production, je structure un vrai jeu d’évaluation. Si vous êtes déjà en production, je surveille dans le temps. Je le dis franchement, il n’y a pas de recette magique. Le bon choix dépend surtout de votre niveau de maturité RAG, pas du framework à la mode.

Situation	Objectif	Ce que je regarde
POC ou prototype	Identifier vite les gros problèmes	Retrieval raté, hallucinations évidentes, réponses sans source
Pré-production	Comparer proprement les variantes	Prompts, modèles, embeddings, chunking, top K, paramètres de retrieval
Production	Détecter les régressions	Drift documentaire, changements de comportement, réponses sûres mais mal justifiées

Sur un POC, je prends un petit dataset représentatif. Pas 500 questions générées au hasard. Plutôt 30 à 80 questions qui ressemblent vraiment à ce que les utilisateurs vont demander. L’objectif, c’est de voir rapidement si le retrieval ramène les bons documents, et si le modèle invente quand il ne sait pas.

En pré-production, je deviens plus strict. Je stabilise les métriques, sinon on compare du bruit. Je versionne les prompts, les modèles, les embeddings, le corpus et les paramètres de retrieval. Le top K, c’est le nombre de documents récupérés avant génération. C’est souvent là que tout se joue. Chez un client, on avait changé seulement le chunking, donc la façon de découper les documents, et la qualité perçue a chuté alors que le modèle était identique.

En production, je ne cherche plus juste un bon score à un instant T. Je surveille les dérives. Les documents changent, les usages changent, les modèles changent parfois sans prévenir. Le vrai danger, c’est le RAG qui répond avec aplomb, mais sans preuve suffisante dans les sources.

Les pièges reviennent souvent, même dans des équipes solides :

• Évaluer uniquement la réponse finale, sans regarder les documents récupérés.
• Utiliser des questions trop faciles, qui donnent une fausse confiance.
• Ignorer le top K et la qualité du classement des sources.
• Mélanger qualité documentaire et qualité du modèle.
• Ne pas versionner les prompts, embeddings et corpus.
• Se fier à un juge LLM sans contrôle humain sur un échantillon critique.

Ma recommandation pratique est simple. Je garde un petit set de questions critiques validées humainement, j’ajoute des métriques automatiques pour accélérer, et je regarde les traces pour comprendre les échecs. Une évaluation RAG utile n’est pas un score décoratif. C’est un système de décision pour améliorer le pipeline.

Alors, vous mesurez vraiment votre RAG ?

Pour moi, le point clé est simple : un RAG ne s’évalue pas comme une réponse LLM isolée. Il faut séparer ce que le retriever trouve, ce que le modèle génère, et ce que l’utilisateur reçoit à la fin. RAGAS est souvent pratique pour démarrer une évaluation structurée, TruLens prend du sens quand on veut observer et suivre le système, DeepEval colle bien aux équipes qui veulent tester en continu. Le bon choix dépend de votre maturité, pas d’un classement universel. En posant les bonnes métriques, vous évitez les corrections au hasard et vous améliorez vraiment la fiabilité de votre RAG.

FAQ

• Pourquoi les métriques BLEU et ROUGE ne suffisent pas pour un RAG ?
  Elles comparent surtout des similarités de texte. Un RAG a besoin d’être jugé sur autre chose : est-ce que le bon contexte a été récupéré, est-ce que la réponse reste fidèle aux sources, est-ce que le système répond correctement de bout en bout. Une réponse peut être bien formulée et pourtant fausse ou mal sourcée.
• Quelle est la différence entre évaluer le retrieval et évaluer la génération ?
  Évaluer le retrieval, c’est vérifier si les bons chunks remontent dans le top K. Évaluer la génération, c’est vérifier si le LLM utilise bien ces chunks pour produire une réponse utile, fidèle et pertinente. Les deux doivent être séparés, sinon on ne sait pas où corriger.
• RAGAS, TruLens ou DeepEval, lequel choisir pour commencer ?
  Pour un premier audit RAG, je regarderais souvent RAGAS ou DeepEval selon la culture de l’équipe. RAGAS est pratique pour scorer des jeux d’évaluation RAG. DeepEval convient bien si vous voulez intégrer les tests dans une logique plus proche du développement logiciel. TruLens devient très intéressant pour tracer et surveiller dans la durée.
• Faut-il absolument des réponses de référence pour évaluer un RAG ?
  Pas toujours, mais c’est risqué de tout automatiser sans aucun contrôle humain. Certaines métriques peuvent fonctionner avec des juges LLM ou avec le contexte récupéré. Pour les sujets critiques, je garde quand même un échantillon validé humainement. Ça sert de garde-fou.
• Quelle métrique regarder en premier côté retrieval ?
  Je commence souvent par Precision@K et Recall@K. Precision@K dit si le top K contient surtout des chunks utiles. Recall@K dit si le système retrouve assez des chunks pertinents disponibles. Ensuite, MRR et NDCG aident à juger l’ordre des résultats, ce qui compte beaucoup en RAG.

 

 

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 mon organisme Formations Analytics, j’accompagne des équipes qui veulent rendre leurs données, leurs automatisations et leurs systèmes IA plus fiables. 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 un projet IA ou RAG, contactez-moi.