EliteTable заставляет LLM эволюционировать код-контроллеры: рост в 6 из 6 задач

Авторы препринта arXiv:2610.12536 описали EliteTable, алгоритм поиска программ, в котором большая языковая модель сама пишет и дорабатывает исполняемые политики управления. Эксперимент прошёл на шести задачах Gymnasium. Каждый поиск шёл десять поколений по 50 слотов кандидатов, на каждую задачу приходилось десять независимых запусков. Итог неоднозначный: медианы оценок кандидатов выросли между первым и последним поколением во всех шести задачах, а на новых эпизодах выигрыш сохранился лишь в части из них.

Как устроен EliteTable

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

Такая схема напоминает эволюционный поиск, где роль мутации и скрещивания играет языковая модель, а селекцией занимается ограниченная таблица. Результат поиска представляет собой не веса нейросети, а код политики. Его можно прочитать, проверить и запустить как обычную программу. Для задач управления это серьёзный довод в пользу подхода.

Что показали шесть задач

По числам из аннотации картина выглядит так:

• Бюджет поиска: 10 поколений × 50 кандидатных слотов, то есть до 500 кандидатов на один запуск.
• Повторяемость: 10 независимо инициализированных поисков на каждую из 6 задач.
• Медианы оценок кандидатов выросли между первым и последним поколением в 6 задачах из 6.
• Медианы поисковых оценок выбранных победителей выросли в 5 задачах из 6.
• В CartPole-v1 выбранный победитель упёрся в потолок поисковой оценки уже в первом поколении всех десяти запусков.
• На отложенных эпизодах все десять парных конечных результатов улучшились в 4 задачах из 6.
• BipedalWalker-v3 и CarRacing-v3 улучшились, но целевых показателей для отчёта не достигли.

Пример с CartPole-v1 показывает, что задача слишком проста, чтобы различать сильные и слабые методы: потолок достигнут сразу, и дальше поиск ничего не доказывает. Куда информативнее BipedalWalker-v3 и CarRacing-v3. Это сложные среды, и здесь прогресс есть, но до заявленных целей он не дотянул.

Где результаты расходятся с ожиданиями

Слабее всего выглядит Acrobot-v1. В шести из десяти поисков результат на отложенных эпизодах ухудшился, а медиана парного изменения оказалась отрицательной. Значит, победитель, отобранный по поисковой оценке, мог подстроиться под конкретные эпизоды поиска и не обобщился на новые. Это классическая проблема отбора по зашумлённой метрике, и таблица элитных решений её, судя по данным, не снимает.

Главная оговорка есть в самой аннотации. Авторы пишут, что для оценки относительной эффективности EliteTable и вклада отдельных компонентов нужны сравнения и абляции. Сейчас таких данных нет. Неизвестно, насколько метод лучше простого случайного перебора программ, генерации без таблицы или других LLM-ориентированных поисковиков. Неясно и то, какой из трёх режимов (предложение, правка, ремикс) даёт основной прирост. Работа документирует улучшение в ходе поиска и частичный перенос выигрыша на новые эпизоды, но не доказывает превосходство метода.

Для практиков вывод такой. Идея хранить компактную таблицу лучших программ и просить LLM переписывать их выглядит рабочей для синтеза управляющего кода, особенно там, где нужна читаемая политика. Но если вы собираетесь применять подход к своим задачам, оценивайте победителей только на отложенных эпизодах, а не на поисковой оценке. Используйте несколько независимых запусков и не доверяйте медианам без парного сравнения. Пока авторы не опубликуют сравнения с базовыми методами и абляции, EliteTable разумно считать интересной гипотезой, а не готовым инструментом.