Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Самосовершенствующуюся LLM-систему научили завершать цикл, когда новые правки уже не дают устойчивой пользы, и возвращать более раннюю версию вместо последней. В экспериментах расход токенов снизился на 48,4–91,6% при сопоставимом качестве на новых тестовых примерах; работа не рецензирована, и числа получили сами авторы. Для команд с фиксированным бюджетом итераций это превращает остановку из ручной настройки в отдельный статистический компонент.
Остановка и выбор версии требуют разных решений
Самосовершенствующаяся система по кругу меняет сохраняемый объект: инструкцию, документ с навыками или программу. На каждом шаге она создаёт кандидата, сравнивает его с текущей версией на проверочном наборе и принимает, если результат стал лучше.
Обычно такой цикл работает до заранее заданного числа шагов или пока не закончится вычислительный бюджет. После насыщения система продолжает тратить токены, а многократная подстройка под один проверочный сигнал повышает риск переоптимизации: поздняя версия лучше проходит знакомую проверку, но хуже работает на новых данных.
Остановить цикл при первом неудачном кандидате нельзя. Слабое предложение может оказаться случайностью, а следующий шаг снова даст прирост. Авторы поэтому сравнивают кандидата и текущую версию по каждому заданию, а не только по общей точности, и последовательно накапливают свидетельства того, что ожидаемый прирост опустился ниже полезного порога.
Новый процесс накопления свидетельств запускается на каждом раунде. Это не даёт сильным ранним улучшениям скрыть последующее плато: процесс, начатый после перехода, быстрее замечает серию бесполезных предложений. Порог остановки задаёт команда — вместе с минимальным приростом, ради которого имеет смысл оплачивать ещё одну итерацию.
Сигнал остановки отвечает только на вопрос, когда завершить вычисления. Для выбора результата метод ищет, какой из перезапущенных процессов накопил больше всего свидетельств, оценивает момент перехода к слабым улучшениям и возвращает версию непосредственно перед ним. Поэтому система может остановиться позднее, чем находилась лучшая версия: дополнительные шаги нужны, чтобы убедиться в насыщении, но их результат не обязан попасть в продукт.
Метод проверили на двух системах эволюции, трёх семействах моделей и пяти наборах задач, включая ответы на вопросы, математику и работу с таблицами. Он предполагает фиксированный проверочный набор, попарные результаты по отдельным заданиям и оценку через правильный или неправильный ответ; теоретические гарантии также опираются на независимость этих результатов и устойчивый переход к режиму слабых улучшений.
На SearchQA последняя версия оказалась не нужна
В связке SkillOpt и DeepSeek V4 Flash на SearchQA детектор подал сигнал после 4-го раунда при полном бюджете в 40 раундов, но выбрал артефакт 1-го раунда. Его точность на новых тестовых примерах составила 82,43% против 82,00% у результата полного цикла. Разница находилась в пределах погрешности.
На других проверенных сочетаниях момент остановки менялся вместе с моделью и задачей. Это отличает метод от сокращённого фиксированного бюджета: он не предписывает всем запускам завершаться на одном шаге, а ждёт свидетельств насыщения в конкретной траектории.
Процедура не распознаёт переоптимизацию или эксплуатацию ошибки в оценке напрямую. Она останавливает цикл, когда предложения перестают давать устойчивый полезный прирост, а выбор более ранней версии снижает вероятность вернуть позднее ухудшение как побочный эффект.
Фиксированный бюджет можно оставить как верхнюю границу
Работа меняет планы команд, которые уже сохраняют результаты кандидата и текущей версии по каждому проверочному примеру. В таком контуре детектор можно поставить рядом с существующей проверкой кандидатов: менять генератор инструкций, навыков или программ не требуется.
Фиксированный бюджет при этом не исчезает. Он остаётся верхней границей расходов и резервным условием завершения, если детектор не накопил достаточно свидетельств. Основным результатом запуска становится не последняя принятая версия, а выбранный снимок состояния до предполагаемого насыщения.
В рабочем контуре придётся явно определить, какой прирост оправдывает ещё один раунд, и насколько консервативно система должна избегать преждевременной остановки. Эти параметры выражают продуктовый компромисс: дорогой цикл с небольшим ожидаемым выигрышем следует останавливать раньше, а для критичной задачи можно потребовать больше свидетельств.
Если система хранит только общий балл, использует свободную оценку модели-оценщика или меняет проверочный набор между раундами, текущую процедуру нельзя перенести без адаптации. Практический первый шаг — сохранять попарные результаты кандидата и действующей версии по каждому примеру, не смешивая их с обучающими данными.
Эксперименты показывают эффект на ограниченном наборе систем, моделей и задач, а не универсальное правило для любого агента. Однако архитектурное разделение уже полезно: генератор предлагает изменения, проверка решает, принять ли отдельного кандидата, детектор завершает весь цикл, а механизм выбора определяет, какую из сохранённых версий выпускать.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
