🤖 machine learning

AlloBench: Measuring Online Tool Allocation Capability in LLM Agents

Het AlloBench-paper introduceert een gekoppelde benchmark die aantoont dat hoewel frontier LLM-agenten in abstracte tekstgebaseerde scenario's bijna optimaal tools kunnen toewijzen, ze er consequent niet in slagen deze strategische capaciteit over te dragen naar praktische code-constructie-taken, wat een significante capaciteitsgrens onthult in online tooltoewijzing.

Oorspronkelijke auteurs: Daniel Wang, Andrew Xu

Gepubliceerd 2026-07-28

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Daniel Wang, Andrew Xu

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat jij de kapitein bent van een ruimteschip met een zeer beperkte brandstofvoorraad. Je vliegt door een asteroïdengordel waar sommige asteroïden gewoon zwevende rotsen zijn, maar andere goudmijnen zijn die steeds opnieuw verschijnen. Jouw taak is om te beslissen: gebruik je nu je kostbare brandstof om een enorme magneet te bouwen om het goud te vangen, of wacht je af om te zien of het goud blijft verschijnen? Als je de magneet te vroeg bouwt, verspil je misschien je brandstof aan een eenmalige rots. Als je te lang wacht, mis je misschien een goudmijn die herhaaldelijk voorkomt. Dit is de dagelijkse strijd van "AI-agenten"—slimme computerprogramma's die proberen ons te helpen door hulpmiddelen te maken, zoals het schrijven van code of het creëren van snelkoppelingen. De grote vraag die wetenschappers zich stellen is: kunnen deze AI-agenten leren om slimme investeerders te zijn met hun eigen "brandstof" (tijd en rekenkracht), of raken ze in paniek en bouwen ze voor elk probleem dat ze zien een hulpmiddel, zelfs als dat verspilling is?

Dit artikel introduceert een nieuwe test genaamd AlloBench om te zien of de slimste AI-modellen ter wereld deze slimme investeringsbeslissingen kunnen nemen. De onderzoekers hebben een spel opgezet waarbij een AI een stroom van 60 verschillende wiskundepuzzels moet oplossen. Sommige puzzels zijn "heet" (ze komen veel voor) en sommige zijn "vallen" (ze verschijnen slechts één keer). De AI heeft een strikt budget: hij kan slechts voor 3 van deze puzzeltypen een herbruikbaar hulpmiddel (een script) bouwen. Als de AI een hulpmiddel voor een val bouwt, verspilt hij een plek en kan hij later geen hulpmiddel meer bouwen voor een hete puzzel. Het doel is om te wachten, naar een patroon te kijken en dan pas een hulpmiddel te bouwen wanneer de AI zeker weet dat het de moeite waard is.

De resultaten lijken een beetje op het kijken naar een genie dat een wiskundetoets met vlag en wimpel haalt, maar vervolgens faalt om die logica toe te passen op het echte leven. Wanneer de onderzoekers de AI vroegen om het spel op een eenvoudige, abstracte manier te spelen—zoals het sorteren van gekleurde ballen in emmers—waren de beste modellen (waaronder Claude Haiku, Claude Opus en GPT-5) verrassend goed. Ze wachtten geduldig, observeerden de herhalende kleuren en bouwden pas een "emmer" wanneer ze er zeker van waren dat het de moeite waard was. Ze gedroegen zich als perfecte investeerders.

Echter, op het moment dat de onderzoekers het spel veranderden naar iets realistischer—door de AI daadwerkelijk computercode te laten schrijven om de puzzels op te lossen—leek het brein van de AI kortsluiting te maken. Ondanks dat de puzzels exact hetzelfde waren, stopten de modellen met wachten. In plaats van te controleren of een puzzeltype een "hete" herhaling was, schreven ze onmiddellijk een script voor de allereerste puzzel die ze zagen. Ze verspilden hun volledige budget van 3 hulpmiddelen aan de eerste drie problemen, zelfs als die problemen zeldzame "vallen" waren die nooit meer zouden verschijnen.

Het artikel stelt vast dat dit falen specif으로 optreedt wanneer de AI wordt gedwongen om code te genereren. Het is alsof de AI een "doe het nu"-schakelaar heeft die blijft hangen wanneer hij code moet typen, waardoor hij vergeet na te denken over de toekomst. De onderzoekers probeerden een kleiner, open-source AI-model te trainen om een betere investeerder te zijn in het abstracte spel, en dat model leerde perfect te wachten. Maar toen ze datzelfde getrainde AI aan vroegen om code te schrijven, vergat het alles wat het had geleerd en ging het terug naar het onmiddellijk verspillen van zijn hulpmiddelen.

Kortom, het artikel laat zien dat hoewel moderne AI-agenten briljant zijn in abstracte planning, ze momenteel moeite hebben om die geduldige houding over te dragen naar de rommelige, echte wereldtaak van het schrijven van software. Ze weten in theorie wanneer ze een hulpmiddel moeten bouwen, maar de handeling van het daadwerkelijk schrijven van de code lijkt hen impulsief te maken, waardoor ze hun middelen te snel verbruiken. Dit suggereert dat voor AI om echt een behulpzame partner te worden bij het bouwen van software, we moeten uitzoeken hoe we hen kunnen stoppen met het overhaast schrijven van code voordat ze hebben gecontroleerd of het eigenlijk wel de moeite waard is.

Technische Samenvatting: ALLOBENCH: HET METEN VAN ONLINE TOOL ALLOCATIE-CAPABILITEIT IN LLM-AGENTS

Probleemstelling

Large Language Model (LLM) agents krijgen steeds vaker de taak om herbruikbare tools (scripts, macro's, wrappers) te creëren om terugkerende taken op te lossen. Terwijl bestaande benchmarks evalueren of een model een correcte tool kan schrijven of kan selecteren uit een bestaande bibliotheek, falen ze grotendeels in het meten van de fundamentele beslissing van wanneer een tool te creëren.

Toolconstructie brengt een vaste kost met zich mee (tijd, tokens, actiebudget), maar biedt het potentieel voor toekomstig hergebruik. Een optimale agent moet de balans vinden tussen het risico op het verspillen van middelen aan zeldzame, eenmalige taken en de opportuniteitskosten van het te lang wachten om frequente, terugkerende taken te vangen. Dit is een online leerprobleem onder onzekerheid. Het artikel stelt dat huidige frontier-modellen mogelijk niet in staat zijn om deze afweging rationeel te maken, met name wanneer het proces van toolcreatie het genereren van code omvat.

Methodologie: AlloBench

De auteurs introduceren AlloBench, een gekoppelde benchmark die ontworpen is om budgetbewust tool-investeringsgedrag te testen over een "framing ladder" die overgaat van abstracte naar volledig constructieve contexten.

Experimentele Opzet

Taakstroom: Een episode bestaat uit een verborgen sequentie van $T=60$ taken afkomstig uit $N=8$ latente klassen.
Distributie: Drie klassen zijn "hot" (hoge frequentie, ~13–23 voorkomens) en vijf zijn "traps" (lage frequentie, ~1–6 voorkomens).
Budget: De agent heeft een vast budget $B=3$ om tools te creëren.
Mechanisme: Bij elke beurt observeert de agent een instantie van een taak. Als de taak behoort tot een klasse waarvoor nog geen tool bestaat en het budget nog niet is uitgeput, kiest de agent ervoor om te COMMIT (een tool creëren, wat budget verbruikt) of te PASS (wachten). Als er een tool bestaat, wordt deze automatisch toegepast.
Beloning: De agent verdient één punt voor elke taakinstantie die wordt opgelost (ofwel door een reeds bestaande tool, ofwel door te passeren als er geen tool nodig is, hoewel passeren 0 punten oplevert voor die specifieke instantie). Het doel is om de totale utiliteit te maximaliseren door zoveel mogelijk "hot" klasse-voorkomens te vangen en "trap" klassen te vermijden.

De Framing Ladder

Om te isoleren waar allocatie-capabiliteiten falen, worden dezelfde taakstromen weergegeven in vier verschillende frames:

R0 (Abstract): Het model ziet gekleurde ballen en kiest tussen KEEP/PASS via vrije tekst. Er is geen code bij betrokken.
R1 (Declaratief): Het model ziet numerieke problemen en maakt declaratieve KEEP/PASS tool-aanroepen. Er is geen codegeneratie.
R2 (Code): Het model moet een niet-lege Python solve(inputs) functie genereren om een klasse te claimen. De correctheid van de code wordt niet geëvalueerd voor de beloning, maar de generatie is vereist.
R3 (Full): Het model moet een script schrijven, uitvoeren en hergebruiken. Correctheid is vereist zodat het script wordt erkend.

Metrieken

First-Sight Commitment Rate: Het fractie van commitments gemaakt op de allereerste verschijning van een klasse. Optimaal gedrag dicteert het wachten op bewijs van herhaling; hoge rates duiden op "eager" (suboptimale) het gedrag.
Score: Een competitieve ratio die de gerealiseerde utiliteit vergelijkt met het theoretische hindsight-optimum (de som van de groottes van de $B$ grootste klassen).

Belangrijkste Bijdragen

AlloBench Benchmark: Een generaliseerbare, gekoppelde benchmark voor het bestuderen van budgetbewuste tool-investering.
Kwantitatieve Scoring: Een metriek om allocatieprestaties van modellen eerlijk te vergelijken, waarbij timing wordt gescheiden van de toolcreatie-capabiliteit.
Ontdekking van een Capability Wall: Bewijs dat frontier-modellen optimaal kunnen alloceren in abstracte settings, maar falen in het overdragen van deze vaardigheid naar toolcreatie.
Lokalisatie van Falen: Identificatie van "code emission" (R2) als de primaire trigger voor allocatiefalen in de meeste modellen, en "full construction" (R3) voor de sterkste modellen.
Beperkingen van Post-Training: Demonstratie dat reinforcement learning (RL) policies getraind op abstracte allocatie niet generaliseren naar numerieke of code-gebaseerde framing.

Experimentele Resultaten

De studie evalueerde vier frontier-modellen (Claude Haiku 4.5, Claude Opus 4.8, GPT-5.4-mini, GPT-5.6 Sol) en een open-source model (Qwen2.5-Coder-14B).

1. Abstracte Competentie vs. Tool-Budgettering Falen

Alle vier de frontier-modellen vertoonden bijna-optimale allocatie in de R0 (Abstract) frame, waarbij ze in >70% van de gevallen wachtten op bewijs van herhaling voordat ze committen. Deze competentie stortte echter in in R3 (Full Construction). In R3 wachtte geen enkel model langer dan 12% van de tijd op herhaling; ze committen bijna onmiddellijk bij de eerste verschijning.

2. Lokalisatie van de Foutmodus

Door de transitie over de framing ladder te analyseren, identificeerden de auteurs de specifieke trigger voor het falen:

Haiku, Opus en GPT-5.4-mini: Deze modellen behielden redelijke allocatie in R0 en R1 (declaratief). Hun allocatievermogen stortte drastisch in bij R2 (Code), waar ze werden vereist om code te emitteren, zelfs als de correctheid van de code niet werd gecontroleerd.
GPT-5.6 Sol: Dit model behield enige allocatie-vaardigheid in R2 (39% first-sight commitment) maar stortte pas in bij R3 (Full Construction), waar scripts moeten worden uitgevoerd en geverifieerd.

3. Post-Training en Generalisatie

De auteurs fine-tuned het Qwen2.5-Coder-14B model met behulp van PPO om de utiliteit in de abstracte R0 te maximaliseren.

Succes: Het post-getrainde model verminderde de first-sight commitment rate in R0 van 74% naar 6% en generaliseerde dit gedrag naar lexicale reskins (bijv. munten in plaats van ballen).
Falen: De geleerde policy vertransferase niet naar R1 (Declaratief) of R2 (Code). Ondanks dat het model getraind was om selectief te zijn in abstracte termen, keerde het terug naar eager commitment wanneer het werd geconfronteerd met numerieke problemen of code-vereisten.

4. Economische Gevoeligheid

In een economische gevoeligheidsanalyse (het variëren van de kosten van toolcreatie) werd de abstracte policy (R0) selectiever naarmate de kosten toenamen, waarbij het de theoretische optimum volgde. In contrast hiermee bleef de code-vereiste policy (R2) inelastisch, en bleef tools bouwen tegen bijna-100% rates, zelfs wanneer de kosten zo hoog waren dat de optimale strategie bijna niets zou bouwen.

Betekenis en Claims

Het artikel stelt dat online tool allocatie een significante grens vormt voor de capabiliteit van moderne frontier-modellen.

Framing Gap: Er is een fundamentele disconnect tussen het vermogen van een model om over hulpbronnen te redeneren in abstracte zin en het vermogen om die redenering uit te voeren wanneer de taak het genereren van code behelst. De auteurs vermoeden dat dit wordt veroorzaakt door post-training op coding datasets (bijv. DeepSWE), die stromen van ongerelateerde problemen met onafhankelijke beloningen presenteren, wat modellen conditioneert om te focussen op de directe instantie in plaats van te "investeren voor later".
Systeemontwerp Implicaties: Huidige tool-bouwende agent-systemen kunnen niet tegelijkertijd budgetallocatie en toolcreatie beheren. De auteurs suggereren dat toekomstige systemen deze taken moeten ontkoppelen: één agent moet de abstracte beslissing nemen om te investeren (gebaseerd op R1-achtige logica), terwijl een aparte agent de constructie afhandelt.
Evaluatiebeperkingen: Bestaande benchmarks vervagen de capaciteit voor toolcreatie met de capaciteit voor allocatie. Een model kan falen in een taak, niet omdat het niet in staat is een tool te schrijven, maar omdat de allocatiepolicy wordt onderdrukt door de constructieve framing.

Het artikel concludeert dat hoewel modellen de latente capaciteit bezitten voor optimale online investering, deze capaciteit momenteel wordt onderdrukt door de specifieke vereisten van code-emissie en uitvoering, een fenomeen dat nog niet is opgelost door standaard post-training technieken.