Sans évaluation rigoureuse, votre RAG est une boîte noire
Une chaîne RAG (Retrieval-Augmented Generation) en production sans métriques d'évaluation, c'est comme un site e-commerce sans analytics : vous ne savez pas ce qui fonctionne ni ce qui échoue. Les entreprises qui déploient un RAG sans protocole d'évaluation découvrent les problèmes par les plaintes utilisateurs — trop tard. Les métriques clés à suivre : faithfulness (fidélité aux sources), answer relevancy (pertinence de la réponse), context recall (capacité à retrouver les bons documents) et context precision (absence de bruit dans les résultats). Avec un protocole structuré et les bons outils, vous passez d'un système opaque à un pipeline mesurable et améliorable.
Le problème
Vous avez construit un assistant IA connecté à votre base documentaire. Les premiers tests sont encourageants. Vous déployez en interne. Et puis les remontées arrivent : « L'IA a inventé un chiffre qui n'existe nulle part », « La réponse ne correspond pas à ce que dit le document », « Il a ignoré la procédure mise à jour le mois dernier ». Ces problèmes sont prévisibles — et mesurables — si vous avez un protocole d'évaluation en place.
Le défi fondamental d'un RAG est qu'il combine deux systèmes faillibles : un moteur de recherche vectorielle qui peut récupérer les mauvais documents, et un LLM qui peut mal interpréter ou halluciner à partir des bons documents. Sans métriques distinctes pour chaque composant, vous ne savez pas lequel corriger quand la réponse est mauvaise.
Les trois symptômes les plus fréquents d'un RAG non évalué :
- Hallucinations silencieuses — Le LLM génère des réponses plausibles mais fausses. Sans vérification systématique contre les sources, personne ne s'en aperçoit jusqu'à ce qu'une décision métier soit prise sur une information erronée.
- Dégradation progressive — Au fil des ajouts de documents, la qualité de la recherche se dégrade. Les nouveaux documents introduisent du bruit, les embeddings perdent en précision, mais aucune alerte ne se déclenche.
- Optimisation à l'aveugle — Vous modifiez le prompt, changez le modèle d'embedding, ajustez le nombre de chunks récupérés… sans savoir si ces changements améliorent ou dégradent les résultats. Chaque itération est un pari.
Le coût de l'inaction est réel : une étude interne menée auprès de nos clients montre que 34% des réponses RAG non évaluées contiennent au moins une inexactitude. Après mise en place d'un protocole d'évaluation et de correction, ce taux tombe à 8%.
La solution IA
Un protocole d'évaluation RAG repose sur trois piliers : des métriques automatisées pour le suivi continu, un dataset de référence pour les tests de régression, et des évaluations humaines pour les cas critiques. Voici les trois composants essentiels à mettre en place.
Métriques automatisées (LLM-as-Judge)
Utilisez un LLM évaluateur (GPT-4o, Claude) pour noter automatiquement la faithfulness, la relevance et la complétude de chaque réponse. Ragas et DeepEval fournissent des implémentations prêtes à l'emploi. Coût : environ 0.02$ par évaluation. Exécution quotidienne sur un échantillon de requêtes réelles.
Dataset de référence (Golden Set)
Constituez un jeu de 200 à 500 paires question/réponse validées par des experts métier. Ce dataset sert de référence pour les tests de non-régression après chaque modification du pipeline. Incluez des questions factuelles, comparatives, multi-documents et des questions pièges hors périmètre.
Évaluation humaine ciblée
Chaque semaine, un expert métier évalue 20 réponses critiques sur une échelle de 1 à 5. Cette boucle de feedback humain détecte les faux positifs des métriques automatisées et alimente le dataset de référence. Utilisez Argilla ou Label Studio pour structurer le processus d'annotation.
Mise en oeuvre
La mise en place d'un pipeline d'évaluation RAG prend 3 à 6 semaines selon la maturité de votre infrastructure. Voici les trois phases clés.
Construire le Golden Set (semaines 1-2)
Collectez 200 questions représentatives de vos utilisateurs réels. Pour chaque question, rédigez la réponse attendue et identifiez les passages sources pertinents. Catégorisez les questions par type (factuel, comparatif, procédural, hors scope). Impliquez au moins 2 experts métier pour valider les réponses de référence. Stockez le tout dans un format structuré (JSON ou CSV) versionné dans Git.
Implémenter les métriques automatisées (semaines 3-4)
Intégrez Ragas ou DeepEval dans votre pipeline CI/CD. Configurez les 4 métriques essentielles : faithfulness (seuil > 0.85), answer relevancy (seuil > 0.80), context recall (seuil > 0.75) et context precision (seuil > 0.70). Branchez le pipeline sur LangSmith ou Weights & Biases pour visualiser les tendances. Automatisez l'exécution quotidienne sur 50 requêtes échantillonnées des logs de production.
Boucle d'amélioration continue (semaines 5-6)
Analysez les premiers résultats : identifiez les catégories de questions où le score est le plus faible. Corrigez en priorité les problèmes de retrieval (chunks mal découpés, métadonnées manquantes) avant les problèmes de génération (prompt engineering). Mettez en place un dashboard de suivi avec alertes automatiques quand une métrique passe sous le seuil. Planifiez une revue hebdomadaire des 20 pires réponses avec l'équipe métier.
Résultats
Voici les résultats mesurés chez nos clients après mise en place d'un protocole d'évaluation RAG structuré, sur des projets de RAG entreprise.
Questions fréquentes
Qu'est-ce qu'une métrique de faithfulness en RAG ?
La faithfulness mesure si la réponse générée par le LLM est fidèle aux documents sources récupérés. Concrètement, chaque affirmation de la réponse doit pouvoir être tracée vers un passage du contexte. Un score de 0.85 signifie que 85% des affirmations sont vérifiables dans les sources. C'est la métrique la plus critique pour éviter les hallucinations.
Combien de questions faut-il dans un dataset d'évaluation RAG ?
Minimum 50 questions pour un pilote, idéalement 200 à 500 pour une évaluation robuste en production. Les questions doivent couvrir les différents types de requêtes utilisateurs : factuelles, comparatives, multi-documents et hors périmètre. Prévoyez 20% de questions pièges (hors scope) pour mesurer le taux de refus approprié.
Quels outils utiliser pour évaluer une chaîne RAG ?
Les trois outils de référence sont Ragas (open source, métriques standardisées), DeepEval (framework Python avec 14 métriques) et LangSmith (plateforme LangChain pour le tracing et l'évaluation). Pour les évaluations humaines, Argilla permet d'annoter les résultats collaborativement. Comptez 2 à 4 semaines pour mettre en place un pipeline d'évaluation complet.
À quelle fréquence faut-il évaluer sa chaîne RAG ?
En production, exécutez une évaluation automatisée quotidienne sur un échantillon de 50 requêtes réelles. Complétez par une évaluation humaine hebdomadaire sur 20 cas critiques. Relancez une évaluation complète (200+ questions) après chaque modification du pipeline : changement de modèle d'embedding, ajout de documents, modification du prompt ou mise à jour du LLM.
Pour les profils tech
Architecture d'un pipeline d'évaluation RAG
Le pipeline d'évaluation s'intègre en parallèle de votre chaîne RAG existante. Il intercepte les triplets (question, contexte récupéré, réponse générée) et calcule les métriques en asynchrone. L'implémentation de référence utilise Ragas comme moteur de métriques, LangSmith pour le tracing, et Weights & Biases pour le suivi longitudinal.
Les 4 métriques essentielles à implémenter :
- Faithfulness — Décompose la réponse en claims, vérifie chaque claim contre le contexte. Implémentation : NLI (Natural Language Inference) ou LLM-as-Judge.
- Answer Relevancy — Génère N questions à partir de la réponse, mesure la similarité cosinus avec la question originale. Score élevé = réponse ciblée, score faible = réponse vague ou hors sujet.
- Context Recall — Compare les passages récupérés avec les passages de référence du Golden Set. Identifie les documents manqués par le retriever.
- Context Precision — Mesure la proportion de passages récupérés réellement utiles pour répondre. Un score faible indique trop de bruit dans le retrieval.
Comparatif des frameworks d'évaluation
| Critère | Ragas | DeepEval | LangSmith | TruLens |
|---|---|---|---|---|
| Métriques RAG natives | 8 métriques | 14 métriques | 5 métriques | 6 métriques |
| Open source | Oui (Apache 2) | Oui (Apache 2) | Partiel | Oui |
| Intégration CI/CD | pytest natif | pytest natif | API REST | API REST |
| Dashboard | Basique | Confident AI | Complet | Complet |
| Coût | Gratuit + coût LLM | Gratuit + coût LLM | Freemium (1$/dev/jour) | Gratuit + coût LLM |