Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Автономную систему научили вести многодневные эксперименты с промышленными рекомендательными моделями и продолжать работу после сбоев. В работе Meta и University of Illinois Urbana-Champaign, которая не проходила рецензирование и где все числа получили сами авторы, среднее число крупных исправлений на цикл снизилось с 4,0 до 0,5. Для команд это сдвигает задачу с выбора особенно способной LLM на построение надёжного контура вокруг неё.
Почему один агент не выдерживает многодневный цикл
Обычные исследовательские агенты последовательно предлагают идею, меняют код, запускают проверку и анализируют результат. Такая схема подходит, когда ответ приходит за минуты или часы. В промышленной рекомендательной системе один цикл занимает от трёх до семи дней, поэтому последовательная работа быстро упирается во время ожидания.
Auto-RecSys ведёт несколько идей параллельно на разных серверах. Каждая идея независимо проходит этапы формулировки, реализации, проверки, обучения и анализа. Если обучение завершается ошибкой, система переводит только этот эксперимент в отладку, не блокируя остальные.
Состояние каждого эксперимента хранится отдельно в общей памяти, доступной со всех серверов. Там остаются изменения кода, идентификаторы заданий, результаты проверок и история действий. После завершения сессии агента или перезапуска сервера другая сессия восстанавливает контекст и продолжает с сохранённого этапа.
Это отличает Auto-RecSys от агента с длинной историей сообщений. Источником истины служит не контекст LLM, а внешнее состояние процесса. Переходы между этапами проверяет код, поэтому модель не может одним неточным вызовом переписать весь жизненный цикл эксперимента.
Как память превращает сбои в инструкции
Система разделяет рассуждение и операционные действия. Текстовые инструкции объясняют LLM, что проверить, как поставить диагноз и когда передать решение человеку. Детерминированные сценарии меняют состояние, записывают файлы, вызывают API и проверяют входные параметры.
Знания хранятся на трёх уровнях. Общая инструкция описывает одинаковый для всех моделей исследовательский цикл. Отдельная инструкция для каждой модели фиксирует нужные файлы, команды проверки, требования к GPU, параметры запуска, удачные процедуры и известные тупики. Файл конкретного эксперимента содержит временные сведения о текущем запуске.
После завершения цикла Auto-RecSys разбирает журнал действий. Успешную последовательность система сохраняет как повторяемую процедуру, а ошибку — вместе с причиной и исправлением. В следующем эксперименте агент получает этот опыт как прямую инструкцию, а не пытается заново восстановить его из необработанных журналов.
Один описанный случай показывает пользу такой памяти. Несколько запусков ломались на этапе публикации результата. Система изменила сам порядок работы, пропустила проблемный этап для этого модуля, и следующая попытка прошла без дополнительного исправления.
Проверка охватила 31 уникальную итерацию на рекомендательных моделях. Главный показатель отражает операционную надёжность: сколько серьёзных вмешательств требовалось, чтобы довести цикл до конца. Он не измеряет качество рекомендаций и не показывает, насколько идеи агента лучше предложений исследователя.
Сначала надёжный контур, потом автономность
Работа не предлагает заменять существующую платформу обучения. Auto-RecSys использует готовые системы распределённого запуска, контроля версий и наблюдения за метриками, а агенты координируют их. Это практичный порядок внедрения: сначала открыть проверенные операции через инструменты, затем добавить сохраняемое состояние и только после этого разрешать самостоятельные циклы.
Для новой модели предусмотрен интерактивный режим. Система останавливается при выборе идеи, проверке кода, отправке задания на обучение и разборе результатов. Когда инструкция модели накопила рабочие команды и типовые ошибки, эти остановки можно отключить.
Такая архитектура меняет планы команд, у которых эксперименты долго занимают GPU, зависят от хрупких конфигураций и уже идут параллельно. Им полезнее инвестировать не в один универсальный запрос к LLM, а в изолированные состояния экспериментов, восстанавливаемые журналы, строгие сценарии запуска и память о неудачных действиях.
Для коротких самодостаточных проверок этот контур может оказаться избыточным. Текущая система рассчитана на одного исследователя, который ведёт несколько моделей, а обновления модельных инструкций принимает без обязательной автоматической проверки. При командном внедрении к схеме понадобятся разграничение доступа, разрешение конфликтов и проверка новых инструкций до автономного запуска.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
