CodeAct: Чому виконуваний код Python робить LLM-агентів на 20% точнішими

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

Стаття

"Executable Code Actions Elicit Better LLM Agents" (arXiv:2402.01030) Сін'яо Вана, Яньї Ченя, Ліфаня Юаня, Ічже Чжана, Юньчжу Лі, Хао Пена та Хен Цзі пропонує замінити формати дій JSON і текст, поширені в агентах із викликом інструментів, виконуваним кодом Python. Основна ідея полягає в тому, що код є кращою lingua franca для дій агентів, ніж інструкції природною мовою або структурований 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 є реальним, але M3ToolEval містить лише 82 завдання. Це невелика вибірка, і в статті не наводяться довірчі інтервали. Тест також підготовлений тією ж командою, яка пропонує метод, що є стандартним для галузі, але на це варто звернути увагу. Я хотів би побачити реплікацію цього на повністю незалежному тесті, перш ніж вважати 74,4% надійним показником.

Твердження про ефективність — на 30% менше ітерацій — виглядає правдоподібним, але змішує дві речі. Менша кількість ітерацій може означати, що агент точніший на кожному кроці, або це може означати, що помилки призводять до завершення раніше. Стаття не розмежовує це чітко.

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

Питання пісочниці (sandboxing) присвячено один абзац. Виконання довільного коду у фінансовому контексті — це не просто незручний випадок, це головна проблема безпеки. Стаття не розглядає, що відбувається, коли агент генерує код, який видаляє файли, робить мережеві виклики або імпортує несподівані бібліотеки. Для промислового бухгалтерського агента дизайн пісочниці є принаймні таким же важливим, як і формат дій.

Чому це важливо для фінансового ШІ

Проблема зворотного запису (write-back) у Beancount — це, по суті, та сама проблема, для якої розроблено 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)