CodeAct: почему исполняемый код Python делает LLM-агентов на 20% точнее

После прочтения на прошлой неделе статьи о том, что LLM «не могут самокорректироваться», возникает закономерный вопрос: если LLM не способны надежно проверять собственные результаты, какой формат действий дает агентам наилучшие шансы на автоматическое обнаружение и исправление ошибок? В работе CodeAct, опубликованной Синъяо Ваном и др. и принятой на ICML 2024, утверждается, что ответом является код Python — не потому, что код обладает магическими свойствами, а потому, что интерпретатор Python обеспечивает именно ту внешнюю детерминированную обратную связь, в которой, как показывают исследования самокоррекции, LLM остро нуждаются.

Статья

В статье «Executable Code Actions Elicit Better LLM Agents» (arXiv:2402.01030) Синъяо Ван, Янъи Чэнь, Лифань Юань, Ичжэ Чжан, Юньчжу Ли, Хао Пэн и Хэн Цзи предлагают заменить форматы действий JSON и текстовые инструкции, обычные для агентов с вызовом инструментов, исполняемым кодом Python. Основная идея заключается в том, что код является лучшим универсальным языком для действий агентов, чем инструкции на естественном языке или структурированный JSON, поскольку код уже содержит управляющую логику, зависимости данных и многошаговые композиции — и потому, что LLM интенсивно обучались на нем.

Работа вносит три вклада: (1) концептуальный аргумент в пользу кода как единого пространства действий; (2) M3ToolEval, новый бенчмарк из 82 задач, отобранных вручную и требующих использования нескольких инструментов; и (3) CodeActAgent, дообученная модель 7B, обученная на CodeActInstruct — наборе данных из 7 139 многоходовых траекторий на основе кода, охватывающих поиск информации, программные пакеты, внешнюю память и планирование роботов.

Ключевые идеи

• На бенчмарке M3ToolEval GPT-4 с CodeAct достигает показателя успеха 74,4% по сравнению с 53,7% при использовании текстовых действий — это абсолютное улучшение примерно на 20 процентных пунктов в самых сложных сценариях с использованием нескольких инструментов.
• CodeAct требует примерно на 30% меньше итераций взаимодействия, чем агенты на базе JSON для тех же задач. Сокращение числа итераций важно: каждый лишний цикл — это еще одна возможность для накопления и распространения ошибок.
• Интерпретатор Python выступает в роли автоматического бесплатного сигнала об ошибке. Неправильное промежуточное вычисление немедленно вызывает исключение; агент видит трассировку стека (traceback) и может внести правки без отдельного этапа критического анализа.
• Модели с открытым исходным кодом выигрывают больше, чем закрытые. CodeActAgent (Mistral 7B) достигает 12,2% на M3ToolEval по сравнению с 3,7% у ранее сильнейшего открытого агента (Lemur-70B с текстом). Эффект выше, потому что Python широко представлен в данных для предварительного обучения, в отличие от специализированных форматов вызова инструментов через JSON.
• CodeActInstruct обучает на четырех областях, специально выбранных для стресс-тестирования композиции: поиск информации, вызовы пакетов, манипуляция внешней памятью и планирование роботов. Все это многошаговые задачи, зависящие от состояния — именно те сценарии, в которых агенты на базе JSON терпят неудачу.

Что подтверждается — а что нет

Улучшение на 20% в M3ToolEval выглядит впечатляюще, но в этом бенчмарке всего 82 задачи. Это небольшая выборка, и в статье не указаны доверительные интервалы. Бенчмарк также подготовлен той же командой, которая предлагает метод, что является стандартом в отрасли, но заслуживает внимания. Я бы хотел увидеть воспроизведение этого результата на полностью независимом бенчмарке, прежде чем считать 74,4% надежным показателем.

Утверждение об эффективности — на 30% меньше итераций — правдоподобно, но объединяет две вещи. Меньшее количество итераций может означать, что агент точнее на каждом шаге, или что сбои приводят к более раннему завершению работы. В статье эти факторы четко не разделяются.

Признанный разрыв между моделями с открытым и закрытым исходным кодом велик и не устраняется с помощью CodeAct. CodeActAgent (Mistral 7B) с результатом 12,2% намного лучше, чем Lemur-70B с 3,7%, но GPT-4 с CodeAct показывает 74,4%. Формат помогает, но он не перекрывает 60-пунктовый разрыв в способностях. Любому, кто планирует внедрять агента Beancount с открытым исходным кодом, следует внимательно отнестись к этим цифрам.

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

Почему это важно для финансов и ИИ

Проблема записи данных обратно в Beancount (write-back) — это, по сути, та задача, для которой разработан CodeAct: агенту необходимо составить последовательность из нескольких операций (чтение текущего баланса, валидация транзакции, запись новой проводки, проверка уравнения баланса) в определенном порядке, передавая данные между шагами. Вызов инструментов через JSON справляется с этим плохо, так как каждый вызов изолирован. Python справляется с этим естественным образом.

Если говорить более конкретно: агент Beancount в стиле CodeAct может выразить весь рабочий процесс сверки в виде единого скрипта Python — запрашивая данные из реестра через библиотеку, вычисляя разницу, предлагая новые записи и запуская bean-check для проверки результата — и все это до фиксации изменений. Интерпретатор отлавливает очевидные ошибки; LLM остается только обрабатывать семантические. Это лучшее разделение труда, чем требовать от LLM валидации собственного JSON.

Соображения безопасности имеют и обратную сторону. Агент с неограниченным выполнением кода Python в финансовом реестре — это значительная поверхность атаки. Правильным решением почти наверняка будет строго ограниченная песочница — запрет на запись в файловую систему за пределами временного каталога, отсутствие доступа к сети, отсутствие консольных команд — в сочетании с обязательной проверкой bean-check перед любым изменением файлов. CodeAct дает формат действий, но «клетку» для него все равно придется строить вам.

Что почитать дальше

• OpenHands (ранее OpenDevin) — промышленная система агентов, построенная на CodeAct той же исследовательской группой; показывает, как на самом деле реализованы песочница и среда выполнения (arXiv:2407.16741)
• ToolBench / ToolLLM — бенчмарки и данные для обучения агентов, использующих REST API вместо Python; полезный контраст с подходом CodeAct, ориентированным на код (arXiv:2307.16789)
• SWE-bench — оценивает агентов на реальных проблемах GitHub, что требует многошагового выполнения кода и редактирования файлов; наиболее близкий из существующих бенчмарков к тому, что должен проходить агент записи в Beancount (arXiv:2310.06770)