VERSE : un optimiseur qui teste ses propres modifications avant de les soumettre

Ce que l’article affirme

Deux rôles. L’exécutant est un modèle gelé qui tente des tâches de code dans un harnais. L’optimiseur lit les trajectoires échouées et modifie le harnais de l’exécutant sur plusieurs tours. Les systèmes précédents gardent l’optimiseur fixe. VERSE lui laisse réviser ses propres prompts, compétences, outils, hooks et notes, tandis que les poids des deux modèles restent gelés.

La première étude est la plus intéressante. Avec un optimiseur Qwen3.8-Flash-Next et un exécutant Qwen3.8-27B, ajouter l’auto-évolution à Meta-Harness a dégradé le résultat : aucun tour n’a battu le harnais initial en validation. Selon les auteurs, l’optimiseur s’écrivait des leçons non testées et ne pouvait pas savoir lesquelles étaient fausses. Avec un outil pour exécuter un brouillon sur une tâche d’entraînement, le même montage a atteint 41,05 % de précision au test, le meilleur chiffre de ce tableau.

Comment fonctionne VERSE

Avant de soumettre une modification, l’optimiseur peut rejouer un échec, réduire une trajectoire ratée aux quelques étapes qui comptent et perturber une étape suspecte pour voir si le résultat change. Entre les tours, il tient un registre : tâches corrigées, tâches régressées, corrections annulées ensuite. Dans une seconde étude avec cinq exécutants, l’optimiseur auto-évolutif a construit 51 artefacts, de quatre sortes : attribution des causes d’échec, vérification, audit d’entraînement et règles de flux de travail, comme des rappels de budget.

Esquisse de la boucle

# Illustration of verify-before-submit. Not the authors' code and not run.
def improve_harness(harness, failures, budget):
    for round_no in range(budget):
        cause = rank_causes(failures)            # attribution
        draft = edit(harness, cause)
        passed_before = [t for t in tasks if run(harness, t)]
        ok_target = run(draft, cause.task)       # replay the failure
        ok_old = all(run(draft, t) for t in passed_before[:5])  # regressions
        if ok_target and ok_old:
            return draft
    return harness

Les chiffres

Le résumé de l’article tient : VERSE avec auto-évolution bat sa propre référence dans les 16 comparaisons du tableau, de 0,6 à 10,3 points. Une lecture attentive ajoute une réserve. Sur quatre hôtes, le meilleur harnais dans la distribution vient de VERSE sans auto-évolution pour trois d’entre eux, et le meilleur hors distribution vient de la version auto-évolutive pour deux. Les outils de vérification font donc l’essentiel du travail dans la distribution, et l’argument pour l’auto-évolution repose surtout sur les tâches récentes et multilingues.

Là où les preuves sont minces

Chaque ligne est une seule exécution d’évolution. Les barres d’erreur sont l’écart sur trois évaluations de test de cette exécution, pas sur des exécutions indépendantes. Le test dans la distribution compte 108 tâches : une tâche vaut environ 0,9 point, et plusieurs écarts du tableau représentent deux ou trois tâches. Toutes les tâches d’entraînement et de validation sont en Python ; sur les 107 tâches hors distribution, plus récentes, 87 sont en Go, Java, Rust ou TypeScript. Les auteurs précisent aussi que les outils de vérification sont fixes, que chaque action est journalisée et que l’exécutant n’a pas de réseau. Cela borne l’auto-modification chez eux, et c’est la partie qu’un praticien devrait reconstruire.

Qui doit s’y intéresser

Les équipes qui règlent un harnais d’agent à la main ou avec un optimiseur. La leçon pratique survit aux réserves : donnez à un éditeur automatique le moyen d’exécuter sa modification et de vérifier que les tâches déjà réussies passent encore, avant de la garder. L’article note que l’optimiseur fixe ne testait souvent que des tâches que le harnais actuel rate, ce qui ne peut pas révéler une régression.