Открытый EnvHarness от Google: ИИ-агенты обучаются в средах, меняющихся вместе с ними

Почему статичные среды становятся ограничением

ИИ-агенты учатся через взаимодействие со средой. Для агента для программирования это может быть репозиторий с оболочкой и набором тестов. Агент для браузера работает с сайтом, а корпоративный агент автоматизации — с изолированной копией внутреннего приложения.

Среда ставит задачу, хранит своё состояние, отвечает на действия агента и определяет, достигнут ли результат. На создание такой системы требуется много инженерной работы, особенно если нужен надёжный проверяющий механизм, способный определить, правильно ли агент выполнил задачу.

Проблема в том, что после создания большинство сред остаются неизменными. Они не подстраиваются под агента, который с ними работает. Если агент постоянно ошибается, потому что не проверяет тесты перед редактированием кода, среда сама не создаёт ситуации, заставляющие его тренировать этот навык. А после освоения исходных задач симулятор становится менее полезным и хуже помогает улучшать агента.

По мере развития агента сложнее находить и редкие кейсы. Зифэн Ван, научный сотрудник Google и соавтор исследования, рассказал VentureBeat, что в фиксированном пространстве действительно сложные среды встречаются всё реже, поэтому командам приходится проверять экспоненциально больше вариантов, чтобы находить содержательные редкие кейсы.

Один из способов решить проблему — генерировать дополнительные среды с помощью ИИ.

Например, GenEnv использует большую языковую модель как симулятор: она создаёт переходы, наблюдения и сигналы успеха, стараясь удерживать задачи около границы возможностей агента. Другой подход, Agent-World, программно синтезирует исполняемые инструменты, базы данных и задачи, из которых собираются новые среды.

Но генерация среды создаёт собственные сложности:

Создание новых сред также не гарантирует адаптацию. По словам Вана, если они по-прежнему формируются из фиксированного распределения, команда просто заменяет один статичный набор другим. По мере улучшения агента полезные примеры снова становится трудно находить.

Как EnvHarness делает среду программируемой

EnvHarness использует другой подход: вместо создания новых сред он меняет способ представления уже существующей среды агенту.

Исследователи сравнивают это с агентским каркасом — программным слоем, который окружает большую языковую модель инструментами, памятью, управлением контекстом и циклами выполнения.

EnvHarness переносит ту же идею на другую сторону взаимодействия:

Адаптированная среда = статичная среда + EnvHarness

Агент продолжает работать через тот же интерфейс. EnvHarness располагается между агентом и средой и меняет процесс обучения, не модифицируя сам симулятор.

Stage меняет начальное состояние среды. Например, в одной из задач бенчмарка ALFWorld агент должен поставить чистую кружку на стол. Обычно кружка лежит на виду. Stage может сначала поместить её в закрытый ящик, чтобы агенту пришлось искать предмет перед выполнением задачи. Можно сделать и наоборот — заранее выполнить раннюю часть задания и сосредоточить обучение на следующем шаге.

Contract меняет само взаимодействие. Он может фильтровать действия, изменять ответы или управлять тем, что видит агент. В той же задаче Contract способен изменить описание комнаты и убрать часть деталей, чтобы агент собирал информацию за несколько шагов. Он также может удалить короткие маршруты навигации, заставив агента обыскивать комнаты по очереди.

Chain объединяет задачи. После того как агент поставил кружку на стол, ему могут поручить разогреть картофелину и положить её на кухонную столешницу. Теперь для успеха нужно выполнить обе задачи. Так появляется более длинная траектория, в которой агенту приходится сохранять цели и распределять доступные действия.

Другой компонент фреймворка, EnvRigger, автоматически решает, как менять среду с учётом слабых мест агента.

EnvRigger работает по циклу «Наблюдение → Диагностика → Написание → Проверка»:

Ван приводит пример агента для программирования, который пытается сэкономить время и отправляет исправление, не запустив тесты. Если система замечает такой короткий путь, она автоматически создаёт правило-плагин: оно перехватывает преждевременную отправку и возвращает предупреждение, заставляя агента сначала запустить набор тестов.

Плагин меняет условия работы агента, но не саму задачу и не её проверяющий механизм.

В этом примере исходный репозиторий и написанные человеком модульные тесты остаются без изменений. Contract блокирует преждевременную отправку снаружи, а исходные тесты по-прежнему определяют, правильно ли написано исправление. Так сохраняется надёжный проверяющий механизм, но у агента появляется возможность отработать новое поведение.

EnvRigger также проверяет изменения перед тем, как оставить их в системе. В экспериментах из статьи базовый цикл начинается с пяти запусков исходной задачи и пяти новых запусков с предполагаемой модификацией. Если новая версия делает задачу нерешаемой, слишком простой или не даёт полезного сигнала, EnvRigger может пересмотреть её и провести дополнительные проверки — всего до пяти итераций написания и валидации.

EnvHarness в работе

Исследователи проверили EnvHarness на пяти бенчмарках:

В основных экспериментах они собирали траектории из сред и извлекали из них навыки, которые можно использовать повторно. Навыки, полученные в средах EnvHarness, превзошли навыки из неизменённых сред на всех пяти бенчмарках.

В SWE-bench Verified вместе с ростом точности обучение с EnvHarness сократило среднюю траекторию с 55.01 до 49.61 шага.

EnvHarness также показал лучшие результаты по сравнению с системами, специально созданными для генерации учебных сред. В SWE-bench Verified он превзошёл SWE-smith на 2.46 процентного пункта, затратив на эпизод на 5.11 шага меньше. В ALFWorld его результат оказался в среднем на 5.7 пункта выше, чем у GenEnv.

Более заметный эффект проявился при многократном запуске цикла адаптации. Каждая новая партия EnvHarness создаётся с учётом состояния агента после обучения на предыдущих партиях.

В среде для программирования ранние раунды выявляли базовые проблемы: запуск тестов и редактирование файлов. В следующих раундах обнаруживались уже другие слабые места:

Масштабные эксперименты из статьи показывают результат такой адаптации. В SWE-bench Verified базовый агент начал с показателя 47.67% и достиг 54.79%, когда учебный набор EnvHarness вырос до 300 сред. Обучение на таком же количестве исходных сред довело результат до 52.13%, а среды, сгенерированные SWE-smith, — до 50.37%.

Показатели исходных и сгенерированных сред начали выравниваться раньше. EnvHarness продолжал создавать учебные среды с учётом последних возможностей агента.

Тот же принцип работает за пределами программирования. В WebArena исследователи задали слабое место, при котором агент отвечал, не прокрутив страницу, и пропускал информацию ниже видимой области. EnvHarness создал Contract, который запрещал получать данные, пока агент не прокрутит страницу. В результате появились траектории, обучавшие агента просматривать страницу целиком перед ответом.

Что потребуется компаниям

EnvHarness сам по себе не обучает агента. Он создаёт опыт, который должна использовать другая система обучения.

В основных экспериментах исследователи применяли дата-пайплайн в стиле ReasoningBank, превращавший траектории в навыки для повторного использования. В корпоративной среде EnvHarness аналогично придётся объединить с извлечением навыков или памяти, файн-тюнингом, обучением с подкреплением либо другим механизмом, который меняет агента под влиянием его опыта.

Поэтому EnvHarness дополняет фреймворки, автоматически меняющие агентский каркас, включая Self-Harness, HarnessX и DarwinX.

Такие системы улучшают правила, рабочие процессы, навыки и другие элементы на стороне агента. EnvHarness меняет условия, в которых агент учится. Ван отмечает, что оптимизация на стороне агента не может происходить в изоляции: внутреннее планирование, рефлексия и принятие решений формируются во взаимодействии с внешним миром. Динамические ограничения среды могут заставить улучшенный каркас столкнуться с поведением, которого агент иначе избегал бы или решал бы с помощью хрупких коротких путей.

Исследователи не проверяли совместную работу EnvHarness с фреймворками саморазвивающихся агентов. Однако эти подходы воздействуют на разные части системы и теоретически могут образовать цикл обратной связи:

У внедрения есть две основные статьи расходов.

Первая — интеграция существующей среды с EnvHarness. Команде нужно написать Bridge, который представит среду через общий интерфейс ActionableEnv. В статье уже есть Bridge для нескольких типов сред, включая среды SWE-bench на базе Docker, OfficeQA и SpreadsheetBench.

Для контейнерных рабочих процессов разработки интеграцию можно разместить за пределами самой среды. По словам Вана, корпоративные дата-пайплайны непрерывной интеграции и доставки обычно запускают среды внутри изолированных контейнеров Docker или Kubernetes, а EnvHarness подключается поверх существующего средства запуска тестов как лёгкий внешний плагин.

Если среда уже поддерживает необходимую схему сброса и пошагового взаимодействия, команда может оставить без изменений образ контейнера, кодовую базу и внутренние модульные тесты. EnvHarness будет перехватывать команды на уровне интерфейса.

Вторая статья расходов — вычислительные ресурсы. Ван называет этот компромисс скорее вычислительным, чем архитектурным. Затраты возникают из-за цикла EnvRigger: ему требуется несколько запусков агента, чтобы диагностировать слабость, создать изменение и проверить, что задача после него остаётся решаемой.

Требование быстро восстанавливать состояние также очерчивает границы применения EnvHarness. Фреймворк подходит для цифровых песочниц, где запуски дешевы, а состояние можно быстро вернуть назад:

Не стоит запускать диагностический цикл непосредственно на системах с необратимыми последствиями или дорогим восстановлением — например, на рабочих базах данных, реальных аккаунтах клиентов или физических роботах. В таких случаях потребуется безопасный симулятор, тестовый контур или восстанавливаемая копия рабочей среды.

Google Research опубликовала код EnvHarness, конфигурации экспериментов и реализацию обучения с подкреплением на GitHub под разрешительной лицензией Apache 2.0.

Исследователи ожидают, что по мере улучшения моделей, управляющих EnvRigger, стоимость разработки и проверки изменений среды снизится: более сильным агентам-проектировщикам должно требоваться меньше итераций. При этом цель EnvHarness — не отказаться от сред, созданных людьми.

Ван описывает фреймворк как способ получить больше учебной ценности из меньшего набора качественных сред с надёжными проверяющими механизмами, которые задают эталон правильного ответа. EnvHarness не заменяет исходные среды, а усиливает их. Среды, спроектированные людьми, сохранят роль базового эталона, тогда как такие подходы, как EnvHarness, могут сократить трудозатраты на разработку и расширить охват каждой среды.