Последняя версия часто хуже лучшей
Цикл самоулучшения выглядит логично: агент находит ошибку, меняет данные или инструкции, запускает обучение, измеряет результат и начинает следующую итерацию. В отчет обычно попадает последняя версия. Это удобно для автоматизации и опасно для качества, потому что улучшение не обязано быть монотонным.
RSIBench-Data заставляет агентов пройти полный цикл работы с данными: поставить диагноз, предложить обучающие примеры, получить новую версию модели, провести оценку и решить, что менять дальше. Только 58,33% проверенных конфигураций смогли превзойти свою первую корректную попытку.
Еще показательнее продолжение после достижения максимума. Среди запусков, которые не остановились на лучшем результате, 78,26% завершились версией хуже собственного пика. Остальные лишь вернулись к прежнему максимуму. Убедительное объяснение новой стратегии не предсказывало улучшение.
Если система сохраняет только последнюю итерацию, она выбрасывает уже найденное рабочее решение. Минимальная защита проста: лучший подтвержденный результат хранится отдельно и не перезаписывается новым кандидатом.
Ошибка передается следующим поколениям навыка
Похожая проблема возникает, когда агент накапливает инструкции в SKILL.md. Новое правило может помочь на одном случае, занять место в контексте, конфликтовать со старым правилом и повредить десятки последующих задач.
VaG изучает длительную эволюцию таких навыков. Авторы обнаружили выраженную деградацию после пикового результата. Дефектное правило становилось родителем для новых изменений и загрязняло следующие поколения. Простое удаление первоначальной ошибки позже возвращало лишь небольшую часть потерянного качества, потому что зависимые правила уже успели закрепиться.
В ответ VaG использует несколько критиков и оценивает предельную пользу каждого изменения. На Terminal-Bench 2 система достигла 72% успешности с каталогом примерно в пять раз меньше исходного варианта. Авторы также проверили перенос на четыре базовые модели и второй набор задач.
Это авторские результаты свежей работы. Они не доказывают, что три критика являются универсальным рецептом. Зато показывают механизм накопления долга: навык хранит не только полезный опыт, но и историю ошибочных объяснений.
Большая часть файла может ничего не давать
Удалить все сомнительное тоже нельзя. Блоки SKILL.md зависят друг от друга: пример использует определение выше, а команда опирается на описанное ограничение. Наивная проверка "удалим один абзац" может сломать связь и приписать этому абзацу чужую ценность.
SkillSV разбивает навык на правила, примеры, сценарии и эвристики, сохраняя зависимости. Затем множество проверяемых запусков оценивает пользу блока, стоимость занимаемого контекста и эффект корректного удаления вместе с зависимыми частями.
После одного прохода уточнения навыки сохранили в среднем 69% исходных токенов без статистически значимого падения на четырех наборах задач. В отдельных случаях оставалось 42-57% текста. Верхние 10% блоков обеспечивали от 21% до 100% измеренной ценности.
Метод дорогой: для каждого крупного файла нужны повторные выполнения на контрольных задачах. Но он проверяет именно то, что обычно принимают на веру. Рост файла не равен росту способности агента.
Контрольная выборка должна переживать цикл
Самоулучшающийся контур легко подгоняется под собственную оценку. Если агент видит все задачи и подробные причины провала, он может выучить частные обходы. Поэтому контрольная выборка должна быть скрыта от автора изменений. Ее нельзя использовать для выбора следующей стратегии, только для решения о принятии кандидата.
Полезно разделить три набора. На рабочих примерах агент ищет ошибки и строит изменения. На проверочном наборе он выбирает между вариантами. Отдельный закрытый набор решает, можно ли заменить лучшую версию. Новые задачи регулярно добавляются из реальных отказов, но старые критичные случаи не исчезают.
Принимать изменение нужно по нескольким условиям. Средний результат должен вырасти сильнее статистического шума. Ни один критичный класс не должен заметно просесть. Запрещенные действия и стоимость выполнения проверяются отдельно. Если кандидат быстрее решает простые задачи ценой опасного поведения на редкой ветке, это не улучшение.
Полезно хранить не один общий максимум, а таблицу лучших результатов по важным срезам. Версия, сильная в научном коде, может проигрывать в работе с терминалом. Новый кандидат заменяет основную версию только при заранее заданном правиле компромисса. Иначе улучшение среднего скрывает перенос ошибок между группами задач. Для каждой сохраненной версии нужны сами артефакты, результаты отдельных примеров и точная конфигурация оценки. Повторный запуск через месяц должен объяснить расхождение, а не создать еще одну несопоставимую строку.
Правило остановки важнее еще одной идеи
Автономный исследователь всегда способен предложить следующую гипотезу. Это не означает, что ее выгодно проверять. После нескольких итераций без подтвержденного прироста цикл должен остановиться или сменить тип вмешательства: вместо новых данных проверить разметку, среду, оценку или программный контур.
Каждая итерация хранит происхождение данных, код обучения, случайные начальные значения, метрики и ссылку на родителя. Лучший вариант остается доступным для немедленного отката. Последняя версия существует как кандидат, а не как победитель по умолчанию.
Самоулучшение без памяти о лучшем результате оптимизирует движение, а не качество. Система продолжает производить версии даже после того, как перестала становиться лучше.
В такой системе остановка является результатом исследования, а не признаком того, что агенту не хватило очередной идеи.