💬 NLP

Scaling Enterprise Agent Routing: Degradation, Diagnosis, and Recovery

Questo articolo investiga come l'accuratezza del routing negli assistenti LLM aziendali degradi all'aumentare dei cataloghi di strumenti da 10 a 110 agenti, identificando i gap di recupero e di confusione come cause primarie del fallimento e dimostrando che lo shortlisting basato su embedding recupera efficacemente una parte significativa delle prestazioni F1 attraverso molteplici modelli frontier.

Autori originali: Kellen Gillespie, Robyn Perry

Pubblicato 2026-06-17

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Kellen Gillespie, Robyn Perry

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di essere il manager di un ufficio enorme e frenetico. Hai un team di 110 dipendenti specializzati (agenti) e 584 competenze specifiche (strumenti) che possono utilizzare. Il tuo compito è prendere una richiesta da un cliente (come "devo inviare un'e-mail") e scegliere istantaneamente l'unico dipendente giusto per gestirla.

Questo documento è un rapporto su cosa succede quando quell'ufficio diventa troppo grande e su come il manager (un'IA) inizi a commettere errori.

Ecco la ripartizione delle loro scoperte utilizzando analogie semplici:

1. Il Problee: La trappola del "Troppe Scelte"

Quando l'ufficio era piccolo (diciamo, 10 dipendenti), il manager era bravissimo nel scegliere la persona giusta. Ma man mano che aggiungevano persone, il manager iniziava a confondersi.

L'Analogia: Immagina di cercare un ago specifico in un pagliaio. Quando il pagliaio è piccolo, è facile. Quando cresce fino alle dimensioni di una montagna, inizi a perdere gli aghi che avresti dovuto trovare.
Il Risultato: Man mano che il catalogo degli strumenti cresceva da 10 a 110, la capacità dell'IA di trovare lo strumento corretto è diminuita significativamente (di circa il 16–23%). Non era che l'IA iniziasse a scegliere strumenti sbagliati più spesso; era che iniziava a mancare completamente gli strumenti giusti.

2. Perché è fallito? Due tipi di errori

I ricercatori hanno suddiviso il fallimento in due problemi distinti, come due diversi motivi per cui un detective potrebbe fallire nel risolvere un caso:

Il "Gap di Recupero" (Il problema del Bibliotecario): L'IA non riusciva nemmeno a vedere lo strumento giusto nell'elenco. Era come un bibliotecario che non riesce a trovare il libro sullo scaffale perché la biblioteca è troppo grande e disordinata. Questa è la parte che i ricercatori potevano risolvere.
Il "Gap di Confusione" (Il problema dei Gemelli): Anche se l'IA vedeva lo strumento giusto, si confondeva comunque. Perché? Perché l'ufficio ha molti "gemelli".
- Esempio: Hai Gmail, Outlook e Yahoo Mail. Hai strumenti per "Migliorare", "Parafrasare" e "Correggere bozze". Fanno quasi la stessa cosa. Anche con un elenco perfetto, l'IA faticava a decidere quale "gemello" fosse il migliore. Questa confusione causava un calo permanente delle prestazioni che non poteva essere risolto semplicemente elencando meglio gli strumenti.

3. La Soluzione: Il filtro della "Lista Breve"

I ricercatori hanno testato una soluzione semplice: Non mostrare all'IA l'intero elenco di 584 strumenti. Invece, usa un filtro rapido (come una barra di ricerca intelligente) per trovare prima i 20 candidati più probabili, e poi chiedi all'IA di scegliere il vincitore da quel piccolo gruppo.

L'Analogia: Invece di chiedere a un giudice di scegliere un vincitore tra 584 concorrenti, chiedi prima a uno scout di scegliere i migliori 20. Poi, il giudice sceglie il vincitore solo da quei 20.
Il Risultato: Questo metodo di "Shortlisting" (creazione di una lista breve) ha funzionato come la magia. Ha recuperato circa il 10–17% della prestazione perduta. Non ha risolto il "Problema dei Gemelli" (la confusione), ma ha risolto completamente il "Problema del Bibliotecario" (mancare lo strumento giusto).

4. Cosa non ha funzionato (e cosa ha funzionato)

Il team ha provato diversi modi per costruire questo "scout" (il filtro):

Il Vincitore: Usare gli Embedding (un tipo di IA che comprende il significato delle parole, non solo la loro ortografia). Questo è stato il metodo migliore. Comprendeva che "inviare un messaggio" ed "e-mail al team" sono simili, anche se le parole sono diverse.
Il Perdente: La Ricerca per Parole Chiave (cercare corrispondenze esatte di parole). È fallita miseramente perché in un ufficio grande, tutti usano le stesse parole (come "e-mail" o "programmare"), quindi cercare quelle parole non aiutava a distinguere i diversi strumenti.
L'Approccio a "Pacchetti": Raggruppare gli strumenti in categorie (come "Strumenti per E-mail" rispetto a "Strumenti per la Scrittura") e scegliere prima una categoria non ha funzionato bene quanto scegliere direttamente i singoli strumenti.

5. Test nel mondo reale

I ricercatori non hanno usato solo domande di test generate dal computer. Hanno testato questo sistema anche su 1.435 richieste reali di utenti veri.

Gli utenti reali sono disordinati: sbagliano l'ortografia, usano lo slang e non dicono esattamente ciò che intendono.
I risultati si sono confermati: anche con dati reali disordinati, il metodo della "Lista Breve" ha comunque aumentato significativamente le prestazioni, dimostrando che non si tratta solo di un trucco da laboratorio — funziona nel mondo reale.

Il Punto Fondamentale

Quando si scala un sistema di IA con troppi strumenti, questo viene sopraffatto e inizia a mancare le risposte giuste.

La Soluzione: Non lasciare che l'IA guardi tutto in una volta. Usa un filtro intelligente per restringere il campo a una lista breve di 20 opzioni prima.
Il Limite: Anche con una lista breve, l'IA si confonderà con gli strumenti che fanno cose molto simili (come diverse app di posta elettronica). Questa parte è più difficile da risolvere, ma il metodo della "Lista Breve" risolve la parte più grande del problema.

Riepilogo Tecnico: Scalare il Routing di Agenti Enterprise

Problema

Man mano che gli assistenti basati su Large Language Model (LLM) evolvono in livelli di orchestrazione, essi indirizzano sempre più frequentemente le richieste degli utenti verso librerie di strumenti e agenti specializzati in crescita. Sebbene piattaforme come OpenAI e Anthropic abbiano introdotto meccanismi (ad esempio, ricerca basata su namespace, recupero BM25) per gestire questa crescita, i meccanismi specifici di degradazione delle prestazioni al crescere dei cataloghi rimangono scarsamente caratterizzati.

Questo documento affronta la domanda critica: come degrada l'accuratezza del routing a singolo step man mano che il catalogo degli agenti scala da una dimensione gestibile a una libreria di dimensioni enterprise? Gli autori si concentrano su un ambiente di produzione caratterizzato da "sovrapposizione semantica densa", dove strumenti funzionalmente simili (ad esempio, molteplici client di posta elettronica, assistenti alla scrittura o tracker di progetti) creano un'ambiguità di routing significativa, uno scenario meno comune nei benchmark focalizzati sulle API.

Metodologia

Configurazione Sperimentale

Lo studio utilizza un catalogo di produttività enterprise reale e distribuito composto da 110 agenti e 584 singoli strumenti. L'valutazione copre punti di scala da 10 a 110 agenti (da 51 a 584 strumenti).

Modelli: Sono stati valutati tre modelli frontier: GPT-5.1, GPT-5.4 (OpenAI) e Claude Sonnet 4.5 (Anthropic).
Dati:
- Query Sintetiche: 4.105 query generate da GPT-4o, categorizzate come esplicite (citando il nome dello strumento) e implicite (descrivendo il bisogno). Lo studio si concentra principalmente sulle query implicite, che rappresentano il traffico reale di produzione.
- Query di Produzione: 1.435 utterance annotate da esseri umani campionate dal traffico live, annotate da tre linguisti per stabilire una verità fondamentale (ground truth) dinamica che tenga conto della sovrapposizione semantica.
Metriche: Precisione multi-label, recall e punteggio F1, calcolati rispetto a un set valido dinamico (strumento target + eventuali altri strumenti validi presenti nello specifico fold di scala).

Framework Diagnostico

Gli autori utilizzano un'Analisi Oracle per decomporre i fallimenti di routing in due gap distinti:

Gap di Recupero (Retrieval Gap): La perdita di prestazioni causata dall'incapacità del modello di far emergere lo strumento corretto dall'intero catalogo.
Gap di Confusione (Confusion Gap): La perdita di prestazioni che persiste anche quando lo strumento corretto è garantito essere presente (il "tetto dell'oracle" scende man mano che il catalogo cresce).

Interventi

Lo studio valuta lo shortlisting basato su embedding come intervento primario. Questo consiste nell'utilizzare un recuperatore denso (text-embedding-3-large) per pre-filtrare l'intero catalogo riducendolo a una lista breve di $k=20$ strumenti prima che il router LLM prenda la decisione finale. Questo viene confrontato con:

Routing flat (senza shortlisting).
Ricerca degli strumenti nativa della piattaforma (namespace search di OpenAI).
Approcci a livello di pacchetto (routing gerarchico, embedding a livello di pacchetto).
Recuperatori fine-tuned (ToolRet-e5).
Recupero lessicale (BM25).

Risultati Chiave

1. Degradazione della Scalabilità

L'accuratezza del routing degrada significativamente all'espandersi del catalogo.

Calo F1: Nelle query implicite, i punteggi F1 scendono di 16–23 punti percentuali in tutti i modelli all'aumentare del catalogo da 51 a 584 strumenti.
Guidato dalla Recall: Il degrado è guidato principalmente da un crollo della recall (che scende da ~55% a ~37%), mentre la precisione scende in modo più moderato. Il modello manca sempre più spesso strumenti validi piuttosto che selezionare quelli errati.
Tetto dell'Oracle (Oracle Ceiling): Anche con un recupero perfetto (un oracle shortlist), il tetto F1 scende di 10 punti percentuali (dal 79% al 69%). Ciò rivela un gap di confusione in cui il modello fatica a distinguere tra strumenti semanticamente simili anche quando vengono presentati insieme.

2. Efficacia dello Shortlisting

Lo shortlisting basato su embedding ( $k=20$ ) recupera con successo una parte significativa delle prestazioni perse.

Recupero: Lo shortlisting recupera +10–11 punti percentuali di F1 alla scala massima in tutti e tre i modelli e due provider.
Validazione in Produzione: Sul traffico reale annotato da umani, il recupero è ancora più pronunciato, variando da +10 a +17 punti percentuali, nonostante la baseline assoluta sia di 10–15 punti inferiore rispetto ai dati sintetici.
Riduzione degli Errori: Lo shortlisting riduce le mancanie di routing dal 31% al 10% alla scala massima. Il compromesso è un tasso di errore dello shortlister stabile del 9% (casi in cui lo strumento corretto non è incluso nei primi 20).

3. Prestazioni Comparative

Livello Strumento vs Livello Pacchetto: Il recupero a livello di strumento supera costantemente gli approcci a livello di pacchetto (routing gerarchico, embedding a livello di pacchetto) di 2–4 punti percentuali. I metodi a livello di pacchetto spesso diluiscono l'insieme dei candidati con strumenti fratelli irrilevanti.
Denso vs Lessicale: Il recupero tramite embedding denso (52.5% F1) supera significativamente il matching lessicale (BM25, 32.8% F1) e i recuperatori fine-tuned addestrati su dati orientati alle API (48.7% F1). Il BM25 fallisce perché gli strumenti enterprise condividono un'alta sovrapposizione di vocabolario.
Consistenza del Modello: Sebbene i modelli più forti (ad esempio, GPT-5.4, Sonnet) forniscano una baseline più alta, seguono la stessa curva di degradazione. Lo shortlisting fornisce un delta di miglioramento costante indipendentemente dalla forza del modello base.

Significato e Rivendicazioni

Il documento sostiene di fornire una diagnosi controllata e basata sulla produzione della "legge di scala" per il routing degli agenti. I suoi principali contributi sono:

Decomposizione del Fallimento: Distingue tra errori di recupero (il modello non trova lo strumento) ed errori di confusione (il modello non riesce a scegliere tra strumenti simili). Ciò chiarisce che, sebbene un migliore recupero possa risolvere la maggior parte dei problemi di scalabilità, rimane un gap di confusione fondamentale che il solo recupero non può colmare.
Validazione dello Shortlisting: Dimostra che lo shortlisting basato su embedding è un intervento altamente efficace e scalabile che recupera circa 10–17pp di F1, rendendolo una strategia valida per sistemi enterprise con centinaia di strumenti.
Limitazioni delle Piattaforme Attuali: Lo studio suggerisce che le funzionalità di ricerca native della piattaforma (come la ricerca di namespace di OpenAI) forniscono solo un sollievo parziale e si stabilizzano a dimensioni di catalogo maggiori, mentre lo shortlisting personalizzato tramite embedding continua a scalare efficacemente.
Specificità del Dominio: Gli autori notano che questi risultati sono specifici per domini con densità di sovrapposizione semantica (come la produttività enterprise). I domini con strumenti funzionalmente distinti potrebbero degradare più lentamente, ma il pattern qualitativo di degradazione guidata dalla recall è probabilmente trasferibile.

Il documento conclude che, mentre il gap di recupero è affrontabile attraverso una migliore selezione dei candidati (shortlisting), il gap di confusione (almeno 10pp) richiede innovazioni architettoniche o a livello di prompt che vadano oltre il semplice recupero, come la deduplicazione delle descrizioni o la chiarificazione multi-turno.