Открытая платформа EnvHarness от Google позволяет агентам искусственного интеллекта обучаться в средах, которые меняются вместе с ними.

Бен Диксон

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

Исследователи из Google Cloud AI Research и их академические партнеры разработали фреймворк с открытым исходным кодом (лицензия Apache 2.0), который превращает эти статические среды в среды, способные адаптироваться к слабым сторонам использующего их агента.

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

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

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

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

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

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

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

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

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

Например, GenEnv — это фреймворк, использующий LLM в качестве симулятора, который генерирует переходы, наблюдения и сигналы об успехе, стараясь при этом выполнять задачи в пределах возможностей агента. Другой метод — Agent-World , который программно синтезирует исполняемые инструменты, базы данных и задачи для создания новых сред.

Однако создание среды порождает свои проблемы. Эти конвейеры, как правило, привязаны к конкретным областям, и сгенерированные среды необходимо проверять на корректность. LLM, выступающий в роли симулятора, может создавать некорректные переходы или дрейфующие сигналы обратной связи. Между тем, исполняемые среды, синтезированные с нуля, могут содержать логические ошибки.

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

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

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

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

Проще говоря:

Агент = модель + инструмент для работы с агентом

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

Индивидуально настроенная среда = статическая среда + EnvHarness

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

Данная структура включает три компонента.

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

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

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

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

EnvRigger работает по циклу «Наблюдение → Диагностика → Запись → Проверка». Сначала он несколько раз запускает агента и анализирует его успешные и неудачные траектории на предмет повторяющихся ошибок. На основе полученных данных он создает компоненты EnvHarness, предназначенные для выявления или исправления ошибок, и запускает новые траектории, чтобы проверить, создают ли внесенные изменения полезный и решаемый обучающий пример.

Ван приводит пример программиста, который идет на компромисс и отправляет патч, не запустив предварительно тесты. «Когда система обнаруживает, что агент использует небрежный подход, например, отправляет патч кода без запуска каких-либо тестов, она автоматически создает правило плагина для перехвата такой преждевременной отправки и возвращает предупреждение, заставляя агента сначала правильно запустить набор тестов», — сказал он.

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

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

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

EnvHarness в действии

Исследователи протестировали EnvHarness на платформах ALFWorld, WebArena, SWE-bench Verified, OfficeQA и SpreadsheetBench.

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

В тесте SWE-bench Verified, помимо повышения точности, тренировка с использованием EnvHarness привела к среднему сокращению траектории с 55,01 до 49,61 шагов.

EnvHarness также показал себя с лучшей стороны по сравнению с системами, специально разработанными для создания обучающих сред. В тесте SWE-bench Verified он превзошел SWE-smith на 2,46 процентных пункта, при этом требуя на 5,11 шагов меньше на эпизод. В тесте ALFWorld он превзошел GenEnv в среднем на 5,7 пункта.

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

В статье представлены результаты экспериментов по масштабированию, демонстрирующие эффект этой адаптации. На SWE-bench Verified базовый агент начал с 47,67% и достиг 54,79% по мере увеличения пула обучающих сред EnvHarness до 300. Обучение на том же количестве исходных сред достигло 52,13%, в то время как обучение в средах, сгенерированных SWE-smith, достигло 50,37%. Кривые для исходных и сгенерированных сред выровнялись раньше, в то время как EnvHarness продолжал создавать обучающие среды, ориентируясь на новейшие возможности агента.

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

Что необходимо предприятиям для использования EnvHarness

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

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

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

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

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

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

Ван говорит, что в случае контейнеризированных рабочих процессов разработки программного обеспечения интеграция может располагаться вне самой среды. «Корпоративные конвейеры CI/CD обычно запускают среды внутри изолированных контейнеров Docker или Kubernetes, а EnvHarness просто подключается в качестве легковесного внешнего плагина поверх существующего средства запуска тестов», — сказал он. Для сред, которые уже предоставляют необходимую схему взаимодействия «сброс и пошаговое выполнение», это означает, что команды могут сохранять образ контейнера, кодовую базу и внутренние модульные тесты в неизменном виде, в то время как EnvHarness перехватывает команды на уровне интерфейса.

Вторая статья расходов — вычислительные ресурсы. «Компромисс с EnvHarness больше связан с вычислительными затратами, чем с архитектурными», — сказал Ван. Эксплуатационные расходы возникают из-за цикла EnvRigger, для которого требуется развертывание нескольких агентов, чтобы диагностировать уязвимость, внести изменения и проверить, остается ли она устранимой.

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

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

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

«EnvHarness не заменяет базовые среды — он выступает в качестве усилителя для них», — сказал Ван. «Хотя созданные человеком среды будут по-прежнему служить эталоном, такие подходы, как EnvHarness, могут предложить практический путь к снижению затрат на разработку и получению большего охвата от каждой среды».

Источник: venturebeat.com