Aller plus loin

Commencez par lire des traces

Des métriques choisies à l’avance mesurent ce que vous avez imaginé. L’analyse d’erreurs part du réel : lisez 50 à 100 traces réelles, notez la première chose qui a mal tourné dans chacune, puis regroupez ces notes en catégories et comptez. La plus grosse catégorie dit quoi corriger, et quelle évaluation mérite d’être écrite. Hamel Husain et Shreya Shankar enseignent cette approche, et c’est par là que la plupart des équipes devraient commencer.

Réussi ou raté vaut mieux qu’une note sur 5

Une note de 1 à 5 ouvre un débat sur l’écart entre un 3 et un 4. Un jugement binaire oblige à dire ce qu’est un résultat correct. Ajoutez une phrase qui explique pourquoi. Ces phrases deviendront les exemples d’un juge LLM.

Un juge LLM est un modèle à valider

Traitez le juge comme un classifieur. Annotez des exemples à la main, gardez-en de côté, et mesurez deux taux : le taux de vrais positifs (il accepte ce qui est bon) et le taux de vrais négatifs (il rejette ce qui est mauvais). L’accord brut cache un juge paresseux. Sur un échantillon bon à 90 %, dire toujours « réussi » donne 90 % d’accord et n’attrape aucun échec.

Combien de cas ?

Un taux de réussite demande un intervalle. L’intervalle de Wilson (1927) se comporte bien sur les petits échantillons : 14 réussites sur 15 se lisent 93 %, avec un intervalle à 95 % d’environ 70 % à 99 %. Passer de 12/15 à 13/15 ne prouve donc rien. Les agents varient aussi d’une exécution à l’autre : répétez chaque cas et signalez à part les cas instables.

Contrôlez le chemin, pas seulement la réponse

Un agent peut donner la bonne réponse après avoir fait quelque chose d’interdit. Les assertions de trajectoire contrôlent ce qu’il a fait :

const calls = trace.toolCalls.map((c) => c.name);
ok(calls.includes('search_policy'), 'policy checked');
ok(calls.indexOf('search_policy') < calls.indexOf('refund'), 'checked before paying');
eq(calls.filter((n) => n === 'refund').length, 1, 'paid once');

Préférez les contrôles sur ce qui doit être vrai, comme « vérifié avant de payer », à une séquence exacte d’outils. Une séquence stricte échoue chaque fois que l’agent trouve un autre chemin valable.

L’évaluation comme barrière

Ajoutez un cas pour chaque panne en production : un bug ne pourra plus revenir en silence. Lancez un sous-ensemble rapide à chaque modification, et l’ensemble complet avant chaque livraison. Bloquez la livraison quand un cas critique échoue, et suivez le score global comme une tendance. Gardez un jeu de test sur lequel vous n’ajustez rien : un jeu optimisé ne mesure plus rien.