CodeAct: Защо изпълнимият Python код прави LLM агентите с 20% по-точни

След като прочетох статията „не могат да се самокоригират“ миналата седмица, естественият следващ въпрос е: ако LLM не могат надеждно да одитират собствения си резултат, кой формат на действие дава на агентите най-добрия шанс за автоматично откриване и възстановяване от грешки? CodeAct, публикуван от Xingyao Wang и др. и приет на ICML 2024, твърди, че отговорът е Python код — не защото кодът е магически, а защото интерпретаторът на Python предоставя точно този вид външна, детерминирана обратна връзка, от която литературата за самокорекция показва, че LLM отчаяно се нуждаят.

Научната статия

„Изпълнимите кодови действия извличат по-добри LLM агенти“ (arXiv:2402.01030) от Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng и Heng Ji предлага замяна на 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) получава един параграф. Изпълнението на произволен код във финансов контекст не е неудобен граничен случай — това е основният проблем със сигурността. Статията не разглежда какво се случва, когато агентът генерира код, който изтрива файлове, прави мрежови повиквания или импортира неочаквани библиотеки. За производствен счетоводен агент дизайнът на изолационната среда е поне толкова важен, колкото и форматът на действието.

Защо това е важно за финансовия изкуствен интелект

Проблемът с обратното записване в 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)