CodeAct: Waarom uitvoerbare Python-code LLM-agents 20% nauwkeuriger maakt

Na het lezen van het artikel over "niet in staat tot zelfcorrectie" vorige week, is een logische volgende vraag: als LLM's hun eigen output niet betrouwbaar kunnen controleren, welk actieformaat geeft agents dan de beste kans om fouten automatisch te detecteren en te herstellen? CodeAct, gepubliceerd door Xingyao Wang et al. en geaccepteerd op ICML 2024, stelt dat het antwoord Python-code is — niet omdat code magisch is, maar omdat een Python-interpreter precies het soort externe, deterministische feedback geeft waarvan de literatuur over zelfcorrectie laat zien dat LLM's die dringend nodig hebben.

Het artikel

"Executable Code Actions Elicit Better LLM Agents" (arXiv:2402.01030) door Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng en Heng Ji stelt voor om de JSON- en tekstactieformaten die gebruikelijk zijn bij tool-aanroepende agents te vervangen door uitvoerbare Python-code. Het kernidee is dat code een betere lingua franca is voor agent-acties dan natuurlijke taalinstructies of gestructureerde JSON, omdat code al control flow, gegevensafhankelijkheden en meerstapscompositie bevat — en omdat LLM's hierop intensief vooraf zijn getraind.

Het artikel levert drie bijdragen: (1) een conceptueel argument voor code als een verenigde actieruimte; (2) M3ToolEval, een nieuwe benchmark van 82 door mensen gecureerde taken die compositie van meerdere tools vereisen; en (3) CodeActAgent, een gefinetuned 7B-model getraind op CodeActInstruct, een dataset van 7.139 meerstaps code-gebaseerde trajecten die informatie-extractie, softwarepakketten, extern geheugen en robotplanning omvatten.

Belangrijkste ideeën

• Op M3ToolEval behaalt GPT-4 met CodeAct een succespercentage van 74,4% tegenover 53,7% met tekstacties — een absolute verbetering van ongeveer 20 procentpunten in de meest veeleisende setting met meerdere tools.
• CodeAct vereist ongeveer 30% minder interactierondes dan op JSON gebaseerde agents voor dezelfde taken. Minder rondes zijn belangrijk: elke extra interactie is een nieuwe kans voor foutvoortplanting.
• De Python-interpreter fungeert als een automatisch, kosteloos foutsignaal. Een verkeerde tussenberekening geeft onmiddellijk een uitzondering; de agent ziet de traceback en kan deze herzien zonder een aparte beoordelingsstap.
• Open-source modellen profiteren meer dan closed-source modellen. CodeActAgent (Mistral 7B) bereikt 12,2% op M3ToolEval tegenover 3,7% voor de voorheen sterkste open-source agent (Lemur-70B met tekst). Het voordeel is groter omdat Python overvloedig aanwezig is in trainingsdata; gespecialiseerde JSON-formaten voor tool-aanroepen zijn dat niet.
• CodeActInstruct traint op vier domeinen die specifiek zijn gekozen om compositie te testen: het zoeken naar informatie, pakketaanroepen, manipulatie van extern geheugen en robotplanning. Dit zijn allemaal meerstaps, toestandsafhankelijke taken — precies de scenario's waarin JSON-agents vastlopen.

Wat overeind blijft — en wat niet

De verbetering van 20% op M3ToolEval is aanzienlijk, maar M3ToolEval bevat slechts 82 taken. Dat is een kleine steekproef en het artikel vermeldt geen betrouwbaarheidsintervallen. De benchmark is ook gecureerd door hetzelfde team dat de methode voorstelt, wat gebruikelijk is in het veld maar wel kritisch moet worden bekeken. Ik zou dit graag gereproduceerd zien op een volledig onafhankelijke benchmark voordat ik 74,4% als een definitief cijfer beschouw.

De claim over efficiëntie — 30% minder rondes — is aannemelijk, maar combineert twee zaken. Minder rondes kan betekenen dat de agent per stap nauwkeuriger is, of het kan betekenen dat fouten eerder leiden tot het beëindigen van de taak. Het artikel ontleedt dit niet duidelijk.

De erkende kloof tussen open- en closed-source modellen is groot en wordt niet weggenomen door CodeAct. CodeActAgent (Mistral 7B) is met 12,2% veel beter dan Lemur-70B met 3,7%, maar GPT-4 met CodeAct zit op 74,4%. Het formaat helpt, maar het dicht geen capaciteitskloof van 60 punten. Iedereen die van plan is een open-source Beancount-agent in te zetten, moet dat getal goed bestuderen.

De kwestie van sandboxing krijgt slechts één alinea. Willekeurige code-uitvoering in een financiële context is geen onbelangrijk randgeval — het is het primaire beveiligingsrisico. Het artikel gaat niet in op wat er gebeurt als de agent code genereert die bestanden verwijdert, netwerkverbindingen maakt of onverwachte bibliotheken importeert. Voor een productie-accounting-agent is het ontwerp van de sandbox minstens zo belangrijk als het actieformaat.

Waarom dit belangrijk is voor finance AI

Het Beancount-terugschrijfprobleem is in feite het probleem waarvoor CodeAct is ontworpen: een agent moet meerdere bewerkingen combineren (huidig saldo lezen, transactie valideren, een nieuwe boeking schrijven, de balansvergelijking controleren) in een specifieke volgorde, waarbij gegevens tussen de stappen doorstromen. JSON-tool-aanroepen gaan hier slecht mee om omdat elke aanroep geïsoleerd is. Python handelt dit natuurlijk af.

Concreter: een Beancount-agent in CodeAct-stijl zou een volledige reconciliatie-workflow kunnen uitdrukken als een enkel Python-script — het grootboek opvragen via een bibliotheek, verschillen berekenen, nieuwe boekingen voorstellen en bean-check uitvoeren op het resultaat — allemaal voordat er iets definitief wordt opgeslagen. De interpreter vangt de overduidelijke fouten op; de LLM hoeft alleen de semantische fouten af te handelen. Dat is een betere taakverdeling dan de LLM vragen om zijn eigen JSON te valideren.

De veiligheidszorg werkt ook de andere kant op. Een agent met onbeperkte Python-uitvoering over een financieel grootboek is een aanzienlijk aanvalsoppervlak. Het juiste ontwerp is vrijwel zeker een zwaar beperkte sandbox — geen schrijfacties naar het bestandssysteem buiten een aangewezen tijdelijke map, geen netwerktoegang, geen shell-commando's — gecombineerd met een verplichte bean-check-controle voordat een bestand wordt aangeraakt. CodeAct geeft je het actieformaat; de kooi moet je zelf nog bouwen.

Wat je nu kunt lezen

• OpenHands (voorheen OpenDevin) — het productie-agentsysteem gebouwd op CodeAct door dezelfde onderzoeksgroep; laat zien hoe de sandboxing en de uitvoeringsomgeving daadwerkelijk zijn geïmplementeerd (arXiv:2407.16741)
• ToolBench / ToolLLM — benchmarks en trainingsdata voor tool-aanroepende agents die REST-API's gebruiken in plaats van Python; een nuttig contrast met de code-eerst benadering van CodeAct (arXiv:2307.16789)
• SWE-bench — evalueert agents op echte GitHub-issues, wat meerstaps code-uitvoering en bestandsbewerking vereist; de meest relevante bestaande benchmark voor wat een Beancount-terugschrijfagent zou moeten kunnen (arXiv:2310.06770)