Benchmark di RAG agentica: instradamento tra 11 database SQL

L'accuratezza di instradamento è la percentuale di domande valutate per cui il modello nomina esplicitamente il database corretto nella risposta finale. Il risultato principale utilizza le 184 domande contrassegnate come difficili sia dal nostro test di similarità sia da una giuria di tre LLM. Le dichiarazioni esplicite mancanti non ricevono alcun punteggio.

Risultati sull'instradamento dei database

qwen3.8-max ha registrato un'accuratezza di instradamento del 83,2% per un'esecuzione da $25,14

Qwen3.8-max ha risposto correttamente a 153 delle 184 domande difficili di instradamento a un costo registrato di $25.14. claude-fable-5 ne ha risposte 151 a $121.55. Tutte le 759 domande sono state completate in entrambe le esecuzioni.

Questa differenza di due domande è inferiore alla variazione misurata nella ripetizione del qwen3.8-max. I costi registrati dipendono dalla scelta del provider e dall'uso della cache, pertanto questo confronto non può stabilire una classifica duratura di prezzo-prestazioni.

L'accuratezza di instradamento finale è aumentata per Grok e Opus, ma è diminuita per Nova

Per claude-opus-5, l'accuratezza sulle domande difficili è aumentata di 25.0 punti percentuali tra la prima verifica del database e la dichiarazione finale. grok-4.5 ha guadagnato 38.0 punti all'interno della propria esecuzione. gpt-5.4-mini non ha registrato alcun guadagno, mentre nova-lite-v1 ha perso 14.0 punti.

Ogni variazione confronta l'inizio e la fine di un'unica esecuzione. Le domande che hanno coinvolto più database al primo turno sono escluse perché non hanno una sola prima scelta.

Questo conteggio utilizza il primo database nell'ordine registrato delle chiamate, inclusi i primi turni con più database. Le variazioni in punti percentuali sopra indicate utilizzano una sola prima scelta.

Una chiamata al database, quindi, non garantisce una correzione utile. Ciò che conta è se il modello usa le informazioni restituite per arrivare alla scelta finale giusta. Si tratta di un'osservazione delle traiettorie registrate, senza un intervento separato che isoli il valore delle chiamate aggiuntive.

Risultati sull'instradamento dei database

I modelli sono presentati in ordine alfabetico. La metodologia rileva differenze nel software utilizzato per eseguirli. Queste condizioni contano nell'interpretare piccole differenze di punteggio.

Gli intervalli stimano l'incertezza di campionamento delle domande. I costi registrati coprono i record riusciti in ciascuna esecuzione. Riflettono i provider e le condizioni di caching utilizzate al momento della misurazione.

Modelli decisionali per l'instradamento dei database

Abbiamo confrontato Jev, Kev-9B, Laya English e sei LLM su 243 domande esaminate dagli stessi 11 database. Ogni modello ha selezionato un database a partire dalle descrizioni fornite.

Laya è stato eseguito localmente su un Apple M4. Kev è stato eseguito su un servizio A100 dedicato raggiunto tramite un tunnel SSH. Gli altri modelli hanno utilizzato API ospitate. La latenza include la richiesta client completa tra le risposte valide. L'accuratezza include ogni domanda tentata.

Jev ha selezionato il database corretto per 240 delle 243 domande, rispetto alle 123 di Laya English: 117 selezioni corrette in più, una differenza di 48.1 punti percentuali. Jev è stato il modello ospitato più veloce per latenza mediana in questa esecuzione. Il deployment locale di Laya ha avuto la latenza mediana più bassa in assoluto, insieme a un'accuratezza sostanzialmente inferiore.

Kev-9B ha selezionato correttamente 236 database, quattro in meno di Jev. Cinque dei suoi sette errori hanno riguardato il database delle carte di debito carburante. La sua risposta mediana ha richiesto 952 ms inclusi rete e tunnel SSH. La mediana del server registrata separatamente è stata di 470 ms. Questa implementazione su A100 ha utilizzato FP32 e kernel di riferimento. La sua velocità dipende da quella configurazione di serving.

Gemini 3.8 Flash e Claude Opus 5 hanno selezionato entrambi il database corretto per ogni domanda. Opus ha impiegato 1.72 volte il tempo mediano e il suo costo API dichiarato è stato 7.58 volte quello di Gemini per queste domande. L'accuratezza è stata uguale per questi due modelli su questo set.

Il risultato di DeepSeek include 19 errori di servizio o di output: 16 risposte HTTP 429, due risposte che hanno violato il formato richiesto a singolo alias e una che ha esaurito il budget di output. Ha selezionato il database corretto in 211 delle sue 224 risposte valide, ovvero il 94,2%. Contando tutti i tentativi si ottiene il 86,8% mostrato nel grafico e nella tabella.

Costi di instradamento: prezzi delle API e stime hardware

Jev ha selezionato il database corretto per il 98,8% delle domande a un costo API di $0,0337 per 1.000 tentativi di instradamento. Qwen3.8 Flash ha registrato un'accuratezza del 97,9% a $0,0791, mentre Gemini 3.8 Flash ha raggiunto il 100,0% a $0.5337. Abbiamo scalato i costi dallo stesso carico di 243 domande, includendo le risposte errate ed escludendo i riscaldamenti. Il costo API di Jev è stato circa 1/120 di quello di Claude Opus 5 per gli stessi 243 tentativi di instradamento.

La stima hardware per Laya è stata di $0,0141 per 1.000 tentativi con un'accuratezza del 50,6%. Kev ha raggiunto il 97,1% a una stima di $0.1250. Entrambe le stime presuppongono che la macchina noleggiata elabori continuamente le richieste. Al 10% di utilizzo, ogni richiesta comporta dieci volte il costo di noleggio, portando Laya a $0,1405 e Kev a $1,2503 per 1.000 tentativi.

Per i cinque LLM con registrazioni di addebito complete, abbiamo diviso i costi API dichiarati per 243 e moltiplicato per 1.000. Jev addebita $0,042 per milione di token in input, con token in output gratuiti. I suoi 194.882 token in input registrati sono costati $0,008185 su 243 tentativi, ovvero $0,0337 per 1.000.¹

Il costo hardware per 1.000 tentativi è uguale al prezzo orario del noleggio × i secondi medi di elaborazione × 1.000 ÷ (3.600 × l'utilizzo). Laya ha registrato una media di 0.2006 secondi per richiesta su un Apple M4. Kev ha registrato una media di 0.4734 secondi sul server A100, escludendo rete e ritardo SSH. Abbiamo applicato questi tempi all'hardware corrispondente presso i provider indicati. Le prestazioni e i totali di fatturazione presso tali provider rimangono non misurati.

Per Kev, abbiamo utilizzato $0,9508/ora per un A100 SXM da 80 GB presso Vast.ai, l'offerta on-demand corrispondente più bassa nei dati del nostro indice dei prezzi di noleggio GPU.

Per Laya, abbiamo utilizzato M4-S di Scaleway con 16 GB di memoria a €0.22/ora. La conversione utilizza il tasso della BCE del 22 settembre di $1,1463 per euro. Scaleway richiede un noleggio minimo di 24 ore, quindi il noleggio minimo è di €5.28, ovvero circa $6,05, anche per un lavoro breve.²³⁴

La pagina del modello di Laya non elencava alcun Inference Provider Hugging Face. La nostra stima copre il noleggio di una macchina e l'esecuzione del modello su di essa. Tempo di configurazione, storage, costi di rete aggiuntivi, tasse e lavoro operativo sono esclusi da entrambe le stime hardware.⁵

Come i modelli decisionali scelgono un database

Per Jev e Laya, l'applicazione fornisce il contesto, una domanda e opzioni denominate con descrizioni. Le loro interfacce Choice restituiscono un'opzione selezionata, le probabilità delle opzioni e un punteggio di confidenza. Il codice dell'applicazione decide cosa fare con tale risultato. Per l'instradamento, le opzioni sono alias di database come db_03 e db_07.⁶⁵

Questo formato rende l'output facile da usare nel codice. Un modello può comunque scegliere il database sbagliato. Un punteggio di confidenza elevato deve inoltre essere convalidato rispetto alla correttezza osservata prima che un'applicazione lo utilizzi per saltare la revisione o attivare un fallback.

Il checkpoint English di Laya utilizza un encoder ModernBERT bidirezionale con una testa decisionale che assegna un punteggio alle opzioni fornite. Le descrizioni delle opzioni arrivano con la richiesta, quindi l'applicazione può modificare le proprie scelte disponibili. Jev espone una API Choice ospitata. La sua documentazione colloca il controllo del flusso di lavoro e le azioni nel codice dell'applicazione. L'interfaccia condivisa non stabilisce che i due modelli abbiano la stessa architettura interna.⁵⁷

Kev-9B utilizza un adattatore LoRA e una testa pointer su Qwen3.5-9B-Base. Assegna un punteggio alle scelte fornite e restituisce le loro probabilità senza generare testo di risposta. Abbiamo utilizzato il suo endpoint Choice compatibile con la stessa domanda e le stesse descrizioni dei database.⁸

Condizioni che influenzano la selezione del database

Database simili hanno ridotto l'accuratezza di instradamento di circa 20 punti

Abbiamo testato il metodo di selezione del database in un esperimento separato su 128 domande. Ogni domanda ha mantenuto il proprio database corretto, mentre gli altri 10 candidati provenivano dal nostro gruppo selezionato oppure da un'estrazione casuale.

Sul sottoinsieme difficile, claude-opus-4.8 ha ottenuto il 71,3% con candidati simili e il 92,0% con candidati casuali. gemini-3.5-flash ha ottenuto il 77,0% e il 96,6%. Entrambe le differenze hanno avuto p-value inferiori a 0.001 nei test appaiati.

Questo esperimento ha utilizzato descrizioni e una risposta del modello per domanda, senza il ciclo di strumenti agentico. Supporta la conclusione più ristretta secondo cui selezionare candidati simili rende più difficile la scelta del database. Il divario misurato non deve essere presentato come l'effetto dell'esplorazione agentica.

I soli nomi hanno prodotto un'accuratezza del 68,8% e del 71,1% in un test pilota

In un altro test pilota su 128 domande, claude-opus-4.8 ha selezionato il database giusto il 68,8% delle volte basandosi solo sui nomi. Il suo punteggio con nomi e descrizioni è stato del 67,2%. gemini-3.5-flash ha ottenuto il 71,1% dai nomi e il 75,0% dal catalogo completo.

Nomi come california_schools e toxicology rivelano direttamente l'argomento. Per il benchmark principale, sostituiamo i nomi dei database con alias da db_01 a db_11. Le descrizioni spiegano comunque il dominio di ciascun database e le risposte degli strumenti espongono i nomi di tabelle e colonne.

Affidabilità dei confronti di instradamento e costo

Esecuzioni ripetute hanno modificato l'accuratezza di instradamento da 1.6 a 2.7 punti

claude-opus-5 ha selezionato il database corretto per 156 delle 184 domande difficili nella prima esecuzione e per 151 nella ripetizione. La sua accuratezza è scesa dal 84,8% all'82,1%. qwen3.8-max è passato da 153 risposte corrette a 150, con un calo dal 83,2% all'81,5%.

Entrambe le ripetizioni hanno utilizzato le stesse domande, anonimizzazione, temperatura e impostazioni del provider delle esecuzioni originali. qwen3.8-max ha cambiato risposta su 13 domande difficili anche se il suo totale è variato di tre. I miglioramenti su alcune domande hanno annullato gli errori su altre.

Queste ripetizioni mostrano che piccole differenze di punteggio possono scomparire in un'altra esecuzione. Una sola ripetizione per modello non può stabilire una distribuzione degli esiti e gli altri 35 modelli non hanno una misurazione ripetuta.

I costi registrati dipendono dal provider e dalle impostazioni di caching

La memorizzazione nella cache dei prompt riutilizza input elaborati in precedenza per ridurre i costi fatturati di input. L'esecuzione di claude-opus-5 è costata $62,78, rispetto a una stima di $105,54 alle tariffe di listino senza cache per lo stesso utilizzo registrato. Tale stima implica un risparmio del 40,5%. Si tratta di un confronto contabile, senza un'esecuzione separata di accuratezza senza cache.

Selezione del database e RAG agentica

La RAG agentica dà a un modello il controllo sulle decisioni di recupero. Può scegliere una fonte, ispezionare la risposta e fare un'altra richiesta. Una semplice pipeline di RAG recupera il contesto attraverso una sequenza predeterminata prima di generare una risposta.

Questo benchmark verifica la selezione della fonte tramite strumenti per database SQL. Non contiene un indice di documenti, passaggi recuperati o un punteggio di ancoraggio della risposta. I risultati descrivono quindi una parte di un sistema di recupero agentico. La ricerca documentale è trattata separatamente nel nostro benchmark di ricerca agentica.

Un modello parte con brevi descrizioni dei database. Può richiedere elenchi di tabelle, ispezionare colonne, eseguire SQL e cambiare database. La sua risposta finale contiene una scelta del database e una query. Il nostro benchmark text-to-SQL riporta l'accuratezza SQL e due punteggi supplementari di revisione.

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

Metodologia del benchmark di RAG agentica

Il set di domande è un sottoinsieme congelato di BIRD-SQL, che associa domande in linguaggio naturale a query SQL di riferimento.⁹

Due segnali definiscono la difficoltà. Il test di similarità conta quanti dei 20 vicini più prossimi di una domanda appartengono ad altri database. Tre LLM valutano se la domanda è confondente tra i database. L'appartenenza al gruppo più difficile richiede almeno cinque vicini di altri database e un'etichetta di giuria confondente.

L'instradamento utilizza il database indicato nel campo esplicito selected_database. Una rotta dedotta dal testo è esclusa dal risultato principale. La correttezza SQL viene valutata separatamente e non determina il punteggio di instradamento.

Il harness è il software che presenta gli strumenti e registra le risposte del modello. Il pannello principale contiene 36 esecuzioni OpenRouter e un'esecuzione Codex CLI. Tra le esecuzioni API, 19 hanno usato la v3, 15 una versione precedente e due hanno combinato record di entrambe le versioni. Nella v3, un livello di recupero analizza i formati alternativi di chiamata degli strumenti supportati. Per llama-4-maverick, la quota di formato non nativo registrata è stata del 97,9%, quindi quel risultato dipende fortemente dall'adattatore. minimax-m2.7 è stato escluso perché non ha effettuato le chiamate agli strumenti del database richieste dal compito.

GPT-6 Astra è stato eseguito all'interno di Codex CLI, il cui identificatore di harness registrato è codex_cli_transcript_v1. Poiché la configurazione è diversa, le differenze di punteggio non possono essere attribuite al solo modello. GPT-6 Astra ha completato tutte le 759 domande. Ha selezionato il database corretto per 155 delle 184 domande difficili e ha registrato un'accuratezza di instradamento del 95,3% sull'intero set. La sua esecuzione non ha riportato costi in dollari.

Benchmark di instradamento per i modelli decisionali

L'esperimento di instradamento separato ha utilizzato 243 domande invariate selezionate da 394 candidati dopo aver riservato 17 domande di sviluppo. Il set di query conteneva 204 domande originariamente facili e 39 originariamente difficili. Tali etichette di difficoltà non sono state rivalidate per questo compito e la selezione non è stata una valutazione blind su dati tenuti fuori.

Quattro descrizioni dei database sono state corrette utilizzando schemi sorgente e testo delle domande prima di raccogliere le previsioni misurate. Le altre sette hanno mantenuto le loro descrizioni compatte. Ogni modello ha ricevuto la stessa domanda, 11 alias e descrizioni, e lo stesso ordine delle opzioni per quella domanda. I SQL di riferimento, le etichette sorgente e le prove supplementari sono stati esclusi. Jev e Laya hanno utilizzato la loro interfaccia Choice nativa. Agli LLM è stato chiesto di restituire un solo alias. I modelli non avevano strumenti di database.

Abbiamo eseguito Jev 1.13.0 tramite la sua API ospitata e il checkpoint Laya English bloccato localmente con Apple M4 MPS, 16 GiB di memoria e quattro thread Torch. Il limite di 404 token del contesto di Laya e il limite di 48 token per le opzioni non hanno prodotto troncamenti dell'input. Sei LLM sono stati eseguiti tramite OpenRouter con provider fissi e impostazioni di ragionamento. Il ragionamento richiesto è stato basso per Gemini 3.8 Flash, minimo per Gemini 3.5 Flash Lite e alto per Opus. È stato disabilitato per DeepSeek, Qwen e Haiku. Ogni modello ha avuto un warmup escluso, una richiesta in volo e nessun nuovo tentativo. L'ordine di invio dei modelli è ruotato tra le domande.

Kev-9B è stato aggiunto il 22 settembre in un'esecuzione separata, preservando gli otto risultati originali. I payload delle sue 243 richieste corrispondevano esattamente agli input originali di Jev, incluso l'ordine delle opzioni. Abbiamo bloccato la revisione del checkpoint 2629c06a e utilizzato un A100 SXM da 80 GB con FP32, attenzione SDPA e LoRA non unito. Il preprocessing delle date e il prefix caching erano disattivati. Dopo aver verificato l'API sulle 17 domande di sviluppo riservate, abbiamo eseguito un warmup escluso e 243 richieste seriali senza nuovi tentativi. Il servizio era riservato al nostro uso. Ogni risposta ha confermato che l'input completo è stato mantenuto. I tempi del server includono tokenizzazione e inferenza sincronizzata. Il grafico utilizza i tempi del client, inclusi overhead SSH e di rete.

L'accuratezza divide le scelte corrette e valide per tutte le 243 domande pianificate, inclusi errori di servizio e di output. La latenza mediana misura la richiesta client completa non in streaming tra le risposte valide, escluso il warmup. I costi dichiarati LLM API coprono le richieste misurate. L'hardware di Laya e i costi di noleggio di Kev non sono stati misurati e la stima del prezzo di listino di Jev è una base contabile diversa. Il confronto descrive questo set curato e queste condizioni di implementazione. I dati pubblici di origine, le revisioni delle descrizioni, il giudizio dei revisori, date di misurazione diverse e l'assenza di ripetizioni limitano la generalizzazione.

Limitazioni

Il sottoinsieme difficile si concentra sul commercio. Quattro database contribuiscono con 171 delle sue 184 domande, ovvero il 92,9%. Cinque degli 11 database non ne contribuiscono nessuna. Questo supporta conclusioni sulla scelta tra database simili all'interno di un dominio, con prove limitate per altre combinazioni di domini.

Dopo errori del provider, sette esecuzioni contengono meno di 759 record valutati. Cinque hanno anche meno di 184 record di domande difficili. I denominatori della tabella mostrano le domande completate. I record mancanti sono esclusi, il che può favorire un modello se le domande omesse erano più difficili.

Gli intervalli di Wilson coprono l'incertezza di campionamento nell'ambito di un modello a livello di domanda. Omettono la variazione tra esecuzioni ripetute, la dipendenza tra domande dello stesso database e l'incertezza introdotta dall'harness. Anche i cambi di provider e il recupero delle chiamate agli strumenti limitano i confronti tra le esecuzioni.

I dati dei benchmark pubblici potrebbero essere comparsi nell'addestramento dei modelli. Controlli che utilizzano 138 parafrasi validate e 65 domande di nuova creazione non hanno rilevato un calo di accuratezza nei modelli testati a costo inferiore. La loro copertura era limitata rispettivamente a sei e tre database. Non risolvono la contaminazione per l'intero pannello e nessun controllo ha utilizzato database pubblicati dopo le date limite di addestramento dei modelli.

Il troncamento dello schema può nascondere tabelle utili. In works_cycles, il limite di 4.000 caratteri lascia visibili 26 delle 66 tabelle nell'elenco schema iniziale. Il modello può richiedere ulteriori dettagli, ma la vista iniziale è incompleta.

Ulteriori letture

• Text-to-SQL: confronto dell'accuratezza degli LLM
• Framework RAG: LangChain vs LangGraph vs LlamaIndex
• I migliori strumenti RAG, framework e librerie
• Ricerca agentica nel 2026: benchmark di 8 API di ricerca per agenti

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  = {{Benchmark di RAG agentica: instradamento tra 11 database SQL}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/agentic-rag}},
  note   = {AIMultiple. Consultato il 25 settembre 2026}
}

Registro delle modifiche

16 aggiornamenti

Tutte16Generale13Metodologia3

202620252024

1. 11 ago

   Aggiornata la sezione 'Cosa rende difficile una domanda in questo benchmark?' con nuovi contenuti.

2. 11 ago

   Aggiornata la metodologia per chiarire come le domande più difficili sono distribuite tra i database.

3. 7 ago

   La sezione sulla metodologia di benchmark RAG Agentic è stata sostituita con una nuova che copre 36 LLM e 11 database.

4. 29 giu

   Aggiunti nuovi modelli al benchmark: Claude Fable 5, Claude Opus 4.8, Gemini 3.5 Flash, Grok 4.3, Claude Opus 4.7.

5. 20 feb

   Aggiornata la sezione della metodologia con nuovi dettagli sull'ambiente del database, l'architettura dell'agente e il processo di valutazione.

6. 23 gen

   Aggiunta una sezione sui modelli a contesto lungo rispetto al RAG agentico.

7. 23 gen

   Rimosse metriche agentiche aggiuntive dalla metodologia.

Collegamenti di riferimento

1.

Models - TypeSafe AI

Mintlify

2.

Apple Silicon Pricing | Scaleway

3.

Euro exchange rates charts

4.

Apple silicon M4 as-a-Service. Cloud Mac | Scaleway

5.

convaiinnovations/laya · Hugging Face

6.

Choice - TypeSafe AI

Mintlify

7.

How to build with TypeSafe - TypeSafe AI

Mintlify

8.

jaredpalmer/kev-9b · Hugging Face

9.

BIRD-bench

Ekrem Sarı

Ricercatore IA

Segui

Ekrem è un Ricercatore IA e Data Scientist presso AIMultiple. Progetta ed esegue benchmark pratici per sistemi di IA 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