Vous avez construit une suite d’évaluation. Elle réussit, vous déployez, puis les utilisateurs signalent immédiatement des régressions qu’elle n’a pas détectées.
C’est l’une des situations les plus courantes et décourageantes en production avec les LLM : des suites d’évaluation impressionnantes en apparence, mais incapables de détecter les régressions importantes. Elles inspirent une confiance injustifiée ; l’équipe déploie des changements qui dégradent la qualité et ne découvre le problème qu’après les utilisateurs.
Créer des évaluations qui détectent vraiment les régressions est plus difficile qu’il n’y paraît. Les bases (jeu de données, sorties attendues, notation) sont faciles. C’est la fiabilité du signal qui exige du travail.
Cet article présente les enseignements tirés de la création d’évaluations fiables, à l’intention des équipes qui prennent au sérieux la qualité de l’IA en production.
Ce que font de bonnes évaluations
Lorsqu’elle est exécutée sur une version candidate, une bonne suite d’évaluation permet de répondre avec un niveau de confiance élevé à la question suivante : cette version est-elle meilleure, moins bonne ou équivalente à la version actuelle ?
Les contrastes :
- Détecte les régressions. Lorsque la qualité diminue sur des modèles réels, la note de l’évaluation diminue.
- Détecte les améliorations. Lorsque la qualité s’améliore, la note reflète cela (et non seulement sur des cas sélectionnés).
- Stable sur les non-changements. Lorsque rien n’a changé de manière significative, la note est cohérente.
- Fiable pour les décisions. Les décisions basées sur les notes des évaluations se corrélent avec les résultats réels des utilisateurs.
Chacun de ces points est plus difficile qu’il n’y paraît.
Le problème du jeu de données
La qualité d’une évaluation dépend de celle de son jeu de données. C’est à ce niveau que la plupart des suites échouent.
Échecs courants du jeu de données
Échec 1 : Cas sélectionnés de manière biaisée. Le jeu de données a été construit lorsque le système fonctionnait, souvent par l’ingénieur qui l’a construit. Ils ont choisi des cas qui “avaient du sens” — des exemples clairs de chaque comportement. Le trafic de production réel est plus complexe. Les cas difficiles, ambigus ou aux limites dominent les échecs mais sont sous-représentés dans le jeu de données.
Échec 2 : Jeu de données obsolète. Le jeu de données a été construit il y a six mois. Depuis, le comportement des utilisateurs a changé, de nouvelles zones de fonctionnalités ont été ouvertes, de nouvelles capacités du produit ont été déployées. Le jeu de données teste une version ancienne du monde.
Échec 3 : Aucune couverture des zones à risque de régression. L’évaluation couvre le “chemin de réussite” de manière approfondie mais ne sonde pas les limites où les régressions se produisent réellement.
Échec 4 : Contamination du jeu de données. Les exemples utilisés dans l’évaluation apparaissent également dans le prompt ou les données de fine-tuning. Le modèle “se souvient” d’eux. Les notes des tests sont gonflées ; la performance réelle est pire.
Échec 5 : Distribution déséquilibrée. 80 % du jeu de données est un type d’entrée ; 5 % est la longue traîne. Une régression dans la longue traîne n’entraîne presque pas de changement de note, même si c’est une régression réelle.
Construction d’un jeu de données solide
Voici quelques principes pour construire des jeux de données solides :
Extraire des données de trafic de production réel. Les meilleurs exemples sont des entrées réelles des utilisateurs (avec suppression des données personnelles). Ils contiennent la véritable complexité que votre système doit gérer.
Voici un flux de travail pratique :
- Capturer un échantillon des appels de production (avec des contrôles de confidentialité appropriés).
- Étiqueter manuellement les sorties attendues (ou étiqueter avec un LLM, puis vérifier par un humain).
- Ajouter le cas au jeu de données d’évaluation.
- Mettre à jour régulièrement le jeu de données (un cycle mensuel est un bon rythme).
Inclure des modes d’échec diversifiés. Inclure spécifiquement des cas qui ont précédemment échoué en production. Ces cas deviennent des tests de régression — si vous corrigez un bug, vous ajoutez le cas d’échec pour qu’il reste corrigé.
Stratifier le jeu de données. Catégoriser les cas (faciles/moyens/difficiles, par sujet, par type d’utilisateur, par longueur). Assurer une couverture significative de chaque catégorie. Suivre les notes par catégorie, pas seulement globalement.
Mélanger les difficultés. Quelques cas faciles (pour détecter les régressions catastrophiques). Quelques cas moyens (la majorité du trafic réel). Quelques cas difficiles (les cas limites). Un jeu de données composé uniquement de cas difficiles fluctue fortement avec de petites modifications ; un jeu de données composé uniquement de cas faciles ne bouge pas pour des régressions réelles.
Taille appropriée. Trop petit et vos statistiques sont bruitées. Trop grand et les exécutions deviennent lentes et coûteuses. Tailles typiques :
- Classification : 200 à 500 cas.
- Génération : 50 à 200 cas.
- Flux d’agents complexes : 20 à 50 cas.
Vous pouvez toujours commencer plus petit et augmenter.
Discipline de mise à jour. Planifier une revue mensuelle du jeu de données. Ajouter de nouveaux modes d’échec. Retirer les cas obsolètes. Mettre à jour les sorties attendues si le comportement souhaité a changé.
Le problème des métriques
Ce que vous mesure détermine ce sur quoi vous optimisez. Choisir de mauvaises métriques est la deuxième cause la plus courante d’échec des évaluations.
Échecs courants des métriques
Échec 1 : Résumés à un seul chiffre masquent les problèmes. Une précision globale de 90 % peut cacher que l’une des catégories importantes est passée de 95 % à 70 %, tandis que les autres ont amélioré. La moyenne semble bonne.
Solution : décompositions par catégorie. Toujours.
Échec 2 : la métrique mesure la mauvaise chose. Une métrique d’exactitude appliquée aux réponses de l’assistance peut ignorer qu’une réponse, bien que correcte, est impolie. Elle ne mesure pas le ton.
Solution : une notation multidimensionnelle qui mesure séparément l’exactitude, le ton, la longueur et le format.
Échec 3 : Insensibilité à la gravité. Une réponse erronée est traitée de la même manière qu’il s’agit d’une erreur mineure ou d’une hallucination dangereuse.
Solution : notation pondérée. Les erreurs graves comptent davantage. Certaines erreurs comptent comme 0 (violations de sécurité) ; d’autres comme -1 (échecs catastrophiques, pire que rien).
Échec 4 : sensibilité bimodale. Le score passe de 100 % à 99 %, variation imperceptible, ou de 100 % à 50 %, chute catastrophique. Les régressions subtiles restent invisibles.
Solution : notation graduelle. Chaque sortie notée sur une échelle continue (1-5 ou 0-1), pas binaire.
Échec 5 : Agrégation à travers les populations. La moyenne sur tous les utilisateurs masque que la performance sur un sous-groupe de 10 % a chuté.
Solution : décomposez les résultats par segments pertinents, tels que le niveau de l’utilisateur, le type de requête ou la langue.
Construction de métriques solides
Multidimensionnelles. Chaque résultat reçoit plusieurs notes : exactitude, ton, format, sécurité, longueur et tout autre critère pertinent.
Pondérées. Certaines dimensions comptent plus que d’autres. Pondérez-les dans toute métrique composite.
Calibrées en termes de gravité. À l’intérieur d’une dimension, distinguez les erreurs mineures des erreurs majeures. Une réponse fausse est pire qu’une réponse légèrement déviée.
Métriques par catégorie. Présentez les scores par segments pertinents : difficulté, sujet ou type d’utilisateur.
Tendance dans le temps. Un score isolé est peu utile ; une tendance l’est. Suivez les scores afin de détecter les dérives.
Alignées avec les utilisateurs. Les métriques doivent se corrélater avec ce que les utilisateurs tiennent vraiment à cœur. Si les utilisateurs se plaignent de l’impolitesse, mesurez l’impolitesse. Si les utilisateurs se plaignent de la longueur, mesurez la longueur.
Le problème des juges
Lorsque vous utilisez un LLM comme juge (un LLM note la sortie d’un autre LLM), le juge est votre évaluateur. Si le juge est biaisé ou incorrect, vos évaluations sont inutiles.
Échecs courants des juges
Échec 1 : Biais de longueur. Les juges LLM ont tendance à préférer les réponses plus longues. Ils noteront une réponse plus longue plus haut même si elle est enflée.
Échec 2 : Biais de format. Les juges préfèrent les sorties structurées (points, titres) par rapport au texte, indépendamment de ce qui est meilleur pour la tâche.
Échec 3 : préférence pour sa propre famille. Lorsqu’il appartient à la même famille que le modèle évalué, le juge tend à mieux noter les résultats de cette famille.
Échec 4 : complaisance. Les juges se conforment au cadrage fourni. Leur dire que « la version précédente était mauvaise » gonfle artificiellement les scores de la nouvelle version.
Échec 5 : Manque de fondement. Les juges notent sur l’impression plutôt que sur des critères spécifiques. Même prompt, des notes différentes lors de différentes exécutions.
Construction de juges solides
Calibrer contre les humains. Prendre un échantillon des notes du juge ; faire renoter par un humain. Là où ils ne s’accordent pas, affiner le prompt du juge ou accepter que les humains soient nécessaires pour cette dimension.
Utiliser des modèles juges différents. Lorsque possible, utiliser un juge d’une famille de modèles différente de celle du système évalué. Réduit la préférence pour soi-même.
Être explicite sur les critères. Le prompt du juge doit spécifier exactement à quoi ressemble le bon et le mauvais, avec des exemples. Des critères vagues produisent des notes vagues.
Éviter les cadres orientés. Ne dites pas au juge “notez sur une échelle où la plupart des sorties sont bonnes.” Ancrez-vous sur des comportements spécifiques.
Grilles assorties de repères. Définissez chaque niveau au moyen d’exemples : « 5 : exact, précis et bien structuré ; 4 : principalement exact, avec éventuellement un détail manquant ; 3 : … ». Ces repères rendent le juge cohérent.
Forcer une sortie structurée. Le juge produit des notes structurées (par dimension, avec des raisons), pas du texte libre. Plus facile à agréger et à auditer.
Un prompt de juge solide ressemble à :
You are evaluating an AI assistant's response.
User query: {query}
Assistant response: {response}
Score on the following dimensions, on a scale of 1-5:
1. Factual accuracy: Are all claims correct? (5 = all correct, 4 = mostly correct with minor issues, 3 = some incorrect, 2 = many incorrect, 1 = mostly wrong)
2. Relevance: Does the response address the user's actual question? (5 = perfectly addresses, 1 = doesn't address)
3. Completeness: Does the response contain enough information? (5 = complete, 1 = severely incomplete)
4. Tone: Is the response appropriately professional? (5 = perfect tone, 1 = inappropriate)
For each score, provide:
- The score
- A one-sentence specific reason
- The specific text in the response that supports your score
Output JSON: {"accuracy": {"score": N, "reason": "...", "evidence": "..."}, ...}
Exécutez ce juge sur un jeu d’étalonnage composé d’exemples notés par des humains. Ajustez-le jusqu’à obtenir un accord dans une marge acceptable.
Conception d’ensembles d’évaluations pour la production
Voici plusieurs dispositifs efficaces en production :
Ensemble 1 : L’ensemble de régression
Un ensemble défini de 200 à 500 cas que le système doit réussir avant tout déploiement. Il est constitué à partir de défaillances réelles, de cas limites et de résultats de référence, et évolue peu.
C’est votre suite « à ne jamais casser ». Chaque pull request l’exécute dans l’intégration continue, et toute régression bloque la fusion.
Ensemble 2 : le test de bon fonctionnement
Un petit sous-ensemble de 10 à 30 cas exécuté fréquemment. Il fournit un retour rapide pendant le développement et détecte immédiatement les régressions catastrophiques.
Intégration : contrôle préalable au commit ou test rapide avant l’évaluation principale.
Ensemble 3 : L’ensemble de découverte
Un ensemble plus vaste et diversifié, composé de centaines de cas issus du trafic réel de production. Exécuté moins souvent, par exemple chaque semaine, il détecte des comportements que les suites plus petites peuvent manquer.
Intégration : tâche planifiée. Résultats examinés lors des réunions de qualité hebdomadaires.
Ensemble 4 : L’ensemble en ligne
Un échantillon du trafic réel de production, noté automatiquement par un juge LLM ou à partir de signaux des utilisateurs. Il détecte les dérives ignorées par les évaluations hors ligne.
Intégration : continu, basé sur un tableau de bord.
Ensemble 5 : L’ensemble de flux utilisateur
Des tests de bout en bout qui exercent des parcours utilisateur complets, et pas seulement des appels LLM isolés. Ils conviennent aux systèmes agentiques et aux flux en plusieurs étapes.
Intégration : avant le déploiement de changements majeurs.
Un système de production mature a les cinq. Commencez par l’ensemble de régression ; ajoutez les autres à mesure que la capacité augmente.
Discipline coût et temps
Les évaluations coûtent de l’argent (appels LLM) et du temps (les exécuter, les examiner).
Une suite de 500 cas évaluée par un modèle de pointe peut coûter de 5 à 20 € par exécution. Dix pull requests quotidiennes représentent donc de 50 à 200 € par jour : une dépense gérable, mais réelle.
Stratégies :
Exécuter les tests rapides sur les pull requests et les suites complètes lors de la fusion. Vous évitez ainsi le coût des branches qui ne seront jamais fusionnées.
Mettre en cache les résultats. Si ni le prompt ni le modèle n’ont changé, vous n’avez pas besoin de les relancer. Mettez en cache par (version_prompt, modèle, version_dataset).
Utiliser des juges moins chers lorsque cela est possible. Un modèle économique correctement étalonné est souvent suffisant.
Paralléliser. Les exécutions d’évaluations sont parallélisables. Utilisez la concurrence.
Échantillonner plutôt qu’exécuter en totalité. Pour les vérifications routinières, échantillonnez 50 cas d’un ensemble de 500 cas. Exécution complète sur les changements importants.
Pour le temps, le budget est généralement “combien de temps un PR peut attendre ?” Visez une évaluation complète en moins de 15 minutes. Au-delà, les développeurs changent de contexte et perdent de la productivité.
Modèles opérationnels
Quelques pratiques qui distinguent les programmes d’évaluation matures :
Pratique 1 : déploiements soumis aux évaluations
Les changements qui affectent les LLM ne peuvent être déployés en production que si les évaluations réussissent. Si le score passe sous le seuil, le déploiement est bloqué et l’ingénieur enquête.
Le seuil est généralement relatif : “la note doit être à l’intérieur de 2 % de la valeur de base.” Permet le bruit mais détecte les régressions significatives.
Pratique 2 : enquêter sur les variations de score
Toute variation significative, à la hausse comme à la baisse, fait l’objet d’une enquête. Si le score augmente, déterminez s’il s’agit d’une amélioration réelle ou d’un test devenu plus facile. S’il diminue, localisez précisément la régression et vérifiez si elle se limite à un segment.
Ne célébrez pas une variation globale et ne paniquez pas : enquêtez.
Pratique 3 : entretien continu du jeu de données
Le jeu de données n’est pas créé une fois pour toutes. Il est entretenu en continu :
- L’utilisateur se plaint d’une réponse → ajouter au jeu de données comme test de régression.
- Nouvelle fonctionnalité déployée → ajouter des cas couvrant celle-ci.
- Le comportement du modèle surprend quelqu’un → si c’est un échec réel, l’ajouter.
- Cas obsolètes (non pertinents) : retirer.
Une réunion mensuelle fonctionne bien. Le jeu de données est traité comme un actif vivant.
Pratique 4 : revue fondée sur les différences
Lors de la revue d’un résultat d’évaluation, concentrez-vous sur les différences par rapport à la base :
- Les cas où la nouvelle version a obtenu une note plus élevée que la base (améliorations).
- Les cas où la nouvelle version a obtenu une note plus basse (régressions).
- Les cas où la note est restée la même (aucun signal).
La différence constitue le signal. Examiner 500 cas un par un est impraticable ; examiner 30 différences est réaliste.
Pratique 5 : revue humaine des désaccords du juge
Périodiquement (hebdomadairement ?), échantillonnez des cas où le juge a donné une note basse et une note haute. La revue humaine vérifie : êtes-vous d’accord avec le juge ?
Les désaccords révèlent :
- Les biais du juge (calibrez le prompt du juge).
- Les problèmes de qualité réels (réparez le système).
- Les problèmes de jeu de données (la sortie attendue du cas est incorrecte).
C’est ainsi que vous maintenez la qualité du juge au fil du temps.
Pratique 6 : revue trimestrielle des évaluations
Une rétrospective trimestrielle sur le programme d’évaluation lui-même :
- Quelles régressions réelles l’ensemble d’évaluation a-t-il détectées ce trimestre ?
- Quelles régressions réelles a-t-il manquées ?
- Quelles fausses alarmes a-t-il produites ?
- Quelles lacunes de couverture connaissons-nous ?
- Quelle est la couverture du jeu de données des comportements actuels de production ?
C’est une méta-évaluation : évaluer l’évaluation. Sans cela, le programme d’évaluation se dégrade.
Exemple concret : évaluation du service client
Pour rendre cela concret, voici une configuration d’évaluation de production pour un système de réponse du service client basé sur l’IA.
Objectif : assurer que les réponses de l’IA aux requêtes des clients sont exactes, utiles, conformes à la marque et sûres.
Jeux de données :
-
Ensemble de régression (300 cas) :
- 50 cas faciles (politiques claires, réponses simples).
- 100 cas moyens (complexité typique).
- 100 cas difficiles (ambigus, sensibles, composés de plusieurs volets).
- 50 cas d’échec connus (scénarios précédemment régressés).
-
Ensemble de découverte (1000 cas) : Échantillonné mensuellement à partir du trafic de production réel, avec suppression des données personnelles.
-
Ensemble antagoniste (50 cas) : prompts spécialement conçus pour tenter d’extraire des informations, d’obtenir des remboursements indus ou de manipuler l’IA.
Métriques :
Pour chaque cas, le juge note sur :
- Précision factuelle (1-5)
- Conformité aux politiques (1-5)
- Adéquation du ton (1-5)
- Complétude (1-5)
- Adéquation de la longueur (1-5)
- Sécurité (binaire : passe/échec)
Juges :
- Juge principal : Claude (un fournisseur différent du système testé, qui utilise GPT — choisir un fournisseur différent évite le biais de préférence pour le même modèle).
- Étalonné par rapport à un évaluateur humain sur 100 cas de référence.
- Recalibré trimestriellement.
Agrégation :
- Score moyen par critère et par segment — type de demande, niveau du client et langue.
- Taux de passage sur la sécurité (doit être à 100 %).
- Note pondérée par cas (utilisée pour les différences).
Opérations :
- Test rapide (30 cas) sur chaque pull request.
- Suite complète de régression (300 cas) lors de la fusion de la pull request.
- Ensemble de découverte (1000 cas) hebdomadairement.
- Ensemble antagoniste (50 cas) avant tout changement de prompt ou de modèle.
- Échantillonnage en ligne de 1 % du trafic de production, noté en temps réel.
Revues :
- Réunion mensuelle : revue des tendances des évaluations, nouveaux modes d’échec, mises à jour du jeu de données.
- Réunion trimestrielle : méta-évaluation, étalonnage du juge et audit du jeu de données.
Résultats (à partir de déploiements réels de systèmes similaires) :
- ~3 régressions détectées par mois qui auraient été déployées sans évaluations.
- ~1 fausse alarme par mois (l’évaluation signale une régression qui est en réalité correcte).
- Détection du décalage en jours plutôt qu’en semaines/mois.
- Confiance accrue dans le déploiement de changements de prompt et de modèle.
Voilà à quoi ressemblent des évaluations de production : non pas un projet réalisé en un week-end, mais un investissement continu au retour mesurable.
Pièges courants
Voici plusieurs pièges que nous observons régulièrement :
Piège 1 : Créer des évaluations après que le produit est sorti. “Nous ajouterons des évaluations plus tard.” Le “plus tard” ne vient jamais. Construisez-les dès le départ.
Piège 2 : responsabilité confiée à un seul ingénieur. Une seule personne construit et maintient l’évaluation ; lorsqu’elle part, celle-ci se dégrade. Répartissez la responsabilité.
Piège 3 : Traiter les évaluations comme statiques. Construites une fois, jamais mises à jour. Deviennent inutiles à mesure que le produit évolue. Traitez l’évaluation comme un actif vivant.
Piège 4 : Faire confiance aveuglément aux notes des évaluations. L’évaluation a dit qu’elle est meilleure, donc déployez-la. Sans vérification humaine, vous déployez des choses que l’évaluation a notées hautement mais que les utilisateurs détestent. Associez les évaluations à une revue humaine pour les changements importants.
Piège 5 : Optimiser pour l’évaluation. Ajuster les prompts spécifiquement pour obtenir de bonnes notes sur l’évaluation. L’évaluation s’améliore ; la réalité ne le fait pas. Soyez vigilant — si les améliorations de l’évaluation ne correspondent pas aux améliorations en production, vous optimisez pour le test.
Piège 6 : Ignorer le coût de l’infrastructure. Les évaluations à grande échelle sont coûteuses (les appels LLM s’accumulent). Sans suivi des coûts, vous découvrez cela à la fin du mois.
Piège 7 : Aucun critère clair de passage/échec. “La note est passée de 4,2 à 4,0 — est-ce une régression ?” Définissez les seuils à l’avance. Tenez-vous-y.
Piège 8 : la suite d’évaluation absorbe tout l’effort de test. Construire des évaluations élaborées tout en omettant les tests élémentaires de correction est une erreur. Les évaluations mesurent la dérive de qualité ; tous les tests ne sont pas des évaluations.
La partie culturelle
La partie la plus difficile des évaluations en production est culturelle. Les ingénieurs et les personnes du produit doivent :
- Faire suffisamment confiance aux évaluations pour les utiliser comme verrous de déploiement. Sans cela, les évaluations sont du théâtre.
- Ne pas leur faire une confiance telle que les variations ne seraient plus examinées. Une confiance aveugle conduit à optimiser pour le test.
- Investir dans la curation du jeu de données comme travail continu. Pas un projet unique.
- Accepter que les évaluations ne remplacent pas le jugement humain. Elles réduisent la surface à examiner par les humains.
- Reconnaître quand un ensemble d’évaluations ne fonctionne pas. Lorsque des régressions réelles passent à travers, l’ensemble d’évaluations est le problème, pas l’utilisateur qui se plaint.
Les équipes qui adoptent cette culture déploient plus rapidement et de manière plus fiable. Les autres finissent soit par accorder trop de poids à des évaluations défectueuses, soit par être paralysées par leur absence.
Le message clé
Créer des évaluations qui détectent vraiment les régressions est plus difficile qu’il n’y paraît mais réalisable.
Les clés :
- Des jeux de données réels et diversifiés issus de la réalité de production.
- Des métriques multidimensionnelles, sensibles aux différents segments et alignées sur l’expérience utilisateur.
- Des juges calibrés que vous avez effectivement vérifiés contre le jugement humain.
- Plusieurs suites répondant à des besoins distincts : régression, contrôle rapide, découverte, évaluation en ligne et bout en bout.
- Une discipline opérationnelle : déploiements soumis aux évaluations, entretien continu du jeu de données et enquête sur les variations.
- Engagement culturel à utiliser et améliorer les évaluations au fil du temps.
Bien conçues, les évaluations deviennent l’élément le plus précieux de votre infrastructure d’IA. Elles permettent de déployer rapidement tout en maintenant la qualité. Sans elles, vous avancez à l’aveugle.
Construisez les évaluations. Faites confiance aux évaluations. Améliorez les évaluations. C’est ainsi que la qualité de l’IA en production est maintenue.
