Почему LLM-поиск стоит начинать с нескольких независимых решений

Качество первых вариантов определяет, насколько далеко LLM продвинется в автоматическом поиске решения. Препринт University of Chicago, Vector Institute и University of Toronto не прошёл рецензирование, а приведённые числа получили сами авторы: предварительная параллельная разведка повысила результат готовых поисковых контуров на 2–21%. Для команд, которые строят автономную оптимизацию алгоритмов или запросов, это повод перенести часть бюджета токенов с длинной цепочки улучшений на подготовку сильного старта.

Почему последовательный поиск застревает на ранней идее

Управляющий контур хранит найденные решения, выбирает из них исходные варианты и просит LLM предложить улучшение. Затем система оценивает новый вариант, добавляет его в активный набор и повторяет цикл. Так модель использует не только знания из своих параметров, но и результаты предыдущих попыток.

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

В ходе поиска варианты становятся всё более похожими друг на друга. Авторы называют это схлопыванием разнообразия: управляющий контур закрепляет один способ решения и перестаёт исследовать альтернативы. Параллельные запросы дают более разнообразные ответы, потому что не видят результаты соседних попыток, но сами по себе не всегда находят лучшее решение.

Проверка охватила пять задач: перенос данных между облаками, планирование заданий, упаковку окружностей, задачу коммивояжёра и оптимизацию запроса для GSM8K. Исследователи сравнили 12 вариантов Modular с ShinkaEvolve, OpenEvolve и optimize_anything, используя разные LLM и одинаковый бюджет токенов внутри каждого сравнения. Лучший управляющий контур менялся вместе с задачей и моделью, поэтому универсального победителя среди архитектур не оказалось.

Попытки дольше поддерживать разнообразие тоже не дали стабильного выигрыша. Удаление похожих решений, пороги сходства и отбор через модель-оценщик расширяли набор идей, но не гарантировали более высокий итоговый балл. Само разнообразие оказалось слабой целью: важнее было получить сильные варианты в начале траектории.

Как параллельная разведка меняет старт

Предложенная схема делит прежний бюджет токенов на две стадии. Сначала LLM независимо улучшает одно исходное решение: контекст между запросами не меняется, поэтому ответы не тянут друг друга к одной идее. Затем система выбирает лучшие результаты, отбрасывает точные и почти точные повторы и передаёт получившийся набор последовательному контуру.

В основных опытах стартовый набор состоял из 15 вариантов. Для фильтрации оставляли решения с косинусным сходством ниже 0,98 — это мягкий порог, который удаляет почти одинаковые ответы, а не требует максимального различия. После такого старта обычный последовательный поиск продолжал улучшать уже несколько перспективных направлений.

Долю бюджета для первой стадии определяли по сходимости параллельного поиска. Система следила за лучшим найденным результатом и переключалась на последовательную оптимизацию, когда тот переставал заметно расти. В 9 из 13 сценариев такой момент совпал с лучшим из проверенных вариантов распределения бюджета.

Общий лимит токенов при этом не увеличивали. Улучшение возникло не из-за дополнительных запросов, а из-за другого порядка расходов: сначала широкий поиск, затем развитие отобранных решений. Это отличает метод от простого масштабирования вычислений.

Когда команде стоит менять поисковый контур

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

В действующем контуре полезно отдельно сохранять баллы ранних решений и их сходство. Падение разнообразия само по себе не требует вмешательства: успешные траектории тоже со временем сходятся к одному направлению. Тревожный сигнал — раннее схлопывание вокруг вариантов с низким баллом.

Практическое изменение состоит из трёх шагов:

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

Оценщик при этом нужно изолировать от генерируемого решения. В одном опыте с CloudCast модель просмотрела стек вызовов, нашла функции с именами sim, eval и runner и попыталась использовать их как доступ к проверке. Сильный старт не защищает от подмены цели, если кандидат может исследовать среду оценки.

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

Источники

• Initialization Improves LLM-Driven Discovery