Agentic RAG Benchmark: Instradamento Multi-Database su 36 LLM

Abbiamo confrontato 36 modelli linguistici di grandi dimensioni sull'instradamento cross-database. Ogni modello riceve una domanda in linguaggio naturale e 11 SQL database descritti a livello di paragrafo, quindi deve decidere quale database contiene la risposta prima di scrivere qualsiasi SQL. Gli 11 database sono stati estratti da 80 candidati BIRD-SQL raggruppando gli embedding delle loro descrizioni, in modo che i candidati siano semanticamente vicini tra loro e i loro nomi reali siano nascosti dietro le etichette db_01 fino a db_11.

Ogni modello ha visto lo stesso insieme congelato di 759 domande a temperatura 0, con l'indicazione di dominio di BIRD omessa.¹ Ogni database è esposto come uno strumento con tre azioni: elenco degli schemi, dettaglio della tabella ed esecuzione della query, con un limite di 10 API chiamate per domanda. L'elenco degli strumenti viene permutato per ogni domanda, quindi la posizione del candidato non può essere interpretata come abilità di instradamento.

Accuratezza di instradamento sulle domande più difficili. La quota delle 184 domande più difficili in cui il database dichiarato dal modello corrisponde al database di riferimento. Una domanda viene considerata una delle 184 quando due segnali indipendenti concordano. Almeno 5 dei suoi 20 vicini più prossimi nello spazio degli embedding devono appartenere ad altri database, e una giuria di tre modelli deve etichettarla come confondente. Questa è la metrica di instradamento principale.

Le 184 domande provengono da 6 degli 11 database, con quote di 51 (regional_sales), 50 (retail_world), 43 (superstore), 27 (works_cycles), 8 (debit_card_specializing) e 5 (college_completion). I quattro database commerciali portano 171 delle 184, ovvero 93%. Gli altri cinque database non contribuiscono per nulla, perché sono semanticamente abbastanza isolati da far sì che nessuna loro domanda superi entrambi i segnali. Il numero misura quindi l'instradamento tra database progettati per essere difficili da distinguere, ed è dominato da un unico cluster commerciale piuttosto che distribuito su undici domini.

Instradamento dichiarato. Il database che il modello indica nella sua risposta finale sotto una chiave esplicita selected_database. Un'esecuzione che non nomina alcun database ottiene punteggio zero anziché ereditare l'ultima chiamata allo strumento. Gli instradamenti recuperati dalla prosa sono esclusi e riportati separatamente.

Risultati del benchmark Agentic RAG

Rieseguire il leader del panel lo fa scendere al sesto posto

claude-opus-5 ha instradato correttamente 0.848 delle domande più difficili, 156 su 184. Lo abbiamo rieseguito una seconda volta in condizioni identiche, stesso insieme congelato, stessa anonimizzazione, temperatura 0, e ha registrato 0.8207, 151 su 184. Quel secondo punteggio è il punteggio pubblicato di claude-fable-5, che si trova al sesto posto. Le posizioni dalla 1 alla 6 vanno da 156 su 184 risposte corrette fino a 151 su 184, una distanza di cinque domande, che è la distanza che il leader stesso ha percorso tra due esecuzioni.

Un secondo modello ha riprodotto lo schema. qwen3.8-max è passato da 0.8315 (153/184) a 0.8152 (150/184). I bucket facile e medio si sono spostati di 0.0000 in entrambi i modelli, e il resto del movimento si trova nei tre bucket difficili, con qwen3.8-max che è passato anche da 153 a 152 sulle domande segnalate dal conteggio dei vicini.

qwen3.8-max ha il delta aggregato più piccolo, 1.6 punti contro 2.7, e il maggiore disaccordo con se stesso, instradando in modo diverso su 13 delle 184 domande difficili dove opus-5 differisce su 8. Un modello può riprodurre il proprio punteggio pur essendo in disaccordo con se stesso su una domanda difficile su quattordici.

Due limitazioni accompagnano questo dato. Una ripetizione fornisce una differenza assoluta, non una deviazione standard, quindi da 1.6 a 2.7 punti è un limite inferiore del rumore piuttosto che una sua descrizione. E 34 delle 36 righe del panel non hanno alcuna ripetizione. Leggete questi punteggi per fasce, non per classifiche.

I soli nomi degli 11 database instradano entro 4 punti dal catalogo completo

Mostrando i nomi reali dei database e nessuna descrizione, claude-opus-4.8 instrada a 0.688 e gemini-3.5-flash a 0.711. Mostrando il catalogo completo, nomi reali più tutte le 11 descrizioni dei paragrafi, gli stessi due modelli ottengono 0.672 e 0.750, quindi per claude-opus-4.8 i soli nomi ottengono un punteggio più alto dell'intero catalogo.

Sostituire i nomi con db_01 fino a db_11 costa a opus-4.8 7.0 punti e a gemini 4.7. Un'esecuzione con nomi reali misura il riconoscimento del nome insieme alla comprensione, motivo per cui ogni numero pubblicato qui proviene dalla condizione anonimizzata.

Una terza condizione separa i due canali. Mantenendo i nomi reali e permutando le descrizioni tra i database, l'instradamento crolla a 0.148 e 0.055, misurato sugli stessi due modelli su un test pilota di 128 domande.

I database scelti per essere confondibili sono circa 20 punti più difficili di quelli casuali

Abbiamo sostituito i 10 database distrattori con 10 estratti casualmente dagli altri 69 di BIRD, sulle stesse 128 domande, stesso database di riferimento, entrambi i bracci anonimizzati. L'instradamento hard_strict passa da 0.713 a 0.920 per claude-opus-4.8 e da 0.770 a 0.966 per gemini-3.5-flash. Entrambi i bracci rispondono alle stesse domande, quindi il test è McNemar con correzione di continuità sulle coppie discordanti, che dà p = 8.6e-04 e p = 2.4e-04. Undici candidati scelti casualmente lasciano entrambi i modelli vicini al massimo.

Sul bucket facile lo stesso contrasto McNemar non è significativo, p = 0.48 e p = 1.00. I distrattori selezionati per cluster avevano lo scopo di interferire con le domande che il conteggio dei vicini segnala come confondibili e di lasciare il resto instradabile indipendentemente dal panel, e questo è lo schema mostrato dai due bracci.

Questa ablazione è solo descrittiva e a colpo singolo piuttosto che agentic, con un'estrazione casuale del panel per domanda. Essa autorizza l'affermazione che la selezione per scoperta di cluster produce un instradamento misurabilmente più difficile rispetto alla selezione casuale. Non autorizza l'affermazione che il conteggio dei vicini stesso causi difficoltà, cosa che abbiamo testato separatamente e trovato non significativa di per sé.

La fascia alta di instradamento non è una fascia di prezzo

qwen3.8-max e kimi-k3 instradano entrambi 153 delle 184 domande difficili, 0.8315 ciascuno, a $25.14 e $40.34 per esecuzione di 759 domande. claude-fable-5 costa $121.55 e instrada 151. Sei modelli si trovano entro 0.03 dal leader su un intervallo di costo di 5x.

La colonna dei costi registra quanto è stato fatturato per l'esecuzione, non l'economia del modello. OpenRouter instrada uno slug di modello verso il provider upstream che lo sta servendo, e le identiche 594 domande sullo stesso modello sono costate $2.09 in un'esecuzione e $8.33 in un'altra. Leggete la colonna come un ordine di grandezza. Una direzione sopravvive a questa deriva. Le due esecuzioni più costose del panel, claude-fable-5 a $121.55 e claude-opus-4.8 a $117.82, non instradano meglio di qwen3.8-max a $25.14.

Un modello può eseguire il ciclo agentic senza trarne beneficio

Limitandosi alle domande il cui primo turno ha sondato un singolo database, il divario di accuratezza tra il primo database toccato da un modello e quello che infine dichiara è di +25.0 punti per claude-opus-5 e +38.0 per grok-4.5. Per gpt-5.4-mini quel divario è 0.0. Per gpt-oss-120b è -3.8 e per nova-lite-v1 è -14.0. Entrambi questi modelli abbandonano un primo sondaggio corretto più spesso di quanto recuperino da uno sbagliato.

I due gruppi differiscono per ampiezza dell'esplorazione. Aggregati sul panel, i modelli sondano 1.12 database distinti sulle domande facili e 1.93 su quelle più difficili. kimi-k3 passa da 1.07 a 2.27 e grok-4.5 da 1.06 a 2.21, mentre gpt-oss-120b passa da 1.01 a 1.10 e gpt-5.4-nano da 1.11 a 1.20.

gpt-5.4-nano impiega 6.5 turni per domanda ed emette chiamate agli strumenti per tutto il tempo, quindi il ciclo viene eseguito. L'esecuzione del ciclo gli fa guadagnare 2.2 punti.

Alcuni provider hanno ignorato la nostra richiesta di chiamate sequenziali agli strumenti. Quando un primo turno ha toccato più database contemporaneamente lo escludiamo da questo confronto, che quindi viene eseguito su meno di 184 domande per alcuni modelli (qwen3.8-max 86, glm-5.2 101, kimi-k3 105).

Sondaggio, commutazione e il divario tra primo sondaggio e instradamento dichiarato

L'esplorazione scala con l'etichetta di difficoltà. Aggregati su tutti i 36 modelli e 759 domande:

Sui 3.122 record di domande più difficili in cui un modello ha cambiato instradamento almeno una volta, 1.717 sono passati da un database sbagliato a quello giusto e 90 sono passati nella direzione opposta, un guadagno netto di 1.627 record con un rapporto vicino a 19 a 1. Ulteriori 983 hanno iniziato su un database sbagliato e non hanno mai raggiunto quello giusto, e 332 hanno lasciato il database corretto per poi tornarvi. Tutti e quattro i conteggi utilizzano la rotta a dichiarazione esplicita, la stessa definizione di ogni altro numero di instradamento qui.

Questa asimmetria è il motivo per cui il benchmark valuta l'instradamento dichiarato invece del primo sondaggio. La versione precedente registrava la prima chiamata di funzione al database dell'agente come sua decisione di instradamento. Su questo panel, tale convenzione sottostima 30 dei 36 modelli di una quantità compresa tra 14.7 e 38.0 punti.

Costo per esecuzione nel panel di 36 modelli

Le 36 esecuzioni sono costate $874.53 in totale, da $0.47 a $121.55. Sei di esse hanno totalizzato meno di 759 domande a causa di errori residui del provider (gemini-3.1-pro-preview 744, gemini-3-flash-preview 755, claude-haiku-4.5 750, nova-lite-v1 750, gpt-5.6-luna 758, gpt-5.6-terra 758).

Il conteggio dei turni varia da 3.79 a 7.64 attraverso il panel e alimenta il conto insieme al prezzo per token. claude-opus-5 ha una media di 3.92 turni per domanda a $62.78, gemini-3.1-pro-preview 7.02 a $80.01 e gpt-oss-120b 3.79 a $0.47.

Tre delle 36 esecuzioni hanno utilizzato la cache dei prompt e le altre 33 no, quindi le righe non sono fatturate sulla stessa base e le tre righe in cache si collocano più in basso di quanto farebbe un'esecuzione non in cache dello stesso modello.

Cache dei prompt e quanto costa il controllo del bias di posizione

In questo benchmark 44% di ogni chiamata del ciclo degli strumenti è un prefisso byte-identico, il prompt di sistema a 362 token più le 11 definizioni degli strumenti a 2.259, quindi 2.621 token di una chiamata che in media si aggira intorno a 6.000. Tre esecuzioni avevano un punto di interruzione esplicito della cache su quel prefisso. claude-opus-5 ha letto 62.2% del suo input dalla cache ed è stato fatturato $62.78 contro $105.54 a prezzo di listino, uno sconto del 40.5%. qwen3.8-max ha letto 68.2%, il massimo che abbiamo misurato, su Alibaba piuttosto che su Anthropic.

Il risparmio è limitato da una decisione progettuale. L'elenco degli strumenti viene permutato per ogni domanda, quindi il prefisso differisce dal byte 0 tra una domanda e l'altra e la cache di ogni domanda viene scritta e letta all'interno delle sue circa cinque chiamate, mai attraverso l'esecuzione. Congelare l'ordine degli strumenti amplierebbe la cache e farebbe risparmiare circa $8.95 per esecuzione di 759 domande. Abbiamo mantenuto la permutazione e l'abbiamo prezzata.

La cache ha modificato il conto e non l'input del modello. Una suite di test negativi cattura i corpi delle richieste reali con il flag attivo e disattivo e richiede che siano byte-identici una volta rimossi i marcatori della cache, e il suo test portante muta un singolo carattere sotto un marcatore e richiede che il controllo lo rilevi. Un difetto di costo è comunque sopravvissuto a quella suite. Il turno di finalizzazione deliberatamente non invia definizioni degli strumenti, quindi il suo prefisso non corrisponde a nessuna voce in cache, e lasciare un punto di interruzione su di esso ha scritto circa 3.2M token di cache che nulla poteva leggere, circa $4 del conto di opus-5. Una revisione avversaria dopo il rilascio della modifica l'ha trovato, con ogni controllo verde.

Agentic RAG e RAG standard

La generazione aumentata dal recupero (Retrieval-Augmented Generation) pone un passo di recupero davanti a un modello linguistico. La domanda viene incorporata, i chunk più vicini vengono restituiti da un indice e il modello risponde basandosi su di essi. Il percorso è fisso e nulla nella pipeline sceglie qualcosa.

L'Agentic RAG affida le decisioni di recupero al modello. Esso sceglie quale fonte interrogare, legge ciò che viene restituito e può interrogare di nuovo, cambiare fonte o perfezionare la query prima di rispondere. Il recupero cessa di essere un passo che viene eseguito una volta sola e diventa un ciclo guidato dal modello.

Quella prima scelta, quale fonte contenga la risposta, è ciò che questo benchmark misura. Ogni modello vede 11 SQL database descritti a livello di paragrafo, con i loro nomi nascosti, e deve sceglierne uno prima di scrivere qualsiasi SQL. Può poi sondarne un secondo e un terzo e cambiare idea. Sulle domande più difficili il panel sonda in media 1.93 database, e 47.3% delle esecuzioni ne tocca più di uno.

Come funziona l'instradamento agentic dei database

L'harness fornisce al modello una domanda e un catalogo di 11 descrizioni di paragrafi, una per database, senza nomi di tabelle o colonne al loro interno. Insieme al catalogo, allega 11 strumenti, uno per database, ciascuno che espone tre azioni: get_schema restituisce l'elenco delle tabelle, get_table_schema restituisce le colonne di una tabella e execute_query esegue SQL su quel database. L'output dello schema è limitato a 4.000 caratteri e i risultati delle query a 50 righe.

Da lì il modello guida. Sceglie uno strumento, legge la risposta all'interno della stessa conversazione e può sondare un database diverso, chiedere il dettaglio di una tabella o eseguire una query sul database su cui ha deciso. Può cambiare database in qualsiasi turno, e 47.3% delle domande più difficili vengono effettivamente sondate su più di uno.

Il ciclo termina in due modi. O il modello smette di richiedere strumenti, oppure utilizza la sua nona chiamata abilitata agli strumenti. In entrambi i casi, l'harness invia quindi una chiamata di finalizzazione senza strumenti allegati, in cui il modello dichiara il database scelto e il suo SQL. Tale chiamata viene eseguita incondizionatamente, per ogni modello e ogni domanda, quindi il budget di chiamate è di nove turni di strumenti più uno, al massimo 10 API chiamate.

Il budget uguale è una correzione a un progetto precedente. Quel progetto aggiungeva il turno di finalizzazione per i modelli che non avevano ancora emesso SQL, il che concedeva una chiamata extra a un'abitudine di output piuttosto che all'abilità. Il limite massimo non è nemmeno una quota. Il panel ha una media tra 3.79 e 7.64 turni di strumenti per domanda, perché un modello può smettere di sondare presto.

Metodologia del benchmark Agentic RAG

Il benchmark misura due competenze separatamente. L'instradamento decide quale database contenga la risposta, e la generazione SQL decide se la query restituisce le righe corrette. L'instradamento è il contributo e porta il titolo principale. La correttezza SQL è misurata rispetto alle query di riferimento di BIRD ed è riportata con la propria incertezza sulla pagina del benchmark text-to-SQL.

• Dataset: split train e dev di BIRD-SQL, 759 domande congelate e bloccate tramite hash.
• Database: 11, selezionati da 80 candidati BIRD tramite clustering agglomerativo dei loro embedding di descrizione a coseno 0.65.
• Segnale di difficoltà: per ogni domanda, i suoi 20 vicini più prossimi contati in base a quanti appartengono a un database diverso.
• Bucket di difficoltà: facile 222, medio 118, qq_only_hard 165, jury_only_hard 70, hard_strict 184.
• Condizione primaria: anonimizzata. I nomi dei database sostituiti da db_01 a db_11 nei nomi degli strumenti e nell'output dello schema.
• Condizione di evidenza: nessuna. L'indicazione di dominio di BIRD è omessa per ogni modello.
• Strumenti: 1 per database, ciascuno che espone 3 azioni (get_schema, get_table_schema, execute_query), 11 in totale, ordine permutato per domanda.
• Vocabolario: una API call è una richiesta al modello. Un turno di strumento è una API call che trasporta l'elenco degli strumenti e può tornare con chiamate agli strumenti. Una chiamata allo strumento è un'azione di database all'interno di un turno, al massimo 11 per turno. La chiamata di finalizzazione è l'ultima API call, inviata senza strumenti.
• Budget di turni: al massimo 10 API call per domanda, fino a 9 turni di strumenti più esattamente una chiamata di finalizzazione che viene sempre eseguita.
• Turni di strumenti utilizzati: da 3.79 a 7.64 per domanda in media nel panel, perché un modello può smettere di sondare presto. Il campo registrato conta i turni di strumenti ed esclude la chiamata di finalizzazione, quindi il suo limite massimo è 9 anziché 10.
• Temperatura: 0. Richieste di chiamate sequenziali agli strumenti. Domande mescolate una volta con un seme fisso prima di qualsiasi suddivisione.
• Metrica di instradamento: accuratezza finale dell'instradamento sul database dichiarato esplicitamente.
• Metrica SQL: corrispondenza di esecuzione rispetto alla query di riferimento di BIRD, riportata come un intervallo a tre valori.
• Panel: 36 modelli, singola esecuzione ciascuno tranne due ripetizioni, $874.53 per le esecuzioni del panel più $85.37 per le ripetizioni.

Quali database portano le domande difficili. Cinque degli undici non contribuiscono affatto alle 184 domande più difficili. Sono california_schools più i quattro semanticamente isolati (financial, synthea, superhero, toxicology), che comunque forniscono 27 delle 165 domande segnalate dai vicini tra di loro.

La tassonomia di difficoltà. Due segnali indipendenti etichettano ogni domanda. Il primo incorpora tutte le 1.922 domande appartenenti agli 11 database e conta, tra i 20 vicini più prossimi di ogni domanda, quanti si trovano in un database diverso. Il secondo è una giuria di tre modelli a cui viene chiesto se la domanda è confondente tra i database. Il bucket più difficile richiede entrambi anziché combinarli.

Nessuno dei due segnali è significativo da solo. La loro congiunzione lo è. Misurata su un modello, l'accuratezza di instradamento sulle domande segnalate da entrambi i segnali era 0.803 volte l'accuratezza sulle domande facili dello stesso database, 95% CI [0.685, 0.943], p = 0.007. Confrontiamo all'interno di ogni database, quindi aggreghiamo tra i database con un rapporto di rischio logaritmico a varianza inversa e una correzione di continuità di 0.5. L'aggregazione avviene su 5 database anziché 6, perché regional_sales porta domande difficili ma nessuna facile e quindi non ha nulla con cui accoppiarsi. Tre fattori mantengono il contrasto esplorativo. Si basa su un modello e cinque strati, ed è osservazionale piuttosto che randomizzato.

Cosa vede il modello. Ogni modello riceve una descrizione a paragrafo di tutti gli 11 database, senza nomi di tabelle o colonne, più gli 11 strumenti per i database. L'anonimizzazione rimuove il nome ma non il dominio. Le descrizioni dicono ancora di cosa tratta ogni database e una volta che il modello chiama get_schema vede i nomi reali di tabelle e colonne. La condizione misura la comprensione della descrizione.

Valutazione dell'instradamento. Il database dichiarato è quello che il modello nomina sotto una chiave esplicita selected_database nel turno di finalizzazione. Un modello che non produce alcuna dichiarazione esplicita ottiene punteggio zero per quella domanda. Gli instradamenti dedotti dalla prosa rimangono fuori dal titolo principale e sono pubblicati separatamente. Una versione precedente di questo lavoro portava tre diverse definizioni della metrica, e la variante estratta dalla prosa gonfiava sei righe del panel da 0.6 a 4.9 punti.

Valutazione dell'SQL. La correttezza è decisa eseguendo entrambe le query e confrontando gli insiemi di risultati. Il nostro audit a cinque modelli ha segnalato che 31.1% delle query di riferimento di BIRD sono difettose, quindi quell'asse è riportato come un intervallo a tre valori anziché come un punteggio singolo. Le regole di valutazione, l'audit di riferimento e l'intervallo completo si trovano sulla pagina text-to-SQL linkata sopra.

Recupero delle chiamate agli strumenti. Cinque famiglie di modelli serializzano le chiamate agli strumenti in formati che il parser standard non accetta. Un livello di recupero analizza tali formati anziché considerarli silenzio, e ogni recupero è registrato per record e per esecuzione. Le chiamate troncate non vengono mai ricostruite. Sei delle 36 righe portano una quota di recupero diversa da zero. Cinque di esse sono di dimensioni trascurabili, 0.4% a 4.4%. La sesta è più grande. llama-4-maverick si attesta a 97.9%, quindi quasi ogni chiamata allo strumento in quella riga è stata recuperata dall'adattatore e quella riga misura il modello più il livello di recupero piuttosto che il modello da solo. Un modello, minimax-m2.7, narra senza emettere alcuna chiamata allo strumento e lo escludiamo dal panel invece di assegnargli punteggio zero.

Non perderti i nostri benchmark e approfondimenti basati sui dati. Il pulsante apre Google; selezionare AIMultiple conferma che desideri vedere AIMultiple più spesso nei risultati di ricerca di Google.

Aggiungi come fonte preferita

Modelli testati

Quattro righe portano un denominatore di domande difficili più piccolo dopo che due passaggi di ripetizione hanno lasciato errori residui del provider, a 182 per gemini-3.1-pro-preview, gemini-3-flash-preview e nova-lite-v1, e 181 per claude-haiku-4.5. Quelle domande sono rimosse dal denominatore invece di essere conteggiate come fallimenti, quindi ogni percentuale è calcolata sui record che sono stati eseguiti.

Accuratezza di instradamento (tutte le 759): La stessa misurazione sull'intero insieme congelato, inclusi i bracci di controllo facile e medio. Il braccio facile è saturo per progettazione.

Gli intervalli al 95%: Ogni intervallo nella tabella sopra è un intervallo di Wilson sulle domande difficili valutate per quel modello, che è 184 per la maggior parte delle righe e 182 o 181 per le quattro righe che hanno perso domande a causa di errori residui del provider. Copre l'incertezza di campionamento delle domande e nient'altro. Non copre il raggruppamento delle domande all'interno dei database, e non copre la variazione tra esecuzioni, che abbiamo misurato separatamente tra 1.6 e 2.7 punti e che è il termine più grande per qualsiasi coppia di modelli vicini l'uno all'altro.

Casualità e linee di base. La probabilità casuale è 0.091 su 11 database. La classe maggioritaria è 0.196 sulle 759 domande e 0.277 su quelle più difficili. Tre recuperatori non agentici ottengono 0.471 (TF-IDF), 0.495 (BM25) e 0.522 (database più vicino per embedding) complessivamente, e da 0.207 a 0.230 su quelle più difficili. Quei tre sono stati misurati sul precedente insieme di 594 domande e non sono stati rieseguiti sulle 759, quindi sono punti di riferimento storici piuttosto che linee di base per questo panel. La probabilità casuale e la classe maggioritaria sono calcolate sulle 759 congelate e sono direttamente confrontabili.

Limitazioni

Entrambi i modelli a esecuzione ripetuta si trovano nella fascia alta, dove le domande sono più difficili e i punteggi sono più compressi. Nessun modello di fascia media è stato ripetuto, quindi il termine di rumore al di fuori della fascia alta non è misurato.

I controlli di contaminazione limitano l'effetto, non lo eliminano. Abbiamo riscritto le domande difficili per preservare il significato e il riferimento, cambiando la formulazione. Sulle 138 delle 184 parafrasi che hanno superato tutti e tre i controlli di validità, l'instradamento non è diminuito e l'effetto del panel è risultato significativo nella direzione opposta, da 0.543 a 0.583, McNemar p = 0.032. Ogni domanda è valutata in entrambi i bracci, quindi l'accoppiamento è reale: 87 coppie hanno favorito la parafrasi contro 60. Sessantacinque domande create da zero e abbinate per difficoltà, stile di formulazione e composizione del database hanno ottenuto un punteggio entro +0.012 dall'insieme pubblicato, p = 0.74. Quest'ultimo confronto è tra due insiemi di domande indipendenti piuttosto che accoppiati, quindi è un confronto a due proporzioni ed è il più debole dei due disegni. Il controllo creato copre 3 degli 11 database, il controllo delle parafrasi 6, ed entrambi sono stati eseguiti solo su modelli economici. Un controllo su database pubblicati dopo le date di cutoff dei modelli non è stato tentato, e 560 delle 759 domande (73.8%) provengono dallo split train di BIRD, la quota più probabile di essere stata memorizzata.

L'eliminazione dei record non valutati sposta il titolo principale al massimo di 0.90 punti. Sei righe hanno perso domande a causa di errori residui del provider e quelle domande escono dal denominatore invece di contare come fallimenti, il che gonfia un punteggio se le perdite cadono su domande difficili. Valutare ogni domanda persa come sbagliata sposta invece gemini-3.1-pro-preview da 0.8242 a 0.8152 sulle domande più difficili (-0.90 pt) e da 0.9140 a 0.8959 sulle 759 (-1.81 pt), gemini-3-flash-preview -0.81 pt, claude-haiku-4.5 -0.79 pt, nova-lite-v1 -0.13 pt. Sette posizioni in classifica si scambiano sulle domande più difficili, ognuna di esse adiacente e ognuna all'interno del rumore tra esecuzioni di 1.6 a 2.7 punti. La convenzione non è quindi determinante alla risoluzione di questo panel.

Le domande più difficili sono una misurazione del cluster commerciale. Quattro database commerciali portano 171 delle 184 domande difficili e cinque database non ne portano nessuna. Il titolo principale generalizza all'instradamento tra database reciprocamente confondibili, che è ciò che il benchmark è stato costruito per misurare, e non all'instradamento cross-dominio in generale. Ampliarlo significa aggiungere domande difficili da un secondo cluster semantico, cosa che il corpus attuale non può fornire.

Il panel è stato eseguito su un harness misto. Diciannove modelli sono stati valutati dopo l'aggiunta del livello di recupero delle chiamate agli strumenti, quindici prima, e due sono a cavallo del cambiamento. Un modello nel gruppo precedente che ha emesso una chiamata allo strumento non standard l'ha vista valutata come silenzio. Analizzando il livello di recupero su tutti i 27.306 record memorizzati non è stata trovata alcuna chiamata recuperabile in nessuna delle righe precedenti, quindi il costo misurato della combinazione è zero, ma una serializzazione che nessun parser gestisce sarebbe invisibile anche a quella scansione.

Le esecuzioni non sono riproducibili a livello di bit. OpenRouter ha servito kimi-k2.6 da 19 provider upstream distinti all'interno di una singola esecuzione e deepseek-v4-pro da 12, e il comportamento di serializzazione differisce tra loro. Tre delle 36 esecuzioni hanno fissato un provider.

L'anonimizzazione è solo del nome. Le descrizioni nominano ancora i loro domini e la prima chiamata allo strumento restituisce nomi reali di tabelle e colonne, quindi questa condizione misura la comprensione di una descrizione piuttosto che il riconoscimento di un nome.

L'output dello schema è troncato a 4.000 caratteri. works_cycles è il database più grande con 66 tabelle, e 26 di esse sopravvivono al taglio. Quel database porta 149 delle 759 domande. I risultati delle query sono limitati a 50 righe.

L'asse di instradamento sta esaurendo lo spazio di manovra. Il braccio di controllo facile è esaurito a 222 su 222 per i migliori modelli, e il bucket più difficile comprime sei modelli in cinque domande. Questo benchmark non può più separare i modelli di frontiera l'uno dall'altro sull'instradamento.

Ulteriori letture

• RAG Frameworks: LangChain vs LangGraph vs LlamaIndex
• Migliori RAG Tools, Frameworks e Librerie
• Agentic Search nel 2026: Benchmark 8 APIs per Agenti
• Top 5 Framework Open-Source di IA Agentic nel 2026
• Text-to-SQL: Confronto dell'Accuratezza degli LLM

FAQ

Cita questo benchmark

Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Agentic RAG Benchmark: Instradamento Multi-Database su 36 LLM}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/agentic-rag}},
  note   = {AIMultiple. Consultato il 11 Agosto 2026}
}

Collegamenti di riferimento

1.

BIRD-bench

Ekrem Sarı

Ricercatore AI

Segui

Ekrem è Ricercatore AI e analista di dati presso AIMultiple. Progetta ed esegue benchmark pratici per sistemi di AI e LLM.

Visualizza il profilo completo

Sii il primo a commentare

Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento