Créer un eval minimum viable

La démonstration de cette vidéo a été enregistrée en août 2026. Elle a été exécutée sur Claude Haiku 4.5, Claude Sonnet 5 et Claude Opus 5. Les résultats différeront sur des modèles plus récents. La démonstration de chaque leçon est une exécution d'eval distincte, donc ses scores et ses coûts ne correspondront pas à ceux des autres leçons.

Un eval est un test que les modèles passent. Il comporte trois parties : des entrées réalistes, la réponse que vous attendez pour chacune, et un moyen d'évaluer ce que chaque modèle renvoie. Chaque modèle exécute votre requête sur chaque entrée. Une entrée associée à sa réponse attendue constitue un cas, et l'évaluation de chaque cas vous donne un score.

La requête d'extraction de Meridian tire trois champs de chaque rapport de projet mensuel : l'ID du projet et le statut du calendrier, qui sont des valeurs courtes, et le risque principal, qui est une phrase.

Créer un eval, c'est comme faire passer un examen, avec vous dans le rôle de l'enseignant et les modèles dans celui des élèves.

Un juge LLM est un second modèle qui vérifie une réponse et décide si elle est correcte. Tout ce qui évalue une réponse est appelé un évaluateur (grader), qu'il s'agisse de code, d'un modèle ou d'une personne. Vous allez construire l'eval de Meridian en six étapes :

1. Choisir un évaluateur pour chaque champ
2. Concevoir l'ensemble des cas
3. Consigner les réponses attendues
4. Configurer le juge LLM pour le risque principal
5. Exécuter les modèles et évaluer leurs réponses
6. Noter manuellement un échantillon avant de faire confiance au juge

Choisir un évaluateur pour chaque champ

Il existe trois façons d'évaluer une réponse. La règle consiste à choisir la méthode la plus rapide qui soit également fiable et évolutive.

1. Évaluation par code. Votre code vérifie qu'une réponse correspond exactement à sa réponse attendue, ou qu'elle contient une expression clé. C'est la méthode la plus rapide et la plus fiable, et elle s'adapte à n'importe quel nombre de cas.
2. Juge LLM. Le juge convient aux réponses où deux phrases différentes peuvent toutes deux être correctes. Il est lui aussi rapide, flexible et évolutif.
3. Évaluation humaine. Une personne lit chaque réponse, ce qui donne la meilleure qualité mais est lent et coûteux, d'où sa place en dernier. Les personnes restent les évaluateurs appropriés pour les tâches spécialisées à fort enjeu et pour les réponses qui relèvent du jugement.

Utilisez le code pour chaque champ qu'il peut vérifier exactement, et ne confiez au juge que ce qui reste. Voici comment cela se traduit pour les trois champs de Meridian sur l'un de ses cas, le rapport r032.

Cependant, lorsqu'un rapport ne mentionne aucun risque, la réponse top_risk attendue est null, la valeur vide de JSON. Le code peut le vérifier avec une correspondance exacte.

Concevoir l'ensemble des cas

Quatre règles façonnent l'ensemble des cas. Elles s'appuient sur les principes de conception des evals de la documentation.

1. Rendez les cas spécifiques à la tâche. Construisez-les à partir de vos propres rapports réels, car des données d'exemple ne montrent que comment un modèle se comporte sur des exemples.
2. Automatisez l'évaluation. Vous exécuterez l'ensemble encore et encore, donc l'évaluation courante doit fonctionner sans intervention humaine.
3. Privilégiez le volume à la finition. À effort égal, de nombreux cas évalués automatiquement vous en apprennent plus que quelques-uns évalués soigneusement à la main.
4. Stratifiez vos cas limites. Un cas limite est une entrée inhabituelle que la production continue d'envoyer, comme un rapport scanné. Donnez à chaque type environ la part de cas qu'il représente en production, donc si les rapports scannés représentent 5 % de ce qui arrive, faites en sorte qu'ils représentent environ 5 % de l'ensemble.

Par-dessus tout, la composition des cas doit ressembler à ce que la production vous envoie. Les équipes assimilent souvent le volume à des centaines de cas, mais un ensemble de 20 à 50 cas simples constitue un excellent point de départ.

Meridian a opté pour 50 cas. Trente sont des rapports typiques, 10 couvrent plusieurs projets, et 10 sont des cas sans risque, c'est-à-dire des rapports sans section de risque. Les deux types inhabituels parviennent à Meridian assez souvent pour que l'entreprise souhaite les couvrir.

Consigner les réponses attendues

Les cas dont les réponses attendues ont été consignées par une personne forment un ensemble étiqueté. Rédigez vous-même chaque réponse attendue, à partir du rapport, avant qu'un modèle ne s'exécute. L'évaluateur par code compare les réponses des modèles à celles-ci.

Meridian conserve son ensemble étiqueté dans un seul fichier, golden.json, avec un enregistrement pour chaque cas. Un enregistrement contient l'id du cas, sa category, et la réponse attendue pour chaque champ. La category est typical, multi_project, ou missing_risk.

Configurer le juge LLM pour le risque principal

Le champ top_risk contient une phrase. Le code ne peut pas déterminer si deux phrases différentes désignent le même risque, donc ce champ est confié au juge. C'est la question de rédaction, et comme l'assistant pédagogique, le juge a besoin d'un guide de notation.

Ce guide est une grille d'évaluation, un ensemble écrit de règles définissant ce qui compte comme correct et ce qui compte comme incorrect. Elle doit être détaillée et claire.

La requête du juge contient le rapport, la réponse et la grille d'évaluation. Chacun figure dans ses propres balises XML, afin que le juge soit moins susceptible de les mélanger. Votre réponse attendue ne figure pas dans la requête, car le juge décide à partir du rapport lui-même. Ainsi, une réponse ne perd pas de points simplement parce qu'elle formule le risque différemment de vous. Conservez tout de même votre réponse attendue, car c'est votre référence pour la bonne réponse lorsque vous notez un échantillon à la main.

La décision du juge sur une réponse s'appelle son verdict. Un verdict n'est utile que s'il revient sous une forme que votre code peut compter. Les rendus structurés vous offrent cela. Vous envoyez un schéma JSON avec la requête, et la réponse doit s'y conformer. Un schéma JSON décrit quels champs le JSON peut contenir et ce que chacun peut contenir.

Le schéma de Meridian comporte deux champs, explanation et verdict. Le verdict doit être correct, incorrect, ou unknown. L'explication est un bref compte rendu des raisons de la décision du juge, donc c'est ce que vous lisez lorsque vous voulez savoir ce qui n'a pas fonctionné avec une réponse.

La valeur la plus importante est unknown. Elle offre au juge une porte de sortie, une option pour dire qu'il ne peut pas déterminer la réponse. Sans elle, le juge doit deviner entre les deux autres chaque fois qu'il n'est pas certain.

Exécuter les modèles et évaluer leurs réponses

Avant de pouvoir évaluer quoi que ce soit, vous avez besoin de réponses. Exécutez votre requête sur chaque cas avec chaque modèle que vous testez, et enregistrez chaque réponse dans un fichier. Meridian a exécuté sa requête d'extraction sur les 50 cas avec Claude Haiku 4.5, Claude Sonnet 5 et Claude Opus 5.

Testez le juge une fois, sur des cas que le code peut également évaluer, pour voir si les deux évaluateurs sont d'accord. La première exécution du juge de Meridian n'a porté que sur les 10 cas sans risque, soit 30 réponses réparties sur les trois modèles. Leur réponse attendue est null, donc le code pouvait aussi les évaluer. Enregistrez chaque verdict à côté de sa réponse, afin de pouvoir vérifier le juge à la main plus tard.

La première exécution du juge, sur les 10 cas sans risque, où le code pouvait également évaluer.

Pour les rapports sans section de risque, Meridian dispose désormais d'un chiffre pour chaque modèle, là où elle n'avait auparavant que des opinions.

Les cinq réponses incorrectes de Haiku 4.5 relèvent toutes du même type d'erreur, et le cas r045 en illustre une.

L'explication du juge nomme le type d'erreur commise par la réponse. Cette erreur provient de la requête d'extraction, qui ne précise jamais quoi faire lorsqu'un rapport ne mentionne aucun risque.

Noter manuellement un échantillon avant de faire confiance au juge

Le juge était d'accord avec le code sur les 30 réponses, mais le code pouvait de toute façon les vérifier. La véritable tâche du juge est d'évaluer du texte libre, là où le code ne peut pas aider. Avant de lui confier cette tâche, vérifiez qu'il est fiable. Deux pratiques y aident.

1. Évaluez vous-même un échantillon. Évaluez à la main une poignée de réponses enregistrées et comparez vos notes aux verdicts du juge, car un juge doit être en accord étroit avec des experts humains. Lorsque vous et le juge êtes en désaccord, clarifiez la grille d'évaluation et relancez-la.
2. Utilisez un juge qui n'a pas rédigé les réponses. Il est généralement préférable d'évaluer avec un modèle différent de celui qui a produit la sortie.

L'essentiel à retenir

1. Évaluez avec le code lorsqu'une vérification exacte fonctionne, avec un juge lorsque deux phrases différentes peuvent toutes deux être correctes, et avec des personnes lorsque cela relève du jugement.
2. Consignez les réponses attendues avant qu'un modèle ne s'exécute, et construisez un ensemble de cas qui ressemble à la production.
3. Donnez au juge une grille d'évaluation, un schéma auquel son verdict doit correspondre, et la possibilité de dire unknown.
4. Évaluez à la main un échantillon du travail du juge avant de lui faire confiance.