Les recherches Anthropic Simon mènent à smevals, un pari plus modeste sur l'évaluation de l'IA

Simon Willison a lancé smevals après des années d'expérimentations sur les évaluations, créant un contraste frappant avec les recommandations plus formelles d'Anthropic pour tester les agents d'IA. Le lien anthropic simon compte, car les deux approches soulignent désormais le même problème. Le score d'un modèle ne dit pas grand-chose tant que les équipes ne testent pas aussi les prompts, les outils, les instructions système et le harnais qui entoure ce modèle.

Willison a développé smevals avec le laboratoire de recherche en IA appliquée Prime Radiant de Jesse Vincent. Le projet exécute de petites suites d'évaluation sur plusieurs configurations, note leurs résultats et génère des rapports pour une inspection plus approfondie.

Cette sortie remet en cause une hypothèse courante sur l'évaluation de l'IA. Les équipes n'ont pas toujours besoin d'une vaste plateforme de benchmarks avant de pouvoir poser une question utile. Elles ont besoin d'une tâche ciblée, de configurations reproductibles, de contrôles explicites et d'une visibilité suffisante pour comprendre les échecs.

Le principal affrontement est donc plus restreint et plus pragmatique qu'Anthropic face à un autre fournisseur de modèles. Il oppose une évaluation locale ciblée à une infrastructure d'évaluation lourde et généraliste. La première privilégie la rapidité et l'inspectabilité, tandis que la seconde prend en charge des expérimentations plus larges et des environnements plus complexes.

Ce que smevals change pour les petites évaluations d'IA

smevals transforme une question produit précise en un répertoire portable de tâches, de configurations et de règles de notation.

Willison a annoncé smevals le 31 juillet 2026. Sa présentation de smevals le décrit comme un outil permettant d'exécuter de petites suites d'évaluation sur différentes configurations de modèles et de noter les résultats produits.

Le flux de travail de base commence avec uvx smevals docs. Cette commande fournit à un agent de programmation la documentation du projet, afin qu'il puisse étudier le format avant de construire une suite d'évaluation.

Cette approche traite la documentation comme un contexte opérationnel. Au lieu de demander aux utilisateurs de mémoriser chaque champ de configuration, le projet attend d'un agent de programmation qu'il lise les instructions et aide à créer les fichiers.

Une évaluation réside ensuite dans un répertoire contenant des fichiers YAML. YAML est un format de données lisible par l'humain, souvent utilisé pour la configuration. Ces fichiers décrivent la question, les tâches, les configurations de modèles et le comportement de notation.

Un utilisateur peut exécuter la même suite sur plusieurs modèles. L'exemple de Willison compare des configurations GPT et Claude nommées au moyen d'arguments -m répétés.

Cette structure de commande est importante. Elle présente le choix du modèle comme une variable au sein d'une expérience plus vaste, plutôt que de traiter le modèle comme le produit tout entier.

smevals sépare également l'exécution de la notation. La commande run enregistre ce qui s'est produit lorsqu'une configuration a tenté une tâche. La commande grade applique ensuite des contrôles définis à ces résultats enregistrés.

Cette séparation crée une limite d'audit utile. Les équipes peuvent conserver le comportement brut, réviser leur logique de notation et examiner comment une grille d'évaluation différente modifie l'interprétation.

L'outil propose deux voies de reporting. La commande serve lance une interface web locale, tandis que build produit du HTML statique pouvant être hébergé ailleurs.

Willison a démontré le flux de travail avec une évaluation de haïkus. Le rapport vérifiait si les modèles produisaient exactement trois lignes non vides et classait les configurations à l'aide des notes obtenues.

Un benchmark de haïkus est volontairement modeste. Il illustre néanmoins un principe d'évaluation sérieux : des exigences étroitement définies révèlent souvent des différences que de larges scores de préférence ne peuvent pas expliquer.

La sortie introduit également un vocabulaire cohérent. Une évaluation contient des tâches, tandis qu'une configuration définit le modèle et les autres variables examinées.

Une exécution enregistre une configuration tentant une tâche. Un correcteur produit une note en appliquant des contrôles, notamment des contrôles déterministes ou des scripts de vérification personnalisés.

Ces contrôles personnalisés peuvent examiner des chaînes, valider des formats tels que XML ou appeler un autre modèle pour émettre un jugement. Cette diversité permet à une même suite de combiner des contraintes objectives et des évaluations de qualité plus subjectives.

Rien dans ce flux de travail ne fait de smevals un produit Anthropic. L'association anthropic simon vient de l'intérêt commun pour l'évaluation des agents et les configurations Claude, et non d'une propriété d'entreprise.

Le changement immédiat est donc l'accessibilité. Un développeur peut désormais empaqueter une petite question d'évaluation sans adopter d'abord un service d'évaluation étendu ni créer un tableau de bord personnalisé.

Pourquoi l'intérêt pour Anthropic Simon se concentre désormais sur le harnais

Le modèle n'est plus la seule unité de comparaison pertinente, car le harnais d'agent qui l'entoure peut modifier le résultat.

Anthropic définit un harnais d'agent comme le système qui traite les entrées, coordonne les appels d'outils et renvoie les résultats. Ses recommandations sur l'évaluation des agents distinguent cette couche du harnais d'évaluation qui exécute et note les expériences.

Cette distinction aide à comprendre pourquoi smevals prend en charge des configurations allant au-delà d'un nom de modèle. Une configuration peut également inclure différents prompts système, paramètres de modèle ou harnais d'agents.

Supposons que deux produits de programmation utilisent le même modèle sous-jacent. L'un fournit au modèle un meilleur contexte de dépôt, tandis que l'autre propose des outils plus solides et des contrôles de complétion plus clairs.

Un benchmark limité au modèle traiterait ces systèmes comme équivalents. Une évaluation au niveau de la configuration peut montrer que leur comportement réel diffère.

La pression s'exerce sur les équipes produit d'IA qui continuent de sélectionner des modèles uniquement à partir de classements publics. Ces classements peuvent aider à réduire le champ des possibles, mais ils reproduisent rarement les prompts, outils, autorisations et données exacts d'un produit.

Le comportement d'un agent se déploie également en plusieurs étapes. Un système peut appeler un outil, modifier un état, interpréter le résultat et décider de poursuivre ou non.

Une erreur précoce peut affecter chaque action ultérieure. Cela rend l'évaluation d'un agent différente de la vérification qu'un chatbot a correctement répondu à une seule question.

Les recommandations d'Anthropic indiquent que les équipes évaluent ensemble le modèle et le harnais d'agent lorsqu'elles évaluent un agent. Cette vision correspond étroitement au modèle de configuration utilisé par smevals.

C'est là que se situe la véritable histoire anthropic simon. Les deux approches détournent l'attention de l'intelligence isolée du modèle pour la porter vers le système complet dont les utilisateurs font l'expérience.

Le calendrier reflète aussi un problème opérationnel grandissant. Les modèles, les prompts et les harnais évoluent indépendamment, alors que les équipes produit doivent toujours identifier ce qui a provoqué une régression.

Un nouveau modèle peut améliorer le raisonnement tout en modifiant le style de sortie. Un prompt système révisé peut réduire la verbosité tout en affaiblissant le suivi des instructions. Une mise à jour du harnais peut exposer de meilleurs outils tout en introduisant des erreurs d'état.

Sans configurations contrôlées, ces changements s'entremêlent. Les équipes constatent qu'un produit semble différent, mais elles ne peuvent pas attribuer la différence avec certitude.

Anthropic décrit cette situation comme un fonctionnement sans visibilité suffisante. Les équipes attendent les plaintes des utilisateurs, reproduisent manuellement les échecs, corrigent un problème et risquent d'introduire une autre régression.

smevals apporte une réponse plus modeste au même problème. Il ne tente pas de reproduire toutes les conditions de production. Il offre aux équipes une manière structurée d'isoler une question avant d'élargir l'expérience.

C'est important pour le travail intensif en connaissances. Une équipe d'ingénierie peut, par exemple, tester si un assistant trouve la bonne spécification interne avant de générer du code.

Le test pourrait comparer deux prompts de récupération, deux versions de modèle ou deux politiques d'outils. Les équipes qui maintiennent une base de connaissances consultable font face à des questions similaires chaque fois que l'accès aux documents évolue.

La comparaison obtenue est plus utile que de demander quel modèle est le meilleur. Elle demande quelle configuration complète exécute une tâche définie dans des conditions énoncées.

Le mécanisme repose sur la séparation, pas sur un score plus intelligent

smevals gagne en clarté en séparant suffisamment les tâches, l'exécution, la notation et le reporting pour pouvoir les inspecter indépendamment.

De nombreux produits d'évaluation promettent un score unique qui facilite la comparaison. Cette commodité peut masquer les décisions ayant produit le score.

smevals adopte une approche plus décomposée. L'évaluation énonce la question générale, et chaque tâche présente un défi spécifique.

Les configurations décrivent ensuite les systèmes qui tentent ces tâches. Une exécution capture la tentative, tandis qu'un correcteur évalue le résultat sauvegardé à l'aide d'un ou plusieurs contrôles.

Cette architecture ressemble à des tests ordinaires, car une grande partie de son fonctionnement suit la logique habituelle des tests. Les entrées, les conditions, les sorties, les assertions et les rapports restent des concepts reconnaissables.

Le comportement des modèles de langage complique chaque composant. Le même prompt peut produire des réponses différentes, tandis que plusieurs réponses différentes peuvent toutes satisfaire l'utilisateur.

Un contrôle utile doit donc correspondre à l'exigence. La comparaison exacte de chaînes convient à un jeton fixe, mais fonctionne mal lorsque plusieurs formulations sont valides.

Les contrôles structurels offrent une autre option. Une équipe peut valider du JSON, du XML, le nombre de lignes, les sections requises ou les fichiers créés dans un environnement d'agent.

Les correcteurs fondés sur des modèles prennent en charge des qualités moins déterministes. Un autre modèle peut évaluer si une réponse respecte une grille, inclut le raisonnement nécessaire ou satisfait une exigence de style.

Toutefois, un juge IA ne transforme pas une question subjective en vérité objective. Il introduit un autre modèle, un autre prompt et un autre ensemble d'hypothèses dans l'évaluation.

Séparer la notation de l'exécution facilite l'étude de cette limite. Une équipe peut conserver les mêmes exécutions et comparer plusieurs méthodes de notation sans payer à nouveau chaque tâche.

Elle peut aussi examiner les désaccords. Si un vérificateur de format réussit alors qu'un juge IA échoue, le rapport révèle deux dimensions différentes au lieu de les moyenner immédiatement.

La couche de reporting compte pour la même raison. Les scores agrégés aident les lecteurs à parcourir les résultats, mais les exécutions individuelles expliquent pourquoi une configuration a réussi ou échoué.

L'exemple de haïkus de Willison illustre cet équilibre. Un classement fournit le résumé, tandis que les exécutions récentes, les détails des tâches, les tags et les informations sur les correcteurs exposent les éléments de preuve sous-jacents.

Le HTML statique apporte un autre avantage pratique. Une équipe peut publier un résultat sans maintenir un service d'évaluation en ligne.

Le point d'entrée uvx réduit également les frictions de mise en place. Selon le guide officiel des outils uv, uvx exécute un outil empaqueté dans un environnement temporaire isolé.

Cette conception convient aux investigations courtes. Un développeur peut essayer la commande sans devoir effectuer d'abord une installation globale persistante.

Le flux de travail avec un agent de programmation réduit un autre coût de mise en place. L'agent peut lire la documentation du projet, proposer des fichiers YAML et aider à affiner le test.

Une révision humaine reste nécessaire. Une suite générée par un agent peut intégrer des attentes vagues, omettre des cas difficiles ou créer des contrôles qui ne récompensent que ses propres hypothèses.

L'outil n'élimine donc pas la conception de l'évaluation. Il raccourcit la distance entre une question et la première version exécutable de cette question.

Cette différence compte. Les équipes reportent souvent l'évaluation parce que l'étape initiale qu'elles imaginent comprend des bases de données, des tableaux de bord, des systèmes de traçage et un vaste jeu de données de référence.

smevals propose une première étape plus étroite : encoder une incertitude réelle et l'exécuter sur quelques configurations contrôlées.

Les petites suites d'évaluation remettent en cause les frameworks lourds

Le principal atout de smevals n'est pas l'étendue de ses fonctionnalités, mais sa capacité à démarrer avec une question circonscrite tout en conservant les éléments de preuve.

Le marché de l’évaluation comprend déjà des frameworks ouverts plus étendus. La plateforme Inspect de l’AI Security Institute du Royaume-Uni prend en charge les jeux de données, solveurs, évaluateurs, agents, sandboxes, fournisseurs de modèles et transcriptions détaillées.

Sa documentation Inspect présente une tâche comme l’association d’un jeu de données, d’un solveur et d’un évaluateur. Le solveur peut effectuer un seul appel de modèle ou piloter un agent multi-tour avec des outils.

Inspect prend également en charge des évaluations de sécurité complexes et des environnements d’exécution isolés. Ces capacités conviennent aux organisations qui exécutent des benchmarks formels ou testent des agents modifiant un état externe.

Promptfoo aborde le problème sous l’angle des tests de prompts et d’applications. Son format de configuration couvre les fournisseurs, prompts, cas de test, assertions et variables.

L’espace de travail d’évaluation officiel montre comment YAML peut définir des fournisseurs, des prompts et les comportements attendus. Cela fait de Promptfoo un point de comparaison pertinent pour les équipes qui traitent déjà les prompts comme du code testable.

smevals arrive dans ce domaine avec un périmètre déclaré plus restreint. Son avantage dépendra de sa capacité à conserver cette cohérence à mesure que les utilisateurs demanderont davantage de fonctionnalités.

Une suite ciblée peut être plus facile à examiner. Chaque tâche peut se rattacher directement à une décision produit, et chaque configuration peut représenter une modification qu’une équipe pourrait réellement déployer.

Cette focalisation améliore aussi l’analyse des échecs. Un test nommé autour d’un besoin utilisateur concret en apprend davantage aux développeurs qu’une catégorie de capacité abstraite.

Prenons un assistant qui prépare les mises à jour produit hebdomadaires. Une petite suite pourrait vérifier qu’il cite les bonnes notes de réunion, distingue les décisions des propositions et évite les affirmations non étayées.

Les configurations pourraient faire varier le prompt de récupération, le modèle et l’outil de sélection des documents. Les évaluateurs pourraient contrôler la présence des citations, l’identité des sources et la cohérence factuelle.

Un benchmark public ne répondrait pas à cette question produit. Il ne dispose ni des documents de l’équipe, ni du flux de travail attendu, ni de sa définition d’une mise à jour utile.

Les frameworks plus lourds restent précieux lorsque l’environnement lui-même exige une simulation. Les agents de navigation, de programmation et les systèmes de service client ont souvent besoin de tâches avec état, de bases de données reproductibles ou de sandboxes.

Les petites suites YAML ne recréent pas automatiquement ces conditions. Elles nécessitent des exécuteurs, scripts, fixtures ou autres composants de harnais compatibles.

C’est pourquoi le principal concurrent est une approche, et non une entreprise précise. Le choix se situe entre commencer localement par une question étroite et commencer par une infrastructure d’évaluation généralisée.

Aucune approche ne l’emporte dans tous les cas. La plus restreinte gagne lorsque le coût de mise en place empêche les équipes de tester quoi que ce soit.

L’approche plus large l’emporte lorsque le test doit contrôler un état complexe, capturer des trajectoires complètes, imposer l’isolation ou fonctionner en continu dans des pipelines de déploiement.

La progression la plus utile pourrait relier les deux. Une équipe peut découvrir des cas précieux avec smevals, puis migrer les tests arrivés à maturité dans un système de régression plus vaste.

Cette progression ne fonctionne que si les artefacts restent lisibles. Les tâches, configurations, sorties et règles de notation doivent être suffisamment claires pour qu’un autre ingénieur puisse les reproduire.

smevals semble conçu autour de cette portabilité, mais l’adoption déterminera si cette convention se maintient. Les outils deviennent plus difficiles à remplacer une fois que les évaluateurs et exécuteurs personnalisés s’accumulent.

La petite taille du projet constitue donc à la fois son argument de vente et son épreuve. Il doit ajouter suffisamment de capacités pour de vrais agents sans recréer chaque plateforme d’évaluation complexe.

Ce que les scores ne peuvent toujours pas trancher

Une suite reproductible peut révéler des comportements, mais elle ne peut garantir que ses tâches, évaluateurs et échantillons représentent la réalité de la production.

La première incertitude concerne la couverture. Une suite compacte peut répondre correctement à une question étroite tout en négligeant des échecs rares qui comptent davantage que son score moyen.

Les équipes peuvent aussi rédiger des tâches autour de cas de réussite connus. Des agents de programmation chargés de générer des évaluations peuvent produire des variations plausibles sans découvrir les cas limites surprenants rencontrés par les vrais utilisateurs.

Les incidents de production devraient donc alimenter la suite en retour. Les plaintes, traces d’échec, tickets de support et revues manuelles peuvent révéler des scénarios que la génération de tâches synthétiques a manqués.

La deuxième incertitude est le non-déterminisme. Les modèles peuvent produire des résultats différents lors de tentatives répétées, même lorsque la configuration semble inchangée.

Un seul passage par tâche ne peut distinguer une configuration fiable d’une configuration qui a réussi par hasard. Les essais répétés deviennent essentiels lorsque la variabilité des sorties influence la décision.

Les recommandations d’Anthropic en matière d’évaluation conseillent d’examiner les taux de réussite sur plusieurs essais. Elles avertissent également qu’un modèle peut trouver une solution valide que l’évaluateur n’avait pas anticipée.

Cela crée un mode d’échec difficile. Un évaluateur rigide peut pénaliser un résultat créatif même lorsque celui-ci sert mieux l’utilisateur.

Le problème inverse se pose avec les évaluateurs fondés sur des modèles. Un juge IA trop indulgent peut accepter une sortie fluide qui enfreint une exigence cachée importante.

Un étalonnage humain aide à repérer ces erreurs. Les réviseurs devraient examiner les réussites et les échecs, comparer les décisions des évaluateurs et réviser les rubriques lorsque le juge récompense le mauvais comportement.

La troisième incertitude concerne la contamination entre le système et l’évaluateur. Lorsque des agents de programmation aident à rédiger les tâches, prompts et contrôles, leurs préférences peuvent façonner le benchmark.

Utiliser un modèle apparenté comme évaluateur peut renforcer cet effet. Le test peut favoriser des formulations ou schémas de raisonnement familiers sans mesurer l’utilité réelle.

Cela ne rend pas l’évaluation par modèle invalide. Cela signifie que la note doit rester traçable jusqu’à une rubrique, une configuration de juge et un processus de revue.

Le quatrième enjeu concerne la confiance statistique. Une suite de trois tâches peut identifier une régression évidente de format, mais elle ne peut étayer de larges affirmations sur la qualité d’un modèle.

smevals se présente comme une petite suite d’évaluation, et les lecteurs devraient conserver cette limite. Ses rapports comparent les tâches exécutées, et non toutes les capacités des modèles concernés.

Les équipes devraient éviter de transformer un résultat local en classement universel. « La configuration A a réussi huit cas produit » est défendable. « Le modèle A est meilleur » ne l’est généralement pas.

Les coûts et la latence exigent une prudence similaire. Une configuration qui obtient un meilleur score peut utiliser des prompts plus longs, davantage d’appels d’outils ou un mode de raisonnement plus lent.

Si ces facteurs comptent pour le produit, la suite doit les enregistrer et les comparer. Les seuls scores de qualité ne peuvent déterminer le meilleur choix à déployer.

La sécurité modifie également la conception de l’évaluation. Un agent ayant accès au shell, au navigateur ou à une base de données a besoin d’environnements isolés et de contrôles sur l’état final.

Une transcription peut montrer qu’un agent a affirmé avoir réussi. Le résultat réel dépend de la création du bon fichier, de la modification de l’enregistrement voulu ou de l’évitement des actions interdites.

Ces limites ne constituent pas un argument contre les petites évaluations. Elles définissent les situations dans lesquelles une petite suite reste fiable.

La convergence anthropic simon est utile précisément parce qu’aucune des deux approches ne traite un chiffre agrégé comme une ligne d’arrivée. Les exécutions, traces, résultats et comportements des évaluateurs méritent tous d’être examinés.

Trois signaux montreront si le chevauchement Anthropic Simon perdure

smevals comptera au-delà de son lancement si les équipes l’utilisent pour comparer de véritables décisions de harnais, étalonner les évaluateurs et conserver des preuves reproductibles.

Le premier signal est l’étendue des suites d’évaluation publiées. Le formatage Haiku démontre le flux de travail, mais les développeurs d’agents ont besoin d’exemples impliquant des outils, un état et une exécution en plusieurs étapes.

Des suites qui comparent uniquement des prompts maintiendraient smevals proche des outils établis de test de prompts. Des suites qui comparent des harnais de programmation ou de recherche soutiendraient son positionnement plus large.

L’évaluation sera plus convaincante si les utilisateurs publient des cas d’agents reproductibles avec des exécutions et contrôles visibles. Elle s’affaiblira si les exemples restent limités à de courtes tâches de formatage de texte.

Le deuxième signal est l’étalonnage des évaluateurs. Le projet prend en charge des contrôles déterministes et des scripts de vérification plus complexes, y compris une évaluation fondée sur des modèles.

Les utilisateurs ont désormais besoin de méthodes pour comparer ces notes au jugement humain. Des rapports utiles devraient mettre en évidence les désaccords plutôt que de les dissimuler dans un score unique.

L’argument en faveur de smevals se renforce si les équipes peuvent réexécuter la notation, inspecter les rubriques et documenter les raisons des changements d’évaluateurs. Il s’affaiblit si les classements se détachent des preuves sous-jacentes.

Le troisième signal est l’intégration au développement quotidien. Une expérimentation locale crée une connaissance une fois, tandis qu’une suite de régression protège les changements futurs.

Observez si les équipes exécutent smevals après des mises à jour de modèles, des modifications de prompts, des changements d’outils et des publications de harnais. Un usage répété montrerait que de petites suites peuvent devenir des actifs d’ingénierie durables.

L’intégration n’exige pas que chaque équipe construise une plateforme élaborée. Un dépôt partagé, des fichiers YAML révisés, des exécutions sauvegardées et un contrôle de publication cohérent peuvent suffire.

Le signal s’affaiblit si les suites deviennent obsolètes après la comparaison initiale. Un benchmark dépassé peut susciter de la confiance sans refléter le produit actuel.

Pour les développeurs et acheteurs en entreprise, l’action concrète est simple. Identifiez une décision actuellement prise à l’intuition, puis définissez le plus petit test susceptible de la remettre en question.

Cette décision peut concerner Claude face à GPT, mais aussi deux prompts système ou deux stratégies de récupération. La configuration doit refléter ce que les utilisateurs vivent réellement.

Considérez le premier résultat comme une preuve, et non comme un verdict. Examinez les échecs, interrogez l’évaluateur, ajoutez des cas issus du travail réel et répétez les essais lorsque le comportement varie.

La leçon durable de anthropic simon n’est pas qu’un petit outil résout l’évaluation de l’IA. C’est que le choix du modèle, la conception des prompts et le comportement du harnais doivent être testés ensemble.

Quelle décision produit votre équipe prend-elle encore à partir de démos, de classements ou de l’instinct ? Transformez cette incertitude en une suite ciblée, conservez les exécutions et voyez si les preuves changent la réponse.