VERSE: оптимизатор, который проверяет свои правки, прежде чем их отправить

Что утверждает статья

Ролей две. Исполнитель - замороженная модель, которая решает задачи по коду внутри харнесса. Оптимизатор читает неудачные траектории и несколько раундов правит харнесс исполнителя. Прежние системы держат оптимизатор неизменным. VERSE позволяет ему менять собственные промпты, навыки, инструменты, хуки и заметки, а веса обеих моделей остаются замороженными.

Интереснее всего первое исследование. С оптимизатором Qwen3.8-Flash-Next и исполнителем Qwen3.8-27B добавление самоэволюции в Meta-Harness ухудшило результат: ни один раунд не обошёл исходный харнесс на валидации. По мнению авторов, оптимизатор записывал в себя непроверенные уроки и не мог понять, какие из них неверны. Дайте ему инструмент для запуска черновика на одной обучающей задаче, и та же схема дала 41,05% точности на тесте - лучшее значение в этой таблице.

Как устроен VERSE

Перед отправкой правки оптимизатор может воспроизвести провал, сократить неудачную траекторию до нескольких важных шагов и возмутить подозрительный шаг, чтобы увидеть, изменится ли исход. Между раундами он ведёт журнал: какие задачи починены, какие сломались, какие исправления потом отменены. Во втором исследовании на пяти исполнителях самоэволюционирующий оптимизатор создал 51 артефакт, и они делятся на четыре вида: определение причин сбоев, проверка, аудит обучения и правила рабочего процесса, например напоминания о бюджете.

Набросок цикла

# 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

Цифры

Вывод статьи подтверждается: VERSE с самоэволюцией обходит свою же базу во всех 16 сравнениях таблицы, на 0,6–10,3 пункта. При внимательном чтении таблицы есть оговорка. Из четырёх хостов лучший харнесс внутри распределения на трёх даёт VERSE без самоэволюции, а лучший вне распределения у самоэволюционирующей версии на двух. Значит, основную работу внутри распределения делают инструменты проверки, а довод в пользу самоэволюции держится в основном на новых многоязычных задачах.

Где доказательств мало

Каждая строка - один эволюционный прогон. Погрешности - разброс по трём тестовым оценкам этого прогона, а не по независимым прогонам. В тесте внутри распределения 108 задач, так что одна задача - около 0,9 пункта, а некоторые разрывы в таблице - две-три задачи. Все обучающие и валидационные задачи на Python, а из 107 новых задач вне распределения 87 на Go, Java, Rust или TypeScript. Авторы также указывают, что инструменты проверки зафиксированы, все действия записываются, а исполнитель работает без сети. Это ограничивает самоизменение в их постановке, и именно эту часть практику пришлось бы воссоздавать.

Кому это важно

Командам, которые настраивают харнесс агента вручную или оптимизатором. Практический урок переживает все оговорки: дайте автоматическому редактору возможность запустить правку и проверить, что уже проходившие задачи проходят, прежде чем оставлять изменение. Авторы отмечают, что неизменный оптимизатор часто проверял только задачи, на которых текущий харнесс падает, а так регрессию не увидеть.