💬 NLP

Benchmark Test-Time Scaling of General LLM Agents

Deze paper introduceert General AgentBench, een unificerend benchmarkkader dat aantoont dat bestaande LLM-agents aanzienlijk prestatieverlies lijden bij de overstap naar algemene taken en dat noch sequentiële noch parallele test-time scaling effectief is vanwege contextlimieten en een verificatiekloof.

Oorspronkelijke auteurs: Xiaochuan Li, Ryan Ming, Pranav Setlur, Abhijay Paladugu, Andy Tang, Hao Kang, Shuai Shao, Rong Jin, Chenyan Xiong

Gepubliceerd 2026-02-24

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Xiaochuan Li, Ryan Ming, Pranav Setlur, Abhijay Paladugu, Andy Tang, Hao Kang, Shuai Shao, Rong Jin, Chenyan Xiong

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 je een super-intelligente robot hebt die je kunt vragen om van alles: een recept zoeken, een stukje code schrijven, een complexe wiskundepuzzel oplossen of een reis plannen. In de wereld van kunstmatige intelligentie (AI) noemen we dit een "Agent".

Deze nieuwe studie, getiteld "Benchmark Test-Time Scaling of General LLM Agents", onderzoekt hoe goed deze robots echt zijn als je ze in de echte wereld zet, in plaats van in een beveiligde testomgeving.

Hier is de uitleg in simpele taal, met een paar creatieve vergelijkingen:

1. Het Probleem: De "Zandbak" vs. De "Stad"

Tot nu toe werden AI-robots getest in speciale "zandbakken".

De zandbak: Stel je voor dat je een robot test om alleen auto's te repareren. Je geeft hem alleen gereedschap voor auto's en vraagt hem alleen auto-reparaties. Hij doet het geweldig!
De echte stad: Maar in het echte leven moet die robot ook boodschappen doen, een brief schrijven en een kookrecept zoeken. Hij moet kunnen schakelen tussen gereedschappen voor auto's, schrijvers en koks, zonder dat iemand hem vertelt wat hij moet doen.

De onderzoekers hebben een nieuwe test ontwikkeld, genaamd General AgentBench. Dit is als het overbrengen van de robot uit de zandbak naar de drukke stad. Ze geven de robot één grote lijst met alle mogelijke gereedschappen (zoals een zoekmachine, een programmeertaal, een rekenmachine) en laten hem zelf beslissen welk gereedschap hij moet gebruiken voor een willekeurige vraag.

Het resultaat? De robots doen het veel slechter dan verwacht. Net als een auto-expert die in paniek raakt als hij plotseling moet koken, zakken de scores van de slimste AI-modellen met wel 30% als ze uit hun speciale vakgebied worden gehaald.

2. De Oplossing: "Meer denken" werkt niet altijd

Mensen denken vaak: "Als een robot een taak niet lukt, laten we hem dan gewoon langer laten nadenken of hem meer keer laten proberen." In de AI-wereld noemen ze dit Test-Time Scaling. De onderzoekers keken naar twee manieren om dit te doen:

A. De "Lange Gesprekslijn" (Sequentiële Scaling)

Stel je voor dat je een robot vraagt een moeilijk probleem op te lossen. Je zegt: "Blijf maar doorgaan met nadenken, schrijf je gedachten op, en als je vastloopt, denk dan nog eens na."

Wat de onderzoekers zagen: In het begin helpt dit. De robot vindt een oplossing. Maar na een tijdje wordt de "gesprekslijn" (de context) zo lang en rommelig dat de robot de draad kwijtraakt.
De analogie: Het is alsof je een vriend vraagt een verhaal te vertellen. Als hij te lang doorgaat zonder pauze, begint hij zichzelf te herhalen, vergeet hij het begin van het verhaal, en raakt hij in de war. Er is een "Context Ceiling" (een plafond): op een gegeven moment helpt meer nadenken niet meer; het maakt het juist erger.

B. De "Meerdere Opties" (Parallelle Scaling)

Stel je voor dat je de robot niet één keer, maar tien keer laat proberen om een probleem op te lossen. Je hoopt dat hij er één keer een perfect antwoord op bedenkt.

Het probleem: De robot moet nu niet alleen het goede antwoord vinden, maar ook herkennen dat het het goede antwoord is.
De analogie: Het is alsof je tien studenten een examen laat maken. Ze maken allemaal een antwoord. Maar nu moet je (de robot) zelf kiezen welk antwoord het juiste is. De onderzoekers zagen dat de robot vaak het goede antwoord produceerde, maar dan dacht: "Nee, dat is fout," en koos een verkeerd antwoord. Dit noemen ze de "Verification Gap" (een gat in de controle). De robot is goed in maken, maar slecht in controleren.

3. De Belangrijkste Conclusies

De studie leert ons drie belangrijke dingen:

Specialisten zijn beter dan Generalisten (voor nu): AI-modellen zijn geweldig als ze zich op één ding richten (zoals alleen coderen), maar ze struikelen als ze alles tegelijk moeten doen. De echte wereld is chaotisch, en de robots zijn daar nog niet helemaal klaar voor.
Meer tijd = niet altijd beter: Als je een robot te lang laat nadenken over één vraag, raakt hij in de war. Er is een limiet aan hoe lang een gesprek kan duren voordat het nutteloos wordt.
Meer pogingen = niet altijd beter: Als je een robot laat proberen om 10 keer een antwoord te geven, heeft hij vaak het goede antwoord in zijn hoofd, maar kan hij het niet herkennen. Hij mist het vermogen om te zeggen: "Hey, dit is het juiste antwoord!"

Samenvatting

Deze paper is als een realiteitscheck voor de AI-industrie. We dachten dat we onze slimme robots gewoon "slimmer" konden maken door ze meer tijd en meer rekenkracht te geven. Maar de onderzoekers tonen aan dat we eerst moeten leren hoe we ze beter kunnen laten organiseren en controleren, voordat we ze zomaar in de drukke stad van de echte wereld kunnen zetten.

De code en de testomgeving zijn openbaar gemaakt, zodat iedereen kan meehelpen om deze robots echt "algemeen" en betrouwbaar te maken.

1. Het Probleem

Huidige benchmarks voor Large Language Model (LLM) agents zijn over het algemeen gespecialiseerd op specifieke domeinen (zoals software-engineering met Docker of webnavigatie met een browserinterface). Hoewel deze nuttig zijn voor het ontwikkelen van gespecialiseerde agents, sluiten ze niet aan bij de realiteit van gebruikersinteracties.

De Kloof: Real-world gebruikersverzoeken zijn vaak open-ended, multi-domein en vereisen dat een agent plannen maakt, redeneert en tools gebruikt binnen een onvoorspelbare omgeving.
Beperking van Bestaande Benchmarks: Bestaande benchmarks evalueren agents in geïsoleerde omgevingen met een beperkte set tools. Ze overschatten vaak de robuustheid van een model omdat ze niet testen of een agent kan schakelen tussen verschillende vaardigheden (zoals zoeken, coderen en redeneren) binnen één uniforme context.
Test-Time Scaling: Er is onzekerheid over hoe "test-time scaling" (het toewijzen van meer rekenkracht tijdens de inferentie, zoals meer iteraties of meerdere samples) werkt voor generale agents in deze complexe, gelaagde omgevingen.

2. Methodologie: General AgentBench

De auteurs introduceren General AgentBench, een nieuw benchmark-framework ontworpen om generale LLM-agents te evalueren onder realistische, gelaagde omstandigheden.

Unificatie van Domeinen: Het benchmark combineert vier domeinen in één framework:
1. Zoeken (Search): Taken van BrowseComp en WebVoyager (informatie zoeken in complexe webcontexten).
2. Coderen (Coding): Taken van SWE-Bench Verified en Terminal-Bench (softwareproblemen oplossen).
3. Redeneren (Reasoning): Taken van MathHay (wiskundig redeneren in lange contexten met "haystack"-vervuiling).
4. Tool-gebruik (Tool-use): Taken van Tau2-Bench en MCP-Bench (coördinatie van meerdere tools in workflows).
Unificatie van Tools (MCP): In plaats van gescheiden omgevingen, gebruiken de auteurs het Model Context Protocol (MCP). Alle tools van alle domeinen worden gepresenteerd als één uniforme toolset aan de agent. De agent moet zelf bepalen welke tool (bijv. een zoek-API, een code-compiler of een rekenmachine) nodig is voor een specifieke taak, zonder voorafgaande kennis van het domein.
Evaluatie van Test-Time Scaling: Het paper onderzoekt twee strategieën om de prestaties te verbeteren door meer rekenkracht toe te wijzen:
1. Sequentiële Scaling: Het verlengen van de interactiegeschiedenis (meer rondes van denken, reflecteren en handelen).
2. Parallelle Scaling: Het genereren van $K$ onafhankelijke trajecten (samples) en het selecteren van het beste antwoord (via "Self-Choice" strategieën zoals point-wise of pair-wise vergelijking).

3. Belangrijkste Bijdragen

General AgentBench: Een unificerend framework dat agents blootstelt aan een realistische mix van tools en domeinen, waardoor de evaluatie dichter bij echte gebruikersinteracties komt dan bestaande gespecialiseerde benchmarks.
Empirisch Bewijs voor Prestatieverval: Het paper toont aan dat er een aanzienlijke prestatiedaling optreedt wanneer modellen worden overgeplaatst van gespecialiseerde naar generale settings.
Identificatie van Schaalingslimieten: De auteurs onthullen twee fundamentele beperkingen bij test-time scaling voor generale agents:
- De "Context Ceiling" bij sequentiële scaling.
- De "Verification Gap" bij parallelle scaling.

4. Resultaten

De auteurs evalueerden tien toonaangevende LLM-agents (waaronder GPT-5, Claude Sonnet 4.5, DeepSeek-R1, Qwen3, en Gemini 2.5).

Prestatieverval in Generale Settings:
- Bij de overstap van gespecialiseerde naar generale benchmarks daalden de meeste modellen met 10% tot 30% in prestatie.
- Sommige modellen (zoals Gemini 2.5-Pro in het redeneringsdomein) leden tot wel 60% verlies.
- Claude Sonnet 4.5 bleek het meest robuust, met slechts een minimale daling (0,2%), voornamelijk dankzij sterke tool-use en coderingscapaciteiten.
- Cross-domein Synergie: Interessant genoeg presteerden sommige modellen (zoals Qwen3-Next en DeepSeek-R1) beter in zoekopdrachten onder de generale setting. Dit kwam doordat ze gespecialiseerde tools (zoals Hugging Face API's of Google Maps) succesvol inzetten voor taken die normaal gesproken alleen webzoekopdrachten vereisen.
Beperkingen van Sequentiële Scaling (Context Ceiling):
- Het verlengen van de interactiegeschiedenis leidt niet tot lineaire verbetering.
- Er is een Context Ceiling: na een bepaald punt (varieerend per model, vaak rond de 96k-112k tokens) begint de prestatie te fluctueren of te dalen.
- De agent raakt overweldigd door de geaccumuleerde geschiedenis, wat leidt tot instabiliteit in het redeneren en het herhalen van fouten in plaats van het vinden van nieuwe oplossingspaden.
Beperkingen van Parallelle Scaling (Verification Gap):
- Hoewel het genereren van meer samples ( $K$ ) de theoretische kans op een correct antwoord verhoogt (gemeten als pass@K), faalt de agent vaak bij het selecteren van het juiste antwoord uit de set.
- Er is een grote kloof tussen de generatiecapaciteit (het vinden van een oplossing) en de verificatiecapaciteit (het herkennen dat het de juiste oplossing is).
- Zelfs wanneer een extern krachtig model (GPT-5) als verifier wordt gebruikt, blijft er een kloof bestaan, wat suggereert dat agents moeite hebben om hun eigen generaties correct te beoordelen, vooral bij complexe, ongebruikelijke uitvoeringssporen.

5. Betekenis en Conclusie

Dit paper biedt een kritisch inzicht in de huidige staat van generale LLM-agents:

Realisme vs. Specialisatie: Het benadrukt dat succes in gespecialiseerde benchmarks niet garandeert dat een agent robuust is in de echte wereld, waar domeinen en tools gemengd zijn.
Schalingsparadox: Het toont aan dat "meer rekenkracht" (meer tokens of meer samples) niet automatisch leidt tot betere resultaten voor generale agents. Zonder betere mechanismen voor contextbeheer (voor sequentiële scaling) en verifiëren (voor parallelle scaling), bereiken agents een plafond.
Toekomstige Richting: De resultaten suggereren dat de focus voor de volgende generatie agents moet verschuiven van puur het vergroten van contextvensters of het genereren van meer samples, naar het verbeteren van context-engineering (hoe informatie wordt beheerd in lange dialogen) en verificatiemechanismen (hoe agents hun eigen werk kritisch beoordelen).

Kortom, General AgentBench dient als een noodzakelijk realiteitscheck voor de ontwikkeling van robuuste, generale AI-systemen die klaar zijn voor complexe, open-ended gebruikersverzoeken.