Evals LLM

Mesurer au lieu de goûter

Une eval rejoue un ensemble de cas connus à travers un système à base de LLM (prompt, agent, chaîne d'outils) et note chaque sortie contre un critère écrit. Anthropic demande des critères spécifiques, mesurables, atteignables et pertinents, et des jeux qui « reflètent la distribution réelle de vos tâches ». OpenAI nomme l'anti-modèle : les « vibe-based evals », où l'on juge à l'œil une poignée de sorties, et recommande d'évaluer « tôt et souvent ».

Une sortie de LLM varie d'une exécution à l'autre, et un changement de prompt, de modèle ou d'outil déplace la qualité sans message d'erreur ; sans eval, la régression se découvre chez l'utilisateur. Anthropic tranche le dilemme volume contre finesse : « plus de questions avec une notation automatique au signal un peu plus faible vaut mieux que moins de questions notées à la main avec soin ».

Trois façons de noter, trois niveaux

Anthropic distingue la notation par code (rapide, fiable, peu nuancée : correspondance exacte, assertion, test), la notation humaine (la plus fine, lente et chère, à réserver) et la notation par LLM (rapide, souple, à valider avant de généraliser). Hamel Husain, dans « Your AI Product Needs Evals » (29 mars 2024), ordonne la pratique en trois niveaux de coût croissant : les tests unitaires à base d'assertions, l'évaluation par modèle et par humain, puis les tests A/B. Sa règle d'hygiène : « retirer toute friction du processus de regarder les données », et suivre la corrélation entre les notes du modèle et celles des humains.

Le LLM-juge et ses biais

Faire noter une réponse ouverte par un modèle s'appelle LLM-as-a-judge. Zheng et al. (« Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena », NeurIPS 2023) ont mesuré qu'un juge GPT-4 atteint plus de 80 % d'accord avec les préférences humaines, le niveau d'accord entre humains eux-mêmes. Le même article décrit les biais à corriger : la position (la première réponse présentée est favorisée), la verbosité (la réponse longue est favorisée) et l'auto-complaisance (le juge préfère ce qu'il aurait écrit).

D'où deux règles reprises par Anthropic, OpenAI et OpenRouter : le juge est un modèle distinct de celui qu'il évalue, et ses notes se valident sur un échantillon étiqueté par des humains avant qu'on lui fasse confiance.

Un golden dataset tiré du trafic, une porte de CI

Le jeu de référence, ou golden dataset, se construit à partir de la production, pas de l'imagination. Les tutoriels d'OpenRouter (30 septembre et 1er octobre 2026) en donnent la recette : échantillonner au hasard une à deux semaines de journaux ; une dizaine d'items pour explorer un problème, 20 à 50 pour démarrer, 100 à 1 000 pour un jeu de régression qui couvre la distribution de production, parce que « la couverture des modes d'échec compte plus que le volume » ; des critères binaires, atteint ou non atteint ; deux annotateurs indépendants sur un sous-ensemble ; une relecture trimestrielle des items de plus de six mois.

Ce jeu devient ensuite une porte dans l'intégration continue : il vit dans le dépôt des prompts, le seuil de réussite se mesure sur des exécutions répétées d'une branche inchangée, le vote majoritaire remplace la température et la graine sur les modèles qui ne les supportent pas, et le contrôle est marqué requis, sans quoi la PR fusionne. Pour un changement de modèle, les cas sont verrouillés, seul le modèle varie, un invariant dur qui casse uniquement sur le candidat bloque la release, et les alias « -latest » sont proscrits parce qu'ils changent de modèle sans commit.

L'outillage au 12 octobre 2026

Ori Eval, publié par OpenRouter le 3 août 2026, écrit les evals en fichiers *.eval.ts lancés avec bun test, avec des assertions sur les appels d'outils et un LLM-juge pour les réponses ouvertes ; l'éditeur annonce « une eval coûte généralement 10 à 30 $ » et une intégration GitHub Actions. En sens inverse, OpenAI déprécie sa plateforme Evals : passage en lecture seule le 31 octobre 2026, fermeture le 30 novembre 2026, et orientation des utilisateurs vers son produit « Datasets ».