💬 NLP

Scaling Enterprise Agent Routing: Degradation, Diagnosis, and Recovery

Dit artikel onderzoekt hoe de routeringsnauwkeurigheid in enterprise LLM-assistenten afneemt wanneer de toolcatalogi schalen van 10 naar 110 agenten, waarbij het identificeren van retrieval- en verwarringskloven als primaire oorzaken van falen en het aantonen dat op embeddings gebaseerde shortlist-methoden effectief een aanzienlijk deel van de F1-prestaties herstellen over meerdere frontiermodellen.

Oorspronkelijke auteurs: Kellen Gillespie, Robyn Perry

Gepubliceerd 2026-06-17

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Kellen Gillespie, Robyn Perry

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 de manager bent van een enorm, druk kantoor. Je hebt een team van 110 gespecialiseerde werknemers (agenten) en 584 specifieke vaardigheden (tools) die ze kunnen gebruiken. Jouw taak is om een verzoek van een klant te ontvangen (zoals "Ik moet een e-mail sturen") en direct de juiste werknemer uit te kiezen om het af te handelen.

Dit papier is een rapport over wat er gebeurt als dat kantoor te groot wordt, en hoe de manager (een AI) fouten begint te maken.

Hier is de uitsplitsing van hun bevindingen met behulp van eenvoudige analogieën:

1. Het Probleem: De "Te Veel Keuzes" Valstrik

Toen het kantoor klein was (bijvoorbeeld 10 werknemers), was de manager erg goed in het kiezen van de juiste persoon. Maar naarmate ze meer mensen toevoegden, raakte de manager in de war.

De Analogie: Stel je voor dat je een specifieke naald in een hooiberg probeert te vinden. Wanneer de hooiberg klein is, is dat makkelijk. Wanneer de hooiberg groeit tot de omvang van een berg, begin je naalden te missen die je eigenlijk had moeten vinden.
Het Resultaat: Naarmate de catalogus van tools groeide van 10 naar 110, daalde het vermogen van de AI om de juiste tool te vinden aanzienlijk (met ongeveer 16–23%). Het was niet zo dat de AI vaker de verkeerde tools begon te kiezen; het was dat de AI de juiste tools volledig begon te missen.

2. Waarom het faalde: Twee soorten fouten

De onderzoekers deelden de mislukking op in twee duidelijke problemen, zoals twee verschillende redenen waarom een detective een zaak niet zou kunnen oplossen:

De "Retrieval Gap" (Het Bibliothecaris-probleem): De AI kon de juiste tool niet eens zien in de lijst. Het was alsof een bibliothecaris het boek in de kast niet kon vinden omdat de bibliotheek te groot en rommelig was. Dit is het deel dat de onderzoekers konden oplossen.
De "Confusion Gap" (Het Tweeling-probleem): Zelfs als de AI de juiste tool wél zag, raakte het nog steeds in de war. Waarom? Omdat het kantoor veel "tweelingen" heeft.
- Voorbeeld: Je hebt Gmail, Outlook en Yahoo Mail. Je hebt "Verbeteren", "Parafraseren" en "Controleren" tools. Ze doen bijna allemaal hetzelfde. Zelfs met een perfecte lijst, worstelde de AI om te beslissen welke "tweeling" de beste match was. Deze verwarring veroorzaakte een permanente daling in de prestaties die niet kon worden opgelost door de tools simpelweg beter te vermelden.

3. De Oplossing: De "Shortlist" Filter

De onderzoekers testten een eenvoudige oplossing: Laat de AI niet de hele lijst van 584 tools zien. Gebruik in plaats daarvan een snelle filter (zoals een slimme zoekbalk) om eerst de 20 meest waarschijnlijke kandidaten te vinden, en vraag de AI daarna om de winnaar te kiezen uit die kleine groep.

De Analogie: In plaats van een rechter te vragen om een winnaar te kiezen uit 584 deelnemers, laat je eerst een scout de top 20 kiezen. Daarna kiest de rechter de winnaar uit alleen die 20.
Het Resultaat: Deze "Shortlisting"-methode werkte als magie. Het herstelde ongeveer 10–17% van de verloren prestaties. Het loste het "Tweeling-probleem" (verwarring) niet op, maar het loste het "Bibliothecaris-probleem" (het missen van de juiste tool) volledig op.

4. Wat niet werkte (en wat wel)

Het team probeerde verschillende manieren om deze "scout" (de filter) te bouwen:

De Winnaar: Het gebruik van Embeddings (een type AI dat de betekenis van woorden begrijpt, niet alleen de spelling). Dit was de beste methode. Het begreep dat "een bericht sturen" en "het team mailen" vergelijkbaar zijn, zelfs als de woorden verschillend zijn.
De Verliezer: Keyword Search (zoeken naar exacte woordovereenkomsten). Dit faalde jammerlijk omdat iedereen in een groot kantoor dezelfde woorden gebruikt (zoals "e-mail" of "planning"), dus hielp het zoeken naar die woorden niet om de verschillende tools te onderscheiden.
De "Pack" Aanpak: Het groeperen van tools in categorieën (zoals "E-mail Tools" versus "Schrijftools") en eerst een categorie kiezen, werkte niet zo goed als het direct kiezen van individuele tools.

5. Testen in de echte wereld

De onderzoekers gebruikten niet alleen door computers gegenereerde testvragen. Ze testten dit ook op 1.435 echte verzoeken van werkelijke gebruikers.

Echte gebruikers zijn rommelig: ze spellen woorden verkeerd, gebruiken straattaal en zeggen niet precies wat ze bedoelen.
De resultaten hielden stand: Zelfs met rommelige echte gegevens verbeterde de "Shortlist"-methode de prestaties nog steeds aanzienlijk, wat bewijst dat dit geen laboratoriumtruc is—het werkt in de echte wereld.

De Kern van de zaak

Wanneer je een AI-systeem opschaalt met te veel tools, raakt het overweldigd en begint het de juiste antwoorden te missen.

De Fix: Laat de AI niet alles tegelijk bekijken. Gebruik een slimme filter om het eerst terug te brengen naar een shortlist van 20 opties.
De Limiet: Zelfs met een shortlist zal de AI in de war raken door tools die zeer vergelijkbare functies hebben (zoals verschillende e-mailapps). Dat deel is moeilijker op te lossen, maar de "Shortlist"-methode lost het grootste deel van het probleem op.

Technische Samenvatting: Schalen van Enterprise Agent Routing

Probleemstelling

Naarmate Large Language Model (LLM) assistenten evolueren naar orchestratielagen, routeren ze steeds vaker gebruikersverzoeken naar groeiende bibliotheken van gespecialiseerde tools en agents. Hoewel platforms zoals OpenAI en Anthropic mechanismen hebben geïntroduceerd (bijv. namespace-gebaseerde zoekopdrachten, BM25-retrieval) om deze groei te beheren, blijven de specifieke mechanismen van prestatievermindering naarmate catalogi schalen ondergekarakteriseerd.

Dit artikel behandelt de kritieke vraag: Hoe degradeert de single-step routing nauwkeurigheid naarmate de agent-catalogus schaalt van een beheersbare omvang naar een enterprise-schaal bibliotheek? De auteurs richten zich op een productieomgeving die wordt gekenmerkt door "dichte semantische overlap", waarbij functioneel vergelijkbare tools (bijv. meerdere e-mailclients, schrijfassistenten of projecttrackers) voor aanzienlijke routing-ambiguïteit zorgen, een scenario dat minder voorkomt in API-gecentreerde benchmarks.

Methodologie

Experimentele Opzet

De studie maakt gebruik van een reële, operationele enterprise productivity catalogus bestaande uit 110 agents en 584 individuele tools. De evaluatie beslaat schaalpunten van 10 tot 110 agents (51 tot 584 tools).

Modellen: Drie frontier-modellen werden geëvalueerd: GPT-5.1, GPT-5.4 (OpenAI) en Claude Sonnet 4.5 (Anthropic).
Data:
- Synthetische Queries: 4.105 queries gegenereerd door GPT-4o, gecategoriseerd als expliciet (noemt de tool direct) en impliciet (beschrijft de behoefte). De studie richt zich primair op impliciete queries, die realistisch productieverkeer vertegenwoordigen.
- Productie-queries: 1.435 door mensen geannoteerde uitingen afkomstig uit live verkeer, geannoteerd door drie linguïsten om een dynamische grondwaarheid (ground truth) vast te stellen die rekening houdt met semantische overlap.
Metrics: Multi-label precisie, recall en F1-score, berekend tegen een dynamische validatieset (doeltool + eventuele ook-geldige tools aanwezig in de specifieke schaal-fold).

Diagnostisch Kader

De auteurs gebruiken een Oracle Analyse om routing-fouten te deconstrueren in twee onderscheidende hiaten:

Retrieval Gap (Retrieval-hiaat): Het prestatieverlies veroorzaakt door het onvermogen van het model om de juiste tool uit de volledige catalogus naar boven te halen.
Confusion Gap (Verwarringshiaat): Het prestatieverlies dat blijft bestaan zelfs wanneer de juiste tool gegarandeerd aanwezig is (het "oracle plafond" daalt naarmate de catalogus groeit).

Interventies

De studie evalueert embedding-gebaseerde shortlisting als een primaire interventie. Dit houdt in dat een dense retriever (text-embedding-3-large) wordt gebruikt om de volledige catalogus voor te filteren tot een shortlist van $k=20$ tools voordat de LLM-router de definitieve beslissing neemt. Dit wordt vergeleken met:

Flat routing (geen shortlisting).
Platform-native tool search (OpenAI's namespace search).
Pack-level benaderingen (hiërarchische routing, pack-level embedding).
Fine-tuned retrievers (ToolRet-e5).
Lexicale retrieval (BM25).

Belangrijkste Resultaten

1. Degradatie bij Schalen

De routing-nauwkeurigheid degradeert significant naarmate de catalogus uitbreidt.

F1-daling: Bij impliciete queries dalen de F1-scores met 16–23 procentpunten over alle modellen heen naarmate de catalogus groeit van 51 naar 584 tools.
Recall-gedreven: De degradatie wordt primair gedreven door een instorting in de recall (dalend van ~55% naar ~37%), terwijl de precisie moderater daalt. Het model mist steeds vaker geldige tools in plaats van ongeldige tools te selecteren.
Oracle Ceiling (Oracle Plafond): Zelfs met perfecte retrieval (een oracle shortlist) daalt het F1-plafond met 10 procentpunten (van 79% naar 69%). Dit onthult een confusion gap waarbij het model moeite heeft om tussen semantisch gelijkaardige tools te differentiëren, zelfs wanneer ze samen worden gepresenteerd.

2. Effectiviteit van Shortlisting

Embedding-gebaseerde shortlisting ( $k=20$ ) herstelt een aanzienlijk deel van de verloren prestaties.

Herstel: Shortlisting herstelt +10–11 procentpunten in F1 bij volledige schaal voor alle drie de modellen en twee providers.
Productie-validatie: Op reële, door mensen geannoteerde verkeer is het herstel nog prominenter, variërend van +10 tot +17 procentpunten, ondanks het feit dat de absolute baseline-prestatie 10–15 punten lager ligt dan bij synthetische data.
Reductie van Fouten: Shortlisting vermindert de routing-misses van 31% naar 10% bij volledige schaal. De trade-off is een stabiele shortlister miss rate van 9% (gevallen waarin de juiste tool niet in de top 20 is opgenomen).

3. Vergelijkende Prestaties

Tool-Level vs. Pack-Level: Tool-level retrieval presteert consistent beter dan pack-level benaderingen (hiërarchische routing, pack-level embedding) met 2–4 procentpunten. Pack-level methoden verdunnen de kandidaat-set vaak met irrelevante 'sibling' tools.
Dense vs. Lexical: Dense embedding retrieval (52.5% F1) presteert aanzienlijk beter dan lexicale matching (BM25, 32.8% F1) en fine-tuned retrievers getraind op API-gecentreerde data (48.7% F1). BM25 faalt omdat enterprise-tools een hoge vocabulaire-overlap delen.
Model Consistentie: Hoewel sterkere modellen (bijv. GPT-5.4, Sonnet) een hogere baseline bieden, volgen zij dezelfde degradatiecurve. Shortlisting biedt een consistente delta-verbetering ongeacht de kracht van het basismodel.

Betekenis en Claims

Het artikel claimt een gecontroleerde, op productie gebaseerde diagnose te bieden van de "scaling law" voor agent routing. De belangrijkste bijdragen zijn:

Deconstructie van Falen: Het maakt onderscheid tussen retrieval errors (het model kan de tool niet vinden) en confusion errors (het model kan niet kiezen tussen vergelijkbare tools). Dit verduidelijkt dat hoewel betere retrieval het merendeel van de schaalproblemen kan oplossen, er een fundamenteel confusion gap blijft bestaan die retrieval alleen niet kan dichten.
Validatie van Shortlisting: Het demonstreert dat embedding-gebaseerde shortlisting een zeer effectieve, schaalbare interventie is die ~10–17pp F1 herstelt, wat het een levensvatbare strategie maakt voor enterprise-systemen met honderden tools.
Beperkingen van Huidige Platforms: De studie suggereert dat platform-native zoekfuncties (zoals OpenAI's namespace search) slechts gedeeltige verlichting bieden en een plateau bereiken bij grotere catalogusgroottes, terwijl custom embedding shortlisting effectief blijft schalen.
Domeinspecificiteit: De auteurs merken op dat deze bevindingen specif