22 juillet 2026
Évaluer un LLM en production : construire une suite d'évals qui compte
Construire des evals LLM utiles en production : succès métier, groundedness, latence, coût, golden dataset, juges LLM et CI.
Les benchmarks publics mesurent autre chose que la production
Quand je déploie un LLM chez un client, je regarde les benchmarks publics avec intérêt, puis je les range assez vite. Ils donnent une indication sur les capacités générales d'un modèle : raisonnement, code, mathématiques, suivi d'instructions. C'est utile pour choisir une famille de modèles. Mais la production pose une question plus précise : est-ce que ce système, avec ce prompt, ces outils, ces données et cette interface, réussit la tâche réelle pour cet utilisateur ?
La plupart des échecs que je vois arrivent dans cet écart. Le modèle est bon sur un classement public, mais l'agent appelle le mauvais outil. Le RAG récupère un document proche, mais pas la source contractuelle. La réponse semble fluide, mais oublie une contrainte métier. La latence est acceptable en démo et pénible dans le workflow quotidien. Une suite d'évals utile commence donc par une idée simple : l'objet mesuré est le système complet, de la donnée à l'interface.
Les quatre métriques que je veux suivre ensemble
Je commence presque toujours par quatre familles de métriques. La première est le succès de tâche : l'utilisateur obtient-il le résultat attendu, dans le bon format, avec les bonnes actions réalisées ? Pour un assistant support, cela peut être identifier la bonne procédure et proposer une réponse prête à envoyer. Pour un agent interne, cela peut être créer le bon ticket, remplir les champs attendus et demander validation au bon moment.
La deuxième est la groundedness : la réponse s'appuie-t-elle réellement sur les sources disponibles ? La troisième est la performance : latence p50, p95, temps par étape, timeouts, retries. La quatrième est le coût : tokens, appels outils, reranking, juges, cache hit rate. Ces dimensions doivent être lues ensemble. Une réponse très grounded mais trop lente peut rater le produit. Une réponse rapide et économique qui dégrade le succès métier coûte plus cher qu'elle ne le montre dans la facture API.
Construire un golden dataset qui ressemble au terrain
Le cœur de la suite d'évals est un golden dataset. Je préfère le construire à partir de traces réelles : questions utilisateurs, conversations support, tickets, exemples de décisions, corrections humaines, cas refusés. Ensuite je nettoie, anonymise si besoin, et transforme chaque exemple en contrat de test. Le dataset doit contenir la demande, le contexte autorisé, les sources attendues, les critères de réussite, et parfois une réponse de référence. Il doit aussi contenir des cas ennuyeux : demandes ambiguës, documents contradictoires, données obsolètes, permissions différentes, et questions où le bon comportement est de demander une précision.
Un bon golden dataset reste petit au début. Cinquante à cent exemples bien choisis valent mieux qu'un millier de lignes que personne ne comprend. Je les classe par familles de risques : récupération, extraction, synthèse, action outil, conformité, ton, coût, latence. À chaque incident en production, j'ajoute un exemple minimal qui aurait dû l'attraper. Le dataset devient alors une mémoire opérationnelle du produit, pas une archive de QA oubliée.
Utiliser un LLM juge sans lui confier toute la qualité
Les juges LLM sont très pratiques parce qu'ils permettent d'évaluer des critères difficiles à coder : réponse complète, citation pertinente, respect d'une consigne métier, résumé fidèle. Je les utilise, mais jamais comme oracle unique. Un juge LLM hérite de biais, varie selon le prompt, favorise parfois les réponses longues, et peut confondre style convaincant et vérité. Il faut le traiter comme un outil de mesure imparfait, calibré sur des exemples humains.
Ma méthode est pragmatique. Je code d'abord les assertions déterministes : JSON valide, champs présents, source obligatoire, refus attendu, seuil de latence, budget token, appel outil correct. Ensuite j'ajoute des juges LLM pour les dimensions sémantiques, avec une grille simple et des exemples annotés. Je garde un échantillon relu par des humains pour mesurer l'accord entre juge et expert. Quand l'accord baisse, je corrige le prompt du juge ou je réduis son périmètre. Le juge aide à scaler l'évaluation, pendant que l'équipe garde la responsabilité de définir la qualité.
Faire tourner les evals comme des tests de régression
Une suite d'évals qui reste dans un notebook finit rarement par protéger la production. Je veux qu'elle tourne dans le cycle de développement : en local sur un sous-ensemble rapide, en CI sur les cas critiques, puis en tâche planifiée sur un set plus large. Chaque changement important doit produire un diff lisible : taux de succès, groundedness, latence, coût, exemples améliorés, exemples dégradés. Le but n'est pas d'obtenir une note parfaite, mais de rendre chaque tradeoff explicite avant le déploiement.
J'aime aussi versionner tout ce qui influence le résultat : modèle, prompt système, prompt outil, index, stratégie de chunking, paramètres de récupération, schéma de sortie, et code d'orchestration. Quand un score bouge, on doit pouvoir expliquer ce qui a changé. En CI, je bloque seulement les régressions critiques : baisse forte sur les tâches cœur, hausse de coût excessive, groundedness sous seuil, ou violation d'un comportement de sécurité produit. Pour le reste, je laisse un rapport qui aide l'équipe à décider.
Une régression silencieuse que les evals ont attrapée
Un exemple concret : sur un assistant interne, nous avons remplacé un modèle par une version plus rapide et moins chère. Les tests manuels semblaient bons. Les réponses étaient plus courtes, plus nettes, et la latence avait baissé. La suite d'évals a pourtant signalé une chute sur les questions avec politiques récentes. Le problème venait d'un détail : le nouveau modèle suivait mieux la consigne de concision, mais citait souvent la première source récupérée au lieu de réconcilier deux documents quand une politique venait d'être mise à jour.
Sans evals, cette régression aurait probablement vécu plusieurs semaines. Elle ne cassait pas l'interface, ne produisait pas d'erreur serveur, et donnait des réponses plausibles. Le correctif a été simple : ajuster le prompt de synthèse pour imposer la comparaison des dates, modifier le reranking pour favoriser les versions actives, et ajouter dix cas de politiques contradictoires au golden dataset. Le coût par réponse a légèrement augmenté, mais le taux de réponses fondées sur la bonne version est remonté. C'est exactement le genre de tradeoff que je veux voir avant que les utilisateurs le découvrent.
La suite d'évals qui compte vraiment
Une bonne suite d'évals agit comme un système de pilotage plutôt que comme un tableau de scores décoratif. Elle relie des exemples réels à des critères mesurables, sépare les dimensions de qualité, expose les coûts, et transforme les incidents en tests de régression. Elle permet aussi de parler clairement avec les métiers : voici ce que le système sait faire, voici ce qui s'améliore, voici ce qui coûte plus cher, voici les cas où une validation humaine garde de la valeur.
Mon conseil est de commencer petit et de rendre la boucle obligatoire. Prenez les vingt tâches qui comptent le plus, écrivez les critères de succès, ajoutez les sources attendues, mesurez latence et coût, puis rejouez ce set à chaque changement. À partir de là, la suite grandit avec le produit. Les meilleurs systèmes LLM que j'ai vus sont ceux dont l'équipe sait mesurer, expliquer et améliorer la qualité semaine après semaine.