Как ИИ учится управлять эволюционными алгоритмами почти как теоретический оптимум

Что открыли

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

Они расширили подход Code World Models (CWM) — это когда LLM пишет Python‑симулятор среды — с игр на случайные комбинаторные задачи оптимизации. Модель получает логи работы простого эволюционного алгоритма ((1{+}1))-(\text{RLS}_k), по этим данным сама пишет симулятор его динамики, а потом по этому симулятору планирует, какой параметр мутации (k) выбирать на каждом шаге.

Результаты по задачам:

• На классических тестах LeadingOnes (LO) и OneMax стратегия CWM-greedy показывает качество в пределах 6% от теоретически оптимальной политики — при этом она никогда не видела траекторий оптимальной политики.
• На функции Jump(_k), где есть «обманная яма» и все адаптивные базовые методы дают 0% успешных запусков, CWM-greedy достигает 100% успеха. Причём ни одна политика сбора данных не использует «оракул», знающий точный параметр разрыва.
• На задачах NK-Landscape, где нет аналитической модели, CWM-greedy обгоняет все базовые методы на 15 независимых инстансах: средний результат 36,94 против 36,32, статистически значимо (p < 0,001), когда в подсказку LLM добавляют эмпирические переходные статистики.

Плюс CWM выигрывает у DQN по трём метрикам:

• Сэмплов меньше: 200 офлайн‑траекторий против 500 онлайн‑эпизодов.
• Успешность выше: 100% против 58%.
• Обобщение лучше: при (k = 3) — 78% против 0%.

Проверка устойчивости показывает стабильный результат: 5 независимых запусков дают сопоставимые модели.

Как исследовали

Команда взяла существующий эволюционный алгоритм ((1{+}1))-(\text{RLS}_k), который на каждом шаге меняет битовую строку, и собрала подоптимальные траектории его работы. То есть логи не идеальной, а обычной, «неумной» стратегии.

Эти траектории подали в LLM и попросили её синтезировать Python‑код, который имитирует поведение оптимизатора: как он переходит из одного состояния в другое при разных значениях (k).

Дальше поверх этого симулятора запустили жадное планирование: на каждом шаге модель перебирает варианты (k) и выбирает тот, который по симулятору обещает лучший ближайший результат.

Эксперименты провели на трёх классах задач:

• LeadingOnes (LO) и OneMax — классические бенчмарки для эволюционных алгоритмов.
• Jump(_k) — задача с «ямой», в которую алгоритмы часто попадают и застревают.
• NK-Landscape — семейство сложных ландшафтов без закрытой формулы, где приходится полагаться только на эмпирические данные.

Для сравнения использовали классические адаптивные стратегии, а также DQN — популярный метод глубокого обучения с подкреплением. Везде измеряли успехи по качеству решения, числу траекторий/эпизодов, проценту успешных запусков и способности переносить стратегию на новые настройки (k).

Что это меняет на практике

Главная идея: LLM может выучить поведение оптимизатора по логам и потом сама управлять его параметрами. Без формальной модели задачи и без доступа к идеальной политике.

Для индустрии это про настройку сложных пайплайнов, где сейчас всё крутится на ручном тюнинге и переборе гиперпараметров:

• Эволюционные алгоритмы в AutoML.
• Оптимизация расписаний и логистики.
• Настройка параметров в сетях связи и распределённых системах.

Там часто нет точной математической модели, а есть только логи. Новый подход показывает, что достаточно порядка 200 офлайн‑траекторий, чтобы LLM‑симулятор начал уверенно управлять алгоритмом и даже выигрывать у DQN, которому нужно 500 онлайн‑эпизодов.

До продукта уровня «одной кнопки» ещё далеко. Сейчас это аккуратное исследование на синтетических задачах, пусть и довольно сложных. Но путь понятен: сначала — внедрение в исследовательские фреймворки для оптимизации, потом — в коммерческие AutoML‑сервисы и системы управления инфраструктурой.

Реалистичный горизонт — несколько лет, при условии что индустрия возьмёт идею и начнёт проверять её на реальных данных, а не только на тестовых функциях.

Что это значит для вас

Если вы работаете с эволюционными алгоритмами, AutoML или сложной оптимизацией, эта работа даёт прямой сигнал: логи ваших запусков — не просто мусор, а сырьё для LLM‑контроллера.

• Вы можете собирать подоптимальные траектории существующих оптимизаторов и обучать LLM писать для них симуляторы.
• Потом использовать эти симуляторы, чтобы автоматически выбирать параметры — как здесь выбирают (k) на каждом шаге.

Если вы уже пользуетесь GPT‑классом моделей для генерации кода, то ближайший практический шаг — экспериментировать с похожим паттерном: «логи → описание динамики → код‑симулятор → планировщик поверх него» в своих задачах.

Если вы продакт или инженер без глубокого бэкграунда в теории оптимизации, вывод простой: LLM можно рассматривать не только как чат‑бота или генератор кода, но и как надстройку‑управляющего над существующими алгоритмами. Но пока это инструмент для исследовательских команд и R&D‑подразделений, а не готовый модуль, который можно сразу встраивать в прод.