Text to SQL Agent Cost: What una funzionalità "Ask Your Data" Richiede Davvero

Il costo di un text to SQL agent per una funzionalità SaaS in produzione si colloca tra qualche settimana di lavoro ingegneristico concentrato e un trimestre di tempo di un piccolo team. La variabilità di questo costo dipende quasi interamente da tre fattori: quanto è disordinato lo schema, quanto deve essere rigido l'isolamento tra tenant e quante domande l'agente deve riuscire a gestire correttamente prima che i clienti la vedano. Il modello è la parte economica. Il semantic layer e le barriere di sicurezza sono dove va il denaro.

Cosa stanno davvero acquistando i founder

La funzionalità sulla roadmap è una casella di testo nella dashboard che dice "ask your data". Un cliente digita "quali account hanno fatto churn l'ultimo trimestre dopo un pagamento fallito", l'agente scrive SQL, la esegue e restituisce una tabella o un grafico. Ogni demo venditore di questa funzionalità funziona magnificamente, perché ogni demo venditore gira su cinque tabelle con nomi come customers e orders.

Il vostro database ha status, status_v2 e una colonna deleted_at che metà delle query si dimentica di considerare. Ha un tenant_id sulla maggior parte delle tabelle e un organisation_id su quelle più vecchie. Ha tre modi di calcolare il revenue, e la finance si fida solo di uno. Un LLM che legge quello schema a freddo produrrà SQL plausibile ma sbagliato in modi che un cliente non può individuare dal risultato. Quel divario tra la demo e il vostro schema è il progetto.

Costo del text to SQL agent: dove va davvero il denaro

Il semantic layer è la voce più grande

Un semantic layer è una descrizione scritta di cosa significano i vostri dati: quali tabelle l'agente può toccare, come si uniscono, come sono definiti "cliente attivo" e "revenue mensile", e quali colonne sono rumore legacy. Gli strumenti recenti in questo ambito esistono proprio per impedire che gli agenti indovinino l'SQL dai nomi grezzi delle colonne, e l'idea è solida. Il modello smette di inventare join e comincia a riempire un template che voi controllate.

La parte costosa è che scriverlo è lavoro di business, non solo ingegneria. Qualcuno che conosce il prodotto deve sedersi e decidere, per iscritto, cosa significano le metriche. Se il vostro team non ha mai concordato una definizione di churn, è questa la settimana in cui lo scoprirete. Pianificate il budget con onestà. Su un prodotto maturo con un centinaio di tabelle, il semantic layer da solo può rappresentare un terzo del costo totale, ed è anche la parte che continua a ripagarsi perché finiscono per usarla anche i vostri analisti umani.

Isolamento tra tenant e permessi

Un text to SQL agent è un programma che esegue query arbitrarie scritte da un modello linguistico contro i dati dei vostri clienti. Trattatelo come tale. La connessione al database che l'agente usa dovrebbe essere un ruolo dedicato di sola lettura, mai l'utente dell'applicazione e mai qualcosa con permessi di scrittura. In PostgreSQL, applicate il confine tra tenant con policy di row-level security basate sul tenant, così che una clausola WHERE errata generata dal modello restituisca nulla invece di restituire le righe di qualcun altro. Impostate uno statement_timeout su quel ruolo, così che un join mal scritto non resti bloccato sul vostro database primario per dieci minuti.

Questo è lo stesso problema di design della RAG consapevole dei permessi: il controllo degli accessi deve risiedere sotto il modello, in un livello che il modello non possa raggirare. Se la risposta di un vendor alla domanda "come prevenite le fughe tra tenant" è "il prompt gli dice di filtrare per tenant", allontanatevi.

L'eval set

Prima che la funzionalità venga lanciata, serve un archivio di domande reali con risposte note e corrette, raccolte da ticket di supporto e chiamate di vendita, eseguite su una copia dei dati di produzione. Cinquanta domande sono un inizio scarso. Duecento sono una base confortevole. Ognuna costa il tempo di qualcuno per scrivere l'SQL corretto e verificare il risultato, e questo è il deliverable che vi dice se la cosa funziona davvero. Abbiamo già scritto del perché le eval vanno inserite nel contratto con il vendor, e questa funzionalità è il caso più chiaro: senza la banca di domande, "funziona" significa "ha funzionato sulle tre query provate nella demo".

La chiamata al modello in sé

Il costo di inferenza è quasi un errore di arrotondamento rispetto a quanto detto sopra, e l'architettura attorno ad essa dovrebbe essere semplice. Il pattern che tende a vincere è una singola chiamata con il semantic layer, le definizioni delle tabelle rilevanti e un pugno di esempi risolti nel contesto, che restituisce SQL più una spiegazione in una riga. Le catene multi-step (un planner che scelga le tabelle, un writer che scriva l'SQL in bozza, un fixer che ripari gli errori) sembrano più rigorose ma in pratica aggiungono latenza, costo e nuovi punti di fallimento.

Abbiamo visto la stessa cosa in un sistema molto diverso. Il nostro stesso motore di outreach fa scraping del sito di un prospect con un crawler self-hosted e un modello locale, poi scrive un'email personalizzata per ogni azienda. Siamo partiti con una catena che estraeva i fatti in un passaggio e scriveva la bozza in un altro. Una singola chiamata che faceva entrambe le cose, con un buon contesto, ha battuto la catena sia in costo che in qualità del risultato. Il text to SQL si comporta allo stesso modo: metti la conoscenza nel contesto, non nell'orchestrazione. Un retry su un errore SQL va bene. Una pipeline a cinque stadi è di solito un segnale che manca il semantic layer.

Costruire o acquistare

Ci sono tre opzioni realistiche.

• La funzionalità AI integrata nel vostro strumento di BI esistente. La più economica e veloce. Buona per dashboard interne o per un prodotto single-tenant. Debole quando ogni cliente può vedere solo le proprie righe, e le definizioni delle metriche sono quelle che lo strumento deduce autonomamente.
• Un vendor di analytics embedded con linguaggio naturale sopra. Una via di mezzo ragionevole se il vostro schema è pulito e il vostro modello di tenancy coincide con il loro. Verificate dove vengono elaborati i dati. Se i vostri clienti sono nel Golfo o nel settore sanitario, la residenza dei dati può escludere questa opzione da sola.
• Costruirlo sul vostro stack. Il più costoso all'inizio, e la scelta giusta quando l'isolamento tra tenant è non negoziabile, quando le vostre metriche hanno definizioni interne, oppure quando la funzionalità fa parte di ciò che vendete piuttosto che essere un semplice valore aggiunto.

Il test onesto è se la casella "ask your data" sia un differenziatore di prodotto o una comodità. Se i clienti pagherebbero di più per averla o farebbero churn senza di essa, costruitela. Se è una casella da spuntare per il mazzo di slide delle vendite, acquistatela e andate avanti.

Come appare una prima versione sensata

Definite lo scope del primo rilascio in modo stretto. Una versione che risponde correttamente a un insieme ristretto di domande batte una che tenta di rispondere a tutto ed è giusta solo la maggior parte delle volte.

1. Scegliete un solo dominio (billing, usage, o supporto) e dieci o quindici tabelle.
2. Scrivete il semantic layer solo per quel dominio, con le definizioni delle metriche approvate da chi possiede quei numeri.
3. Create il ruolo di sola lettura, le policy di row-level security e i timeout prima che venga scritto il primo prompt.
4. Costruite l'eval set a partire da domande reali dei clienti ed eseguitelo a ogni modifica.
5. Mostrate l'SQL generato e il numero di righe accanto a ogni risposta, così che gli utenti più esperti possano individuare gli errori.
6. Lanciate la funzionalità su un gruppo ristretto di account amichevoli e leggete ogni query che eseguono per due settimane.

Espandete al dominio successivo solo una volta che il tasso di successo delle eval sul primo dominio è diventato poco interessante perché ormai scontato.

Domande da fare a chi vi fa un preventivo

Un preventivo per questa funzionalità che arriva come un singolo numero senza domande collegate è un preventivo per la demo, non per il prodotto. Chiedete:

• Come si connetterà l'agente al database, e con quali permessi?
• Dove risiede il filtro per tenant, e cosa succede se il modello lo omette?
• Chi scrive le definizioni delle metriche, e quanto tempo si stima che ci vorrà?
• Come appare l'eval set al momento della consegna, e quale tasso di successo è il criterio di accettazione?
• Quale modello viene usato, e come si presenta il costo per query a mille domande al giorno?
• Cosa succede quando lo schema cambia il trimestre prossimo?

Le risposte vi dicono se il team ha già portato questo tipo di lavoro su uno schema reale o solo su un tutorial. Se volete un secondo parere su un preventivo, o una stima mirata per il vostro database, parliamone.