Runtime Burden Allocation for Structured LLM Routing in Agentic Expert Systems: A Full-Factorial Cross-Backend Methodology

Deze studie toont aan dat gestructureerde LLM-routing fundamenteel een systeemprobleem is waarbij de verdeling van rekenlast over de generatiestack backend-specifiek is, waardoor er geen universeel optimale modus bestaat en een full-factoriale benchmark methode essentieel is voor betrouwbare implementatie in agente systemen.

De kern

Stel je voor dat je een hoofdregisseur bent in een groot theater. Je krijgt elke seconde honderden vragen van het publiek (de gebruikers). Je taak is niet om zelf het antwoord te bedenken, maar om te beslissen: "Ga dit gesprek naar de komedie-afdeling, de actie-scène, of naar de technische crew?"

In de wereld van kunstmatige intelligentie (AI) noemen we dit routeren. De "hoofdregisseur" is een groot taalmodel (zoals ChatGPT of Gemini). Maar hier zit een addertje onder het gras: het model moet niet alleen het juiste antwoord kiezen, maar het antwoord ook in een perfect gestructureerd formaat geven (bijvoorbeeld een strakke JSON-code), zodat de computer het direct kan begrijpen en doorsturen.

Deze studie, getiteld "Runtime Burden Allocation for Structured LLM Routing", onderzoekt een heel belangrijk vraagstuk: Wie doet het zware werk?

De Grote Vraag: Wie draagt de last?

Stel je voor dat je een pakketje moet versturen. Je hebt drie manieren om dit te doen:

1. De Regisseur doet alles: De AI moet het antwoord bedenken én het in een perfect verpakt doosje (de structuur) stoppen. Dit is zwaar werk voor de AI.
2. De Regisseur doet het lichte werk, de verpakker doet de rest: De AI geeft alleen een korte, simpele boodschap (bijv. "Stuur naar actie"). Een slimme computerprogrammaatje (lokaal) pakt dit op en maakt er een perfect verpakt doosje van.

De onderzoekers (Zhou Hanlin en Chan Huah Yong) hebben gekeken wat er gebeurt als je deze keuze maakt bij verschillende soorten AI-modellen (Google's Gemini, OpenAI's modellen, en Llama).

De Ontdekking: Er is geen "beste" manier voor iedereen

Het meest verrassende resultaat is: Er bestaat geen universele beste manier.

Het is alsof je zegt: "Deze auto is de snelste op alle wegen." Dat klopt niet. Op een racebaan is hij fantastisch, maar op een modderig pad is hij waardeloos.

• Bij Google (Gemini) en OpenAI: Het werkt prima als de AI het zware werk doet (het antwoord én de verpakking). Ze zijn betrouwbaar. Als je het werk uitbesteedt aan de lokale computer (om het sneller te maken), gaat de kwaliteit soms iets achteruit, maar het blijft bruikbaar.
• Bij Llama (een open-source model): Dit is waar het misgaat. Als je Llama vraagt om alleen een korte boodschap te geven en de rest aan de computer over te laten, valt het systeem in elkaar. De AI raakt in de war, geeft onzin terug, en de lokale computer kan daar niets mee. De "last" die je van de AI probeert te halen, blijkt voor dit specifieke model te zwaar om op een simpele manier te dragen.

De Analogie van de Vertaler

Stel je voor dat je een brief moet laten vertalen naar het Chinees.

• Manier A (Direct): Je vraagt een expert-vertaler: "Vertaal deze brief perfect en geef het in een strakke PDF." De expert doet het, maar het duurt even en kost veel geld.
• Manier B (Gecomprimeerd): Je vraagt de expert alleen: "Wat is de kernboodschap?" en laat een computer het in een PDF zetten.
  • Bij een zeer ervaren vertaler (Gemini/OpenAI) werkt dit goed. De kernboodschap is duidelijk, de computer maakt een mooie PDF. Snel en goedkoop.
  • Bij een minder ervaren vertaler (Llama) werkt dit slecht. Als je vraagt om alleen de kern, raakt hij in de war. Hij geeft een vaag antwoord, en de computer maakt daar een onleesbare rommel van.

Wat betekent dit voor de praktijk?

De onderzoekers zeggen: "Houd op met zoeken naar de ene 'beste' AI-instelling voor iedereen."

In plaats daarvan moeten bedrijven kijken naar compatibiliteit:

1. Kijk naar je model: Als je een krachtig, duur model gebruikt, kun je het werk misschien uitbesteden om tijd te winnen.
2. Kijk naar je risico: Als je een goedkoper model gebruikt, moet je misschien het zware werk (de perfecte structuur) bij het model zelf laten, ook al duurt het iets langer.
3. Streaming is niet alles: Veel mensen denken dat "streaming" (woorden één voor één zien verschijnen) het gevoel van snelheid geeft. Maar voor een computer die een beslissing moet nemen, maakt het niet uit of je de woorden langzaam ziet verschijnen. De computer moet wachten tot het hele pakketje (het antwoord) binnen is. Dus, streaming helpt niet echt bij het versnellen van de daadwerkelijke beslissing.

De Conclusie in Eén Zin

Het succes van een slim AI-systeem hangt niet alleen af van hoe slim het model is, maar van hoe je het werk verdeelt tussen het model en de computer eromheen. Wat werkt als een wonder voor het ene model, kan een ramp zijn voor het andere. De kunst is om de juiste balans te vinden voor jouw specifieke situatie.

Technische samenvatting

1. Probleemstelling

Grote Taalmodellen (LLMs) worden steeds vaker gebruikt als centrale besturingscomponenten in agentische AI-systemen, in plaats van alleen als tekstgeneratoren. In deze context is de belangrijkste output niet de tekst zelf, maar een gestructureerd controle-record (bijv. een JSON-object) dat bepaalt welke subsystemen, tools of geheugenmodules worden aangeroepen.

Het artikel stelt dat gestructureerde routing vaak ten onrechte wordt benaderd als louter een prompt-engineering probleem. De auteurs betogen dat het fundamenteel een systeemniveau-probleem van lastverdeling (burden allocation) is. De vraag is niet alleen of het model de taak begrijpt, maar hoe de structurele werklast wordt verdeeld tussen het generatiemodel en de omringende software:

• Moet het model de volledige, machine-leesbare structuur direct genereren?
• Moet het model een gecomprimeerde tussenstand genereren die lokaal wordt omgezet?
• Hoe beïnvloeden transportmechanismen (streaming vs. non-streaming) de betrouwbaarheid?

Bestaande benchmarks missen vaak inzicht in hoe runtime-pakketten (hoe de output wordt verpakt en verwerkt) de prestaties beïnvloeden onder verschillende backend-condities.

2. Methodologie

De auteurs introduceren een full-factorial cross-backend benchmark om deze lastverdeling te analyseren.

• Experimenteel Ontwerp: Het onderzoek omvat 48 verschillende implementatieconfiguraties, verdeeld over 15.552 verzoeken.
• Factoren:
  • Backends: OpenAI, Gemini en Llama.
  • Runtime-modi (4 types):
    • MJ (Minimal JSON): Directe JSON-output met een beperkt token-budget.
    • SJ (Standard JSON): Directe JSON-output met een ruimer budget.
    • MJS (Streaming JSON): JSON-output via streaming.
    • MCLR (Compressed Local Reconstruction): Het model genereert een compacte, platte tekstcode; een deterministische lokale software reconstructeert de uiteindelijke JSON-structuur.
  • Beperkingen: Beperkt vs. Onbeperkt budget.
  • Transport: Streaming vs. Non-streaming.
• Framework: De auteurs definiëren een "Runtime Burden-Allocation Framework" met drie dimensies:
  1. Serialisatie-last: Hoeveel schema-construktie moet het model doen?
  2. Transport-semantiek: Streaming vs. voltooid bericht.
  3. Locatie van realisatie: Wordt de structuur door het model of lokaal gegenereerd?
• Statistische Analyse: Er wordt gebruikgemaakt van Type-II ANOVA om hoofdeffecten en interacties (vooral Backend × Modus) te testen, met focus op effectgroottes (partial eta squared) in plaats van alleen p-waarden.

3. Belangrijkste Resultaten

De resultaten weerleggen het idee dat er één "beste" routing-modus bestaat die universeel toepasbaar is.

• Dominante Interactie: De interactie tussen de Backend en de Runtime-modus is de belangrijkste determinant voor prestaties (met een zeer hoge effectgrootte, o.a. 0.960 voor Routing Accuracy). Wat werkt voor OpenAI, werkt niet noodzakelijk voor Llama.
• Correctheid vs. Efficiëntie Trade-off:
  • Directe JSON (MJ/SJ): Biedt de hoogste correctheid (Routing Accuracy) en stabiliteit, vooral op Gemini en OpenAI.
  • Gecomprimeerde reconstructie (MCLR): Biedt aanzienlijke efficiëntiewinst (minder tokens, lagere latentie), maar leidt tot een drastische daling in correctheid bij bepaalde backends.
    • Gemini/OpenAI: MCLR verlaagt de Routing Accuracy met ongeveer 23-27% ten opzichte van de JSON-baselines.
    • Llama: MCLR leidt tot een instorting van de prestaties (Routing Accuracy daalt van ~82% naar ~23%, Format Compliance naar ~53%).
• Streaming heeft weinig waarde: Voor gestructureerde controle-taken, waarbij de volledige output nodig is voordat downstream-taken kunnen starten, heeft streaming (MJS) weinig tot geen positief effect op de correctheid en slechts een beperkt effect op de operationele latentie.
• Route-specifieke kwetsbaarheid: Aggregatiecijfers kunnen misleidend zijn. Specifieke routes (zoals "developer" of "tool-call") zijn vaak veel kwetsbaarder voor lastveranderingen dan algemene chat-routes. Op Llama daalt de "developer"-routing naar 0% bij MCLR, terwijl chat-routes stabiel blijven.
• Workflow Lower-Bound Completion (WLC): Een afgeleide metric die de minimale kans schat dat een downstream-workflow een bruikbaar record ontvangt. Bij Llama en MCLR is deze waarde 0%, wat betekent dat de compressie de workflow volledig blokkeert ondanks de lage kosten.

4. Kernbijdragen

1. Conceptueel Raamwerk: De herformulering van gestructureerde routing als een lastverdelingsprobleem (burden allocation) in plaats van een puur prompt-probleem. Dit introduceert een nieuwe dimensie voor systeemontwerp.
2. Methodologische Innovatie: Een full-factorial benchmark die specifiek is ontworpen om backend-specifieke interacties bloot te leggen, in plaats van alleen modellen te vergelijken.
3. Empirisch Bewijs: Het aantonen dat "backend-compatibiliteit" een eerste-orde systeem-effect is. Er is geen universeel optimale oplossing; de keuze hangt af van de specifieke backend.
4. Praktische Richtlijnen: De ontwikkeling van drie implementatieregels voor expert-systemen:
   • Behoud directe gestructureerde emissie (JSON) als correctie prioriteit heeft.
   • Gebruik gecomprimeerde lokale reconstructie alleen na backend-specifieke validatie.
   • Overschat streaming niet voor compacte controle-taken.

5. Betekenis en Conclusie

Dit artikel is significant voor de ontwikkeling van agente expert-systemen omdat het de focus verschuift van "welk model is het slimst" naar "hoe verpakken we de output voor dit specifieke model en deze specifieke taak".

De studie waarschuwt tegen het blind toepassen van efficiëntie-optimalisaties (zoals compressie of streaming) zonder rekening te houden met de semantische stabiliteit van de gekozen backend. Voor productie-systemen betekent dit dat engineers runtime-pakketten moeten kiezen op basis van compatibiliteit met de specifieke backend, waarbij ze de trade-off tussen kosten en de risico's op workflow-fouten (zoals het verkeerd routeren van kritieke taken) zorgvuldig afwegen.

De conclusie is dat gestructureerde routing een systeemontwerpprobleem is waarbij de keuze van de runtime-architectuur (lastverdeling) even belangrijk is als de keuze van het taalmodel zelf.