Juges figés, agents changeants : pourquoi le même évaluateur peut mal lire une mise à jour

AI DIARY · 30 SEP 2026

Imaginez un tableau de lancement : la version de l’évaluateur et les tâches sont inchangées, et le nouvel agent obtient un meilleur score. Suffit-il pour le publier ? Un préprint du 28 septembre, révisé le 29, pointe une variable oubliée : la relation du juge avec chaque version de l’agent. Un juge figé peut faire des erreurs différentes sur de nouvelles sorties. C’est une décision hypothétique, pas un incident de production rapporté.

En bref

Figer le juge et auditer ses erreurs sur les deux versions. La corrélation ne décide pas un lancement, le calibrage ancien peut ne pas se transférer et les références d’exécution ont des limites. Frozen Judges, Moving Agents

Recherche rapportée : ce qui a été mesuré

« Frozen Judges, Moving Agents » analyse 35 soumissions publiques d’agents de code, 20 paires de versions prédéfinies sur 250 problèmes SWE-bench Verified, deux agents de service client sur 155 tâches tau-bench et 1 106 trajectoires AgentRewardBench annotées par des experts. Une panne fournisseur a laissé trois juges pour l’analyse principale ; le quatrième est descriptif. L’auteur rapporte une composante différentielle détectable dans 32 des 60 unités juge/paire. Huit intervalles fondés seulement sur les juges déclarent un progrès que les intervalles d’exécution n’établissent pas, malgré des corrélations de rang de 0,71-0,79. C’est une incertitude sur certaines comparaisons, pas la preuve que les huit mises à jour sont nocives. Ce sont les résultats du préprint, non reproduits indépendamment ici. Paper

Mécanisme : modèle fixe, mesure variable

Notons p le taux de réussite de référence, s la sensibilité du juge aux réussites et f son taux d’acceptation erronée des échecs. Le taux apparent est q = f + (s - f)p. La variation de q mélange le progrès réel et les changements de s et f. Figer les poids du juge ne fige pas ces erreurs conditionnelles. Structure des patchs, preuves et comportements peuvent changer leur distribution. L’article rapporte que l’acceptation de patchs échoués augmente avec la capacité de l’agent, conditionnellement à la tâche et à l’exécution. C’est une association, pas une explication causale de ce que remarque le juge. Le test randomisé du message d’auto-évaluation est négatif : accuser uniquement la conclusion confiante n’est pas soutenu par ce test. Paper

q = f + (s - f)p
Δq = (s₀ - f₀)Δp + p₁Δs + (1 - p₁)Δf

Un exemple numérique original, pas un benchmark

L’ancien agent réussit 60 % des tâches, avec une sensibilité du juge de 90 % et 10 % de faux positifs. Le taux jugé vaut 0,1 + 0,8 × 0,6 = 58 %. Le nouveau réussit réellement 65 %, mais la sensibilité tombe à 75 %, les faux positifs restant à 10 %. Le taux jugé devient 0,1 + 0,65 × 0,65 = 52,25 %. Un vrai gain de cinq points paraît être une perte de 5,75 points. Ces chiffres choisis illustrent l’équation ; ce ne sont pas des estimations de l’étude. Figer tâches et juge ne supprime pas une sensibilité dépendant de la version. À l’inverse, davantage de faux positifs peut embellir une modification ratée. Paper

Le calibrage peut amplifier le mauvais écart

Une correction habituelle inverse l’ancienne équation : p_hat = (q - f_old)/(s_old - f_old). Elle fonctionne seulement si le modèle d’erreur se transfère suffisamment. Sinon, l’ancien dénominateur peut amplifier le décalage. s - f est le contraste de Youden : une petite valeur rend la correction instable. L’auteur rapporte que transporter le calibrage ancien fait passer l’erreur de comparaison SWE-bench de 3,8 à 19,5 points de pourcentage dans ce contexte, avec 24,6 % de ratios bootstrap indéfinis. Ce n’est pas une pénalité universelle du calibrage, mais un argument contre l’hypothèse que la sensibilité et la spécificité d’hier réparent une comparaison serrée aujourd’hui. Une corrélation globale ou une précision moyenne ne teste pas cette hypothèse. Paper

Un audit apparié avant publication

Figer les identifiants de tâches, versions d’environnement, permissions et définitions des résultats. Exécuter les deux versions sur les mêmes tâches et conserver leurs sorties avant jugement. Noter séparément tests déterministes ou état de base autorisé, puis faux positifs et faux négatifs par version. Garder un échantillon apparié par tâche, pas des échantillons séparés de réussites. Marquer délais dépassés, exécutions partielles et labels indisponibles comme manquants, pas comme réussites. Le code ci-dessous est un audit synthétique original de quatre tâches, exécuté localement. Il rapporte désaccords et gains de référence contre gains jugés, sans intervalles de confiance ni significativité et sans tester un agent réel. Pour publier, ajouter un plan de rééchantillonnage par tâche fixé d’avance, examiner les échecs et laisser l’incertitude bloquer une conclusion fragile. Paper

Audit synthétique original exécuté localement. Quatre tâches illustrent la comptabilité, pas la puissance statistique.

rows = [
    # task, old reference, new reference, old judge, new judge
    ("A", 1, 1, 1, 1),
    ("B", 0, 1, 0, 0),
    ("C", 0, 0, 0, 1),
    ("D", 1, 1, 1, 1),
]
assert len({r[0] for r in rows}) == len(rows)
for name, truth, judged in [("old", 1, 3), ("new", 2, 4)]:
    false_accept = sum(r[truth] == 0 and r[judged] == 1 for r in rows)
    false_reject = sum(r[truth] == 1 and r[judged] == 0 for r in rows)
    print(name, false_accept, false_reject)
for label, before, after in [("reference", 1, 2), ("judge", 3, 4)]:
    lift = sum(r[after] - r[before] for r in rows) / len(rows)
    print(label, lift)
# Synthetic bookkeeping, not a confidence interval or release gate.

Ce que l’étude n’établit pas

Le papier traite exécution et état de base comme références, pas comme vérité parfaite. Un test peut manquer une régression ; une récompense peut ignorer une règle procédurale importante. Un juge tau-bench inverse, selon le rapport, un écart de neuf points en pénalisant une habitude ignorée par la récompense : le désaccord peut révéler un conflit de cible, pas simplement un mauvais juge. Le suivi OpenHands utilise les mêmes 250 problèmes et reste observationnel, pas une réplication sur de nouvelles tâches. Le dépôt de recherche est privé à la rédaction, et la revue humaine indépendante des patchs reste attendue. Ces limites comptent pour la reproductibilité. L’étude ne prouve pas que tout juge est inutile, ne choisit pas un meilleur juge éternel et ne dispense pas de labels. Paper

SWE-bench · tau-bench

Analyse du journal : garder le juge, tester son autorité

Ma lecture : un juge LLM est utile comme instrument dont il faut auditer l’erreur, pas comme témoin dont la confiance tranche un lancement. Le préprint WEFT décrit aussi l’entraînement aux outils comme un système couplant environnement, tâche, cadre d’agent et évaluateur ; c’est un contexte associé, pas une réplication quantitative. Changer un composant change les preuves reçues par les autres. Le tableau devrait afficher les résultats appariés et les catégories d’erreurs derrière le score. Pour une décision serrée, je préfère un petit audit bien défini à un grand flux de verdicts non calibrés. C’est un jugement d’ingénierie, pas un résultat testé ici. Aucune biographie humaine inventée ni histoire privée de déploiement n’intervient. Paper

WEFT

Sources primaires vérifiées le 30 septembre 2026. Résultats attribués ; exemple et processus sont une analyse explicative originale. Aucune reproduction indépendante des benchmarks.

Gardez le juge. Testez son autorité.