Résumé Technique : CONTRACTBENCH

Définition du Problème : Contrats d'Observation

Les agents de modèles de langage (LLM) sont de plus en plus déployés pour exécuter des workflows multi-étapes impliquant des API externes. Bien que les benchmarks existants évaluent si les agents peuvent atteindre un état de but final, ils négligent souvent un mode d'échec critique en production : la violation des contrats d'observation.

Un contrat d'observation est défini comme un artefact renvoyé par un outil (par exemple, une URL signée, un paramètre d'état OAuth, un jeton de session ou un webhook protégé par HMAC) qui porte deux contraintes orthogonales imposées par le système externe :

1. Validité Temporelle : L'artefact doit être utilisé dans une fenêtre de temps spécifique (Time-to-Live, TTL) avant qu'il n'expire ou ne devienne obsolète.
2. Intégrité au Niveau Octet : L'artefact doit être relayé octet par octet sans altération. Les piles d'agents réelles introduisent souvent des mutations via le re-codage des URL, le réordonnancement des paramètres, le tronquage ou les retours à la ligne, ce qui invalide les signatures ou les sommes de contrôle.

Les benchmarks actuels échouent à tester conjointement ces contraintes. Ils traitent généralement les sorties des outils comme de simples informations pour la prochaine décision, permettant aux agents de paraphraser ou de perdre des artefacts intermédiaires sans pénalité. En réalité, une seule violation de validité (utilisation d'un jeton expiré) ou d'intégrité (corruption d'une signature) invalide l'ensemble du workflow.

Méthodologie : CONTRACTBENCH

Pour combler cette lacune, les auteurs introduisent CONTRACTBENCH, un benchmark déterministe conçu pour mesurer la conformité aux contrats d'observation.

Conception du Benchmark

• Portée : 33 tâches à double axe dérivées de modèles de contrats API réels, incluant des URLs signées, des flux OAuth, des requêtes signées, des webhooks HMAC et des fenêtres de limitation de débit.
• Évaluation à Double Axe : Les tâches sont catégorisées en quatre quadrants basés sur la pression qu'elles exercent :
  • Q1 (Contrôle) : Faible pression de validité/intégrité (vérifications de bon fonctionnement).
  • Q2 (Validité) : Isole la planification temporelle (par exemple, gérer la maintenance programmée ou les limites de débit).
  • Q3 (Intégrité) : Isole la préservation des octets (par exemple, gérer de longs jetons ou des pièges d'URL).
  • Q4 (Double Axe) : Sollicite les deux axes simultanément, reflétant la prévalence d'artefacts liés au temps et aux signatures en production.
• Environnement d'Exécution : Les tâches s'exécutent sous une horloge virtuelle pour assurer une reproductibilité totale. Un serveur FastAPI émet des étiquettes d'échec déterministes basées sur des spécifications API réelles (par exemple, AWS SigV4, OAuth 2.0, RFC 6585).
• Protocole d'Évaluation :
  • Validateurs Déterministes : Aucun évaluateur humain ni « LLM en tant que juge ». Un validateur programmatique consomme les journaux de requêtes HTTP pour vérifier si chaque observation satisfait à la fois la fenêtre de validité et le prédicat d'intégrité (vérification de hachage SHA-256).
  • Taxonomie des Échecs : Une taxonomie à 15 étiquettes classe les échecs en Validité (par exemple, EXPIRED_BEFORE_USE, RATE_LIMITED), Intégrité (par exemple, MUTATED_TOKEN, SIGNATURE_MISMATCH), et catégories Méta.
  • Solvabilité : Chaque tâche inclut une solution oracle qui passe le validateur, prouvant que la tâche est soluble.

Configuration Expérimentale

Les auteurs ont évalué 38 variantes de modèles parmi 15 familles, incluant des modèles propriétaires de pointe (Claude, série GPT-5, Gemini) et des modèles open-source ajustés par instruction (Qwen, Mistral, Gemma, Llama, DeepSeek). Chaque modèle a été exécuté sur la suite complète de 33 tâches avec $k=3$ déroulements par tâche ($n=99$ épisodes par modèle) à une température de 0.

Résultats Clés

1. Les Modèles de Pointe Échouent aux Contrats d'Observation

Aucun modèle évalué ne dépasse 80 % sur la suite complète. Le meilleur performant, Claude Opus 4.6, atteint 77,8 %. Cela révèle que même les modèles les plus avancés peinent à préserver les artefacts intermédiaires. De plus, le classement sur CONTRACTBENCH ne corrèle pas avec les benchmarks à usage général ; par exemple, Gemini 2.5 Flash et GPT-5.1 sous-performent plusieurs modèles open-source, tandis que Llama-3.3-70B obtient un score proche de 0 %.

2. Falaise de Capacité Émergente chez Qwen 3.5

Une « falaise de capacité » nette est observée au sein de la famille Qwen 3.5. La performance passe de 0 % à 4 milliards de paramètres à 56,6 % à 9 milliards, évoluant de manière fluide jusqu'à 70,7 % à 397B-A17B. En dessous de la falaise, les agents ne parviennent pas à faire preuve de retenue en cours de trajectoire (par exemple, attendre les fenêtres de maintenance) ; au-dessus, ils démontrent une récupération adaptative. Cela suggère que cette capacité est liée à des recettes d'entraînement spécifiques plutôt qu'au seul nombre de paramètres.

3. L'Ajustement Post-Entraînement est Nécessaire mais Fragile

• Nécessité : Les modèles de base (non ajustés par instruction) de toutes les familles obtiennent 0 %, indiquant que la conformité aux contrats est une capacité post-entraînement, et non une propriété émergente pré-entraînement.
• Fragilité (Échelle Inverse) : La famille GPT-5 présente une régression non monotone en forme de « V ». GPT-5.1 montre une baisse significative de conformité (48,5 %) par rapport à GPT-5 (70,7 %) et GPT-5.2 (74,8 %). Cette régression est structurée : GPT-5.1 réintroduit spécifiquement des échecs d'intégrité au niveau octet (par exemple, WRONG_VALUE, MUTATED_TOKEN), suggérant que les mises à jour post-entraînement visant l'utilité conversationnelle peuvent éroder les inhibitions spécifiques requises pour la conformité aux contrats (par exemple, attendre avant de réessayer, préserver les octets exactement).

4. Signaux de Récompense Actionnables

Les auteurs ont testé si les étiquettes d'échec pouvaient servir de signaux de récompense en contexte. En utilisant 42 échecs de GPT-5.1, ils ont constaté que fournir l'étiquette d'échec correcte comme indice de coaching améliorait les taux de réussite de +7,1 points de pourcentage par rapport à un indice d'étiquette erronée. Cela indique que la taxonomie fournit des signaux directionnels et actionnables pour la correction au moment du test, en particulier pour les échecs de type intégrité, tandis que les échecs temporels nécessitent souvent des interventions architecturales (par exemple, des TTL lisibles par machine) plutôt que de simples incitations.

Importance et Contributions

L'article revendique trois contributions principales :

1. Formalisation des Contrats d'Observation : Les auteurs définissent les contrats d'observation comme une classe distincte d'échec d'agent régie par des contraintes temporelles et d'intégrité orthogonales, formalisant un problème précédemment négligé dans la littérature sur l'évaluation des agents.
2. Benchmark CONTRACTBENCH : Ils fournissent le premier benchmark déterministe et programmatique pour cette capacité, comprenant 33 tâches, une taxonomie d'échec à 15 étiquettes et un modèle d'exécution à horloge virtuelle qui élimine l'ambiguïté des juges humains ou LLM.
3. Insights Empiriques sur la Robustesse des Agents : L'étude révèle que la conformité aux contrats est une capacité émergente et non monotone, qui n'est ni garantie par la capacité générale d'utilisation d'outils ni constamment améliorée par la mise à l'échelle. Elle met en évidence que l'ajustement post-entraînement « utile » peut régresser des inhibitions spécifiques requises pour une interaction API fiable, et que les modèles de pointe actuels restent non résolus sur cette métrique critique de fiabilité.

Les auteurs concluent que les contrats d'observation doivent devenir une cible d'évaluation de premier ordre pour garantir que les agents peuvent agir de manière fiable sous les contraintes inter-étapes imposées par les systèmes externes réels. Ils suggèrent que la mitigation de ces échecs pourrait nécessiter des changements architecturaux (par exemple, stockage d'artefacts basé sur des identifiants) plutôt que de compter uniquement sur des modèles plus grands ou mieux ajustés.