Creare un Vantaggio Informativo con l’Accesso Conversazionale ai Dati

Create an Informational Advantage with Conversational Data Access.

Una guida per implementare Text2SQL per potenziare le organizzazioni data-driven

Figura 1: Rappresentazione del flusso Text2SQL

Man mano che il nostro mondo diventa sempre più globale e dinamico, le aziende sono sempre più dipendenti dai dati per prendere decisioni informate, obiettive e tempestive. Tuttavia, al momento attuale, sfruttare pienamente il potenziale dei dati organizzativi è spesso un privilegio di pochi scienziati e analisti dei dati. La maggior parte dei dipendenti non padroneggia gli strumenti convenzionali della scienza dei dati (SQL, Python, R ecc.). Per accedere ai dati desiderati, passano attraverso uno strato aggiuntivo in cui gli analisti o i team BI “traducono” la prosa delle domande di business nel linguaggio dei dati. Il potenziale di attrito e inefficienza in questo percorso è elevato: ad esempio, i dati potrebbero essere consegnati con ritardi o addirittura quando la domanda è già obsoleta. Le informazioni potrebbero andare perse lungo la strada quando i requisiti non vengono tradotti con precisione in query analitiche. Inoltre, la generazione di insights di alta qualità richiede un approccio iterativo che viene scoraggiato con ogni passaggio aggiuntivo nel ciclo. D’altra parte, queste interazioni ad-hoc creano interruzioni per il costoso talento dei dati e li distraggono dal lavoro sui dati più strategico, come descritto in queste “confessioni” di un data scientist:

Quando ero alla Square e il team era più piccolo, avevamo una temuta rotazione “analytics on-call”. Era rigorosamente a rotazione settimanale e se era il tuo turno, sapevi che avresti fatto molto poco lavoro “reale” quella settimana e passato la maggior parte del tuo tempo a rispondere a domande ad-hoc dai vari team di prodotto e operazioni dell’azienda (abbiamo chiamato questo SQL monkeying). C’era una concorrenza spietata per i ruoli di manager nel team di analytics e penso che questo fosse interamente il risultato dei manager esentati da questa rotazione; nessun premio di status poteva competere con la possibilità di non fare lavoro on-call.[1]

In effetti, non sarebbe bello parlare direttamente con i tuoi dati invece di dover passare attraverso molteplici round di interazione con il personale dei dati? Questa visione è abbracciata dalle interfacce conversazionali che consentono agli esseri umani di interagire con i dati utilizzando il linguaggio, il nostro canale di comunicazione più intuitivo e universale. Dopo aver analizzato una domanda, un algoritmo la codifica in una forma logica strutturata nel linguaggio di query scelto, come SQL. Pertanto, gli utenti non tecnici possono chattare con i loro dati e ottenere rapidamente informazioni specifiche, rilevanti e tempestive, senza fare il giro attraverso un team BI. In questo articolo, esamineremo i diversi aspetti di implementazione di Text2SQL e ci concentreremo su approcci moderni con l’uso di Large Language Models (LLM), che raggiungono le migliori prestazioni al momento attuale (cf. [2]; per una panoramica su approcci alternativi oltre LLM, si rimanda il lettore a [3]). L’articolo è strutturato secondo il seguente “modello mentale” degli elementi principali da considerare quando si pianifica e si costruisce una funzione di intelligenza artificiale:

Figura 2: Modello mentale di una funzione di intelligenza artificiale

Iniziamo con la fine in mente e ripercorriamo il valore: perché dovresti integrare una funzione Text2SQL nel tuo prodotto dati o analytics. I tre principali vantaggi sono:

  • Gli utenti business possono accedere ai dati organizzativi in modo diretto e tempestivo.
  • Questo solleva gli scienziati e gli analisti dei dati dal carico delle richieste ad-hoc degli utenti business e consente loro di concentrarsi su sfide avanzate dei dati.
  • Questo consente al business di sfruttare i suoi dati in modo più fluido e strategico, trasformandoli finalmente in una base solida per la presa di decisioni.

Ora, quali sono gli scenari di prodotto in cui potresti considerare Text2SQL? I tre principali contesti sono:

  • Stai offrendo un prodotto dati/BI scalabile e vuoi consentire a più utenti di accedere ai loro dati in modo non tecnico, aumentando così sia l’uso che la base utente. Ad esempio, ServiceNow ha integrato le query dei dati in un’offerta conversazionale più ampia e Atlan ha di recente annunciato l’esplorazione dei dati in linguaggio naturale.
  • Stai cercando di costruire qualcosa nello spazio dei dati/IA per democratizzare l’accesso ai dati nelle aziende, in tal caso potresti potenzialmente considerare un MVP con Text2SQL al centro. Fornitori come AI2SQL e Text2sql.ai stanno già facendo il loro ingresso in questo spazio.
  • Stai lavorando su un sistema BI personalizzato e vuoi massimizzarne e democratizzarne l’uso nell’azienda individuale.

Come vedremo nelle sezioni seguenti, Text2SQL richiede una configurazione iniziale non banale. Per stimare il ROI, considerare la natura delle decisioni che devono essere supportate e la disponibilità dei dati. Text2SQL può essere una vittoria assoluta in ambienti dinamici dove i dati cambiano rapidamente e sono utilizzati attivamente e frequentemente nel processo decisionale, come nel caso degli investimenti, del marketing, della produzione e dell’industria dell’energia. In questi ambienti, gli strumenti tradizionali per la gestione delle conoscenze sono troppo statici e modi più fluidi per accedere ai dati e alle informazioni aiutano le aziende a generare un vantaggio competitivo. In termini di dati, Text2SQL fornisce il maggior valore con un database che è:

  • Grande e in crescita, in modo che Text2SQL possa sfruttare il suo valore nel tempo man mano che sempre più dati vengono sfruttati.
  • Di alta qualità, in modo che l’algoritmo Text2SQL non debba gestire un eccessivo rumore (inconsistenze, valori vuoti, ecc.) nei dati. In generale, i dati generati automaticamente dalle applicazioni hanno una maggiore qualità e coerenza rispetto ai dati creati e mantenuti dagli esseri umani.
  • Semanticamente maturi, invece di grezzi, in modo che gli esseri umani possano interrogare i dati in base ai concetti centrali, alle relazioni e alle metriche che esistono nel loro modello mentale. Si noti che la maturità semantica può essere raggiunta da un passaggio di trasformazione aggiuntivo che conforma i dati grezzi in una struttura concettuale (cf. sezione “Arricchimento della richiesta con informazioni sul database”).

Nelle sezioni seguenti, approfondiremo i dati, l’algoritmo, l’esperienza utente e i requisiti non funzionali rilevanti di una funzione Text2SQL. L’articolo è scritto per i responsabili di prodotto, i progettisti UX e quei data scientist e ingegneri che sono all’inizio del loro percorso Text2SQL. Per queste persone, fornisce non solo una guida per iniziare, ma anche un terreno comune di conoscenza per le discussioni intorno alle interfacce tra prodotto, tecnologia e business, inclusi i relativi compromessi. Se sei già più avanzato nella tua implementazione, i riferimenti alla fine forniscono una gamma di approfondimenti da esplorare.

1. Dati

Ogni impresa di apprendimento automatico inizia con i dati, quindi inizieremo chiarificando la struttura dei dati di input e di output che vengono utilizzati durante la formazione e la previsione. In tutto l’articolo, utilizzeremo il flusso Text2SQL dalla figura 1 come nostra rappresentazione in esecuzione e evidenzieremo in giallo i componenti e le relazioni attualmente considerati.

Figura 3: In questa rappresentazione Text2SQL, gli elementi e le relazioni relativi ai dati sono contrassegnati in giallo.

1. 1 Formato e struttura dei dati

Tipicamente, una coppia di input-output Text2SQL grezzi consiste in una domanda in linguaggio naturale e la corrispondente query SQL, ad esempio:

Domanda: “Elencare il nome e il numero di follower per ogni utente.”

Query SQL:

seleziona nome, follower da user_profiles

Nello spazio dei dati di formazione, la mappatura tra domande e query SQL è molti-a-molti:

  • Una query SQL può essere mappata a molte diverse domande in linguaggio naturale; ad esempio, la semantica della query sopra può essere espressa da: “mostrami i nomi e i numeri dei follower per utente”, “quanti follower ci sono per ogni utente?” ecc.
  • La sintassi SQL è altamente versatile e quasi ogni domanda può essere rappresentata in SQL in modi multipli. L’esempio più semplice sono le diverse disposizioni delle clausole WHERE. Su una posizione più avanzata, chiunque abbia fatto l’ottimizzazione della query SQL saprà che molte strade portano allo stesso risultato e le query semanticamente equivalenti potrebbero avere una sintassi completamente diversa.

La raccolta manuale dei dati di formazione per Text2SQL è particolarmente noiosa. Non richiede solo la padronanza di SQL da parte dell’annotatore, ma anche più tempo per esempio rispetto a compiti linguistici più generali come l’analisi del sentiment e la classificazione del testo. Per garantire una quantità sufficiente di esempi di formazione, può essere utilizzata l’aumento dei dati, ad esempio, LLM può essere utilizzato per generare parafrasi per la stessa domanda. [3] fornisce una panoramica più completa delle tecniche di aumento dei dati Text2SQL.

1.2 Arricchimento della richiesta con informazioni sul database

Text2SQL è un algoritmo all’interfaccia tra dati strutturati e non strutturati. Per prestazioni ottimali, entrambi i tipi di dati devono essere presenti durante la formazione e la previsione. In particolare, l’algoritmo deve conoscere il database interrogato e essere in grado di formulare la query in modo tale che possa essere eseguita contro il database. Questa conoscenza può includere:

  • Colonne e tabelle del database
  • Relazioni tra le tabelle (chiavi esterne)
  • Contenuto del database

Ci sono due opzioni per incorporare la conoscenza del database: da un lato, i dati di formazione possono essere limitati a esempi scritti per il database specifico, in tal caso lo schema viene appreso direttamente dalla query SQL e dal suo mapping alla domanda. Questa impostazione a singolo database consente di ottimizzare l’algoritmo per un singolo database e/o azienda. Tuttavia, uccide qualsiasi ambizione di scalabilità, poiché il modello deve essere perfezionato per ogni singolo cliente o database. In alternativa, in un ambiente multi-database, lo schema del database può essere fornito come parte dell’input, consentendo all’algoritmo di “generalizzarsi” a nuovi schemi di database non visti in precedenza. Anche se assolutamente necessario se si vuole utilizzare Text2SQL su molti database diversi, si tenga presente che richiede uno sforzo di ingegneria considerevole. Per qualsiasi database aziendale ragionevole, includere tutte le informazioni nella richiesta sarà estremamente inefficiente e probabilmente impossibile a causa delle limitazioni della lunghezza della richiesta. Pertanto, la funzione responsabile della formulazione della richiesta dovrebbe essere abbastanza intelligente da selezionare un sottoinsieme di informazioni del database che è più “utile” per una determinata domanda, e farlo anche per database non visti in precedenza.

Infine, la struttura del database svolge un ruolo cruciale. In quegli scenari in cui si ha un controllo sufficiente sul database, si può rendere la vita del modello più facile facendolo apprendere da una struttura intuitiva. Come regola generale, più il database riflette il modo in cui gli utenti aziendali parlano dell’azienda, migliore e più veloce può essere il modello ad apprenderne. Pertanto, considerare l’applicazione di trasformazioni aggiuntive ai dati, come l’assemblaggio di dati normalizzati o altrimenti dispersi in tabelle larghe o in un vault dati, la denominazione di tabelle e colonne in modo esplicito e non ambiguo, ecc. Tutto il know-how aziendale che è possibile codificare in anticipo ridurrà l’onere dell’apprendimento probabilistico sul modello e aiuterà a ottenere risultati migliori.

2. Algoritmo

Figura 4: In questa rappresentazione di Text2SQL, gli elementi e le relazioni relativi all'algoritmo sono contrassegnati in giallo.

Text2SQL è un tipo di analisi semantica – la mappatura di testi in rappresentazioni logiche. Pertanto, l’algoritmo deve “imparare” non solo il linguaggio naturale, ma anche la rappresentazione target, nel nostro caso, SQL. In particolare, deve acquisire i seguenti elementi di conoscenza:

  • Sintassi e semantica SQL
  • Struttura del database
  • Comprensione del linguaggio naturale (NLU)
  • Mappatura tra il linguaggio naturale e le query SQL (sintattica, lessicale e semantica)

2.1 Risolvere la variabilità linguistica nell’input

All’input, la principale sfida di Text2SQL risiede nella flessibilità del linguaggio: come descritto nella sezione Formato e struttura dei dati, la stessa domanda può essere parafrasata in molti modi diversi. Inoltre, nel contesto conversazionale della vita reale, dobbiamo affrontare una serie di problemi come errori di ortografia e grammatica, input incompleti e ambigui, input multilingue, ecc.

Figura 5: L'algoritmo Text2SQL deve affrontare molti varianti diversi di una domanda

I LLM come i modelli GPT, T5 e CodeX si avvicinano sempre di più alla risoluzione di questa sfida. Apprendendo da enormi quantità di testo diverso, imparano a gestire un gran numero di modelli e irregolarità linguistiche. Alla fine, diventano in grado di generalizzare su domande che sono semanticamente simili nonostante abbiano forme diverse. I LLM possono essere applicati senza personalizzazione o dopo il perfezionamento. Il primo, sebbene comodo, porta a una minor accuratezza. Il secondo richiede maggiori competenze e lavoro, ma può aumentare significativamente l’accuratezza.

In termini di accuratezza, come previsto, i modelli che funzionano meglio sono gli ultimi modelli della famiglia GPT, compresi i modelli CodeX. Ad aprile 2023, GPT-4 ha portato a un aumento drammatico dell’accuratezza di oltre il 5% rispetto allo stato dell’arte precedente e ha raggiunto un’accuratezza del 85,3% (sulla metrica “esecuzione con valori”).[4] Nel campo open-source, i tentativi iniziali di risolvere il puzzle Text2SQL si sono concentrati sui modelli di auto-codifica come BERT, che eccellono nelle attività di NLU.[5, 6, 7] Tuttavia, in mezzo all’entusiasmo intorno all’AI generativa, gli approcci recenti si concentrano sui modelli autoregressivi come il modello T5. T5 è pre-addestrato utilizzando l’apprendimento multi-tasking e si adatta facilmente a nuovi compiti linguistici, incluse diverse varianti di analisi semantica. Tuttavia, i modelli autoregressivi hanno un difetto intrinseco quando si tratta di compiti di analisi semantica: hanno uno spazio di output non vincolato e nessuna guardia semantica che limiterebbe il loro output, il che significa che possono diventare sorprendentemente creativi nel loro comportamento. Sebbene questo sia incredibile per la generazione di contenuti liberi, è un fastidio per compiti come Text2SQL in cui ci aspettiamo un output mirato e ben strutturato.

2.2 Convalida e miglioramento della query

Per limitare l’output di LLM, è possibile introdurre meccanismi aggiuntivi per la convalida e il miglioramento della query. Ciò può essere implementato come passaggio di convalida extra, come proposto nel sistema PICARD.[8] PICARD utilizza un parser SQL che può verificare se una query SQL parziale può condurre a una query SQL valida dopo il completamento. Ad ogni passo di generazione di LLM, i token che invaliderebbero la query vengono respinti e vengono mantenuti i token validi con la probabilità più alta. Essendo deterministico, questo approccio garantisce una validità SQL al 100% purché il parser osservi le regole SQL corrette. Inoltre, decoppia la convalida della query dalla generazione, consentendo così di mantenere entrambi i componenti indipendentemente l’uno dall’altro e di aggiornare e modificare LLM.

Un altro approccio consiste nell’incorporare direttamente la conoscenza strutturale e SQL in LLM. Ad esempio, Graphix [9] utilizza strati consapevoli del grafico per iniettare conoscenze strutturate SQL nel modello T5. A causa della natura probabilistica di questo approccio, esso influenza il sistema verso le query corrette, ma non fornisce una garanzia di successo.

Infine, LLM può essere utilizzato come agente multistep che può verificare e migliorare autonomamente la query.[10] Utilizzando più passaggi in un prompt di catena di pensiero, l’agente può essere incaricato di riflettere sulla correttezza delle proprie query e migliorare eventuali difetti. Se la query convalidata non può ancora essere eseguita, il traceback di eccezione SQL può essere passato all’agente come feedback aggiuntivo per il miglioramento.

Oltre a questi metodi automatizzati, che avvengono nel backend, è anche possibile coinvolgere l’utente durante il processo di controllo della query. Descriveremo questo in maggior dettaglio nella sezione sull’esperienza utente.

2.3 Valutazione

Per valutare il nostro algoritmo Text2SQL, è necessario generare un dataset di test (validazione), eseguire il nostro algoritmo su di esso e applicare le metriche di valutazione pertinenti sul risultato. Una suddivisione ingenua del dataset in dati di formazione, sviluppo e validazione sarebbe basata su coppie domanda-query e porterebbe a risultati subottimali. Le query di convalida potrebbero essere rivelate al modello durante la formazione e portare a una visione eccessivamente ottimistica delle sue capacità di generalizzazione. Una suddivisione basata sulla query, in cui il dataset è suddiviso in modo tale che nessuna query appaia sia durante la formazione che durante la convalida, fornisce risultati più veritieri.

In termini di metriche di valutazione, ciò che ci interessa in Text2SQL non è generare query completamente identiche allo standard di riferimento. Questo metodo di “corrispondenza esatta della stringa” è troppo rigoroso e genererebbe molti falsi negativi, poiché diverse query SQL possono condurre allo stesso dataset restituito. Invece, vogliamo ottenere un’alta precisione semantica e valutare se le query previste e quelle “standard di riferimento” restituiscano sempre gli stessi dataset. Esistono tre metriche di valutazione che approssimano questo obiettivo:

  • Precisione della corrispondenza esatta dell’insieme: le query SQL generate e di destinazione vengono suddivise nei loro costituenti, e i set risultanti vengono confrontati per identità.[11] Lo svantaggio qui è che tiene conto solo delle variazioni di ordine nella query SQL, ma non delle differenze sintattiche più evidenti tra query semanticamente equivalenti.
  • Precisione di esecuzione: i dataset risultanti dalle query SQL generate e di destinazione vengono confrontati per identità. Con buona fortuna, le query con semantica diversa possono ancora superare questo test su un’istanza di database specifica. Ad esempio, supponendo un database in cui tutti gli utenti sono di età superiore a 30 anni, le due query seguenti restituirebbero risultati identici nonostante abbiano semantica diversa: seleziona * da utente seleziona * da utente dove età > 30
  • Precisione del test-suite: la precisione del test-suite è una versione più avanzata e meno permissiva della precisione di esecuzione. Per ogni query, viene generato un insieme (“test suite”) di database altamente differenziati per quanto riguarda le variabili, le condizioni e i valori nella query. Quindi, la precisione di esecuzione viene testata su ciascuno di questi database. Sebbene richieda uno sforzo aggiuntivo per ingegnerizzare la generazione del test-suite, questa metrica riduce significativamente anche il rischio di falsi positivi nella valutazione. [12]

3. Esperienza utente

Figura 6: In questa rappresentazione Text2SQL, gli elementi e le relazioni relativi all'esperienza utente sono contrassegnati in giallo.

Lo stato dell’arte attuale di Text2SQL non consente un’integrazione completamente trasparente nei sistemi di produzione, ma è necessario gestire attivamente le aspettative e il comportamento dell’utente, che dovrebbe sempre essere consapevole di interagire con un sistema AI.

3.1 Gestione degli errori

Text2SQL può fallire in due modalità, che devono essere gestite in modi differenti:

  • Errori SQL : la query generata non è valida — o per un problema di sintassi SQL, o perché non può essere eseguita sul database specifico per via di problemi semantici o lessicali. In questo caso, non può essere restituito alcun risultato all’utente.
  • Errori semantici : la query generata è valida, ma non rispecchia la semantica della domanda, portando quindi a un dataset restituito errato.

La seconda modalità è particolarmente complicata poiché il rischio di “fallimenti silenziosi” — errori che passano inosservati all’utente — è alto. Il prototipo di utente non avrà né il tempo né le competenze tecniche per verificare la correttezza della query e/o dei dati risultanti. Quando i dati vengono utilizzati per prendere decisioni nel mondo reale, questo tipo di fallimento può avere conseguenze devastanti. Per evitare questo, è fondamentale educare gli utenti e stabilire parametri di sicurezza a livello aziendale che limitino l’impatto potenziale, come controlli aggiuntivi sui dati per le decisioni con un impatto maggiore. D’altra parte, possiamo anche utilizzare l’interfaccia utente per gestire l’interazione tra umani e macchine e aiutare l’utente a individuare e migliorare le richieste problematiche.

3.2 Interazione tra umani e macchine

Gli utenti possono interagire con il sistema di intelligenza artificiale con diversi gradi di intensità. Maggiore interazione per richiesta può portare a risultati migliori, ma rallenta anche la fluidità dell’esperienza utente. Oltre all’eventuale impatto negativo di query e risultati errati, considera anche quanto motivati saranno i tuoi utenti a fornire feedback per ottenere risultati più accurati e aiutare a migliorare il prodotto nel lungo termine.

Il modo più semplice e meno coinvolgente è lavorare con punteggi di confidenza. Sebbene il calcolo naïve della confidenza come media delle probabilità dei token generati sia eccessivamente semplicistico, possono essere utilizzati metodi più avanzati come feedback verbale. [13] La confidenza può essere visualizzata nell’interfaccia e evidenziata con un avviso esplicito nel caso in cui sia pericolosamente bassa. In questo modo, la responsabilità di un adeguato follow-up nel “mondo reale” — sia una rifiuto, un’accettazione o un controllo aggiuntivo dei dati — cade sulle spalle dell’utente. Anche se è una scelta sicura per te come venditore, trasferire questo lavoro all’utente può anche ridurre il valore del tuo prodotto.

Una seconda possibilità è coinvolgere l’utente in un dialogo di chiarimento nel caso di query a bassa confidenza, ambigue o altrimenti sospette. Ad esempio, il tuo sistema potrebbe suggerire correzioni ortografiche o grammaticali all’input e chiedere di disambiguare parole o strutture grammaticali specifiche. Potrebbe anche consentire all’utente di richiedere in modo proattivo correzioni nella query:[14]

UTENTE: Mostrami i task di John in questa sprint.

ASSISTENTE: Vuoi vedere i task creati da John, o quelli su cui sta lavorando?

UTENTE: task creati da John

ASSISTENTE: Ok, ecco gli ID dei task:

UTENTE: Grazie, vorrei anche vedere maggiori informazioni sui task. Per favore, ordina anche per urgenza.

ASSISTENTE: Certamente, ecco i task insieme a descrizioni brevi, assegnatari e scadenze, ordinati per scadenza.

Infine, per facilitare la comprensione delle query da parte dell’utente, il tuo sistema può anche fornire una riformulazione testuale esplicita della query e chiedere all’utente di confermarla o correggerla.[15]

4. Requisiti non funzionali

In questa sezione, discutiamo i requisiti non funzionali specifici per Text2SQL così come i compromessi tra di essi. Ci concentreremo sui sei requisiti che sembrano più importanti per il compito: accuratezza, scalabilità, velocità, spiegabilità, privacy e adattabilità nel tempo.

4.1 Accuratezza

Per Text2SQL, i requisiti di accuratezza sono elevati. In primo luogo, Text2SQL è tipicamente applicato in un contesto di conversazione in cui le previsioni vengono fatte una per volta. Pertanto, la “legge dei grandi numeri” che tipicamente aiuta a bilanciare l’errore nelle previsioni in batch, non aiuta. In secondo luogo, la validità sintattica e lessicale è una condizione “difficile”: il modello deve generare una query SQL ben formata, potenzialmente con sintassi e semantica complesse, altrimenti la richiesta non può essere eseguita sul database. E se questo va bene e la query può essere eseguita, potrebbe ancora contenere errori semantici e portare a un dataset restituito errato (cf. sezione 3.1 Gestione degli errori).

4.2 Scalabilità

Le principali considerazioni sulla scalabilità riguardano se si desidera applicare Text2SQL su un singolo database o su più database – e in quest’ultimo caso, se l’insieme dei database è noto e chiuso. In caso affermativo, avrai un tempo più facile poiché puoi includere le informazioni su questi database durante la formazione. Tuttavia, in uno scenario di prodotto scalabile – che sia un’applicazione Text2SQL standalone o un’integrazione in un prodotto dati esistente – il tuo algoritmo deve far fronte a qualsiasi nuovo schema di database al volo. Questo scenario non ti dà nemmeno l’opportunità di trasformare la struttura del database per renderla più intuitiva per l’apprendimento (link!). Tutto ciò porta a un pesante compromesso con l’accuratezza, il che potrebbe anche spiegare perché i fornitori Text2SQL attuali che offrono una query ad hoc di nuovi database non hanno ancora raggiunto una significativa penetrazione di mercato.

4.3 Velocità

Dato che le richieste Text2SQL saranno tipicamente elaborate online in conversazione, l’aspetto della velocità è importante per la soddisfazione dell’utente. Sul lato positivo, gli utenti sono spesso consapevoli del fatto che le richieste di dati possono richiedere un certo tempo e mostrare la pazienza richiesta. Tuttavia, questa buona volontà può essere compromessa dall’impostazione della chat, dove gli utenti si aspettano subconsciamente una velocità di conversazione simile a quella umana. I metodi di ottimizzazione brute-force come la riduzione delle dimensioni del modello potrebbero avere un impatto inaccettabile sull’accuratezza, quindi considera l’ottimizzazione dell’infrazione per soddisfare questa aspettativa.

4.4 Esplicabilità e trasparenza

Nel caso ideale, l’utente può seguire come la query è stata generata dal testo, vedere la mappatura tra parole o espressioni specifiche nella domanda e la query SQL, ecc. Ciò consente di verificare la query e apportare eventuali modifiche durante l’interazione con il sistema. Inoltre, il sistema potrebbe fornire anche una riformulazione testuale esplicita della query e chiedere all’utente di confermarla o correggerla.

4.5 Privacy

La funzione Text2SQL può essere isolata dall’esecuzione della query, quindi le informazioni sul database restituite possono essere mantenute invisibili. Tuttavia, la domanda critica è quanto di informazioni sul database sia incluso nel prompt. Le tre opzioni (in ordine decrescente di livello di privacy) sono:

  • Nessuna informazione
  • Schema del database
  • Contenuto del database

La privacy si contrappone all’accuratezza – meno vincolato sei nell’includere informazioni utili nel prompt, migliori saranno i risultati.

4.6 Adattabilità nel tempo

Per utilizzare Text2SQL in modo durevole, è necessario adattarsi alla deriva dei dati, ovvero alla distribuzione in evoluzione dei dati a cui il modello viene applicato. Ad esempio, supponiamo che i dati utilizzati per il raffinamento iniziale riflettano il comportamento di interrogazione semplice degli utenti quando iniziano a utilizzare il sistema BI. Con il passare del tempo, le esigenze di informazione degli utenti diventano più sofisticate e richiedono query più complesse, che travolgono il tuo modello ingenuo. Inoltre, gli obiettivi o la strategia di un’azienda potrebbero anche derivare e indirizzare le esigenze di informazione verso altre aree del database. Infine, una sfida specifica di Text2SQL è la deriva del database. Mentre il database dell’azienda viene esteso, nuove colonne e tabelle non viste fanno la loro strada nel prompt. Mentre gli algoritmi Text2SQL progettati per l’applicazione multi-database possono gestire bene questo problema, può avere un impatto significativo sull’accuratezza di un modello a singolo database. Tutti questi problemi sono risolti al meglio con un set di dati di raffinamento che riflette il comportamento reale degli utenti nel mondo reale. Pertanto, è cruciale registrare le domande e i risultati degli utenti, nonché eventuali feedback associati che possono essere raccolti dall’uso. Inoltre, gli algoritmi di clustering semantico, ad esempio utilizzando embedding o modellizzazione dei topic, possono essere applicati per rilevare i cambiamenti sottostanti a lungo termine nel comportamento degli utenti e utilizzare questi come ulteriore fonte di informazioni per perfezionare il set di dati di raffinamento.

Conclusioni

Riassumiamo i punti chiave dell’articolo:

  • Text2SQL consente di implementare un accesso intuitivo e democratico ai dati in un’azienda, massimizzando così il valore dei dati disponibili.
  • I dati Text2SQL consistono in domande in ingresso e query SQL in uscita. La mappatura tra domande e query SQL è molti-a-molti.
  • È importante fornire informazioni sul database come parte del prompt. Inoltre, la struttura del database può essere ottimizzata per renderla più facile per l’algoritmo di apprendere e capirla.
  • All’ingresso, la principale sfida è la variabilità linguistica delle domande in linguaggio naturale, che può essere affrontata utilizzando LLM pre-addestrati su una vasta gamma di stili di testo diversi
  • L’output di Text2SQL dovrebbe essere una query SQL valida. Questo vincolo può essere incorporato “iniettando” conoscenze SQL nell’algoritmo; in alternativa, utilizzando un approccio iterativo, la query può essere controllata e migliorata in più fasi.
  • A causa del potenziale impatto elevato dei “fallimenti silenziosi” che restituiscono dati errati per la presa di decisioni, la gestione dei fallimenti è una preoccupazione primaria nell’interfaccia utente.
  • In modo “aumentato”, gli utenti possono essere attivamente coinvolti nella convalida iterativa e il miglioramento delle query SQL. Sebbene ciò renda l’applicazione meno fluida, riduce anche i tassi di fallimento, consente agli utenti di esplorare i dati in modo più flessibile e crea segnali preziosi per ulteriori apprendimenti.
  • I principali requisiti non funzionali da considerare sono l’accuratezza, la scalabilità, la velocità, l’esplicabilità, la privacy e l’adattabilità nel tempo. I principali compromessi consistono tra l’accuratezza da un lato e la scalabilità, la velocità e la privacy dall’altro.

Riferimenti

[1] Ken Van Haren. 2023. Sostituire un analista SQL con 26 prompt ricorsivi GPT

[2] Nitarshan Rajkumar et al. 2022. Valutazione delle capacità di Text-to-SQL dei grandi modelli di lingua

[3] Naihao Deng et al. 2023. Progressi recenti in Text-to-SQL: una panoramica di ciò che abbiamo e di ciò che ci aspettiamo

[4] Mohammadreza Pourreza et al. 2023. DIN-SQL: Apprendimento decomposto in contesto di Text-to-SQL con autocorrezione

[5] Victor Zhong et al. 2021. Adattamento fondato per il parsing semantico eseguibile a zero-shot

[6] Xi Victoria Lin et al. 2020. Collegamento dei dati testuali e tabulari per il parsing semantico Text-to-SQL cross-domain

[7] Tong Guo et al. 2019. Generazione BERT-based Text-to-SQL migliorata dal contenuto

[8] Torsten Scholak et al. 2021. PICARD: Parsing Incrementale per la decodifica auto-regressiva vincolata dai modelli di lingua

[9] Jinyang Li et al. 2023. Graphix-T5: Mixing Pre-Trained Transformers with Graph-Aware Layers for Text-to-SQL Parsing

[10] LangChain. 2023. LLMs e SQL

[11] Tao Yu et al. 2018. Spider: un dataset umano di grandi dimensioni etichettato per il parsing semantico complesso e cross-domain e il task Text-to-SQL

[12] Ruiqi Zhong et al. 2020. Valutazione semantica per Text-to-SQL con suite di test distillati

[13] Katherine Tian et al. 2023. Chiedi solo per la calibrazione: strategie per elicitarne i punteggi di confidenza calibrati dai modelli di lingua raffinati con feedback umano

[14] Braden Hancock et al. 2019. Imparare dal dialogo dopo il deployment: alimentati, chatbot!

[15] Ahmed Elgohary et al. 2020. Parla con il tuo parser: Text-to-SQL interattivo con feedback in lingua naturale

Tutte le immagini sono dell’autore.