Évaluation et Tests

1. Pourquoi l'évaluation est la discipline manquante

Il existe une version du génie logiciel dans laquelle la justesse est définie par une suite de tests. Vous écrivez une fonction, vous écrivez des tests par rapport à une spécification, et les tests réussissent ou échouent. La qualité de la fonction n'est pas une question d'opinion ; c'est une question de preuves. Le prompt engineering pratiqué sans évals n'a pas d'équivalent à cela. Le prompt semble "correct" ou ne l'est pas — et ce n'est pas une fondation sur laquelle on peut bâtir un système fiable.

La difficulté fondamentale est que les sorties des modèles de langage sont stochastiques et à haute dimension. Le même prompt peut produire des sorties différentes lors d'exécutions successives. L'espace de sortie n'est pas un binaire réussite/échec mais une distribution continue sur la qualité. Cela signifie que l'évaluation des systèmes LLM est intrinsèquement probabiliste : vous ne vous demandez pas "est-ce que cela renvoie la bonne valeur ?" mais "est-ce que ce système produit des sorties dans la bande de qualité acceptable, de manière fiable, sur une distribution représentative d'entrées ?"

Shankar et al. (2024) en démontrent une dimension dans leur étude sur la manière dont les équipes calibrent l'évaluation assistée par LLM par rapport aux préférences humaines — montrant une divergence systématique lorsque les pipelines de juges ne sont pas alignés.^#Validator L'infrastructure d'éval n'est pas un luxe qui arrive après que le produit fonctionne. C'est l'instrument qui vous dit si le produit fonctionne dès le départ.

En pratique, les équipes sans pipelines d'éval structurés ont tendance à surestimer la qualité du système, à attribuer à tort les échecs aux mauvais composants et à régresser sur des capacités fonctionnant précédemment lorsqu'elles itèrent sur des prompts sans tests de régression. Ce sont des schémas d'échec récurrents chez les praticiens contre lesquels il faut se prémunir par la conception.

Une raison secondaire pour laquelle l'évaluation est négligée : elle nécessite de rendre explicite la barre de qualité. Dire "la sortie doit être utile et précise" n'est pas une spécification — c'est un souhait. Écrire une éval vous force à opérationnaliser la qualité : précise par rapport à quelle vérité terrain (ground truth), utile selon quelle grille d'évaluation (rubric), évaluée contre quelle distribution d'entrée. Cet exercice, aussi inconfortable soit-il, fait surface les désaccords sur ce que le système est censé faire avant que ces désaccords ne fassent surface en production.

2. La pile d'évaluation

Un cadre d'évaluation mature comporte trois couches, chacune répondant à une question différente. N'exécuter que la couche supérieure — évaluation humaine de bout en bout — est coûteux, lent et ne produit aucun signal sur l'origine d'un échec. N'exécuter que la couche inférieure — tests unitaires sur des prompts individuels — ne vous dit rien sur le fonctionnement de la pipeline complète. Vous avez besoin des trois.

En pratique, L1 et L2 s'exécutent automatiquement à chaque changement de prompt — ils constituent votre pipeline de CI (Intégration Continue). L3 s'exécute périodiquement (chaque semaine, ou avant une version majeure) et lorsque les scores automatisés changent de manière inattendue. Les sorties de L3 sont utilisées pour calibrer L1 et L2 : si un prompt de juge note très bien des sorties que les évaluateurs humains notent systématiquement mal, le prompt du juge doit être révisé.

La pyramide des coûts est inversée : L1 est assez bon marché pour être exécuté à chaque commit, L2 coûte des dizaines à des centaines d'appels API par exécution, L3 coûte du temps humain. Concevez votre pipeline de manière à ce que L1 capture la majorité des régressions avant qu'elles n'atteignent L2, et que L2 capture les échecs avant qu'ils n'atteignent L3.

3. Construire le dataset d'évaluation

Un dataset d'éval est une collection de triplets (entrée, sortie attendue, métadonnées) par rapport auxquels votre système est mesuré. Bien le construire est l'un des investissements les plus rentables de tout le flux de travail en prompt engineering — un dataset qui ne représente pas votre véritable distribution d'entrée produira des scores d'éval vides de sens, ou pire, trompeurs.

Le "golden set"

Commencez par un golden set de 50 à 100 exemples vérifiés manuellement. C'est l'éval minimale viable — assez petite pour être annotée avec soin, assez grande pour détecter des différences de performance significatives entre les versions de prompt. Les exemples doivent être tirés de votre distribution d'entrée réelle ou attendue, pas de cas pratiques faciles à vérifier.

Un golden set bien construit comporte quatre composants pour chaque exemple : l'entrée, la réponse de référence (vérité terrain), une grille d'évaluation (rubric) qui définit ce qu'est une réponse correcte, et une étiquette de catégorie qui vous permet d'analyser la performance par type d'entrée. L'étiquette de catégorie est particulièrement importante — un score agrégé de 82% peut cacher si votre système échoue uniformément ou de manière catastrophique sur une sous-catégorie spécifique.

Cas adverses et cas limites

Un golden set tiré uniquement d'entrées représentatives passera à côté des modes d'échec qui importent le plus. Consacrez au moins 20% de votre ensemble d'éval aux cas adverses et limites : des entrées conçues pour sonder les frontières de la fiabilité du système.

À mesure que le système mûrit, les ajouts les plus précieux à l'ensemble d'éval sont les cas dérivés d'échecs : des entrées réelles issues de la production où le système a produit une sortie erronée ou problématique. Ce sont les cas que vous n'aviez pas anticipés lors de la conception du système, ce qui en fait les cas sur lesquels le système est le plus susceptible de continuer à échouer. Chaque échec en production doit produer au moins un nouveau cas d'éval.

4. Taxonomie des métriques

Aucune métrique unique ne capture la qualité de la sortie pour toutes les tâches. Le bon choix dépend du type de tâche, du format de sortie et de l'investissement possible dans l'annotation. Les trois niveaux suivants couvrent toute la gamme des besoins d'évaluation LLM, du plus économique au plus expressif.

Correspondance exacte et métriques basées sur des règles

La correspondance exacte de chaînes, la correspondance par regex et la validation de schéma sont les métriques les moins chères et les plus fiables — lorsqu'elles sont applicables. Elles le sont lorsque le format de sortie est totalement contraint : on attend du modèle qu'il renvoie un schéma JSON spécifique, une étiquette de classification issue d'un vocabulaire fixe, un booléen ou un nombre. Dans ces cas, une vérification basée sur des règles est à la fois plus rapide et plus fiable que n'importe quelle métrique basée sur un modèle.

Le mode d'échec est évident : la correspondance exacte est trop stricte pour toute tâche impliquant la génération de langage naturel. Une réponse qui répond correctement à une question avec des mots différents échouera à une évaluation par correspondance exacte. Utilisez les métriques basées sur des règles pour la structure de sortie et les clés factuelles (le JSON contient-il les champs requis ? l'étiquette est-elle dans l'ensemble autorisé ?), pas pour le contenu du texte généré.

Similitude sémantique

Les métriques basées sur des références comparent la sortie générée à une chaîne de référence en utilisant des embeddings ou le chevauchement de n-grammes. ROUGE (Recall-Oriented Understudy for Gisting Evaluation) mesure le chevauchement de n-grammes et est le standard pour les tâches de résumé.^#ROUGE BERTScore calcule la similitude cosinus au niveau des jetons entre la sortie générée et la référence en utilisant des embeddings contextuels, ce qui le rend plus robuste à la paraphrase que les méthodes n-grammes.^#BERTScore

La limite de toutes les métriques basées sur des références est qu'elles nécessitent... une référence. Lorsque plusieurs bonnes réponses existent, ou lorsque la référence a été écrite par un humain qui a utilisé une formulation particulière, le score pénalise les bonnes paraphrases et récompense les sorties qui ressemblent superficiellement à la référence, indépendamment de la justesse factuelle. Traitez ces métriques comme nécessaires mais insuffisantes : un ROUGE élevé ne signifie pas une haute qualité ; un ROUGE bas ne signifie pas une basse qualité.

LLM-as-judge

L'approche la plus expressive et de plus en plus dominante : utiliser un second modèle de langage — généralement un modèle plus puissant que celui évalué — comme juge automatisé. Le modèle juge lit l'entrée, la sortie du système et éventuellement une réponse de référence, et note la sortie selon une rubrique que vous définissez dans le prompt du juge.

Zheng et al. (2023) formalisent cela dans le cadre d'évaluation MT-Bench, démontrant que GPT-4 en tant que juge obtient plus de 80% d'accord avec les évaluateurs experts humains sur des tâches de suivi d'instructions à réponse ouverte — comparable au taux d'accord entre deux annotateurs humains indépendants — sur une gamme de tâches de génération ouvertes.^#Judge Cette découverte s'est confirmée dans les études ultérieures et a établi le LLM-as-judge comme le standard pratique pour évaluer le texte généré à grande échelle.^#Judge

5. Concevoir le prompt du juge

Un juge LLM ne vaut que ce que vaut son prompt. Un prompt de juge vague produit des scores bruyants et incohérents qui ajoutent de la variance sans ajouter de signal. Les principes de conception ci-dessous sont dérivés de la méthodologie MT-Bench et des conclusions pratiques de Shen et al. (2023), qui ont trouvé les évaluateurs LLM incohérents et dépendants de la dimension dans leur évaluation du résumé abstractif — une alerte précoce indiquant que les pipelines de juges non calibrés produisent des signaux peu fiables.^{#Summarization}

Utilisez un score par points avec des critères explicites, pas une comparaison relative. Demander au juge de choisir la meilleure de deux sorties introduit un biais de position — le juge favorise systématiquement la sortie présentée en premier. La notation absolue par rapport à une rubrique produit des résultats plus cohérents et est plus facile à interpréter.

Définissez explicitement chaque niveau de score. "Notez sur une échelle de 1 à 5" n'est pas une rubrique. Une rubrique indique au juge ce qui différencie précisément un 3 d'un 4 — sinon, les distributions de scores se regroupent autour de 3-4 car le juge n'a aucune raison de principe d'utiliser les extrêmes.

Demandez une réponse structurée avec le raisonnement en premier. Forcer le juge à produire une explication avant de s'engager sur un score réduit l'ancrage positionnel et produit une trace de raisonnement que vous pouvez inspecter lorsque les scores sont inattendus. C'est le principe de la chaîne de pensée appliqué à l'évaluation.

Trois biais connus à tester et à atténuer dans votre prompt de juge. Le biais de verbosité : les juges ont tendance à noter plus haut les réponses plus longues, indépendamment de la qualité du contenu — contrez cela en pénalisant explicitement la longueur inutile dans la rubrique. Le biais de self-enhancement : un modèle utilisé comme son propre juge note ses propres sorties plus haut qu'un juge indépendant ne le ferait — utilisez une famille de modèles différente pour le juge. Le biais de format : les réponses avec un formatage Markdown, des titres et des listes sont mieux notées qu'une prose simple de qualité égale — contrôlez cela en dépouillant ou en normalisant le formatage de la sortie avant l'évaluation. Les types spécifiques de biais — verbosité, auto-amélioration et format — sont largement documentés dans les recherches sur l'évaluation des LLM, y compris dans l'étude MT-Bench citée plus haut.

Calibrez votre juge par rapport à des annotations humaines avant de lui faire confiance à grande échelle. Si votre juge et vos évaluateurs humains sont en désaccord sur plus de 25% des exemples, le prompt du juge a besoin d'une révision — pas un modèle plus puissant, mais une rubrique plus précise. La capacité du modèle est rarement le goulot d'étranglement de la qualité du juge ; la précision de la rubrique l'est presque toujours.

6. Évaluer les pipelines RAG

Un pipeline RAG comporte deux composants qui doivent être évalués indépendamment : le système de récupération et le système de génération. Évaluer uniquement la sortie finale — "la réponse est-elle correcte ?" — rend impossible la localisation des échecs. Une mauvaise réponse peut signifier que les bons fragments ont été récupérés mais que le modèle les a ignorés, ou que les mauvais fragments ont été récupérés et que le modèle les a fidèlement reproduits. La correction est différente dans chaque cas.

Es et al. (2023) introduisent le cadre RAGAS — Retrieval-Augmented Generation Assessment — comme une méthodologie d'évaluation largement sans référence — le rappel de contexte nécessite une réponse étalon, tandis que les trois autres métriques n'en ont pas besoin — qui décompose la qualité du RAG en quatre métriques indépendantes, ciblant chacune un mode d'échec spécifique.^#RAGAS

Métriques de récupération

Le rappel de contexte (Context recall) mesure si les fragments récupérés contiennent assez d'informations pour répondre à la question. Il est calculé en vérifiant si chaque affirmation de la réponse de vérité terrain est attribuable à au moins un fragment récupéré — une métrique basée sur une référence qui rend la qualité de récupération directement mesurable. Un faible rappel de contexte signifie que l'information correcte n'a pas été récupérée ; le correctif se trouve dans la configuration du découpage ou de la récupération, pas dans le prompt de génération.

La précision du contexte (Context precision) mesure la proportion de fragments récupérés qui sont réellement pertinents pour la requête. Un système qui récupère dix fragments, dont seulement deux sont pertinents, a une faible précision — et les huit fragments non pertinents diluent le signal et déclenchent potentiellement les échecs de sur-récupération décrits dans la leçon 05. La précision du contexte est sans référence : elle peut être calculée avec un juge LLM qui note l'aptitude de chaque fragment à répondre à la requête indépendamment.

Métriques de génération

La fidélité (Faithfulness) est la métrique de génération spécifique au RAG la plus importante. Elle mesure si chaque affirmation factuelle dans la réponse générée est étayée par le contexte récupéré — pas si la réponse est correcte, mais si elle est fondée. Une réponse fidèle basée sur un mauvais contexte reste un succès de fidélité ; corriger le score de fidélité est un problème de récupération, pas de génération. Utilisez un prompt de juge structuré comme l'exemple de la section 5.

La pertinence de la réponse (Answer relevance) mesure si la réponse générée s'adresse réellement à la question posée. Un mode d'échec courant dans les systèmes RAG est l'excès de prudence (hedging) : le modèle produit une réponse du type "D'après les informations disponibles, plusieurs considérations existent..." qui est techniquement fondée mais n'est pas une réponse directe à la requête. La pertinence de la réponse est calculée en demandant à un juge si la question est totalement répondue, partiellement répondue ou évitée — et elle capture ce schéma de prudence que les scores de fidélité ignorent totalement.

Exécutez les quatre métriques sur chaque mise à jour de votre ensemble d'éval. Suivez-les comme des séries temporelles distinctes. Un changement de prompt qui améliore la fidélité tout en dégradant la précision du contexte, ou qui améliore la pertinence tout en dégradant le rappel, vous dit précisément ce qui a changé — et cette précision est ce qui rend l'itération possible.

7. Tests de régression et CI

Un prompt est un artefact logiciel. Il doit être versionné, revu et testé avant déploiement — de la même manière que tout autre changement de code. La raison pour laquelle la plupart des équipes ne le font pas est que les outils pour le versionnage de prompts ont historiquement été médiocres et que la boucle de feedback a été informelle. Ces deux conditions ont considérablement évolué. Il n'y a plus de bonne excuse pour déployer des changements de prompt sans exécuter une suite de régression au préalable.

L'exigence de base est simple : lorsqu'un prompt du système change, exécutez la suite d'éval complète pour ce prompt et affichez un différentiel (diff) des changements de score. Un changement qui améliore la performance globale tout en régressant sur une catégorie d'entrée spécifique n'est visible que si vous avez les étiquettes de catégorie et la référence historique pour comparer. Sans cette infrastructure, les régressions se propagent silencieusement en production.

Khattab et al. (2023) formalisent cela davantage dans DSPy, qui présente l'ensemble du pipeline de prompt engineering comme un problème de compilation : les prompts ne sont pas écrits à la main mais optimisés automatiquement par rapport à une métrique, la suite d'éval servant de fonction objectif à maximiser par le compilateur.^#DSPy Même sans adopter l'approche d'optimisation entièrement automatisée de DSPy, l'idée centrale est correcte : la suite d'éval est la spécification, et l'itération sur les prompts est la procédure de recherche. Cette formulation rend la valeur d'un dataset d'éval rigoureux évidente — ce n'est pas une surcharge de test, c'est la cible que vous visez.

Le problème du diff de prompt

Une subtilité unique au versionnage de prompts : de petits changements de formulation peuvent produire des changements de sortie importants et non évidents. Ajouter "sois concis" à un prompt système peut améliorer la longueur moyenne des sorties mais dégrader la fidélité parce que le modèle omet des nuances. Retirer "Tu es un expert en..." peut réduire légèrement le calibrage de la confiance d'une manière qui nécessite cinquante évaluations pour être détectée statistiquement.

L'implication est que les changements de prompt doivent être revus avec la même minutie que les changements de code sur les chemins critiques — et le diff d'éval est l'outil de code review. Un changement qui montre des scores corrects globalement mais déplace la distribution des scores individuels (plus de 3 et de 5, moins de 4) n'est pas un changement neutre ; c'est un changement dans la fiabilité que l'agrégat dissimule. Suivez la variance des scores, pas seulement la moyenne.

8. La décision de mise en production

La décision de mise en production est une question de jugement, pas un calcul — mais elle doit être éclairée par des preuves. L'infrastructure d'éval construite dans cette leçon existe pour produire ces preuves. Voici un cadre pratique pour traduire les scores d'éval en une décision argumentée.

L'erreur de livraison la plus courante n'est pas de livrer trop tôt — c'est de livrer sans avoir défini ce que signifie "prêt". Une équipe qui n'a pas fixé de score cible avant la première éval trouvera toujours une raison pour laquelle le score actuel est acceptable. Une équipe avec une cible prédéfinie dispose d'un critère clair, objectif et reproductible qui ne peut pas être ajusté après coup.

Une seconde erreur courante consiste à traiter la livraison initiale comme la fin du processus d'évaluation. La production est le lieu de la véritable distribution d'entrée. Les requêtes des utilisateurs réels contiendront des schémas, des formulations et des variétés d'intentions que votre golden set n'a pas anticipés. L'infrastructure d'éval construite avant le lancement est la référence ; le système de surveillance en production est ce qui vous dit si cette référence tient la route. C'est un processus continu, pas deux phases distinctes.

Références

1. #Validator Shankar, S., et al. (2024). Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences. Étudie le calibrage de l'évaluation assistée par LLM par rapport aux préférences humaines et signale une divergence systématique lorsque les pipelines de juges sont insuffisamment alignés. arXiv:2404.12272
2. #ROUGE Lin, C.-Y. (2004). ROUGE: A Package for Automatic Evaluation of Summaries. Introduit la famille de métriques ROUGE basée sur le chevauchement de n-grammes ; reste le standard pour l'évaluation du résumé. Proceedings of the ACL Workshop on Text Summarization Branches Out. aclanthology.org/W04-1013
3. #BERTScore Zhang, T., et al. (2019). BERTScore: Evaluating Text Generation with BERT. Utilise des embeddings contextuels BERT pour calculer la similitude sémantique entre le texte généré et la référence ; plus robuste à la paraphrase que les méthodes n-grammes. ICLR 2020. arXiv:1904.09675
4. #Judge Zheng, L., et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. Établit le LLM-as-judge comme une méthodologie d'évaluation scalable, rapportant >80% d'accord entre les juges GPT-4 et les annotateurs experts humains. NeurIPS 2023. arXiv:2306.05685
5. #Summarization Shen, T., et al. (2023). Large Language Models are Not Yet Human-Level Evaluators for Abstractive Summarization. Constate que les évaluateurs LLM sont incohérents et dépendants de la dimension dans l'évaluation du résumé abstractif, soulignant les limites de fiabilité pour les configurations de juges non calibrés. arXiv:2305.13091
6. #RAGAS Es, S., et al. (2023). RAGAS: Automated Evaluation of Retrieval Augmented Generation. Introduit le cadre à quatre métriques RAGAS — rappel de contexte, précision du contexte, fidélité et pertinence de la réponse — pour l'évaluation des composants RAG sans nécessiter de références de vérité terrain. arXiv:2309.15217
7. #DSPy Khattab, O., et al. (2023). DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines. Formule le prompt engineering comme un problème de compilation avec des métriques d'éval comme fonction objectif ; introduit l'optimisation automatique des prompts par rapport à un ensemble d'éval étiqueté. arXiv:2310.03714
8. #Survey Guo, Q., et al. (2023). Evaluating Large Language Models: A Comprehensive Survey. Large taxonomie des dimensions d'évaluation des LLM incluant la capacité, l'alignement et la sécurité ; couvre les méthodologies d'évaluation automatisées et humaines par types de tâches. arXiv:2310.19736
9. #Anthropic Anthropic. (2025). Define success criteria and build evaluations. Documentation d'Anthropic sur la construction de pipelines d'éval pour les systèmes basés sur Claude : critères de succès, conception de jeux de données et flux de développement de tests avant déploiement. platform.claude.com/docs/en/test-and-evaluate/develop-tests