Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Автоматический поиск улучшений для рекомендательных моделей испытали на производственном масштабе и выяснили: без отдельной проверки, памяти и смены стратегии он систематически тратит вычисления впустую. За 12 недель контур провёл свыше 220 экспериментов и обошёл вручную настроенные варианты по основным офлайн-метрикам. Поскольку препринт не рецензирован, а числа получили сами авторы, командам стоит воспринимать его как схему устройства контура, а не как гарантию такого же прироста.
Долгий эксперимент меняет правила AutoResearch
В исходной схеме AutoResearch LLM меняет сценарий обучения, запускает его и сохраняет вариант, если контрольная метрика выросла. В производственной системе такой цикл перестаёт быть коротким: обучение занимает часы, кампания переживает контекст одного диалога, а качество нельзя свести к одному показателю.
Контур проверяли в двух системах книжных рекомендаций. Первая строила векторные представления книг по совместным покупкам и тексту, причём агент мог переписывать весь сценарий обучения. Вторая присваивала книгам иерархические коды и позволяла агенту менять конфигурацию и архитектуру модели.
Для первой системы основной метрикой стала Recall@6 — полнота первых шести рекомендаций, то есть доля случаев, когда среди ближайших книг находилась следующая покупка пользователя. Во второй измеряли взвешенную связность: насколько похожи книги внутри кластеров на разных уровнях иерархии.
Стоимость одной итерации различалась примерно в 760 раз. Поэтому дорогой контур проверял изменения до запуска на GPU, а дешёвый мог сначала провести эксперимент и автоматически откатить неудачный вариант.
Границы результатов заданы самой постановкой: обе системы относятся к книжным рекомендациям одной организации, а метрики остаются офлайн-заменителями поведения пользователей. Переходы между версиями контура происходили по ходу кампании, а не в контролируемом сравнении компонентов.
Пять сбоев сводятся к трём защитным механизмам
Хрупкая инфраструктура. Агент предлагает код, который не учитывает память GPU, распределённое обучение, ограничения оценщика или формат сообщений между агентами. Такой сбой не даёт полезного результата, но занимает вычислительные ресурсы наравне с полноценным экспериментом.
Распад памяти. После смены запуска или сокращения контекста агент возвращается к уже отвергнутым идеям. Конфигурацию со слишком долгим обучением он повторно проверил не менее шести раз, хотя отрицательный результат был записан в исследовательской программе.
Застой поиска. Достигнув локального максимума, агент продолжает менять близкие параметры и получает колебания в пределах шума. Сам он редко признаёт, что исчерпал направление и должен сменить гипотезу.
Игнорирование стоимости. Агент не сравнивает ожидаемую пользу эксперимента с ценой вычислений. Рискованный многочасовой запуск и дешёвая проверка одного параметра для него выглядят как равноправные следующие шаги.
Зацикливание на метрике. Во второй системе увеличение числа кодов улучшало связность кластеров, но дробило нижние уровни до одиночных книг. Агент честно повышал заданный показатель, одновременно делая иерархию менее пригодной для продукта.
Авторы свели защиту к трём действиям. Предотвращать — проверять смысл и инфраструктурную допустимость кода до дорогого запуска. Сохранять — записывать удачные и неудачные гипотезы во внешнее хранилище, которое переживает задания и окна контекста. Перенаправлять — подключать отдельного критика только при застое, чтобы он менял класс решений, а не предлагал ещё одну настройку параметра.
Планы меняет стоимость ошибки, а не выбор LLM
В первой системе полнота рекомендаций выросла в 1,82 раза относительно варианта, который инженеры настраивали вручную. Во второй связность кластеров выросла в 2,1 раза. Агент также спроектировал резервный вариант только на текстовых данных, который увеличил охват каталога в 5,8 раза.
Эти результаты поддерживают сам подход к автоматическому поиску, но не снимают с команды ответственность за контур. LLM можно поручить систематическую проверку гипотез внутри заданной области; выбор данных, метрик и допустимых продуктовых компромиссов остаётся человеческой задачей.
Для дорогих итераций план архитектуры стоит дополнить отдельным агентом-проверяющим. Он должен искать не только синтаксические ошибки, но и неправильное распределение вычислений, риск исчерпания памяти и несовместимость с оценщиком. Если запуск дешёвый, такой этап может стоить дороже предотвращённого сбоя — тогда достаточно автоматического отката.
Историю экспериментов нужно хранить как структурированные данные, а не как длинный журнал переписки. Для каждой гипотезы полезны изменение, результат, причина отказа и условия, при которых повторная проверка оправданна. Иначе модель найдёт убедительное объяснение, почему старую ошибку стоит повторить.
Оценщик следует отделить от кода, который меняет агент, и показывать несколько продуктовых показателей одновременно. Однако набор метрик сам по себе не решает зацикливание: когда связность, чистота жанров и размер кластеров конфликтуют, человек должен решить, какой компромисс допустим или нужен ли отдельный этап обработки после модели.
Работа меняет планы команд с многочасовыми обучающими заданиями и длинными исследовательскими кампаниями: один агент с одним журналом здесь недостаточен. Для коротких и дешёвых опытов полная многоагентная схема может не окупиться, но внешняя память и явное правило остановки остаются полезными.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
