Faire grandir le harnais, pas le contexte : les échecs deviennent du code
Une prépublication du 24 septembre teste le remplacement de décisions répétées du modèle par du code. Les gains sont prometteurs, sans garantie de sécurité.
RESEARCH DIARY · 26 SEP 2026
Imaginez un agent de navigation qui s'arrête après chaque clic pour poser au modèle la même question ennuyeuse : relancer la recherche, filtrer ces résultats ou quitter une page cassée ? Posée des centaines de fois, elle gonfle le prompt et brûle des jetons sur une décision qui ne change pas. Un nouveau preprint propose de déplacer ce jugement répétitif dans du code que le harnais écrit lui-même. Dans ses tests, l'astuce marche, avec des limites qui méritent une lecture attentive.
Faits rapportés
- Ce que mesure l’article: Deux benchmarks, trois tailles de modèle et bien moins d'appels au modèle que la référence. Ce sont les chiffres des auteurs.
- La barrière teste 50 tâches mises de côté et ne peut pas certifier le web ouvert. La fragilité du code réparé et le surapprentissage restent des questions ouvertes.
Comment le harnais se développe
Le cadre initial fixe les interfaces du modèle et des outils sans stratégie de résolution. Les traces d’exécution localisent l’échec à une fonction ; un optimiseur répare ensemble une fenêtre bornée d’échecs. Un test sur des tâches mises de côté vérifie les capacités précédentes ; si elles régressent, le code et l’état de formation reviennent au point de contrôle. Le modèle garde le raisonnement propre à chaque tâche.
Exemple explicatif, pas résultat reproduit
Imaginons un agent qui ouvre des résultats, élimine les pages sans preuve et relance la recherche. Une fonction pourrait fixer l’ordre du filtrage et des essais. C’est une illustration, pas une fonction précise démontrée dans l’article. Les instructions sur une page externe restent des données non fiables.
Ce que mesure l’article
Sur BrowseComp-Plus et WebArena-Verified, les auteurs utilisent pour chacun 200 tâches d’entraînement, 50 tâches de validation et 50 finales, avec trois modèles de 4B à 120B. Ils rapportent la meilleure réussite moyenne dans cinq des six configurations, 76.0–91.8 % d’appels modèle en moins et 74.4–98.6 % de coût d’inférence en moins que leur base Tool-Calling. Sur WebArena-Verified, ils obtiennent 44.7–45.3 % selon le modèle contre 6.7 % pour Tool-Calling avec 4B. Ce sont leurs mesures, non un audit indépendant en production.
Analyse et limites
La validation protège les résultats de ses 50 tâches, pas tous les sites ni les permissions. Le code réparé peut être fragile ou surajusté. Les coûts dépendent du calcul et des comparateurs choisis. L’ablation unique (36 % pour la méthode complète contre 18 %, 22 % et 28 %) éclaire le mécanisme sans démontrer sa sûreté.
Ce qu’il faut retenir
Séparer le contrôle récurrent du jugement propre à la tâche. Garder un code versionné, une petite surface de modification, un test de régression et un retour arrière complet. L’autorité pour agir au nom d’une personne doit être vérifiée hors du contrôleur appris.
# Pseudo-code explicatif, pas une implémentation du papier
if gate_success(candidate) < gate_success(checkpoint):
restore(checkpoint)
else:
checkpoint = candidateGrowing Harness preprint · Full method and results. Version 2 posted 24 Sep 2026; author results, not independently replicated.