Quel framework choisir pour l’évaluation RAG ?

L’évaluation RAG se choisit selon ce que je veux mesurer : récupération, génération ou qualité finale. RAGAS, TruLens et DeepEval ne jouent pas exactement le même rôle. Le vrai sujet, c’est d’éviter les réponses jolies mais fausses, ou correctes mais mal sourcées.

Pourquoi évaluer un RAG autrement ?

Un système RAG doit être évalué autrement parce qu’il combine deux sources d’erreur différentes, le retriever et le générateur.

Le retriever, c’est la partie qui va chercher les bons fragments de connaissance dans vos documents. Il sélectionne des passages, parfois quelques paragraphes, parfois des bouts de page, puis il les donne au LLM. Le LLM, lui, produit la réponse à partir de ce contexte. Dit comme ça, ça paraît simple. En pratique, c’est là que les ennuis commencent.

Quand une réponse est mauvaise, je ne peux pas juste dire “le modèle s’est trompé”. Il faut comprendre où ça casse. Le problème peut venir de plusieurs endroits :

• Le bon contexte n’a jamais été récupéré, donc le LLM répond avec ce qu’il peut.
• Le contexte récupéré contient trop de bruit, avec des passages vaguement liés mais pas vraiment utiles.
• Les bons passages sont présents, mais mal classés, noyés derrière des informations secondaires.
• Le modèle ignore le contexte fourni et hallucine, c’est-à-dire qu’il invente une réponse plausible mais fausse.

C’est pour ça que les métriques classiques comme BLEU et ROUGE ne suffisent pas. BLEU et ROUGE comparent surtout des textes entre eux. En gros, elles regardent si la réponse ressemble à une réponse de référence, avec des mots ou des séquences proches. C’est utile pour certains usages, mais ça ne dit pas si la réponse est bien ancrée dans les documents. Ça ne dit pas non plus si le contexte récupéré était pertinent, ni si le modèle est resté fidèle aux sources.

J’ai vu ça souvent sur le terrain. Le chatbot répond bien en apparence, le ton est propre, la phrase est fluide, tout donne confiance. Puis on regarde les passages cités, et là on voit qu’ils ne prouvent rien. Ou pire, le modèle invente un lien logique entre deux infos qui n’ont rien à voir. C’est discret, mais dangereux, surtout quand le RAG sert à répondre à des clients, des équipes support ou des métiers qui prennent des décisions derrière.

Donc pour évaluer correctement un RAG, il faut arrêter de juger uniquement la réponse finale. Il faut séparer les couches d’évaluation : la récupération, le contexte, puis la génération. C’est exactement ce qu’on va regarder ensuite.

Quelles couches faut-il mesurer ?

Il faut mesurer trois couches : la récupération, la génération, puis le résultat de bout en bout. Si je ne mesure qu’une seule couche, je peux croire que mon RAG marche alors qu’il se plante juste avant, ou juste après. C’est un piège classique, je l’ai vu chez un client avec une base documentaire propre sur le papier, mais des réponses moyennes parce que les bons passages arrivaient trop bas dans la liste.

La première couche, c’est la qualité de récupération. Le retrieval, c’est le moment où le système cherche les passages pertinents dans vos documents. Ici, je veux savoir si les bons passages remontent dans le top K, donc dans les K premiers résultats renvoyés au modèle. Je regarde aussi s’ils sont classés assez haut. Un bon passage en position 9, quand le modèle ne lit que les 5 premiers, c’est presque comme s’il n’existait pas. Et je vérifie le bruit. Trop de passages vagues, doublons ou hors sujet, ça dilue le contexte et ça pousse le modèle à répondre à côté.

La deuxième couche, c’est la qualité de génération. Là, je regarde ce que le modèle fait avec le contexte. Est-ce qu’il utilise vraiment les sources récupérées ? Est-ce qu’il reste fidèle à ce qui est écrit ? Est-ce qu’il invente des détails parce que la question l’y pousse un peu ? C’est là qu’on parle souvent d’hallucination, c’est-à-dire une réponse plausible mais non supportée par les documents.

La troisième couche, c’est la qualité end-to-end, ou bout en bout. Là, je me mets côté utilisateur. Est-ce que la réponse aide vraiment ? Est-ce qu’elle est complète, claire, utile, actionnable ? Une réponse peut être fidèle aux sources mais inutilisable, trop longue, trop floue, ou incapable de répondre au vrai besoin.

Récupération	Est-ce que les bons passages remontent dans le top K, assez haut, avec peu de bruit ?
Génération	Est-ce que le modèle utilise le contexte, respecte les sources et évite les hallucinations ?
Bout en bout	Est-ce que la réponse finale est complète, utile, claire et actionnable pour l’utilisateur ?

RAGAS, TruLens et DeepEval couvrent ces couches, mais pas avec le même niveau d’automatisation. Certaines métriques fonctionnent sans réponse de référence, par exemple pour vérifier la fidélité au contexte. D’autres demandent une réponse attendue, souvent appelée ground truth, pour comparer la sortie du modèle à une réponse idéale. Le bon choix dépend donc de ce que vous avez déjà sous la main : des questions seules, des documents annotés, ou un vrai jeu de tests avec réponses validées. Et pour commencer proprement, je regarde presque toujours les métriques de retrieval, parce que si la récupération est mauvaise, le reste va bricoler.

Quelles métriques de retrieval suivre ?

Les métriques clés à suivre sont Precision@K, Recall@K, MRR et NDCG, parce qu’elles mesurent directement la qualité du retriever, donc sa capacité à remonter les bons fragments avant même que le modèle génératif écrive quoi que ce soit.

Precision@K répond à une question simple : parmi les K premiers fragments récupérés, combien sont vraiment pertinents ? La formule est : Precision@K = nombre de fragments pertinents dans le top K / K. Si je regarde les 5 premiers résultats et que 3 sont utiles, ma Precision@5 vaut 3/5, donc 0,6. C’est très pratique quand je veux limiter le bruit envoyé au LLM.

Recall@K regarde l’autre côté du problème : est-ce que j’ai retrouvé assez de bons fragments disponibles dans le corpus ? La formule est : Recall@K = fragments pertinents récupérés dans le top K / total des fragments pertinents dans le corpus. Si 10 passages parlent vraiment du sujet et que mon retriever en remonte 4 dans le top 10, mon Recall@10 vaut 0,4. C’est souvent critique sur des bases documentaires où une réponse complète dépend de plusieurs sources.

MRR, pour Mean Reciprocal Rank, mesure à quelle position arrive le premier fragment pertinent. La formule est : MRR = 1/N * somme de 1 / rang du premier fragment pertinent. Plus le premier bon passage arrive haut, meilleur est le score. Et franchement, côté utilisateur, ça change tout. Si je demande une politique de remboursement et que le bon passage arrive en position 7, l’expérience ne sera pas la même que s’il arrive en position 1.

NDCG est utile quand la pertinence n’est pas juste oui ou non. Certains passages peuvent être parfaits, d’autres seulement partiellement utiles. NDCG gère cette pertinence graduée et pénalise les bons documents placés trop bas. Je l’aime bien quand on commence à avoir des cas métier un peu fins, avec des réponses qui dépendent du contexte.

Ces métriques demandent des jugements de pertinence annotés, même légers. Pas besoin de créer une usine à gaz au départ. Un petit jeu de questions, quelques documents marqués comme pertinents ou non, et on a déjà une base solide. C’est souvent l’investissement le plus rentable au début.

Métrique	Ce qu’elle mesure	Quand l’utiliser
Precision@K	La part de fragments pertinents dans les K premiers résultats.	Quand je veux réduire le bruit envoyé au modèle.
Recall@K	La part des fragments pertinents du corpus retrouvés dans le top K.	Quand je veux éviter de rater des informations importantes.
MRR	La position du premier fragment pertinent.	Quand le premier bon résultat doit arriver très vite.
NDCG	La qualité du classement avec des niveaux de pertinence.	Quand certains passages sont plus utiles que d’autres.

Que valent RAGAS TruLens et DeepEval ?

Quand je compare RAGAS, TruLens et DeepEval, je ne les mets pas dans le même panier. RAGAS est très pratique pour évaluer les métriques RAG classiques. TruLens est fort pour observer et tracer ce qui se passe dans une application LLM. DeepEval est intéressant quand on veut rapprocher l’évaluation du monde des tests automatisés, comme on le ferait dans un vrai workflow de développement.

RAGAS, je le vois souvent comme le bon point de départ quand une équipe veut savoir si son RAG tient debout. RAG veut dire Retrieval Augmented Generation, c’est le principe d’aller chercher des documents avant de générer une réponse. Ce que j’aime bien avec RAGAS, c’est qu’il ne réduit pas tout à un score magique. Il sépare notamment context precision et context recall. En clair, est-ce que les contextes récupérés sont pertinents, et est-ce qu’on a bien récupéré ce qu’il fallait. Il propose aussi des métriques comme faithfulness, answer relevancy, context precision et context recall.

TruLens joue un autre rôle. Il sert à instrumenter, tracer et évaluer des applications LLM. Instrumenter, ça veut dire ajouter des capteurs dans l’application pour comprendre ce qui se passe vraiment. Avec ses feedback functions comme groundedness, answer relevance et context relevance, il aide surtout quand une réponse est mauvaise et qu’on veut savoir pourquoi. Chez un client, c’est souvent là que ça débloque les discussions. On arrête de dire “le modèle hallucine” et on voit si le problème vient du retrieval, du prompt, du contexte ou de la génération.

DeepEval adopte une logique plus proche d’un framework de test pour LLM. C’est utile si vous voulez automatiser vos contrôles dans un pipeline, par exemple avant de déployer une nouvelle version. On retrouve des métriques comme answer relevancy, faithfulness, contextual precision, contextual recall et contextual relevancy.

Outil	Point fort	Métriques typiques	Bon cas d’usage
RAGAS	Évaluation RAG classique, claire et structurée	Faithfulness, answer relevancy, context precision, context recall	Mesurer la qualité d’un système RAG sur un jeu de test
TruLens	Traçage, observation et diagnostic des applications LLM	Groundedness, answer relevance, context relevance	Comprendre pourquoi une réponse sort mal en production ou en pré-prod
DeepEval	Tests automatisés orientés développement	Answer relevancy, faithfulness, contextual precision, contextual recall, contextual relevancy	Intégrer l’évaluation LLM dans un pipeline CI/CD

Le bon choix dépend surtout de votre maturité. Si vous démarrez, RAGAS suffit souvent. Si vous avez besoin de monitoring et de diagnostic fin, TruLens devient très utile. Si votre équipe veut industrialiser avec des tests reproductibles, DeepEval colle mieux à la logique dev.

Comment choisir sans se tromper ?

Je choisis le framework selon le problème que je veux diagnostiquer, pas selon le nom le plus connu. C’est la lecture la plus simple, et franchement c’est celle qui évite pas mal de mauvaises décisions.

Si mon doute principal porte sur les passages récupérés, je pars sur des métriques de retrieval, c’est-à-dire des métriques qui vérifient si les bons documents remontent au bon moment. Dans ce cas, RAGAS peut suffire. Il permet de mesurer des choses comme la pertinence du contexte, la fidélité de la réponse au contexte, ou la qualité globale de la génération.

Si je veux comprendre le comportement d’une application en production ou en préproduction, TruLens devient plus intéressant. Son point fort, c’est le traçage. Je vois ce qui se passe à chaque étape : question utilisateur, documents récupérés, prompt final, réponse du modèle, feedbacks. C’est très utile quand le problème n’est pas juste “la réponse est mauvaise”, mais “je ne sais pas où ça casse”.

Si l’équipe veut écrire des tests reproductibles, les rejouer souvent, et les intégrer dans une logique CI ou QA, DeepEval est souvent plus adapté. La CI, c’est l’intégration continue : en gros, des tests automatiques qui tournent à chaque changement de code, de prompt ou de pipeline.

Problème principal	Choix naturel
Les mauvais passages remontent	RAGAS et métriques de retrieval
Je veux comprendre le comportement complet	TruLens
Je veux des tests automatisés et reproductibles	DeepEval

Le piège classique, c’est de croire qu’un score global suffit. Un 82 sur 100 ne dit pas si le problème vient du retriever, du prompt, du modèle, ou des données. Autre piège que je vois souvent : mélanger hallucination et mauvais retrieval. Une réponse peut sembler inventée alors que le modèle n’a juste jamais reçu le bon extrait.

J’ai eu le cas chez un client. L’équipe pensait avoir un problème de LLM. En regardant les traces, on a vu que le retriever ramenait surtout des fragments incomplets, coupés au mauvais endroit. Le modèle faisait ce qu’il pouvait avec un contexte bancal. Changer de modèle n’aurait presque rien réglé.

Je garde aussi un dataset d’évaluation stable. Sinon, je compare du vent. Et je teste plus que trois exemples réussis. Il faut aussi inclure les cas où le système doit répondre “je ne sais pas”. C’est souvent là qu’on détecte les vrais risques.

• Objectif : Savoir ce que je veux diagnostiquer avant de choisir l’outil.
• Dataset : Garder un jeu d’évaluation stable avec des cas simples, difficiles et négatifs.
• Métriques : Séparer retrieval, fidélité, hallucination et qualité de réponse.
• Fréquence d’évaluation : Tester à chaque changement important de données, prompt ou modèle.
• Seuils d’alerte : Définir à partir de quel score je bloque, je corrige, ou je surveille.

Vous voulez vraiment faire confiance à votre RAG ?

Je ne vois pas l’évaluation RAG comme un sujet académique. C’est ce qui permet de savoir si votre système répond juste, avec les bons éléments, au bon moment. Il faut séparer la récupération, la génération et la qualité finale, sinon on corrige souvent le mauvais problème. RAGAS aide bien sur les métriques RAG, TruLens donne de la visibilité sur le comportement de l’application, DeepEval facilite les tests automatisés. Le meilleur choix dépend de votre usage et de votre maturité. Le bénéfice est simple : vous gagnez en fiabilité, vous réduisez les hallucinations et vous améliorez concrètement l’expérience utilisateur.

FAQ

• Qu’est-ce que l’évaluation RAG ? L’évaluation RAG consiste à mesurer si un système de retrieval augmented generation récupère les bons documents, utilise correctement ce contexte et produit une réponse fiable pour l’utilisateur.
• Pourquoi BLEU et ROUGE ne suffisent pas pour un RAG ? Ces métriques comparent surtout des similarités de texte. Elles ne disent pas vraiment si la réponse est ancrée dans le contexte, si elle évite les hallucinations ou si les bons passages ont été récupérés.
• Quelle différence entre Precision@K et Recall@K ? Precision@K mesure la proportion de fragments pertinents dans les K premiers résultats. Recall@K mesure la part des fragments pertinents retrouvés parmi tous ceux qui auraient dû être récupérés.
• RAGAS, TruLens ou DeepEval, lequel choisir ? RAGAS est pratique pour les métriques RAG classiques, TruLens pour l’observation et le traçage d’applications LLM, DeepEval pour automatiser des tests d’évaluation dans un workflow de développement.
• Faut-il des réponses de référence pour évaluer un RAG ? Pas toujours. Certaines métriques peuvent être évaluées sans réponse de référence, notamment avec un juge LLM. Mais pour mesurer sérieusement le retrieval, des jugements de pertinence annotés restent très utiles.

 

 

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 fiabiliser leurs données, leurs parcours analytics et leurs systèmes IA sans empiler des outils au hasard. J’ai travaillé avec des clients 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 mettre en place une évaluation RAG sérieuse dans votre business, contactez-moi.