Исследование: переобучение и лишний compute съедают 68% прироста от эволюции харнесса

Когда команда автоматически эволюционирует харнесс вокруг замороженной LLM, она получает рост метрик без единого обновления весов. Новая работа с Hugging Face Daily Papers проверяет, сколько из этого роста реально. Авторы ввели протокол Harness-Delta Attribution (HDA) и прогнали его на 11 моделях-исполнителях и трех фреймворках эволюции харнесса. Результат неудобный: в 21 конфигурации со статистически значимым приростом на поисковой выборке в среднем 54% выигрыша объясняется переобучением под артефакты бенчмарка, еще 14% дает дополнительный вычислительный бюджет на инференсе.

Что именно раскладывает HDA

Харнесс — это все, что окружает модель: системные промпты, описания навыков, набор инструментов и код оркестрации. Эволюционные фреймворки итеративно переписывают эти компоненты и отбирают версии, которые лучше проходят на search set. Вес модели при этом фиксирован, поэтому такой подход выглядит дешевой альтернативой дообучению.

Проблема в том, что итоговая цифра «было 40, стало 52» смешивает несколько эффектов. HDA делит прирост на три части:

• переобучение, то есть выигрыш от артефактов конкретной поисковой выборки;
• эффект test-time scaling, когда эволюционировавший харнесс просто тратит больше токенов, попыток или шагов;
• остаток, который авторы трактуют как верхнюю границу обобщаемого улучшения.

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

Цифры по 21 конфигурации

Эксперименты охватывают математику, кодинг, креативные и агентные задачи. Отбирали только случаи, где прирост на поисковой выборке статистически значим. Таких набралось 21.

• Среднее по этим случаям: переобучение объясняет 54% прироста, test-time scaling — 14%.
• В 14 из 21 конфигураций совокупная доля двух факторов превышает 50%.
• Если сложить средние, на остаток приходится около трети исходного выигрыша. Это среднее, а не гарантия для конкретной настройки.
• Размер остатка и перенос на отложенные задачи сильно зависят от типа задачи, модели и фреймворка.

Отдельный вывод касается валидации. Сигналы, основанные на валидационной выборке, не предотвращают переобучение. Команда, которая останавливает эволюцию по лучшему валидационному скору, все равно может получить харнесс, подогнанный под свой бенчмарк. Кроме того, выигрыши на search set часто не переносятся на отложенные задачи. Данных о том, что они переживут практический сдвиг распределения, мало.

Как оценивать эволюцию харнесса на практике

Для команд, которые строят агентов, вывод приземленный. Отчет «харнесс дал +12 пунктов» без разбивки сам по себе мало что говорит. Нужно проверять минимум три вещи. Первая: как результат ведет себя на действительно отложенных задачах, не участвовавших ни в поиске, ни в выборе чекпойнта. Вторая: сколько вычислений стал тратить новый харнесс на задачу, и что покажет базовая версия с тем же бюджетом. Третья: насколько результат устойчив, если слегка поменять распределение задач, например формулировки, домены или инструменты.

Для исследователей фреймворков эволюции работа задает планку: сравнение по одной метрике на search set больше не выглядит достаточным. Атрибуция прироста становится частью методологии, как абляции в обычном машинном обучении.

Ограничения тоже есть. Остаток в HDA — верхняя граница, а не измеренная обобщающая способность, а выводы построены на 21 конфигурации. Но направление понятно. Пока оценка не отделяет реальное улучшение агента от подгонки и дополнительного compute, заявления о том, что харнесс можно улучшать автоматически без обновления весов, стоит принимать с поправкой примерно на две трети прироста.