Любой эксперимент упирается в одно и то же: запуск, оценка, изменение, снова запуск. Тим Суини и Зубин Айсола из Weights & Biases на AI Engineer World’s Fair показали агента Arya, который этот цикл крутит сам: запускает обучение, смотрит результаты, правит код и гиперпараметры, запускает снова. Полезно разобрать, что в этой обвязке отдано агенту, а что осталось человеку.
Что именно делает Arya
Arya — это research-агент в платформе Weights & Biases, который работает в знакомом ML-инженеру интерфейсе: слева список экспериментов, справа графики метрик. Тим Суини показывал демо на проекте Karpathy Auto Research, где у него уже было больше 200 запусков. Агент там сам скачивает код, ставит задачи в очередь на GPU, запускает обучение и правит гиперпараметры без участия человека.
Важная деталь: Arya не изобретает новую архитектуру в каждой итерации. Тим Суини подчёркивает, что в живом демо агент сознательно избегал больших архитектурных изменений и менял только гиперпараметры. Маленькие мутации легче сравнивать.
Анатомия обвязки
Тим Суини сразу признаёт, что архитектура типичная для agent-систем: веб-клиент и iOS-клиент, API-сервер, база данных и worker harness, то есть рабочая обвязка, в которой крутится агент. Само интересное в пяти утилитах вокруг этого воркера:
- Песочница для произвольного кода и shell-вызовов. Зубин Айсола говорит, что возможность «дать агенту делать что угодно» — ключ к появлению неожиданного поведения.
- Провайдер модели. У них это Weights & Biases Inference, плюс внешние модели. Стек собирается модель-агностично.
- Очередь запусков (launch queue) и GPU. Долгие задачи выносятся из основного цикла агента, чтобы не блокировать его на часы или дни.
- Хранилище артефактов для версий агента и моделей.
- Observability-слой (Weave). В него логируется 100% трасс: сессии, ходы, вызовы инструментов, ошибки.
Зачем логировать вообще всё
Зубин Айсола каждый день смотрит трассы из продакшена и перетаскивает их в офлайн-окружение, чтобы по ним «карабкаться в гору», то есть улучшать агента. Его аргумент: если у вас динамическая система, где агент, оценки и конфигурация постоянно меняются, без измерений вы не отличите улучшение от шума.
Принцип, который он явно называет: исследовательский и продуктовый код должны быть побайтово идентичны. У них 4-часовая синхронизация между продом и research-окружением, чтобы исследователи не уходили в сторону при нарезке новых вариантов агента. Если у вас в офлайне агент один, а в проде другой, вы оптимизируете не ту штуку.
Цикл улучшения и место человека
Зубин описывает цикл так: гипотеза, реализация кандидата, анализ оценок. Внутри этого цикла живут два контура (офлайн и онлайн), которые гоняют разные варианты агента и сливают данные в один дашборд, где команда принимает go/no-go решение по изменению промпта или архитектуры. Лучший вариант идёт в прод через реестр моделей.
Что отдано агенту: запуск экспериментов, правка кода, чтение логов, генерация новых задач для hill climbing. Зубин прямо показывал, как Arya по prod-трассе сам придумывает новую задачу и добавляет её в офлайн-набор.
Как применить
- Сделайте продовый и офлайновый код побайтово одинаковыми. Если у вас разные версии агента в двух средах, ваши оценки не про прод. Они про другую систему.
- Логируйте 100% трасс в одно хранилище в одном формате. Без этого вы не перетащите продакшен-кейс в офлайн и не поймёте, что чинить.
- Дробите изменения. Тим Суини в демо намеренно менял только гиперпараметры. Большие архитектурные скачки рискованны и плохо сравниваются.
- Сделайте песочницу, в которой агенту разрешено всё. Неожиданные полезные поведения появляются именно там, где нет жёстких ограничителей.
- Считайте много трасс, потом решайте, что с ними делать. Зубин прямо формулирует принцип: «Лучше запустить больше экспериментов, чем меньше». Для агентов это верно так же, как для классического обучения.