Évaluation des systèmes agentiques : La méthode des quatre axes

Début 2026, je menais une preuve de valeur en gestion de patrimoine pour une grande banque nord-américaine. L’agent en question n’était pas un chatbot. Il opérait au sein d’un workflow gouverné : il recevait un dossier, appelait des outils (récupération de documents, vérifications de filtrage, recherches de comptes), et produisait un résultat structuré que les étapes de processus en aval consommaient sans intervention humaine préalable. Vers la fin d’une session de travail, quelqu’un côté client a posé la question que toute entreprise finit par poser : « Pourquoi ce modèle ? Et combien cela nous coûtera-t-il par dossier ? »

Je n’avais pas de réponse défendable, et le marché non plus. Tout ce qui était publié sur la qualité des modèles à l’époque était conçu pour l’ère des chatbots : scores MMLU, classements d’arène, et “bake-offs” basés sur des impressions où quelqu’un collait le même prompt dans trois modèles et choisissait son préféré. Rien de tout cela n’indique si cet agent, avec ces outils, au sein de ce processus, sur ces dossiers, produit des champs corrects à un prix prévisible. Un Elo de classement ne peut pas vous dire si le modèle ignorera silencieusement une vérification de sanctions lorsque le dossier semble routinier.

J’ai donc construit un banc d’évaluation pour cela. À l’époque, les « évaluations d’agents » n’étaient pas une catégorie demandée ; il n’existait aucun outil prêt à l’emploi pour évaluer un agent intégré à un processus, j’ai donc dû décider de zéro ce qui valait la peine d’être mesuré. J’ai retenu quatre axes : le coût, la qualité, la fiabilité des outils et la sensibilité à la température. Depuis, ces quatre mêmes axes ont été appliqués à de nombreux engagements en entreprise, et la question à laquelle je n’avais pas pu répondre dans cette pièce revient maintenant à presque chaque première réunion. Le marché a rattrapé la question. Ce guide est la méthode.

Pourquoi les évaluations de benchmark répondent à la mauvaise question

Un agent intégré à un processus diffère d’un chatbot de quatre manières qui invalident toutes les techniques d’évaluation de l’ère des chatbots.

Il est multi-tour par construction. Une instance de processus est une boucle : le modèle planifie, appelle un outil, reçoit le résultat, planifie à nouveau. Un seul dossier peut impliquer deux appels de modèle ou quatorze. Toute métrique calculée sur « un prompt, une complétion » mesure une chose qui n’arrive jamais en production.

Il appelle des outils, et les appels d’outils sont le travail. La réponse finale est souvent la partie la moins intéressante de la transcription. Le fait que l’agent ait appelé la recherche de bénéficiaires effectifs avant de rendre un verdict importe plus que la formulation du verdict. Une évaluation qui n’inspecte que le texte final est aveugle à la majorité des modes de défaillance.

Son output est structuré et consommé par des machines. L’agent émet du JSON que les étapes en aval utilisent pour le routage. Il n’y a pas d’humain dans la boucle pour remarquer qu’un champ est subtilement erroné. « Ça semble correct » n’est pas une note ; soit risk_rating correspond à l’étiquette de référence, soit non.

Son coût est une propriété de la boucle entière, pas de la liste de prix des tokens. Chaque aller-retour d’outil renvoie le contexte de conversation croissant. Les tentatives de réessai sur un output malformé sont aussi des appels de modèle. Deux modèles avec des prix par token similaires peuvent différer de multiples en coût mesuré par dossier, car l’un d’eux prend plus d’itérations pour terminer.

Dimension	Évaluations de benchmark (ère chatbot)	Évaluations de processus (ère agent)
Unité de mesure	Un prompt, une complétion	Une instance de processus, de bout en bout
Forme d’interaction	Q&A à tour unique	Boucle multi-tour avec appels d’outils
Output évalué	Texte libre, préférence humaine	Champs structurés, notés par champ
Modèle de coût	Prix par million de tokens	Coût mesuré par dossier, incluant les réessais et les allers-retours d’outils
Modes de défaillance visibles	Réponse erronée ou inutile	Champ erroné, outil omis, mauvais outil, arguments malformés ou hallucinés, réponse prématurée
Ce que signifie « bon »	Position au classement	Le processus s’est terminé correctement à un coût acceptable et prévisible

Le reste de ce guide aborde les quatre axes un par un. Chacun est un ensemble d’éléments concrets à journaliser et de métriques à calculer. Ensemble, ils répondent aux deux questions posées dans cette pièce : quel modèle, et à quel coût par dossier.

Axe 1 : Coût par instance de processus

L’unité qui compte n’est pas le token. C’est le dossier : une demande de prêt, une révision KYC, une réclamation. C’est l’unité sur laquelle l’entreprise base ses prix, son personnel et ses budgets, c’est donc l’unité que votre évaluation doit rapporter.

Le coût mesuré par instance est la somme de chaque appel de modèle déclenché par l’instance :

• L’appel de planification initial.
• Un appel par aller-retour d’outil, chacun renvoyant le contexte accumulé. Dans une boucle d’agent naïve, les tokens d’entrée augmentent à chaque itération, de sorte que les dossiers gourmands en outils coûtent disproportionnellement plus cher que ce que le premier appel suggère.
• Chaque réessai. Si le modèle émet un output qui échoue à la validation de schéma et que la couche d’orchestration le relance, ce réessai représente de l’argent réel et doit être inclus dans le chiffre.
• Tout appel auxiliaire requis par le pattern : validateurs d’output, vérifications de garde-fou, résumé des résultats d’outils surdimensionnés.

Pour le calculer, journalisez par appel de modèle : identifiant du modèle, tokens d’entrée, tokens de sortie, latence et raison de la fin. Journalisez par instance : nombre d’itérations et nombre de réessais. Multipliez les tokens par les prix actuels du fournisseur et faites la somme. Rapportez la médiane et le p95, car les distributions de coûts agentiques ont des queues longues ; le dossier qui déclenche trois réessais et douze appels d’outils est celui qui apparaît sur la facture.

Une métrique dérivée a gagné sa place dans chaque engagement depuis : le coût par dossier correct, qui est le coût par instance divisé par la fraction d’instances que le modèle a entièrement réussies. Un modèle bon marché qui se trompe un tiers du temps n’est pas bon marché, car quelqu’un paie pour la reprise.

La découverte qui a rendu cet axe célèbre dans mon propre travail : sur une tâche de type KYC lors de ce premier engagement, un modèle de milieu de gamme a égalé la précision du modèle premium à environ 1/13e du coût par dossier. Pas 20 % moins cher. Treize fois moins cher, sans perte de qualité mesurée sur cette tâche. La raison, rétrospectivement, est peu excitante : la tâche était de l’extraction et du suivi de règles avec des outils bien spécifiés, et non un jugement ouvert. Les modèles de milieu de gamme sont bons pour cela maintenant. Mais personne dans la pièce n’aurait parié sur ce ratio à l’avance, et sans un banc d’évaluation, personne n’aurait pu le prouver. Les listes de prix par token prédisaient un écart ; seul le coût mesuré par dossier l’a quantifié.

Le piège sur cet axe est de comparer les listes de prix au lieu de mesurer. Un modèle qui coûte deux fois moins cher par token mais qui, en moyenne, prend deux itérations de boucle supplémentaires et un réessai par dossier peut s’avérer plus coûteux. J’ai vu cette inversion exacte se produire. Mesurez la boucle, pas la liste.

Axe 2 : Qualité, notée par champ

La qualité pour un agent intégré à un processus signifie : l’output structuré correspond-il à ce qu’un expert compétent aurait produit pour ce dossier ? Cela nécessite deux choses que la plupart des équipes ignorent : un jeu de données de référence construit à partir de cas réels, et une notation par champ.

Construction du jeu de données de référence. Ma règle sur le terrain : 10 à 30 scénarios élaborés à partir de cas réels valent mieux que 1 000 scénarios synthétiques. Les générateurs de cas synthétiques (généralement un autre LLM) reproduisent les mêmes angles morts que le modèle testé ; ils génèrent des cas propres, bien formés, statistiquement moyens. Les cas réels présentent les difficultés qui mettent réellement les agents en échec : le nom composé qui déjoue une heuristique de correspondance, le client à double nationalité, le document auquel il manque une page, l’entité dont l’adresse enregistrée diffère de son adresse opérationnelle. La procédure que j’utilise :

1. Asseyez-vous avec les personnes qui exécutent le processus aujourd’hui et extrayez 10 à 30 cas réels, couvrant les cas routiniers, les cas limites et les cas notoirement difficiles.
2. Anonymisez-les structurellement : préservez la nature de la difficulté (la présence d’un trait d’union, le document manquant) tout en remplaçant chaque valeur d’identification.
3. Pour chaque scénario, demandez à l’expert de noter la valeur correcte pour chaque champ d’output, ainsi que les outils qu’une exécution correcte doit appeler. Cette deuxième annotation alimente l’Axe 3.
4. Demandez à un deuxième expert de revoir les étiquettes. Si les deux ne sont pas d’accord, le champ est ambigu ; soit resserrez sa définition, soit excluez-le de la notation. Les étiquettes de référence ambiguës sont la façon dont les évaluations vous mentent.

Notation par champ, pas par impression. Parce que l’output est structuré, la plupart des notations peuvent être déterministes : correspondance exacte pour les énumérations et les identifiants, correspondance normalisée pour les noms et les dates, tolérance numérique pour les montants. Réservez le LLM-juge pour les champs de justification en texte libre, et traitez ces scores comme indicatifs, non autoritaires (plus d’informations sur le biais du juge sous les limitations). Calculez :

• Précision par champ sur l’ensemble des scénarios, afin de voir que entity_type est correct mais que source_of_wealth est faible.
• Taux de champs tous corrects par scénario, le nombre qui correspond aux « dossiers ne nécessitant aucune reprise ».
• Précision des champs critiques comme titre distinct. Dans un processus de conformité, se tromper sur pep_flag n’est pas la même chose que de se tromper sur une nuance de formatage. Pondérez en conséquence et indiquez-le dans le rapport.

Le piège sur cet axe est l’assouplissement progressif de la notation. Lorsqu’un modèle obtient un mauvais score, la tentation est d’assouplir le comparateur (« assez proche ») plutôt que d’accepter le score. Figez les règles de notation avant de lancer le “bake-off”, et ne les modifiez qu’avec la même discipline que celle que vous appliqueriez à la modification d’une suite de tests.

Axe 3 : Fiabilité des outils, l’axe que personne ne mesure

C’est l’axe que je n’ai jamais vu dans l’évaluation de quiconque d’autre, et c’est celui qui a le plus influencé les décisions. Les métriques des chatbots n’en ont aucune notion, car les chatbots n’ont pas d’outils à omettre.

Un agent intégré à un processus reçoit des outils avec un contrat implicite : pour cette classe de dossier, vous appelez la vérification de filtrage, puis la recherche de propriété, puis vous répondez. Le modèle peut enfreindre ce contrat de manière à ne produire aucune erreur, aucune exception et aucun artefact visible dans l’output final. Le pire d’entre eux est l’omission d’outil : l’agent n’appelle pas silencieusement un outil qu’il aurait dû appeler, puis produit une réponse qui semble complète.

Le taux d’omission est invisible dans les démos et fatal en production. Dans une démo, le cas du chemin heureux est montré, l’output semble plausible, et tout le monde acquiesce. En production, « l’agent n’a pas effectué la vérification des sanctions sur 4 % des dossiers » est une constatation réglementaire, pas une métrique de qualité. La seule défense est de le mesurer, c’est pourquoi le jeu de données de référence contient des annotations d’appels d’outils attendus. Ma phrase habituelle dans les rapports : taux d’omission mesurés, non supposés.

Si votre banc d’évaluation n’enregistre que ce que l’agent a dit, vous évaluez un générateur de texte situé près de quelques outils. Enregistrez ce qu’il a fait et ce qu’il n’a pas fait.

À partir des transcriptions (que vous journalisez déjà pour l’axe des coûts), calculez par modèle :

• Rappel d’outil : parmi les appels d’outils qu’une exécution correcte requiert, quelle fraction l’agent a-t-il effectuée ?
• Taux d’omission par outil : quels outils spécifiques sont omis, et sur quelles classes de scénarios ? Les omissions se regroupent ; un outil qui est omis est généralement un outil dont la description ne rend pas sa nécessité évidente.
• Taux d’outil erroné : l’agent a appelé quelque chose, mais pas la bonne chose.
• Taux d’arguments malformés : appels qui ont échoué à la validation de schéma.
• Précision des arguments : appels qui ont passé la validation mais contenaient des valeurs erronées.

La taxonomie complète des défaillances d’outils, dans l’ordre de mes préoccupations :

Omission d’outil

L’agent aurait dû appeler un outil et ne l’a pas fait, et a quand même répondu. Aucune erreur n’est levée nulle part. La détection nécessite des annotations d’appels attendus ; rien dans le runtime ne vous le dira. C’est le mode de défaillance qui justifie l’axe entier.

Réponse prématurée

Une variante systémique de l’omission : l’agent commence la séquence requise, puis décide en cours de boucle qu’il en sait assez et rend un verdict avec la séquence incomplète. Courant sur les cas qui semblent routiniers, ce qui est exactement le moment où les réviseurs ne sont pas attentifs. Détectez en comparant la séquence d’appels exécutée avec l’ensemble requis, et non pas seulement en vérifiant que chaque outil apparaît quelque part.

Arguments hallucinés

L’appel est valide selon le schéma et le runtime l’accepte, mais une valeur d’argument a été inventée plutôt que tirée du dossier : un identifiant de compte fabriqué, une date que les documents ne contiennent pas. Celui-ci passe toutes les portes automatiques et empoisonne les données en aval. La détection nécessite des valeurs de référence au niveau des arguments ou une vérification ponctuelle par un expert ; prévoyez un budget pour cela.

Sélection d’outil erronée

L’agent appelle l’outil d’historique de compte alors que le dossier nécessitait l’outil de filtrage. Généralement un symptôme de descriptions d’outils qui se chevauchent plutôt qu’une faiblesse du modèle. Détectable automatiquement par rapport aux annotations.

Arguments malformés

L’appel échoue à la validation de schéma. Bruyant, peu coûteux à détecter, et principalement un problème de coût de réessai plutôt qu’un problème de correction, à condition que votre couche d’orchestration valide et réessaie réellement. Les modèles qui malforment fréquemment les arguments apparaissent également comme coûteux sur l’Axe 1, ce qui est la façon dont les axes se recoupent.

Voici la partie qui rend cet axe exploitable plutôt que fataliste : dans mes engagements, une grande partie des défaillances de fiabilité des outils remontait aux spécifications des outils, et non au modèle. Descriptions vagues, noms qui se chevauchent, énumérations non documentées, paramètres dont le but n’est clair que pour la personne qui a écrit l’API. La correction des spécifications a davantage influencé les taux d’omission et d’outils erronés que le changement de modèle. J’ai rédigé la discipline côté spécifications séparément dans le guide des contrats d’outils ; le banc d’évaluation est la façon de découvrir quels contrats échouent, et les contrats sont la façon de les corriger.

Axe 4 : Sensibilité à la température

J’ai ajouté cet axe en m’attendant à ce qu’il soit ennuyeux. Exécuter la grille à quelques températures, confirmer que la température zéro réduit la variance de l’output, rédiger une diapositive, passer à autre chose. Ce n’est pas ce que les données ont montré.

À température zéro, les modèles que j’ai testés ne sont pas seulement devenus plus cohérents. Ils sont devenus plus rigoureux avec les outils : rappel d’outil plus élevé, taux d’omission plus faibles, sur les mêmes scénarios avec les mêmes prompts. La température modifiait ce que l’agent faisait, pas seulement la répétabilité de son action. Mon explication de travail est mécanique plutôt que mystérieuse : à chaque point de décision, le modèle évalue « appeler un outil » par rapport à « répondre avec ce que j’ai », et l’échantillonnage à une température plus élevée prend occasionnellement le chemin de plus faible probabilité, qui pour un agent bien ‘prompté’ est le plus paresseux. À température zéro, le chemin gourmand inclut plus souvent l’appel d’outil. Je tiens cette explication de manière lâche ; les mesures, je les tiens fermement.

Pourquoi cet axe existe-t-il : les clients réglementés demandent spécifiquement la température zéro, et les fournisseurs la présentent régulièrement comme un contrôle de sécurité. Avant de répéter cette affirmation dans une banque, vous devriez savoir ce que la température zéro fait réellement à votre agent spécifique, car « elle modifie les outils qui sont appelés » est une déclaration matériellement différente de « elle réduit le caractère aléatoire ».

Ne dites pas à un client réglementé que la température zéro est un contrôle de sécurité tant que vous n’avez pas mesuré ce qu’elle modifie. Dans mes exécutions, elle a modifié les outils qui étaient appelés.

Méthode : exécutez l’ensemble complet du jeu de données de référence à chaque température candidate (j’utilise 0, une valeur basse comme 0,2 à 0,3, et la valeur par défaut du fournisseur), chaque scénario étant répété plusieurs fois par réglage afin de pouvoir séparer la variance du niveau. Rapportez les trois autres axes ventilés par température : précision, rappel d’outil, taux d’omission et coût par dossier, plus le désaccord entre les exécutions comme mesure de la variance. Deux mises en garde du terrain : certains modèles de classe de raisonnement ignorent ou rejettent entièrement le paramètre de température, alors vérifiez que le réglage est réellement appliqué ; et les résultats de température sont spécifiques au modèle et au fournisseur, alors remesurez lorsque l’un ou l’autre change plutôt que de transposer la conclusion.

Ce que les chiffres apportent à votre architecture : le routage des modèles

Les quatre axes ne sont pas un bulletin à archiver. Ce sont des entrées de routage.

Tracez chaque modèle candidat comme un point : coût mesuré par dossier sur un axe, taux de champs tous corrects sur l’autre. Les points tracent une courbe coût-qualité, et la forme de cette courbe est la décision. Trois formes récurrentes :

• Courbe plate. Le modèle de milieu de gamme offre la même qualité que le modèle premium pour une fraction du coût. C’était la découverte de type KYC : même précision, environ 1/13e du coût. Décision : utilisez le modèle de milieu de gamme, gardez le modèle premium comme cible d’escalade, et économisez la différence. Les courbes plates sont courantes pour les tâches d’extraction et de suivi de règles avec de bons contrats d’outils.
• Courbe en falaise. La qualité chute brusquement en dessous d’un certain niveau de modèle. Courant sur les tâches nécessitant un véritable jugement multi-étapes ou une synthèse à travers de nombreux documents. Décision : payez pour le niveau au-dessus de la falaise ; ne laissez pas les achats vous convaincre de descendre en dessous.
• Courbe « payer pour rien ». Le modèle premium est plus cher et pas meilleur, parfois pire en rappel d’outil (les modèles plus grands ne sont pas uniformément de meilleurs agents ; mesurez, ne supposez pas). Décision : évidente.

La conséquence plus profonde est le routage par étape. Un agent intégré à un processus n’est pas une seule décision de modèle ; c’est une décision par étape, car la couche d’orchestration (Camunda dans mes implémentations, mais Temporal, LangGraph, ou une boucle Node.js faite maison vous offrent la même flexibilité) lie un modèle à chaque tâche indépendamment. Cela permet la philosophie multi-modèles que j’apporte maintenant à chaque engagement :

• Adaptez la taille de chaque étape. Les étapes d’extraction et de classification de documents sont confiées au modèle de milieu de gamme que l’évaluation a montré être suffisant. L’étape qui nécessite de peser des preuves contradictoires reçoit le modèle premium. Exécutez le banc d’évaluation par étape, pas seulement par processus.
• Routez vers le premium sur signal, pas par défaut. Une faible confiance rapportée par le modèle, un échec de validation de schéma, ou une classe de cas difficile identifiée par le jeu de données de référence peut router une instance vers le modèle premium, ou vers un humain. La décision d’escalade réside dans la définition du processus, où elle est visible et auditable, et non enfouie dans un prompt.
• Le modèle le moins cher est l’absence de modèle. Si le comportement mesuré par l’évaluation d’une étape est reproductible par un moteur de règles ou une recherche, retirez entièrement le LLM de cette étape. L’évaluation est souvent la façon de le découvrir : lorsqu’un modèle obtient un score de 100 % sur une étape à travers tous les niveaux, cette étape n’avait probablement pas besoin d’un modèle.

Le coût par dossier au niveau du processus devient alors une somme pondérée sur les étapes, et vous pouvez répondre à la deuxième question de la pièce (« combien cela coûtera-t-il par dossier ? ») avec un chiffre assorti de barres d’erreur au lieu d’un haussement d’épaules.

Exécuter les évaluations en continu

La première exécution du banc d’évaluation répond à « quel modèle ». Chaque exécution ultérieure répond à une question plus importante : « venons-nous de le casser ? »

Un agent intégré à un processus présente au moins cinq surfaces de changement, et chacune d’elles peut silencieusement déplacer les quatre axes :

1. Modifications de prompt. La modification innocente de formulation qui fait chuter le rappel d’outil de dix points. J’ai vu une « clarification » de prompt d’une phrase doubler un taux d’omission.
2. Modifications des spécifications d’outils. Renommer un paramètre, ajouter un outil, affiner une description. Chacun de ces éléments modifie ce que le modèle sélectionne et la façon dont il interagit avec le schéma.
3. Mises à jour de version de modèle. Mises à niveau délibérées. Ne supposez jamais que la nouvelle version domine l’ancienne sur les quatre axes ; vérifiez le rappel d’outil en particulier.
4. Dérive du fournisseur. Le même alias de modèle se comportant différemment après une mise à jour côté fournisseur dont vous n’avez pas été informé. Épinglez les versions exactes du modèle lorsque le fournisseur le permet ; lorsque ce n’est pas le cas, une réexécution planifiée du banc d’évaluation est votre détecteur de dérive.
5. Modifications de configuration. Température, limites de tokens, politiques de réessai. L’Axe 4 existe parce que ceux-ci ne sont pas neutres.

Traitez donc le banc d’évaluation comme une suite de régression. Versionnez le jeu de données de référence dans le même dépôt que les prompts et les spécifications d’outils. Marquez chaque exécution d’évaluation avec un hachage de configuration couvrant la version du prompt, la version des spécifications d’outils, l’identifiant du modèle et la température, afin que tout score soit reproductible et toute régression bisectable. Gérez les changements de la même manière que vous gérez le code : une modification de prompt qui fait chuter le rappel d’outil devrait échouer à la révision avant d’atteindre la production, et le rapport d’évaluation est l’artefact de révision.

C’est abordable parce que le jeu de données de référence est petit. Vingt scénarios, trois répétitions, un modèle : c’est une exécution de pause-café, suffisamment bon marché pour être attachée à chaque changement significatif plutôt que d’être réservée aux “bake-offs” trimestriels. La discipline des 10 à 30 scénarios de l’Axe 2 ne concerne pas seulement la qualité des étiquettes ; c’est ce qui rend l’évaluation continue économiquement ennuyeuse, ce qui est ce qui la fait réellement se produire.

Ce que cette méthode ne résout pas

La section honnêteté, car une méthode à laquelle vous faites confiance au-delà de ses limites est pire qu’aucune méthode.

Les jeux de données de référence deviennent obsolètes. Le processus change, les formats de documents changent, la réglementation change, et le jeu de données de référence cesse discrètement de représenter la production. Un jeu de données de référence est un instantané du processus au moment de sa rédaction. Revoyez-le chaque fois que le processus lui-même est revu, et retirez les scénarios qui ne se produisent plus. Un banc d’évaluation affichant un score vert sur les cas de l’année dernière est un faux réconfort.

Un petit n donne des classements, pas des certifications. Dix à trente scénarios classeront de manière fiable les modèles et détecteront les régressions importantes. Cela ne soutiendra pas « 94,2 % de précision » dans un document d’audit ; l’intervalle de confiance sur 20 cas est large, et prétendre le contraire est une faute professionnelle. Utilisez le banc d’évaluation pour les décisions d’ingénierie. Si une fonction de conformité a besoin d’un chiffre de précision certifié, il s’agit d’un exercice d’échantillonnage plus vaste et géré séparément.

Le LLM-juge présente des biais connus. Le biais de verbosité, le biais de position et l’auto-préférence (un modèle évaluant favorablement l’output de sa propre famille) sont tous documentés. C’est pourquoi la méthode pousse la notation vers des vérifications déterministes par champ, ce que les outputs structurés rendent possible. Là où un juge est inévitable (justifications en texte libre), utilisez un modèle d’une famille différente de tout candidat testé, une grille d’évaluation fixe et des vérifications périodiques de concordance humaine. Et gardez les scores du juge hors des chiffres principaux.

Les évaluations sur-apprennent comme tout le reste. Si vous ajustez les prompts par rapport au jeu de données de référence pendant des semaines, vous enseignez pour le test, et le score cesse de prédire la production. Réservez quelques scénarios qui n’influencent jamais les changements de prompt, et intégrez de nouveaux cas réels au fur et à mesure qu’ils arrivent. Lorsque le score des scénarios réservés et le score de développement divergent, croyez le score des scénarios réservés.

Quatre axes ne sont pas tous les axes. Cette méthode ne dit rien sur la robustesse aux attaques adverses, l’injection de prompt via les résultats d’outils, la mémoire à long terme, ou la qualité des transferts avec humain dans la boucle. Ceux-ci nécessitent leurs propres évaluations. Les quatre axes sont ceux qui ont répondu aux questions que les entreprises m’ont réellement posées ; ils sont un plancher, pas un plafond.

La version en un paragraphe

Les évaluations de l’ère des chatbots ne peuvent pas vous dire quel modèle devrait exécuter un agent intégré à un processus gouverné, alors mesurez l’agent de la manière dont l’entreprise le percevra : construisez un jeu de données de référence de 10 à 30 cas réels anonymisés avec des outputs attendus par champ et des appels d’outils attendus, puis évaluez chaque modèle candidat sur quatre axes : le coût par instance de processus (chaque itération de boucle, réessai et aller-retour d’outil, rapporté par dossier, où un modèle de milieu de gamme a un jour égalé un modèle premium à environ 1/13e du coût), la précision par champ par rapport aux étiquettes de référence (correspondance déterministe, pas d’impressions), la fiabilité des outils (taux d’omission, sélection d’outil erronée et arguments malformés ou hallucinés, mesurés plutôt que supposés, car une vérification de conformité silencieusement omise est invisible dans une démo et fatale en production), et la sensibilité à la température (la température zéro a modifié la rigueur des outils dans mes exécutions, pas seulement la variance, alors mesurez avant de l’appeler un contrôle de sécurité). Intégrez les courbes coût-qualité résultantes dans le routage de modèle par étape, réexécutez le banc d’évaluation comme une suite de régression à chaque changement de prompt, d’outil et de modèle, et tenez compte des résultats avec prudence là où la méthode est faible : les petits jeux de données de référence classent les modèles mais ne les certifient pas, et les jeux de données de référence deviennent obsolètes.

Références

• Anthropic, « Créer des évaluations empiriques solides » : docs.anthropic.com/en/docs/build-with-claude/develop-tests
• Anthropic, « Construire des agents efficaces » : anthropic.com/engineering/building-effective-agents
• OpenAI, guide des « Évaluations » : platform.openai.com/docs/guides/evals
• Zheng et al., « Évaluer les LLM-juges avec MT-Bench et Chatbot Arena » (le traitement canonique des biais des juges) : arxiv.org/abs/2306.05685
• Yao et al., « τ-bench : Un benchmark pour l’interaction agent-outil-utilisateur dans des domaines réels » : arxiv.org/abs/2406.12045
• Classement Berkeley Function-Calling, pour les comparaisons publiques d’appels de fonctions (contexte utile, pas un substitut à votre propre jeu de données de référence) : gorilla.cs.berkeley.edu/leaderboard.html
• Hamel Husain, « Votre produit IA a besoin d’évaluations » : hamel.dev/blog/posts/evals
• Guide complémentaire sur l’aspect spécifications de la fiabilité des outils : Contrats d’outils
• Cette méthode a été extraite de travaux de preuve de valeur en production avec de grandes institutions financières ; les engagements sont généralisés et aucun code d’évaluation client n’est public.