Routing di query più intelligente per assistenti SQL AI: come ridurre i costi senza sacrificare la qualità

Immagina il tuo assistente SQL come un razzo, che sfreccia attraverso query complesse. Poi un giorno ti rendi conto di utilizzare carburante per razzi per recuperare una lista della spesa.

È emozionante, fino a quando non arriva la bolletta del carburante. Improvvisamente diventa chiaro che le commissioni semplici non richiedono un razzo. La stessa cosa accade quando ogni richiesta SQL, dalla ricerca di base all’analisi multischema, viene instradata allo stesso potente modello AI.

Il processo di ottenere un assistente SQL AI è solitamente lo stesso. All’inizio, la produttività aumenta: le query vengono eseguite più velocemente, il codice boilerplate scompare e gli sviluppatori spendono meno tempo scrivendo query SQL di routine. Man mano che più team lo utilizzano, il numero di query aumenta. Quando arriva la bolletta dell’infrastruttura, l’economia cambia.

Il problema è con l’edificio. Costa molto eseguire modelli AI Frontier in grado di pensare a piani di esecuzione, schemi e logica di query complessa. Quel prezzo ha senso per compiti difficili, poiché costa circa $0,03 per query. Quando utilizzato per semplici istruzioni SELECT e operazioni CRUD, diventa uno spreco su larga scala.

Ma la risposta non è abbassare il modello. È inviare le query nel posto giusto. Il routing di query intelligente ordina ogni richiesta in base alla sua difficoltà e la invia al modello giusto. Questo metodo può ridurre i costi di inferenza del 40-70% nei carichi di lavoro SQL senza abbassare la qualità dell’output.

Questo articolo spiega come funziona quell’architettura: definendo i livelli di complessità SQL, costruendo pipeline di classificazione e routing, e misurando i reali compromessi tra costo e qualità una volta che il sistema è in funzione. Questi modelli riflettono le lezioni apprese durante lo sviluppo di capacità AI consapevoli dello schema in dbForge AI Assistant.

Perché un modello non si adatta a tutti i compiti SQL

Non tutte le query SQL sono uguali per quanto riguarda la complessità. Una query che recupera un utente per chiave primaria e una che ricostruisce i canali di sessione su più schemi con funzioni di finestra sono entrambe SQL, ma il ragionamento necessario per generarle è molto diverso.

Se un sistema le tratta allo stesso modo, il risultato è prevedibile: spreco di calcolo. Nella maggior parte dei carichi di lavoro aziendali, la maggior parte delle query sono di routine. Ricerche semplici, letture di una sola tabella, inserimenti di base, correzioni di sintassi. Niente di complicato. Inviare tutte quelle a un modello di frontiera è come utilizzare un ascensore merci per trasportare un quaderno.

Un modo per pensare al problema è dividere le query in livelli di complessità:

Il divario di costo tra i livelli è grande. Una query di livello 1 potrebbe costare intorno a $0,001 su un modello leggero. La stessa query inviata a un modello di frontiera costa più vicino a $0,03. A 10.000 query al giorno, si tratta di $10 contro $300 di spesa giornaliera. Una differenza di 30 volte, solo a causa delle decisioni di routing.

La consapevolezza dello schema è anche importante qui. Le query di livello 3 non hanno solo bisogno di più calcolo. Hanno bisogno di contesto: relazioni tra tabelle, chiavi esterne, indici, sintassi specifica del database. Quel contesto deve essere iniettato durante l’inferenza.

Eseguire una query di livello 1 semplice attraverso lo stesso percorso pesante spreca token, aggiunge latenza e non migliora il risultato.

Un’architettura pratica per la selezione del modello

Un sistema di routing solitamente ha quattro fasi: classificazione, routing, esecuzione e convalida. Ogni fase fa un lavoro diverso e ogni fase può fallire in modi diversi. Aiuta a pensare a loro separatamente prima di assemblare la pipeline completa.

La classificazione è il passaggio più importante. Il classificatore riceve la query SQL grezza o il prompt di linguaggio naturale che genererà una query e la assegna a un livello di complessità. Ci sono tre modi comuni per costruire questo classificatore.

Classificazione basata su regole si basa su modelli di regex e parsing dell’albero di sintassi astratta (AST) per rilevare segnali strutturali: cose come il numero di tabelle, la profondità di annidamento, le funzioni di finestra, le sottquery o gli operatori di aggregazione. Questo approccio è veloce e prevedibile, con quasi nessun sovraccarico. Funziona bene per casi ovvi: le istruzioni SELECT semplici e le operazioni DML di base possono solitamente essere identificate senza coinvolgere un modello. 

Modelli di classificazione leggeri utilizzano un piccolo modello di linguaggio addestrato per stimare la complessità SQL. Questo aggiunge un passaggio extra, ma è una delle decisioni con il più alto ROI nell’intera pipeline. Una chiamata al classificatore potrebbe costare intorno a $0,0001, che giustifica facilmente l’evitare una chiamata al modello di frontiera da $0,03. 

In molti setup, questi modelli leggeri possono anche essere eseguiti localmente, rimuovendo efficacemente il costo per le query degli utenti semplici. Possono anche classificare i prompt di linguaggio naturale prima che venga generata la SQL, il che è utile nei flussi di lavoro degli assistenti in cui la query non esiste ancora. 

Classificazione ibrida combina entrambi gli approcci. La logica basata su regole gestisce i casi chiari a costo zero, mentre il classificatore gestisce il caso ambiguo: le query che sembrano moderate ma potrebbero effettivamente richiedere un ragionamento consapevole dello schema per generare correttamente. 

Routing si verifica dopo la classificazione. Ma il livello da solo non è l’unico fattore. Alcune altre cose influenzano dove una query dovrebbe andare. Queste includono: 

1. Requisiti di contesto dello schema. Alcune query necessitano che il modello comprenda le relazioni tra tabelle, gli indici o altri dettagli strutturali. Queste query portano più contesto e solitamente necessitano di essere instradate a un modello con capacità più elevate. 
2. Tolleranza alla latenza. Le funzionalità orientate all’utente come l’autocompletamento o le suggerimenti in linea hanno budget di latenza rigorosi. I compiti in background solitamente non li hanno. In quei casi, un modello più lento ma più capace potrebbe essere accettabile. 
3. Soglie di confidenza. A volte il classificatore non è sicuro del livello. In quei casi, il routing verso l’alto è solitamente l’opzione più sicura. Un declassamento errato può produrre una query cattiva e scatenare ritentativi, che spesso costa più dell’uso del modello più forte fin dall’inizio. 

Il livello di convalida viene eseguito dopo che il codice è stato eseguito. Il lavoro di questo è quello di catturare gli errori di routing prima che raggiungano l’utente. Dopo l’esecuzione, vengono eseguiti controlli per assicurarsi che la sintassi sia corretta, che i risultati siano ragionevoli (la query ha restituito le forme di riga corrette?) e che lo schema sia coerente. Quando un risultato non supera la convalida, il sistema si sposta su un livello superiore e riavvia la query.

In Devart, la cosa più importante per ottenere l’accuratezza del routing di dbForge AI Assistant era costruire il contesto consapevole dello schema nella decisione di classificazione. Senza il contesto dello schema, le query che utilizzavano nomi di tabelle poco chiari o si basavano su relazioni implicite venivano sempre classificate in modo errato e inviate a modelli più economici che non potevano gestirle. La soluzione era fornire al classificatore non solo la struttura della query, ma anche alcuni metadati dello schema.

Misurare ciò che conta: compromessi tra costo e qualità nella pratica

Il caso d’uso per il routing vale solo se la qualità si mantiene. La riduzione dei costi che causa un output degradato, ritentativi aumentati o sfiducia degli sviluppatori non è un risparmio, è un trasferimento di costo dalla bolletta dell’infrastruttura al tempo di ingegneria. Tre metriche determinano se un sistema di routing funziona effettivamente.

Costo per query per livello stabilisce la base. Tenere traccia della spesa effettiva a ogni livello separatamente, non come media ponderata. La media oscura se il routing funziona, un sistema che instrada il 50% delle query al livello sbagliato mostrerà comunque un costo medio più basso, mentre produce silenziosamente risultati peggiori. 

Il punteggio di qualità controlla la correttezza, la completezza e l’aderenza alle migliori pratiche SQL. La velocità di escalation è il segnale più diretto. Indica quante volte un modello di livello 1 o 2 produce un output che non supera la convalida e necessita di essere inviato a un’altra posizione. Un sistema ben tarato dovrebbe mantenere l’escalation al di sotto del 5%. Il classificatore necessita di essere riaddestrato al di sopra di quel livello. Potrebbe essere in errore nel leggere i segnali strutturali o potrebbe non avere il contesto dello schema di cui ha bisogno per distinguere tra moderate e complesse. 

Impatto sulla latenza esamina quanto tempo ci vuole per una risposta per spostarsi da un livello all’altro, inclusa qualsiasi tempo extra necessario per la classificazione. Gli utenti dovrebbero notare solo un ritardo di 50-100 millisecondi nelle interazioni che passano attraverso il livello di routing. Se la classificazione stessa diventa un problema, l’approccio ibrido (regole per casi chiari, classificatore solo per casi poco chiari) risolve il problema senza perdere accuratezza. 

Nella vita reale, un sistema di routing ben tarato può ridurre i costi di inferenza del 40-60%, mantenere l’escalation al di sotto del 5% e mantenere la qualità dell’output alta per query complesse. Per risparmiare il 70% o più, di solito è necessario eseguire compiti di livello 1 con modelli più piccoli. Ciò potrebbe funzionare, ma rende anche le cose più complesse, il che non tutte le squadre vogliono gestire.

La “tassa di escalation” è un’altra cosa che deve essere esaminata. Se il routing è troppo duro sui modelli più economici, il sistema potrebbe dover fare più lavoro nel complesso: chiamata al classificatore, chiamata iniziale al modello, convalida fallita, reindirizzamento e seconda chiamata al modello. In alcuni casi, ciò costa più dell’invio della query al modello di frontiera fin dall’inizio.

Guardare solo il costo per chiamata perde questo effetto. La velocità di escalation deve essere tracciata insieme ad esso.

Ripercussioni strategiche per i team di ingegneria

Il routing intelligente non è solo un optional per i deploy di AI SQL maturi; è un must-have per quelli a lungo termine. Le squadre che lo saltano scambiano un problema di budget che non può essere risolto con un problema di architettura che può essere. I modelli sono lì; l’unica cosa rimasta è decidere quali seguire per primi.

Inizia con il classificatore, non con i modelli. Il livello di routing decide se tutto il resto funziona. Un classificatore ibrido ben tarato ti darà la maggior parte dei risparmi sui costi senza rendere le cose troppo complesse.

Utilizza il contesto dello schema dell’alimentazione per aiutarti a prendere decisioni di classificazione. Per i carichi di lavoro SQL che coinvolgono relazioni tra più tabelle o ragionamento specifico dello schema, la struttura della query da sola non è sufficiente. I metadati dello schema parziali al momento della classificazione aumentano notevolmente l’accuratezza del livello.

Utilizza la velocità di escalation come segnale di qualità principale. Trova la classificazione errata più velocemente di qualsiasi altra metrica e mostra esattamente dove il classificatore necessita di migliorare.

Prima del classificatore, pianifica il livello di convalida. Sapere cosa sembra un fallimento e cosa causa un’escalation rende la logica di routing più pulita e il sistema più in grado di gestire i casi limite.

Il valore del livello di routing aumenta, non diminuisce, man mano che i modelli open-source migliorano e il costo dell’inferenza locale diminuisce. I modelli di livello 1 più economici rendono la differenza di costo tra i livelli più grande, il che rende la classificazione corretta più preziosa. L’architettura di routing costruita oggi sarà utile per molto tempo, non solo come una soluzione rapida.