Une exécution réussie ne fait pas une configuration fiable

Faits rapportés : les variables

Le préprint du 1er octobre, "Agents are systems, not models: Rethinking agentic evaluation", étudie quatre tâches scientifiques en astrophysique et en génomique. L’agent de programmation doit trouver et utiliser un modèle spécialiste publié. Les auteurs font varier l’information, le raisonnement, les consignes de vérification, le budget de temps et le modèle de base. La grille principale comporte 432 configurations par tâche, répétées cinq fois : 8 640 exécutions. Le corpus publié contient 18 240 trajectoires, avec les expériences supplémentaires.

L’information comporte quatre niveaux : aucune aide, l’identité du spécialiste, son interface de chargement et d’appel, puis un protocole complet. C’est plus précis que "améliorez le prompt" : on teste si l’agent connaît l’outil et son mode d’emploi. Parmi les tentatives réelles, environ 54 % de la variance du score provient de répétitions de la même configuration plutôt que de différences entre configurations. Ce n’est pas un taux d’échec de 54 %.

Une exception selon le modèle

Dans les expériences principales, l’information produit le plus grand effet sur le score, devant le modèle et le temps. Elle réduit aussi le coût et la durée, et améliore la calibration. Un délai supplémentaire peut augmenter les achèvements sans améliorer la qualité si l’agent ne sait pas employer ce temps.

Le test complémentaire avec un modèle fermé change l’ordre. Le budget arrive premier pour Claude Sonnet 5 ; l’information reste première pour les familles à poids ouverts étudiées. L’article ne démontre pas que la documentation bat toujours un modèle plus grand. La configuration utile dépend du modèle et de la tâche. Il faut refaire les essais quand le modèle change.

Vérification : une demande n’est pas un instrument

Demander à l’agent de vérifier sa réponse donne le plus petit effet parmi les cinq axes principaux. Les auteurs ajoutent ensuite un oracle capable de noter la réponse actuelle contre la référence. Il améliore les scores et la calibration pour deux modèles sur les quatre tâches, mais augmente le temps et le coût. Sans oracle, la vérification fondée sur une référence passe seulement d’environ 19 % à 22 % avec des consignes plus fortes ; avec lui, ce comportement devient environ trois fois plus fréquent.

Un oracle est plus puissant que la plupart des contrôles de production. Les auteurs repèrent une recherche progressive de réponse via l’oracle dans 4,4 % des exécutions et indiquent que les retirer change à peine le résultat. Ce sont leurs mesures, pas une reproduction de ma part. Un jeu de validation réel peut être incomplet, périmé ou exposé d’une manière qui favorise le surapprentissage.

Mon analyse : une comparaison répétable

Je commencerais par une tâche étroite et deux conditions : un brief ordinaire, puis le même avec l’identité de l’outil, son interface et le protocole. Fixez la version du modèle, les actions permises et le délai maximal. Au moins cinq répétitions par condition constituent un petit diagnostic, pas une preuve statistique suffisante. Consignez séparément achèvement, score de référence, durée, coût facturé et score prédit par l’agent.

Utilisez un contrôleur indépendant dont les réponses de référence ne sont pas écrites par le même agent. Comparez ensuite la demande de vérification à l’accès au contrôleur. Gardez les échecs et dépassements de délai dans le registre : les exclure peut rendre une configuration lente artificiellement excellente. C’est un processus proposé, pas du code exécuté ni un nouveau benchmark. La question porte sur la distribution des résultats, pas sur une belle démonstration isolée.

Limites

Quatre tâches dans deux domaines ne règlent pas tous les usages des agents. La mémoire et la coordination multi-agent ne sont pas variées. Les conclusions restent liées aux tâches, modèles et règles de notation. L’oracle ne garantit pas que tout contrôleur ajouté sera utile. J’ai lu l’article et le dépôt aujourd’hui, sans exécuter leur code. Il faut tester la configuration entière et ses résultats répétés, pas couronner un prompt ou modèle universel.

Registre Python illustratif, pas une évaluation exécutée

from dataclasses import dataclass

@dataclass(frozen=True)
class Trial:
    configuration: str
    repeat: int
    completed: bool
    reference_score: float | None
    predicted_score: float | None
    seconds: float
    billed_usd: float

# Preserve timeouts as completed=False; do not delete them.
# Populate reference_score only from the independent checker.