I Due Paradigmi di Scoperta degli Strumenti
Nel campo degli agenti linguistici potenziati da strumenti, due approcci principali emergono per la scoperta delle API: Retrieve-then-Plan (RtP) e Plan-then-Retrieve (PtR). Il primo, RtP, è l'approccio dominante, che incorpora la query dell'utente e recupera strumenti simili tramite ricerca di vicini più prossimi approssimati. Il secondo, PtR, rappresenta un'alternativa in cui il modello linguistico genera prima Stub di Strumenti Astratti (funzioni ipotetiche che descrivono le capacità necessarie), che poi servono come query di recupero contro il registro delle API.
Questi due paradigmi sono stati valutati su ToolBench, un dataset che comprende 46.984 endpoint API unici suddivisi in 50 categorie. Lo studio ha esaminato tre sottogruppi di query: single-tool (G1), multi-tool intra-categoria (G2) e multi-tool cross-categoria (G3). I risultati hanno mostrato una chiara dipendenza dalla complessità: RtP supera PtR nelle query single-tool, mentre PtR supera RtP nelle query multi-tool.
Risultati e Implicazioni
La differenza di prestazioni tra RtP e PtR è stata osservata a ogni budget di recupero (da k=1 a k=20) e si è dimostrata robusta in registri di dimensioni variabili, da 1.000 a 47.000 API. Inoltre, i risultati sono stati coerenti tra diverse famiglie di modelli, tra cui Gemini 2.5 Flash e gpt-oss-120b.
Uno dei risultati più interessanti è la caratterizzazione di un fallimento di tipo stub-hallucination, in cui il modello linguistico inventa nomi di API plausibili ma non esistenti. Questo fenomeno agisce come una spada a doppio taglio: nelle query semplici, PtR astratte i segnali di nomi propri che RtP abbinato direttamente, mentre nelle query complesse, lo stesso meccanismo scompone l'intento multifaccettato in sottobisogni funzionali.
L'analisi dei costi di inferenza ha rivelato che la chiamata di scoperta aggiuntiva di PtR raddoppia approssimativamente il costo di inferenza. Questo costo aggiuntivo si ripaga nelle query multi-tool, ma è svantaggioso nelle query single-tool. Pertanto, lo studio suggerisce che un routing adattivo alla complessità potrebbe essere una direzione pratica, guidata da un segnale a costo zero già presente nel pipeline (il punteggio di recupero top-1 di RtP).
Esempi Pratici e Applicazioni
Per comprendere meglio queste differenze, consideriamo un esempio pratico. Supponiamo che un utente voglia pianificare un viaggio. Con RtP, il sistema potrebbe recuperare direttamente strumenti come "cerca voli" e "prenota hotel" basandosi sulla query iniziale. Con PtR, invece, il sistema potrebbe generare prima uno stub astratto come "cerca opzioni di viaggio" e poi recuperare strumenti specifici come "cerca voli" e "prenota hotel".
In un contesto più complesso, come la pianificazione di un evento aziendale, PtR potrebbe scomporre l'intento in sottotemi come "trova location", "invia inviti" e "gestisci budget", recuperando strumenti specifici per ciascuna di queste funzioni. Questo approccio è particolarmente utile quando le query sono complesse e richiedono l'integrazione di più strumenti.
Conclusione e Direzioni Future
Lo studio di Apple Machine Learning Research fornisce preziose intuizioni sui vantaggi e gli svantaggi di RtP e PtR. Mentre RtP è più efficiente per query semplici, PtR offre un vantaggio significativo nelle query complesse che richiedono l'integrazione di più strumenti. Tuttavia, il costo aggiuntivo di PtR suggerisce che un approccio adattivo potrebbe essere la soluzione ottimale.
Le future ricerche potrebbero esplorare ulteriormente il routing adattivo alla complessità, utilizzando segnali già presenti nel pipeline per decidere dinamicamente tra RtP e PtR. Inoltre, potrebbe essere utile indagare su come mitigare il fenomeno di stub-hallucination, migliorando l'accuratezza e l'affidabilità degli stub generati.