Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
EvoAlloc научился по ходу эволюции программ решать, каким кандидатам стоит выделить вычисления, а какие лучше пропустить. В препринте, который не прошёл рецензирование и приводит замеры самих авторов, система достигла результатов базового метода с 59–82% меньшим числом полных оценок. Для команд, которые автоматически улучшают код через генерацию и тестирование вариантов, распределитель вычислений становится отдельной частью поискового алгоритма, а не заранее заданным фильтром.
Как распределитель учится на собственных решениях
При эволюции программ LLM предлагает изменение, система запускает получившийся код и добавляет удачные варианты в архив. Полная оценка может требовать прогонов по множеству задач, случайных начальных условий или цепочек вызовов других моделей. Если проверить слабого кандидата, вычисления пропадут; если отбросить сильного, он не попадёт в архив и не станет основой для следующих вариантов.
Обычные методы решают эту задачу по правилу, заданному до начала поиска. EvoAlloc хранит явную стратегию на естественном языке и меняет её по накопленным результатам. При каждом решении распределитель видит предложенное изменение, качество родительской программы, лучший текущий результат, остаток бюджета и результаты уже проверенных родственных кандидатов.
Стратегия разрешает отправить программу на полную оценку, отбросить её или сначала запросить более дешёвую промежуточную проверку. В начале запуска все кандидаты проходят полную оценку, чтобы система собрала первые примеры. Затем она сводит удачные и неудачные решения в повторно используемый опыт и предлагает новую версию правил.
Новая стратегия не заменяет старую только потому, что LLM сочла её убедительной. Обе версии применяют к кандидатам, на которых они расходятся, и открывают нужные им результаты проверок. Система сначала выбирает вариант, который реже пропускает нового лидера, затем учитывает число полных и промежуточных оценок.
У такого обучения есть слепая зона: после отказа от проверки истинное качество программы остаётся неизвестным. Поэтому EvoAlloc иногда полностью оценивает отброшенного кандидата. Если он оказался сильным, стратегия получает пример собственной ошибки, а программа возвращается в поиск и может стать родителем следующих вариантов.
Сэкономленные оценки превращаются в дополнительные попытки
EvoAlloc сравнили с ShinkaEvolve в общей поисковой системе: генератор программ, оценщики и остальные механизмы не менялись. Эксперименты охватили ADAS-AIME, где улучшается обвязка агента для решения математических задач, и Circle Packing, где поиск оптимизирует исполняемую программу. Результаты усредняли по нескольким независимым запускам.
Чтобы достичь итогового качества ShinkaEvolve, EvoAlloc потребовалось на 59–82% меньше полных оценок. Совокупный расход токенов LLM сократился на 61–89%; в него входили не только предложения программ, но и работа распределителя, обновление стратегии и её проверка. Значит, служебные вызовы модели не съели экономию от отбора кандидатов.
При одинаковом бюджете полных оценок итоговая метрика выросла примерно на десятую часть. Причина не сводится к ранней остановке слабых вариантов: освободившийся бюджет позволяет рассмотреть больше предложений, расширить дерево поиска и получить новые линии потомков.
Стратегия при этом менялась вместе с поиском. На раннем этапе она чаще собирала промежуточные свидетельства, когда поведение кандидатов ещё трудно предсказать. Позже улучшения стали встречаться реже, и распределитель начал чаще отбрасывать предложения без дорогого прогона.
Когда подход меняет архитектуру поисковой системы
Работа даёт практический ориентир системам, где оценка кандидата сопоставима по стоимости с его генерацией или дороже неё. В такой архитектуре стоит отделить распределение бюджета от генератора и хранить для каждого решения контекст поиска, выбранное действие, промежуточные результаты и итог полной проверки. Без этой истории распределитель не сможет пересматривать критерии на основании последствий.
Проверку отброшенных вариантов тоже следует учитывать в бюджете заранее. Если фильтр никогда не видит собственные ошибки, он может закрепить неверное правило и систематически закрыть целую ветвь поиска. EvoAlloc показывает способ избежать этого: расходовать небольшую часть вычислений на кандидатов, которым текущая стратегия отказала.
Результат пока относится к двум задачам внутри одного программного каркаса. Опыт накапливался в пределах отдельного запуска, а генератор, оценщики и механизм обновления оставались фиксированными. Поэтому работа не доказывает, что тот же распределитель даст такую же экономию в поиске архитектур, настройке промышленных агентов или задачах с быстрыми тестами.
Менять весь контур эволюции программ ради EvoAlloc рано. Но при проектировании нового контура уже имеет смысл предусмотреть программный интерфейс распределителя, отдельный учёт его токенов и контрольные запуски при одинаковом бюджете. Тогда фиксированный фильтр можно будет заменить обучаемой стратегией без перестройки генератора и оценщиков.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
