> For the complete documentation index, see [llms.txt](https://guides.ia.numerique.gouv.fr/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guides.ia.numerique.gouv.fr/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/evaluations-automatisees.md). # Evaluations automatisées {% hint style="info" icon="arrows-to-circle" %} **Automatiser l’évaluation du système RAG via des métriques de qualité, de conformité et de performance** {% endhint %} 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](/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/jeu-de-donnees-de-reference.md) 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. {% hint style="info" %} *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.* {% endhint %} 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) {% hint style="info" icon="cubes-stacked" %} #### 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 {% endhint %} {% hint style="info" icon="cubes-stacked" %} #### 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 {% endhint %} #### Evaluation de la génération {% hint style="info" icon="cubes-stacked" %} #### 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 {% endhint %} {% hint style="info" icon="cubes-stacked" %} #### 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 {% endhint %} #### Evaluation de la sécurité et de la conformité {% hint style="info" icon="cubes-stacked" %} #### 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 {% endhint %} {% hint style="info" icon="cubes-stacked" %} #### 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)** > {% endhint %} {% hint style="info" icon="cubes-stacked" %} #### **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** > {% endhint %} #### Evaluations des performance technique {% hint style="info" icon="cubes-stacked" %} #### 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. > {% endhint %} {% hint style="info" icon="cubes-stacked" %} #### 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. > {% endhint %} *** *\* 💡 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.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://guides.ia.numerique.gouv.fr/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/evaluations-automatisees.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.