Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Автоматический поиск изменений в коде модели часто застревает, потому что одна итоговая метрика скрывает конфликт между полезными свойствами. ConflictGuide снизил ошибку по основной задаче до 28%, а ошибку, связанную с конфликтом, — до 14%; препринт ещё не рецензирован, и числа в нём получили сами авторы. Для команд это рецепт не замены AutoResearch, а его перестройки после выхода на плато.
Работу выполнили Binqian Xu, Qiran Zou, Xiangbo Shu и Dianbo Liu из National University of Singapore и Nanjing University of Science and Technology.
Как измерили то, что скрывает итоговая метрика
Обычный цикл AutoResearch работает так: агент для работы с кодом меняет программу обучения, запускает эксперимент и получает одно число — например, ошибку прогноза. Если число улучшилось, система сохраняет изменение. По истории таких попыток агент предлагает следующий вариант.
Проблема возникает, когда итоговое число складывается из конкурирующих свойств. Модель временного ряда должна одновременно хранить далёкий контекст и нелинейно обрабатывать текущий сигнал. Модель с оценкой неопределённости должна точно классифицировать знакомые примеры, но не становиться излишне уверенной на чужих данных. Одинаковое улучшение основной метрики может означать как удачный баланс, так и выигрыш одного свойства за счёт другого.
ConflictGuide сначала определяет конкретную пару конфликтующих свойств и механизм, который их связывает. Для этого система сопоставляет архитектуру, данные, функцию обучения и способ оценки с таксономией конфликтов из научной литературы. Если свидетельств недостаточно, она отказывается назначать конфликт, а не подбирает его по формальному сходству.
Затем для каждого свойства задают отдельную диагностическую метрику. Она считывает выходы, внутренние состояния или параметры модели, но не вмешивается в обучение. Перед поиском метрику проверяют на парных экспериментах и задают порог, после которого изменение можно считать ослаблением конфликта.
Сам поиск делится на две стадии:
- Сначала — широкое исследование. Агент видит только итоговую метрику и свободно меняет представление данных, архитектуру и обучение.
- После замедления — направленная доработка. Агент получает результаты диагностик для каждого изменения и видит, какое свойство улучшилось, а какое пострадало.
- Диагностики влияют на отбор. Явное улучшение задачи сохраняют сразу. Небольшой выигрыш сохраняют лишь тогда, когда он достаточно ослабляет конфликт. Изменения с ухудшением основной метрики не принимают.
Поздняя диагностика вывела поиск из плато
Когда диагностические метрики включили не сразу, а после общей стадии поиска, доля изменений, улучшавших оба свойства, выросла с 7,2% до 13,1%. Продолжение с одной итоговой метрикой почти переставало продвигаться, тогда как ConflictGuide находил дальнейшие улучшения при равном бюджете экспериментов.
Проверка охватила пять семейств моделей: оператор для физических процессов, классификатор с оценкой неопределённости, резервуарную сеть для временных рядов, модель сжатия изображений и графовую нейросеть. В каждом случае ConflictGuide и обычный AutoResearch продолжали поиск из общей точки, получали одинаковый вычислительный бюджет и проходили полное переобучение для итоговой оценки.
Конфликты различались по природе. В операторе для физических процессов сталкивались доминирующие и слабые частотные компоненты, в сжатии изображений — компактность представления и сохранение деталей, в графовой сети — полезное объединение соседей и вредные сообщения от несовместимых узлов. Поэтому универсальной диагностической метрики у метода нет: её приходится проектировать и проверять для каждой модели.
Эффект не сводился к дополнительным числам в подсказке. На графовой модели и классификаторе ConflictGuide обошёл варианты, где агенту показывали несколько общих метрик или только словами описывали компромисс. Перенос на Kimi K2.7 Code и среду AIDE также сохранил преимущество диагностической обратной связи, поэтому результат не привязан только к Claude Code Opus 4.6.
Что менять в планах команд AutoResearch
Работа меняет архитектуру цикла поиска, если система уже перебирает код по одной агрегированной метрике. Раннюю стадию не стоит перегружать узкой диагностикой: в экспериментах обратная связь о конфликте с самого начала концентрировала агента на одном типе исправлений и сокращала разнообразие предложений.
Границу между стадиями лучше фиксировать заранее или связывать с устойчивым замедлением основной метрики. Для моделей с достаточным пространством изменений авторы чаще использовали разделение бюджета 100/100 итераций. Анализ чувствительности показал пользу такого баланса в изученном операторе, но не превращает его в универсальную настройку для других задач.
Основная инженерная работа лежит до запуска агента. Команде нужно назвать два желательных свойства, связать их с механизмом модели, реализовать независимые измерители и проверить, что они действительно реагируют на нужный конфликт. Если надёжные измерители построить нельзя, ConflictGuide не даёт содержательного сигнала и должен остановиться на обычной обратной связи.
Меняется и правило принятия изменений. Слабый прирост итоговой метрики больше не считается достаточным сам по себе: его нужно подтвердить улучшением конфликтующих свойств. Это защищает историю поиска от правок, которые выглядят полезными из-за шума или перераспределяют ошибку между скрытыми режимами.
Практический вывод узкий: не заменять итоговую метрику панелью показателей с первой итерации, а сначала исследовать пространство решений, затем открыть агенту проверенные измерения конкретного конфликта. Такой подход подходит для циклов, которые уже дошли до плато и где команда может объяснить, какие два поведения мешают друг другу.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
