Evaluations automatisées

Automatiser l’évaluation du système RAG via des métriques de qualité, de conformité et de performance

L'évaluation automatisée d’un système RAG désigne l’ensemble des méthodes et outils permettant de mesurer de manière systématique, reproductible et à grande échelle la qualité, la performance et la robustesse d’un assistant, sans intervention humaine directe sur chaque test.

Elle repose généralement sur :

• un jeu de données de référence représentatif des usages réels ;
• des métriques objectivables, correspondant aux critères de qualité attendus, appliquées à la fois à la recherche documentaire (retriever) et à la génération de réponses ;
• des outils d’exécution et de comparaison automatique, permettant d’évaluer différentes versions du système dans le temps.

L’évaluation automatique ne se substitue pas à l’évaluation humaine, indispensable pour juger la pertinence métier, l’utilité et la confiance, mais constitue un socle indispensable pour avoir une équipe autonome dans l'évolution de l'outil et industrialiser le pilotage de la qualité d’un système RAG, en particulier lors du passage à l’échelle et en production.

L'effort de la mise en place repose sur l'ensemble de l'équipe : les profils métier sur la création du jeu de données de référence et les profils techniques sur l'implémentation technique des évaluations automatisées.

Critères de qualité attendus et métriques associées

L’évaluation de la qualité d’un système RAG ne peut pas se limiter à un indicateur unique. La performance globale d’un assistant conversationnel repose sur plusieurs dimensions complémentaires, qu’il est nécessaire de définir en amont pour éviter toute analyse partielle ou biaisée. La première étape consiste donc à clarifier les critères de qualité attendus au regard des usages métier.

• Pertinence

La pertinence constitue un premier critère fondamental. Il s’agit d’évaluer si la réponse produite correspond réellement à la question posée par l’utilisateur. Cette analyse ne porte pas uniquement sur le contenu textuel de la réponse, mais également sur son adéquation avec l’intention exprimée et sur la pertinence des sources mobilisées. Une réponse peut être techniquement correcte tout en étant mal orientée ou insuffisamment contextualisée par rapport au besoin réel.

• Fidélité

La fidélité aux sources représente un second critère essentiel. Dans un système RAG, la réponse doit être strictement ancrée dans les documents récupérés par le moteur de recherche. Il convient donc de vérifier que le contenu généré reflète fidèlement les informations présentes dans les sources et qu’aucun élément n’est inventé ou extrapolé de manière abusive. La capacité du système à s’abstenir de répondre lorsqu’aucune information pertinente n’est disponible constitue également un indicateur important de maturité et de fiabilité.

• Performance de l'expérience :

La qualité d’un système RAG ne se limite toutefois pas au contenu informationnel. La performance de l’expérience utilisateur doit également être prise en compte. La rapidité de réponse, la stabilité du service et, dans certains contextes, la consommation de ressources ou le coût énergétique participent à l’évaluation globale. Un assistant précis mais trop lent ou instable peut difficilement être déployé à grande échelle.

Ces différents critères doivent être analysés à la lumière de l’architecture même du système. Pour mémoire, un RAG repose sur deux composants étroitement interdépendants :

• le moteur de recherche (retriever), chargé d’identifier les documents pertinents dans la base de connaissances,
• le modèle de génération (LLM), qui rédige la réponse à partir des éléments récupérés.

Les métriques d’évaluation doivent donc couvrir ces deux briques distinctes, en mesurant à la fois la qualité de la recherche documentaire et celle de la génération.

Dans la pratique, les critères métier sont traduits en familles de métriques implémentées par les profils techniques de l’équipe. À terme, ces indicateurs ont vocation à être automatisés, visualisables dans des tableaux de bord et partagés avec les profils fonctionnels afin d’objectiver les décisions d’amélioration.

Il existe peu de références universelles sur les seuils à atteindre pour considérer qu’un système RAG est satisfaisant. Une approche pragmatique consiste à définir d’abord les critères métier prioritaires, à les décliner en métriques mesurables, puis à établir une baseline sur la première version du système. Les évolutions ultérieures doivent viser une amélioration progressive de cette baseline, tout en étant systématiquement confrontées aux retours utilisateurs, qui demeurent un indicateur déterminant de la qualité réelle perçue.

Les métriques permettent de mesurer, de manière standardisée, l’écart entre la réponse produite par le système et la réponse attendue sur différents critères d'analyse.

Ces métriques sont généralement calculées à partir d’un jeu de données de référence. Pour chaque question de ce jeu, le système génère une réponse qui est ensuite comparée à la réponse attendue définie en amont. Cette démarche permet d’objectiver les progrès, d’identifier les régressions et d’ancrer l’amélioration du système dans une logique mesurable et continue. Nous décrivons, de manière théorique, quatre grande familles de métriques avec des objectifs de mesure complémentaires.

Familles de métriques

Métriques liées à la récupération (Retriever)

Ces métriques évaluent la capacité du système à identifier et sélectionner les documents pertinents en amont de la génération :

• taux de rappel et de précision des documents récupérés ;
• position des documents pertinents dans les résultats (ranking) ;
• couverture des sources attendues.

Une faiblesse à ce niveau impacte mécaniquement la qualité de la réponse finale, indépendamment du modèle de langage utilisé.

Métriques liées à la génération de la réponse (LLM)

Les métriques de génération visent à évaluer la qualité du texte produit à partir des documents récupérés :

• cohérence et complétude de la réponse ;
• fidélité aux sources (absence d’hallucination) ;
• adéquation avec la réponse attendue du jeu de référence.

Certaines métriques reposent sur des comparaisons textuelles, tandis que d’autres utilisent des modèles de langage comme juges* pour évaluer la qualité ou la conformité des réponses.

Métriques liées à l'éthique et la conformité

Il est également nécessaire d’intégrer des métriques spécifiques pour :

• détecter des biais potentiels (culturels, sociaux, idéologiques) ;
• identifier des réponses discriminantes ou inappropriées ;
• vérifier le respect des règles de sécurité, de neutralité et de conformité réglementaire.

Métriques liées aux performances techniques

Enfin, l’évaluation automatique doit inclure des métriques techniques, telles que :

• le temps de réponse ;
• la stabilité du système ;
• le taux d’erreurs ou d’échecs ;
• la consommation de ressources (CPU, mémoire, appels API)
• la consommation énergétique

Ces éléments conditionnent directement l’expérience utilisateur et la capacité de passage à l’échelle. Le calcul des métriques s'effectue sur la base d'un jeu de données de référence.

Métriques simples pour évaluer un assistant RAG

Pour démarrer la construction d'un assistant conversationnel basé sur un système RAG, parmi l'ensemble des métriques disponibles, nous préconisons un sous-ensemble de démarrage :

Métrique	pour vérifier que l'outil	composant
Recall@k	trouve les bons documents	retriever
Precision@k	évite le bruit	retriever
Faithfulness	s'ancre dans les sources	generation
Answer Relevancy	répond utilement à la question	generation
Toxicity, biais	évite les contenus nocifs	generation
Multi-turn consistency	conserve le contexte tout au long de la conversation	generation
Latence	est réactif pour les utilisateurs	infra
Consommation	reste frugal compte tenu du besoin fonctionnel	infra

Ces métriques forment un baromètre équilibré automatisable quotidiennement sans annotation humaine coûteuse. Elles couvrent les trois dimensions critiques d’un système RAG conversationnel :

• Qualité du retrieval (contexte)
• Qualité de la génération (réponse)
• Sécurité et conformité

Ce socle constitue une base générique extensible, pouvant être enrichie selon les exigences métier et techniques.

Evaluation la récupération (retriever)

Recall@k

Question clé : est-ce que les documents nécessaires à la réponse sont présents parmi les k premiers résultats ? Mesure : évalue si l’information nécessaire à la bonne réponse est bien présente dans le contexte transmis au modèle de génération.

Formule : Recall@k = (Documents pertinents retrouvés dans le top-k) / (Documents pertinents attendus)

Échelle : Score de 0 à 1

Exemple d’interprétation :

3 documents sont considérés comme pertinents pour répondre à une question. Le système en retrouve 2 dans les 5 premiers résultats (k=5) → Recall@5 = 2 / 3 = 0,67 Le retriever retrouve une majorité des documents utiles, mais pas tous.

Points d’attention

• dépend fortement de la qualité du jeu de données de référence (gold set)
• Peut être élevé même si les résultats contiennent beaucoup de bruit

Precision@k

Question clé : parmi les documents récupérés, combien sont réellement utiles ?

Mesure : évalue si les documents proposés dans les k premiers résultats sont réellement pertinents, ou s’ils contiennent du bruit.

Formule : Precision@k = (Documents pertinents retrouvés dans le top-k) / k

Échelle : Score de 0 à 1

Exemple d’interprétation :

Le système retourne 5 documents (k=5). 3 sont réellement pertinents → Precision@5 = 3 / 5 = 0,60 Les résultats contiennent encore du bruit, mais une majorité est pertinente

Point d'attention

Dans des environnements complexes, il peut être pertinent d’ajouter :

• F1@k (équilibre Recall / Precision)
• MRR (Mean Reciprocal Rank) pour mesurer la position du premier document pertinent

Evaluation de la génération

Faithfulness

Question clé : la réponse est-elle strictement basée sur les informations fournies ?

Mesure : évalue la fiabilité factuelle du système

Formule : une réponse est fidèle si toutes ses affirmations factuelles peuvent être justifiées par les documents sources fournis. Score de fidélité = (Assertions correctes) / (Assertions totales) ou Score de fidélité LLM = un modèle évaluateur attribut un score de fidélité en comparant réponse et contexte

Échelle : Score de 0 à 1

Exemple d’interprétation :

Contexte : “La Tour Eiffel a été inaugurée en 1889.” Réponse : “La Tour Eiffel a été construite en 1895.” → 0.2 (faible fidélité)

Point d'attention

• Faithfulness ≠ exactitude absolue
• Une réponse peut être factuellement vraie mais non fidèle si l’information n’est pas dans le contexte

Answer relevancy

Question clé : la réponse traite-t-elle vraiment la demande de l’utilisateur ?

Mesure : analyse la similarité de sens entre la question et la réponse

Formule - deux approches combinables :

• évaluation par un modèle juge si la réponse à la question pour déterminer si elle y répond complètement, partiellement ou pas du tout.
• calcul de similarité sémantique via embeddings vectoriels (cosine similarity).

Échelle : score continu entre 0 (hors sujet) et 1 (parfaitement pertinent).

Exemple d’interprétation :

Question : “Qu’est-ce qu’un modèle de langage ?” Réponse A : “C’est un système d’IA entraîné à prédire du texte.” → 0.95 Réponse B : “Les modèles d’IA peuvent générer des images.” → 0.4

Point d'attention

• La similarité vectorielle ne capture pas toujours la complétude
• Un score élevé ne garantit pas la correction factuelle

Evaluation de la sécurité et de la conformité

Toxicity

Question clé : la réponse contient-elle des propos agressifs, insultants ou haineux ?

Mesure : détecte la présence de contenu offensant, violent ou discriminant.

Formule

• Modèles spécialisés de classification
• Score probabiliste de toxicité
• Détection multi-classes (insulte, menace, harcèlement, etc.)

Échelle : 0 à 1

Exemple d’interprétation :

Réponse : “C’est une idée stupide.” → 0.4 Réponse : “Tu es un imbécile.” → 0.9

Point d'attention

• Sensibilité au contexte culturel
• Faux positifs possibles dans certains débats

Bias

Question clé : la réponse contient-elle des préjugés, des stéréotypes ou des jugements discriminants ?

Mesure : analyse pour détecter les signes de partialité.

Formule

• Analyse lexicale et sémantique
• Tests contrastifs (même requête avec variables démographiques modifiées)
• Évaluation par LLM-as-judge ou humain

Échelle : 0 à 1

Exemple d’interprétation :

“Les jeunes sont forcément moins compétents.” → 0.9 (biais fort)

Consistency (multi-turn)

Question clé : le modèle reste-t-il cohérent au fil des échanges ?

Mesure : compare les affirmations précédentes avec les nouvelles réponses

Formule : consistency = (Assertions cohérentes) / (Assertions comparées)

Echelle : 0 à 1

Exemples d'interprétation

Réponse 1 : “Votre contrat dure jusqu'en novembre.” Réponse 4 : "Votre contrat dure jusqu'en mars → incohérence

Evaluations des performance technique

Latence

Question clé : le système répond-il suffisamment vite pour garantir une expérience utilisateur fluide?

Mesure : mesure le temps moyen de réponse Formule :

• Latence moyenne = (Somme des temps de réponse) / (Nombre total de requêtes)
• Percentile - P95 = valeur en dessous de laquelle se situent 95 % des temps de réponse.

Unité : ms ou secondes

Exemples d'interprétation

Si 1 000 requêtes ont été traitées : Moyenne = 2,4 s P95 = 4,8 → 95 % des utilisateurs reçoivent une réponse en moins de 4,8 secondes. 5 % subissent une latence plus élevée.

Consommation énergétique

Question clé : Quelle quantité d’énergie est nécessaire pour produire une réponse ?

Mesure : consommation énergétique moyenne par requête / token généré / conversation complète

Formule

• Consommation moyenne par requête = (Énergie totale consommée sur une période) / (Nombre total de requêtes)
• Consommation par token = (Énergie totale consommée) / (Nombre total de tokens générés)

Unité : Wh ou kWh

Exemple d'interprétation

Sur une journée : Énergie totale consommée de12 kWh pour 10 000 requêtes traitées Consommation moyenne = 12 000 Wh / 10 000 = 1,2 Wh par requête Si une version optimisée descend à 0,8 Wh par requête, le système devient 33 % plus efficient à qualité équivalente.

---

* 💡 Prendre en compte le coût des modèles de langage utilisés comme juges

Lorsque des modèles de langage sont utilisés pour évaluer automatiquement les réponses (LLM-as-a-judge), il est indispensable d’intégrer une analyse de coût dans la stratégie d’évaluation.

Chaque appel à un LLM génère :

• un coût financier, idéalement coût par point de qualité gagné (qualité vs coût) ;
• une latence supplémentaire ;
• une empreinte énergétique non négligeable.

Sinon on risque d’avoir un système “bien évalué” mais une boucle d’évaluation trop chère/lente pour itérer. Les bonnes pratiques d’évaluations insistent sur la conception d’évaluations adaptées à la prod (coût/latence/fiabilité)

Il convient donc de :

• réserver ces métriques aux phases ou aux cas à forte valeur ajoutée ;
• limiter leur usage à des échantillons représentatifs plutôt qu’à l’ensemble des données ;
• arbitrer entre modèles plus ou moins coûteux selon le niveau de finesse attendu.