J'ai un jour déployé un changement de prompt qui a rendu mon agent de support 4 % meilleur sur la métrique que je surveillais et 30 % moins efficace pour fermer réellement les tickets. L'eval était au vert. Les utilisateurs étaient furieux. C'est là que j'ai compris que la plupart des evals d'agents mesurent la mauvaise chose — ils mesurent si la sortie semble correcte, pas si l'agent a fait ce qu'il fallait.
Si vous construisez des agents et que vos evals sont une poignée de vérifications « la réponse a-t-elle l'air bien » notées par un autre modèle, vous n'avez pas d'evals. Vous avez des impressions avec un chiffre collé dessus. Voici comment j'écris des evals pour des agents IA qui détectent vraiment les régressions.
Asserter sur le comportement, pas sur la prose
L'amélioration la plus importante : arrêtez de noter le texte final et commencez à noter ce que l'agent a fait. A-t-il appelé les bons outils, dans un ordre raisonnable, avec les bons arguments ? A-t-il modifié les fichiers qu'il était censé modifier et laissé les autres intacts ? Ce sont des faits vérifiables, pas des opinions.
Pour un agent de code, mon eval ne lit pas le résumé. Il vérifie : la suite de tests passe-t-elle après l'exécution, l'agent a-t-il touché uniquement les fichiers dans le périmètre, a-t-il évité de modifier le lockfile ? Trois assertions booléennes. Aucun juge LLM nulle part. Elles ne flanchent jamais et capturent les défaillances qui comptent.
assert run_tests() == 0, "tests fail after agent run"
assert touched_files <= allowed_files, f"out of scope: {touched_files - allowed_files}"
assert "package-lock.json" not in touched_files
La dernière vient d'un incident réel. Un agent continuait à régénérer « utilement » le lockfile et à casser le CI. Une assertion, et ça ne s'est plus jamais produit.
Tester la trajectoire, pas seulement le point final
Les agents échouent au milieu. La réponse finale peut être correcte par chance après un chemin catastrophique — six recherches redondantes, un appel d'outil avec des arguments inutilisables qui a eu la chance d'échouer gracieusement, un mauvais virage dont il s'est remis. Si vous ne vérifiez que le point final, vous êtes aveugle à une trajectoire qui est à un petit changement de l'échec total.
Je log donc chaque événement et j'asserte sur le chemin. A-t-il appelé la recherche avant de répondre à une question qui nécessitait des informations fraîches ? A-t-il effectué plus de deux appels d'outils redondants ? A-t-il jamais déclenché is_error: true sur un résultat d'outil ? Vous pouvez noter une trajectoire sans juge — la plupart du temps, c'est du comptage et de la correspondance de motifs sur le flux d'événements.
Le comportement du modèle a changé récemment, soit dit en passant. Les nouveaux modèles Opus ont recours aux outils de manière plus conservatrice. Une assertion « chercher d'abord » qui passait sur un modèle plus ancien peut commencer à échouer non pas parce que l'agent a empiré, mais parce qu'il répond maintenant depuis le contexte quand il ne devrait pas. C'est exactement le type de régression qu'un eval de trajectoire détecte et qu'un eval de sortie rate.
Quand vous avez besoin d'un juge LLM, épinglez-le
Certaines choses nécessitent genuinement du jugement — le ton était-il bon, le résumé a-t-il capté le point clé, l'explication était-elle vraiment correcte ? Très bien. Utilisez un juge LLM. Mais traitez le juge comme du code de production, parce que c'en est.
Trois règles que je ne romps jamais. Un : épinglez le modèle de juge et sa version. Si votre juge se met à jour silencieusement, vos scores changent et vous poursuivrez une régression qui n'est en réalité qu'un changement de juge. Deux : donnez au juge un rubric concret, pas « notez ceci de 1 à 10. » « La réponse cite-t-elle un fichier et un numéro de ligne spécifiques ? oui/non » surpasse un score d'impression à chaque fois. Trois : vérifiez le juge par rapport à des étiquettes humaines sur un échantillon. Un juge que vous n'avez jamais audité est un générateur de nombres aléatoires avec de bonnes relations publiques.
Voici un piège spécifique aux modèles actuels. Si vous dites au juge « ne signalez que les problèmes de haute gravité » ou « soyez conservateur », les nouveaux modèles suivent cela à la lettre — ils trouvent les bugs, puis refusent de signaler ceux qui sont en dessous de votre seuil. Votre rappel mesuré chute et il semble que l'agent ait régressé alors qu'en réalité le juge est simplement devenu plus obéissant. Dites au juge de tout signaler avec une confiance et une gravité, et filtrez en aval. Déplacez le filtrage hors de l'étape de jugement.
Construire l'ensemble d'evals à partir de vos échecs
Ne vous asseyez pas pour faire un brainstorming de cas de test. Vous écrirez ceux que vous gérez déjà. Au lieu de cela, chaque fois qu'un agent merde en production, ce scénario exact devient un cas d'eval. L'incident du lockfile, la boucle d'aller-retour, la fois où il a répondu depuis un contexte périmé — chacun est maintenant un test de régression permanent.
C'est la partie que les gens sautent parce qu'elle n'est pas glamour. Mais un ensemble d'evals issu d'incidents réels vaut dix brainstormés. Il est structurant d'une manière que les cas synthétiques ne le sont jamais, parce que chaque cas est un bug qui vous a vraiment mordu.
Exécutez-les à chaque changement de prompt
Tout l'intérêt, c'est la boucle. Vous changez un prompt, vous exécutez les evals, vous voyez les assertions de trajectoire avant de déployer. Mon désastre avec l'agent de support s'est produit parce que j'ai jeté un œil à quelques sorties et déployé sur une intuition. Si j'avais eu des evals de trajectoire — « a-t-il vraiment résolu le problème ou a-t-il juste semblé le résoudre » — la baisse de 30 % aurait été rouge avant de toucher un seul utilisateur.
Les evals ne sont pas une porte de qualité que vous boulonnez à la fin. Ils sont la seule chose qui sépare « je pense que ce prompt est meilleur » et « ce prompt est meilleur. » L'un de ces deux, c'est de l'ingénierie. L'autre est une supposition qui porte une blouse de laboratoire.
Faites-les grandir à partir de vos cicatrices. Assertez sur ce que l'agent a fait. Épinglez votre juge. Et ne déployez plus jamais un changement de prompt sur la base d'impressions.