Представьте, что вы создали систему автоматизированных научных открытий. Она работает на LLM, генерирует гипотезы, тестирует их, отбирает лучшие. Вы публикуете результаты — и все восхищаются. Но что если я скажу вам: та же самая система, запущенная на другой задаче или с другой моделью, покажет результат хуже простого перебора? Именно это и доказали исследователи в свежей работе, потратив 3.1 миллиона запусков языковых моделей, чтобы показать: универсального harness не существует.

Что такое harness в автоматизированных открытиях

Harness — это не просто оболочка вокруг модели. Это комплексная система, которая решает, как хранить найденные решения (archive), как выбирать родителей для следующей итерации (parent selection), как балансировать между исследованием нового и углублением в найденное (exploration vs exploitation), и как распределять ограниченный бюджет вычислений между разными стратегиями.

Две популярные системы — OpenEvolve и TTT-Discover — часто позиционируются как универсальные решения. OpenEvolve использует эволюционный поиск с MAP-Elites архивом, multi-island эволюцией и вдохновляющей выборкой из истории. TTT-Discover применяет UCT/PUCT-подобные стратегии для выбора родителей. Обе системы сложные, многокомпонентные, и обе требуют значительных вычислительных ресурсов.

Но вот проблема: поскольку запуски дорогие и стохастические, их часто сравнивают на слишком малом количестве независимых испытаний. Если вы запустили систему 3-5 раз и она показала результат лучше baseline — это ещё не значит, что она действительно лучше. Это может быть просто удачей.

Методология: 30 конфигураций, 12 пар, 3.1 миллиона запусков

Исследователи из Stanford (при поддержке JP Morgan и Google.org) подошли к проблеме системно. Они декомпозировали OpenEvolve и TTT-Discover на составные компоненты и создали 30 различных конфигураций harness. Каждая конфигурация — это уникальная комбинация выбора родителя, размера архива, стратегии exploration, глубины поиска.

Все 30 конфигураций были протестированы на 12 парах модель-задача:

Модели: Qwen2.5-3B-Instruct, Qwen3-4B-Instruct, GPT-OSS-20B, GPT-OSS-120B (от 3B до 120B параметров).

Задачи: circle packing (упаковка кругов), Heilbronn triangle (треугольники Хайльбронна), second autocorrelation inequality (абстрактная задача неравенств). Это три принципиально разные математические задачи — от геометрической оптимизации до абстрактных неравенств.

Для каждой пары модель-задача все harness работали с одинаковым бюджетом rollout'ов (от 160 до 1600 в зависимости от модели). Каждая конфигурация запускалась 5 раз независимо. Для построения baseline-распределения использовались 30-100 запусков Sequential Best-of-N (простейший baseline: на каждой итерации генерируем N детей, выбираем лучшего, повторяем).

Общий объём: более 3.1 миллиона запусков LLM. Это не просто «мы попробовали несколько вариантов» — это статистически строгое исследование с bootstrap-тестированием, поправками на множественное тестирование (Holm's correction) и проверкой значимости.

Главный результат: OpenEvolve проигрывает простым альтернативам

Начнём с самого шокирующего вывода: полные конфигурации OpenEvolve показали худший результат среди всех протестированных harness. majority-win score (доля побед во всех парах) составил всего 0.033 с cross-pair p-value 0.978 — то есть статистически неотличимо от случайного выбора.

Почему? Потому что добавление компонентов не даёт монотонного улучшения. Исследователи шаг за шагом добавляли усложнения к простому baseline: сначала exploration из полной истории, потом MAP-Elites архив, потом multi-island эволюция. Каждый компонент помогал в отдельных парах модель-задача, но одновременно ухудшал результат в других.

Например, добавление UCT/PUCT parent selection (как в TTT-Discover) давало статистически значимый выигрыш для GPT-OSS-20B на задаче Heilbronn triangle. Но на circle packing и second autocorrelation inequality та же самая конфигурация показывала результат ниже baseline.

Лучшей конфигурацией оказалась простейшая: epsilon-greedy с K=1 и ε=0.2. Она с вероятностью 20% выбирает родителя из полной истории поиска, а в 80% случаев берёт лучшее найденное решение. Это не эволюция с островами, не MAP-Elites, не tree search — это просто иногда смотрит в историю, а чаще жадно улучшают лучшее.

Но даже эта лучшая конфигурация после поправки Holm теряет статистическую значимость (p-value возрастает с 0.023 до 0.678). Вывод однозначен: ни одна фиксированная конфигурация не доминирует кросс-задачно.

Почему это важно: harness как гиперпараметр

Результат меняет парадигму. Если раньше исследователи искали «лучший harness» (как когда-то искали лучшую архитектуру нейросети), теперь становится ясно: harness — это гиперпараметр, зависящий от модели и задачи. То, что работает для GPT-OSS-20B на геометрической задаче, может не работать для Qwen3-4B на абстрактном неравенстве.

Это не значит, что сложные системы бесполезны. Это значит, что их нельзя применять слепо. Если вы хотите использовать OpenEvolve или TTT-Discover, вам нужно либо заранее знать, что для вашей конкретной задачи они работают, либо адаптировать их на лету.

И здесь исследователи предлагают решение.

Решение: адаптивное распределение бюджета

Ключевое наблюдение: ранний прогресс поиска предсказывает финальный результат. Исследователи замеряли Spearman correlation между лучшим score на 10%, 25% и 50% checkpoint и финальным score.

На 10% checkpoint корреляция слабая (от 0.0 до 0.47). На 50% checkpoint — уже сильная (выше 0.70 для 11 из 12 пар модель-задача). Это значит: если к середине поиска какая-то конфигурация показывает лучший результат, скорее всего, она останется лидером и в конце.

Это наблюдение позволяет построить адаптивную стратегию: запустить много конфигураций параллельно, на ранних checkpoint'ах отсечь слабых, сконцентрировать оставшийся бюджет на сильных. Исследователи назвали это EnsembleEvolve.

Конкретный пример: стратегия 17→5→2→1. Запускаем 17 конфигураций, на 25% checkpoint оставляем 5 лучших, на 50% — 2 лучших, на 75% — 1 финалиста. Бюджет: 17×0.25 + 5×0.25 + 2×0.25 + 1×0.25 = 5 full-run equivalents (ровно столько же, сколько 5 полных запусков одной конфигурации).

Результат: адаптивная стратегия превосходит все фиксированные harness. Средний score по всем 12 парам: 85.75 против 84.54 у неадаптивного ансамбля (5 конфигураций до конца), 82.49 у single-harness (одна конфигурация × 5 запусков) и 84.35 у Sequential BoN baseline.

Важно: выигрыш не просто от того, что мы пробуем много конфигураций. Непруненый ансамбль (5 конфигураций до конца, без отсечения) показывает 84.54. Адаптивный с прунингом — 85.75. Разница в 1.21 балла — это именно эффект от использования раннего фидбека для принятия решений.

Почему компоненты мешают: разбор конкретных failure modes

Контекстно объяснить, почему сложные конфигурации проигрывают простым, помогает анализ конкретных failure modes. Первый — dilution of search pressure. Когда система поддерживает большой Top-K архив (например, K=16), она хранит множество разнообразных решений и сэмплирует родителей из всех них. Это увеличивает разнообразие, но размывает давление отбора: вместо того чтобы концентрировать вычисления вокруг лучших найденных решений, система размазывает их по всем 16 кандидатам. Для circle packing, где существует чёткая иерархия качества упаковок, это контрпродуктивно — лучше жадно улучшать топ-1 решение.

Второй failure mode — overhead of diversity maintenance. MAP-Elites архив требует дополнительной оценки novelty каждого кандидата относительно архива. Это не бесплатная операция: для каждого нового решения нужно сравнить его с десятками архивных записей по пространству поведений. Для моделей уровня Qwen2.5-3B-Instruct этот overhead съедает 15-20% бюджета rollout'ов, которые можно было бы потратить на фактическую генерацию и оценку кандидатов.

Третий failure mode — coordination cost multi-island evolution. Когда система запускает несколько параллельных островов эволюции и периодически мигрирует лучшие решения между ними, возникает проблема синхронизации. Если один остров нашёл отличное решение, а другие ещё далеко, миграция может преждевременно доминировать и уничтожить разнообразие — тот самый premature convergence, от которого multi-island подход должен был защитить.

Статистическая инфраструктура: почему 5 запусков недостаточно

Критически важный методологический вклад работы — демонстрация того, что стандартная практика сравнения harness на 3-5 запусках статистически несостоятельна. Исследователи построили null distribution: 100,000 bootstrap-ресемплингов из 100 (или 30 для GPT-OSS) baseline-запусков, каждый раз выбирая 5 случайных запусков и беря максимум. Затем они сравнивали наблюдаемый best-of-five результат каждой конфигурации с этим распределением.

Результат показателен: многие конфигурации, которые при наивном взгляде казались «улучшающими baseline», на самом деле попадали в 95-й перцентиль null distribution. То есть их результат был совместим с тем, что мог бы дать обычный Sequential BoN при удачном стечении обстоятельств. Только после набора 100,000 bootstrap trials и применения Holm's correction для поправки на множественное тестирование стало возможно отделить реальные улучшения от стохастического шума.

Все данные — rollout-level логи для каждого model-problem pair — опубликованы как reusable statistical infrastructure. Это значит, что будущие предложения новых harness могут быть протестированы против уже построенных null distributions без необходимости повторять дорогостоящие baseline-запуски. Такой подход к воспроизводимости — редкость в области LLM-based discovery.

Практические выводы для исследователей

Что это значит на практике? Если вы строите систему автоматизированных открытий на LLM, у вас есть три стратегии:

Первая: выбрать один harness и надеяться, что он подойдёт. Это стратегия single-harness commitment — средняя оценка 82.49. Самый рискованный вариант.

Вторая: попробовать несколько harness до конца и выбрать лучший post-factum. Это unpruned ensemble — 84.54. Лучше, но всё ещё не оптимально.

Третья: запустить много конфигураций, использовать ранний фидбек для отсечения слабых, сконцентрироваться на сильных. Это adaptive ensemble — 85.75. Лучший результат при том же бюджете.

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

Часто задаваемые вопросы

Почему OpenEvolve работает хуже простых методов?

OpenEvolve — это композиция множества компонентов: MAP-Elites архив, multi-island эволюция, inspiration sampling. Каждый компонент добавляет overhead и усложняет поиск. В некоторых задачах эти компоненты помогают (например, multi-island эволюция полезна для задач с несколькими локальными оптимумами). Но в других задачах они мешают: overhead перераспределения ресурсов между островами замедляет сходимость, MAP-Elites архив требует дополнительной оценки разнообразия. В результате сложная система проигрывает простой epsilon-greedy, которая просто иногда смотрит в историю поиска.

Как выбрать checkpoint для прунинга?

Исследователи тестировали checkpoint на 25%, 50% и 75% полного запуска. Оптимальная стратегия использует все три точки: запускает много конфигураций, на 25% отсекает худшие 70%, на 50% — ещё половину оставшихся, на 75% — финальный отбор. Если у вас ограниченный бюджет мониторинга, можно использовать только 50% checkpoint — корреляция с финальным результатом уже выше 0.70, что даёт достаточно информации для прунинга.

Применимо ли это за пределами математических задач?

Исследование тестировалось на трёх математических задачах. Принципы адаптивного распределения бюджета (successive halving, Hyperband, ASHA) широко используются в hyperparameter optimization и работают на самых разных задачах. Ограничение: вам нужна функция оценки, которая возвращает промежуточный score. Для математических задач это легко (evaluator запускается на каждом кандидате). Для задач без явной функции оценки (например, генерация текста) адаптивный подход требует разработки прокси-метрик.

Итог

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

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

Код, данные и статистические артефакты доступны на GitHub. Если вы строите систему автоматизированных открытий — не ищите идеальный harness. Стройте систему, которая адаптируется на лету.