Creazione di un margine informativo con accesso conversazionale ai dati

Ripubblicato da Platone

Seguaci: 0

AI conversazionale per l'analisi dei dati

Figura 1: Rappresentazione del flusso Text2SQL

Poiché il nostro mondo sta diventando sempre più globale e dinamico, le aziende dipendono sempre più dai dati per prendere decisioni informate, obiettive e tempestive. Tuttavia, fin d'ora, liberare tutto il potenziale dei dati organizzativi è spesso un privilegio di una manciata di data scientist e analisti. La maggior parte dei dipendenti non padroneggia il toolkit di data science convenzionale (SQL, Python, R ecc.). Per accedere ai dati desiderati, passano attraverso un livello aggiuntivo in cui analisti o team di BI "traducono" la prosa delle domande aziendali nel linguaggio dei dati. Il potenziale di attrito e inefficienza in questo percorso è elevato: ad esempio, i dati potrebbero essere consegnati con ritardi o anche quando la domanda è già diventata obsoleta. Le informazioni potrebbero perdersi lungo il percorso quando i requisiti non vengono accuratamente tradotti in query analitiche. Inoltre, la generazione di insight di alta qualità richiede un approccio iterativo che viene scoraggiato ad ogni ulteriore passaggio del ciclo. Dall'altro lato, queste interazioni ad-hoc creano interruzioni per i costosi talenti dei dati e li distraggono dal lavoro sui dati più strategico, come descritto in queste "confessioni" di un data scientist:

Quando ero in Square e il team era più piccolo, avevamo una temuta rotazione di "analytics su chiamata". Era rigorosamente ruotato su base settimanale e, se fosse stato il tuo turno, sapevi che quella settimana avresti svolto pochissimo lavoro "reale" e trascorrerai la maggior parte del tuo tempo a rispondere a domande ad hoc dai vari team operativi e di prodotto presso il company (SQL monkeying, l'abbiamo chiamato). C'era una concorrenza spietata per i ruoli di manager nel team di analisi e penso che questo sia stato interamente il risultato dell'esenzione dei manager da questa rotazione: nessun premio di status poteva competere con la carota di non svolgere il lavoro di guardia.[1]

In effetti, non sarebbe bello parlare direttamente con i tuoi dati invece di dover affrontare più cicli di interazione con il tuo personale di dati? Questa visione è abbracciata da 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 prescelto, come SQL. Pertanto, gli utenti non tecnici possono chattare con i propri dati e mettere rapidamente le mani su informazioni specifiche, pertinenti e tempestive, senza fare la deviazione attraverso un team di BI. In questo articolo, prenderemo in considerazione i diversi aspetti di implementazione di Text2SQL e ci concentreremo sugli approcci moderni con l'uso di Large Language Models (LLM), che raggiungono le migliori prestazioni fin d'ora (cfr. [2]; per un sondaggio su approcci alternativi oltre agli LLM, si rimanda ai lettori [3]). L'articolo è strutturato secondo il seguente "modello mentale" dei principali elementi da considerare durante la pianificazione e la costruzione di una funzionalità AI:

AI conversazionale per l'analisi dei dati — Figura 2: modello mentale di una funzione AI

Iniziamo con la fine in mente e ricapitoliamo il valore: perché dovresti creare una funzionalità Text2SQL nel tuo prodotto di dati o analisi. I tre vantaggi principali sono:

Utenti aziendali può accedere ai dati organizzativi in modo diretto e tempestivo.
Questo allevia data scientist e analisti dall'onere delle richieste ad hoc da parte degli utenti aziendali e consente loro di concentrarsi sulle sfide avanzate relative ai dati.
Questo permette al affari per sfruttare i propri dati in modo più fluido e strategico, trasformandoli finalmente in una solida base per il processo decisionale.

Ora, quali sono gli scenari di prodotto in cui potresti prendere in considerazione Text2SQL? Le tre impostazioni principali sono:

Stai offrendo un prodotto dati/BI scalabile e vogliono consentire a più utenti di accedere ai propri dati in modo non tecnico, aumentando così sia l'utilizzo che la base di utenti. Ad esempio, ServiceNow ha query di dati integrate in un'offerta conversazionale più ampiae Atlan ha recentemente ha annunciato l'esplorazione dei dati in linguaggio naturale.
Stai cercando di costruire qualcosa nello spazio dati/IA per democratizzare l'accesso ai dati nelle aziende, nel qual caso potresti potenzialmente considerare un MVP con Text2SQL al centro. Fornitori come AI2SQL ed Text2sql.ai stanno già facendo il loro ingresso in questo spazio.
Stai lavorando su un sistema BI personalizzato e vogliono massimizzare e democratizzare il suo utilizzo nella singola azienda.

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 i dati disponibili. Text2SQL può essere una vittoria assoluta in ambienti dinamici in cui i dati cambiano rapidamente e vengono utilizzati attivamente e frequentemente nel processo decisionale, come gli investimenti, il marketing, la produzione e l'industria energetica. In questi ambienti, gli strumenti tradizionali per la gestione della conoscenza 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 massimo valore con un database che è:

Grande e in crescita, in modo che Text2SQL possa dispiegare il suo valore nel tempo man mano che viene sfruttata una quantità sempre maggiore di dati.
Di alta qualità, in modo che l'algoritmo Text2SQL non debba gestire un rumore eccessivo (incoerenze, valori vuoti e così via) nei dati. In generale, i dati generati automaticamente dalle applicazioni hanno una qualità e una coerenza superiori rispetto ai dati creati e gestiti da persone.
Semanticamente maturo al contrario di raw, in modo che gli esseri umani possano interrogare i dati sulla base di concetti, relazioni e metriche centrali che esistono nel loro modello mentale. Si noti che la maturità semantica può essere raggiunta mediante un'ulteriore fase di trasformazione che conforma i dati grezzi in una struttura concettuale (cfr. sezione "Arricchire il prompt con le informazioni del database").

Di seguito, approfondiremo i dati, l'algoritmo, l'esperienza utente, nonché i requisiti non funzionali pertinenti di una funzionalità Text2SQL. L'articolo è scritto per product manager, progettisti UX e quegli scienziati e ingegneri di dati che sono all'inizio del loro viaggio Text2SQL. Per queste persone, fornisce non solo una guida per iniziare, ma anche un terreno comune di conoscenza per discussioni sulle interfacce tra prodotto, tecnologia e business, compresi i relativi compromessi. Se sei già più avanzato nella tua implementazione, i riferimenti alla fine forniscono una serie di approfondimenti da esplorare.

Se questo contenuto educativo approfondito è utile per te, puoi farlo iscriviti alla nostra mailing list di ricerca sull'IA per essere avvisato quando rilasciamo nuovo materiale.

1. Dati

Qualsiasi attività di apprendimento automatico inizia con i dati, quindi inizieremo chiarendo la struttura dei dati di input e di destinazione utilizzati durante l'addestramento e la previsione. In tutto l'articolo utilizzeremo il flusso Text2SQL della Figura 1 come rappresentazione in esecuzione ed evidenzieremo in giallo i componenti e le relazioni attualmente considerati.

1.1 Formato e struttura dei dati

In genere, una coppia input-output Text2SQL non elaborata è costituita da una domanda in linguaggio naturale e dalla query SQL corrispondente, ad esempio:

Question"Elenca il nome e il numero di follower per ciascun utente.

Query SQL:

seleziona nome, follower da user_profiles

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

Una query SQL può essere mappata a molte domande diverse in linguaggio naturale; ad esempio, la semantica della query di cui sopra può essere espressa da: "mostrami i nomi e il numero di follower per utente","quanti follower ci sono per ogni utente?" eccetera.
La sintassi SQL è estremamente versatile e quasi ogni domanda può essere rappresentata in SQL in più modi. L'esempio più semplice sono i diversi ordinamenti delle clausole WHERE. Su una posizione più avanzata, chiunque abbia eseguito l'ottimizzazione delle query SQL saprà che molte strade portano allo stesso risultato e che le query semanticamente equivalenti potrebbero avere una sintassi completamente diversa.

La raccolta manuale dei dati di addestramento per Text2SQL è particolarmente noiosa. Non solo richiede la padronanza di SQL da parte dell'annotatore, ma anche più tempo per esempio rispetto ad attività linguistiche più generali come l'analisi del sentimento e la classificazione del testo. Per garantire una quantità sufficiente di esempi di formazione, è possibile utilizzare l'aumento dei dati, ad esempio è possibile utilizzare LLM per generare parafrasi per la stessa domanda. [3] fornisce una rassegna più completa delle tecniche di aumento dei dati di Text2SQL.

1.2 Arricchire il prompt con le informazioni del database

Text2SQL è un algoritmo all'interfaccia tra dati strutturati e non strutturati. Per prestazioni ottimali, entrambi i tipi di dati devono essere presenti durante l'addestramento e la previsione. Nello specifico, l'algoritmo deve conoscere il database interrogato ed essere in grado di formulare la query in modo tale da poter essere eseguita sul database. Questa conoscenza può comprendere:

Colonne e tabelle del database
Relazioni tra tabelle (chiavi esterne)
Contenuto della banca dati

Esistono due opzioni per incorporare la conoscenza del database: da un lato, i dati di addestramento possono essere limitati a esempi scritti per il database specifico, nel qual caso lo schema viene appreso direttamente dalla query SQL e la sua mappatura alla domanda. Questa impostazione del singolo database consente di ottimizzare l'algoritmo per un singolo database e/o azienda. Tuttavia, elimina qualsiasi ambizione di scalabilità, poiché il modello deve essere messo a punto per ogni singolo cliente o database. In alternativa, in un'impostazione multi-database, lo schema del database può essere fornito come parte dell'input, consentendo all'algoritmo di "generalizzare" a nuovi schemi di database invisibili. Sebbene sia assolutamente necessario adottare questo approccio se si desidera utilizzare Text2SQL su molti database diversi, tenere presente che richiede un notevole sforzo ingegneristico tempestivo. Per qualsiasi ragionevole database aziendale, includere tutte le informazioni nel prompt sarà estremamente inefficiente e molto probabilmente impossibile a causa dei limiti di lunghezza del prompt. Pertanto, la funzione responsabile della formulazione tempestiva dovrebbe essere abbastanza intelligente da selezionare un sottoinsieme di informazioni del database che è più "utile" per una data domanda e farlo per database potenzialmente invisibili.

Infine, la struttura del database gioca un ruolo cruciale. In quegli scenari in cui hai un controllo sufficiente sul database, puoi semplificare la vita del tuo modello lasciando che impari da una struttura intuitiva. Come regola generale, più il tuo database riflette il modo in cui gli utenti aziendali parlano dell'azienda, migliore e più veloce il tuo modello può imparare da esso. Pertanto, prendere in considerazione l'applicazione di ulteriori trasformazioni ai dati, come l'assemblaggio di dati normalizzati o altrimenti dispersi in tabelle ampie o un archivio di dati, la denominazione di tabelle e colonne in modo esplicito e non ambiguo e così via. Tutta la conoscenza aziendale che è possibile codificare in anticipo ridurrà l'onere dell'apprendimento probabilistico sul tuo modello e aiutarti a ottenere risultati migliori.

2. Algoritmo

Text2SQL è un tipo di analisi semantica — la mappatura dei testi alle rappresentazioni logiche. Pertanto, l'algoritmo non deve solo "imparare" il linguaggio naturale, ma anche la rappresentazione target, nel nostro caso SQL. In particolare, deve acquisire e le seguenti conoscenze:

Sintassi e semantica SQL
Struttura del database
Comprensione del linguaggio naturale (NLU)
Mappatura tra linguaggio naturale e query SQL (sintattiche, lessicali e semantiche)

2.1 Risoluzione della variabilità linguistica nell'input

All'input, la sfida principale 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 della conversazione nella vita reale, dobbiamo affrontare una serie di problemi come errori di ortografia e grammatica, input incompleti e ambigui, input multilingue ecc.

LLM come i modelli GPT, T5 e CodeX si stanno avvicinando sempre di più alla soluzione di questa sfida. Imparando da enormi quantità di testi diversi, 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 superficiali diverse. Gli LLM possono essere applicati immediatamente (zero-shot) o dopo la messa a punto. Il primo, sebbene conveniente, porta a una minore precisione. Quest'ultimo richiede più abilità e lavoro, ma può aumentare significativamente la precisione.

In termini di accuratezza, come previsto, i modelli più performanti sono gli ultimi modelli della famiglia GPT inclusi i modelli CodeX. Nell'aprile 2023, GPT-4 ha portato a un notevole aumento della precisione di oltre il 5% rispetto al precedente stato dell'arte e ha raggiunto una precisione dell'85.3% (оsulla metrica "esecuzione con valori").[4] Nel campo dell'open source, i tentativi iniziali di risolvere il puzzle Text2SQL si sono concentrati su modelli di codifica automatica come BERT, che eccellono nelle attività NLU.[5, 6, 7] su modelli autoregressivi come il modello T5. T5 è pre-addestrato utilizzando l'apprendimento multi-task e quindi si adatta facilmente a nuovi compiti linguistici, incl. diverse varianti di analisi semantica. Tuttavia, i modelli autoregressivi hanno un difetto intrinseco quando si tratta di attività di analisi semantica: hanno uno spazio di output non vincolato e nessun guardrail semantico che limiterebbe il loro output, il che significa che possono diventare incredibilmente creativi nel loro comportamento. Sebbene si tratti di cose straordinarie per la generazione di contenuti in formato libero, è una seccatura per attività come Text2SQL in cui ci aspettiamo un output di destinazione vincolato e ben strutturato.

2.2 Convalida e miglioramento delle query

Per vincolare l'output LLM, possiamo introdurre ulteriori meccanismi per convalidare e migliorare la query. Questo può essere implementato come ulteriore fase di convalida, come proposto nel sistema PICARD.[8] PICARD utilizza un parser SQL che può verificare se una query SQL parziale può portare a una query SQL valida dopo il completamento. A ogni passaggio di generazione da parte di LLM, i token che invaliderebbero la query vengono rifiutati e vengono conservati i token validi con la probabilità più elevata. Essendo deterministico, questo approccio garantisce una validità SQL al 100%, purché il parser osservi le regole SQL corrette. Inoltre, disaccoppia la convalida della query dalla generazione, consentendo così di mantenere entrambi i componenti indipendentemente l'uno dall'altro e di aggiornare e modificare l'LLM.

Un altro approccio consiste nell'incorporare la conoscenza strutturale e SQL direttamente nel LLM. Ad esempio, Graphix [9] utilizza strati che riconoscono il grafico per iniettare conoscenza SQL strutturata nel modello T5. A causa della natura probabilistica di questo approccio, orienta il sistema verso query corrette, ma non fornisce una garanzia di successo.

Infine, il LLM può essere utilizzato come agente multi-step in grado di controllare e migliorare autonomamente la query.[10] Utilizzando più passaggi in un prompt della 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 dell'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 delle query. Descriveremo questo in modo più dettagliato nella sezione sull'esperienza dell'utente.

2.3 Valutazione

Per valutare il nostro algoritmo Text2SQL, dobbiamo generare un set di dati di test (convalida), eseguire il nostro algoritmo su di esso e applicare metriche di valutazione pertinenti al risultato. Un set di dati ingenuo suddiviso in dati di formazione, sviluppo e convalida si baserebbe su coppie domanda-query e porterebbe a risultati non ottimali. Le query di convalida potrebbero essere rivelate al modello durante l'addestramento e portare a una visione eccessivamente ottimistica delle sue capacità di generalizzazione. UN suddivisione basata su query, in cui il set di dati è suddiviso in modo tale che nessuna query venga visualizzata sia durante l'addestramento 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 al gold standard. Questo "corrispondenza stringa esatta" Il metodo è troppo rigoroso e genererà molti falsi negativi, poiché query SQL diverse possono portare allo stesso set di dati restituito. Invece, vogliamo raggiungere il massimo accuratezza semantica e valutare se le query previste e quelle "gold standard" restituirebbero sempre gli stessi set di dati. Esistono tre metriche di valutazione che si avvicinano a questo obiettivo:

Precisione della corrispondenza esatta: le query SQL generate e di destinazione vengono suddivise nei loro componenti e gli insiemi risultanti vengono confrontati per l'identità.[11] Il difetto qui è che tiene conto solo delle variazioni di ordine nella query SQL, ma non delle differenze sintattiche più pronunciate tra query semanticamente equivalenti.
Precisione di esecuzione: i set di dati risultanti dalle query SQL generate e di destinazione vengono confrontati per l'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 abbiano più di 30 anni, le seguenti due query restituirebbero risultati identici pur avendo una semantica diversa:
selezionare * dall'utente
selezionare * dall'utente con età > 30
Precisione della suite di test: l'accuratezza della suite di test è una versione più avanzata e meno permissiva dell'accuratezza dell'esecuzione. Per ogni query viene generato un set (“test suite”) di database altamente differenziati rispetto alle variabili, condizioni e valori della query. Quindi, l'accuratezza dell'esecuzione viene testata su ciascuno di questi database. Sebbene richieda uno sforzo aggiuntivo per progettare la generazione della suite di test, questa metrica riduce anche significativamente il rischio di falsi positivi nella valutazione.,

3. Esperienza dell'utente

L'attuale stato dell'arte 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 essere sempre consapevole di interagire con un sistema di intelligenza artificiale.

3.1 Gestione dei guasti

Text2SQL può fallire in due modalità, che devono essere rilevate in modi diversi:

Errori SQL: la query generata non è valida: l'SQL non è valido o non può essere eseguito sul database specifico a causa di difetti lessicali o semantici. In questo caso, nessun risultato può essere restituito all'utente.
Errori semantici: la query generata è valida ma non riflette la semantica della domanda, portando quindi a un set di dati restituito errato.

La seconda modalità è particolarmente complicata poiché il rischio di "guasti silenziosi" - errori che non vengono rilevati dall'utente - è elevato. L'utente prototipo non avrà né il tempo né la competenza tecnica per verificare la correttezza della query e/o dei dati risultanti. Quando i dati vengono utilizzati per il processo decisionale nel mondo reale, questo tipo di fallimento può avere conseguenze devastanti. Per evitare ciò, è fondamentale educare gli utenti e stabilire guardrail a livello aziendale che limitano il potenziale impatto, come ulteriori controlli dei dati per le decisioni con un impatto maggiore. D'altra parte, possiamo anche utilizzare l'interfaccia utente per gestire l'interazione uomo-macchina e aiutare l'utente a rilevare e migliorare le richieste problematiche.

3.2 Interazione uomo-macchina

Gli utenti possono essere coinvolti con il tuo sistema di intelligenza artificiale con diversi gradi di intensità. Una maggiore interazione per richiesta può portare a risultati migliori, ma rallenta anche la fluidità dell'esperienza dell'utente. Oltre al potenziale impatto negativo di query e risultati errati, considera anche quanto saranno motivati i tuoi utenti a fornire feedback avanti e indietro per ottenere risultati più accurati e contribuire anche a migliorare il prodotto a lungo termine.

Il modo più semplice e meno coinvolgente è lavorare con i punteggi di fiducia. Mentre l'ingenuo calcolo della confidenza come media delle probabilità dei token generati è eccessivamente semplicistico, è possibile utilizzare metodi più avanzati come il feedback verbalizzato. [13] La confidenza può essere visualizzata nell'interfaccia ed 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" — che si tratti di un rifiuto, di un'accettazione o di un ulteriore controllo dei dati — ricade sulle spalle del tuo utente. Sebbene questa sia una scommessa sicura per te come fornitore, trasferire questo lavoro all'utente può anche ridurre il valore del tuo prodotto.

Una seconda possibilità è quella di coinvolgere l'utente in un dialogo di chiarimento in caso di domande poco confidenziali, ambigue o comunque 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 chiedere in modo proattivo correzioni nella query:[14]

UTENTE: Mostrami le attività di John in questo sprint.

ASSISTENTE: Vuoi vedere le attività create da John o quelle su cui sta lavorando?

UTENTE: attività create da John

ASSISTENTE: Ok, ecco gli ID attività:

UTENTE: Grazie, vorrei anche vedere maggiori informazioni sulle attività. Si prega di ordinare anche per urgenza.

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

Infine, per facilitare la comprensione delle query da parte dell'utente, il vostro sistema può anche fornire un'esplicita riformulazione testuale 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 e i compromessi tra di essi. Ci concentreremo sui sei requisiti che sembrano più importanti per l'attività: accuratezza, scalabilità, velocità, spiegabilità, privacy e adattabilità nel tempo.

4.1 Precisione

Per Text2SQL, i requisiti di accuratezza sono elevati. Innanzitutto, Text2SQL viene in genere applicato in un'impostazione di conversazione in cui le previsioni vengono effettuate una per una. Pertanto, la "Legge dei grandi numeri" che in genere 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, può ancora contenere errori semantici e portare a un set di dati restituito errato (cfr. sezione 3.1 Gestione degli errori).

4.2 Scalabilità

Le principali considerazioni sulla scalabilità sono se si desidera applicare Text2SQL su uno o più database e, in quest'ultimo caso, se l'insieme di 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 un prodotto scalabile, che si tratti di un'applicazione Text2SQL autonoma o di un'integrazione in un prodotto di dati esistente, il tuo algoritmo deve far fronte a qualsiasi nuovo schema di database al volo. Questo scenario inoltre non ti dà l'opportunità di trasformare la struttura del database per renderlo più intuitivo per l'apprendimento (link!). Tutto ciò porta a un pesante compromesso con l'accuratezza, il che potrebbe anche spiegare perché gli attuali fornitori di Text2SQL che offrono query ad hoc di nuovi database non hanno ancora raggiunto una significativa penetrazione del mercato.

Velocità 4.3

Poiché le richieste Text2SQL vengono in genere elaborate online in una 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 necessaria pazienza. Tuttavia, questa buona volontà può essere minata dall'impostazione della chat, in cui gli utenti si aspettano inconsciamente una velocità di conversazione simile a quella umana. I metodi di ottimizzazione della forza bruta come la riduzione delle dimensioni del modello potrebbero avere un impatto inaccettabile sull'accuratezza, quindi considera l'ottimizzazione dell'inferenza per soddisfare questa aspettativa.

4.4 Spiegabilità e trasparenza

Nel caso ideale, l'utente può seguire come è stata generata la query 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 anche fornire una riformulazione testuale esplicita della query e chiedere all'utente di confermarla o correggerla.

Privacy di 4.5

La funzione Text2SQL può essere isolata dall'esecuzione della query, quindi le informazioni del database restituite possono essere mantenute invisibili. Tuttavia, la domanda critica è quante informazioni sul database sono incluse nel prompt. Le tre opzioni (diminuendo il livello di privacy) sono:

Nessuna informazione
Schema del database
Contenuto della banca dati

La privacy va a compromessi con l'accuratezza: meno sei vincolato a 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 la distribuzione mutevole dei dati a cui viene applicato il modello. Ad esempio, supponiamo che i dati utilizzati per la messa a punto iniziale riflettano il semplice comportamento di query 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 sopraffanno il tuo modello ingenuo. Inoltre, gli obiettivi o la strategia di un cambiamento aziendale potrebbero anche deviare e indirizzare le esigenze informative verso altre aree del database. Infine, una sfida specifica di Text2SQL è la deriva del database. Man mano che il database aziendale viene esteso, nuove colonne e tabelle invisibili si fanno strada nel prompt. Anche se gli algoritmi Text2SQL progettati per l'applicazione multi-database possono gestire bene questo problema, possono avere un impatto significativo sull'accuratezza di un modello a database singolo. Tutti questi problemi vengono risolti al meglio con un set di dati di ottimizzazione che rifletta il comportamento attuale e reale degli utenti. Pertanto, è fondamentale registrare le domande e i risultati degli utenti, nonché qualsiasi feedback associato che può essere raccolto dall'utilizzo. Inoltre, è possibile applicare algoritmi di clustering semantico, ad esempio utilizzando incorporamenti o modellazione di argomenti, per rilevare i cambiamenti sottostanti a lungo termine nel comportamento degli utenti e utilizzarli come fonte aggiuntiva di informazioni per perfezionare il set di dati di messa a punto

Conclusione

Riassumiamo i punti chiave dell'articolo:

Text2SQL consente di implementare un accesso ai dati intuitivo e democratico in un'azienda, massimizzando così il valore dei dati disponibili.
I dati Text2SQL sono costituiti da domande all'input e query SQL all'output. 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 facilitare l'apprendimento e la comprensione da parte dell'algoritmo.
Per quanto riguarda l'input, la sfida principale è la variabilità linguistica delle domande in linguaggio naturale, che possono essere affrontate utilizzando LLM che sono stati pre-addestrati su un'ampia varietà di stili di testo diversi
L'output di Text2SQL deve essere una query SQL valida. Questo vincolo può essere incorporato "iniettando" la conoscenza SQL nell'algoritmo; in alternativa, utilizzando un approccio iterativo, la query può essere verificata e migliorata in più passaggi.
A causa dell'impatto potenzialmente elevato dei "guasti silenziosi" che restituiscono dati errati per il processo decisionale, la gestione dei guasti è una preoccupazione primaria nell'interfaccia utente.
In modo "aumentato", gli utenti possono essere attivamente coinvolti nella convalida iterativa e nel miglioramento delle query SQL. Sebbene ciò renda l'applicazione meno fluida, riduce anche i tassi di errore, consente agli utenti di esplorare i dati in modo più flessibile e crea segnali preziosi per un ulteriore apprendimento.
I principali requisiti non funzionali da considerare sono l'accuratezza, la scalabilità, la velocità, la spiegabilità, la privacy e l'adattabilità nel tempo. I principali compromessi consistono tra accuratezza da un lato e scalabilità, velocità e privacy dall'altro.

Riferimenti

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

[2] Nitarshan Rajkumar et al. 2022. Valutazione delle funzionalità da testo a SQL di modelli di linguaggio di grandi dimensioni

[3] Naihao Deng et al. 2023. Recenti progressi nel text-to-SQL: un'indagine su ciò che abbiamo e ciò che ci aspettiamo

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

[5] Victor Zhong et al. 2021. Adattamento radicato per l'analisi semantica eseguibile zero-shot

[6] XiVictoria Lin et al. 2020. Bridging di dati testuali e tabulari per l'analisi semantica da testo a SQL tra domini

[7] Tong Guo et al. 2019. Contenuto Generazione da testo a SQL basata su BERT migliorata

[8] Torsten Scholak et al. 2021. PICARD: analisi incrementale per la decodifica auto-regressiva vincolata da modelli linguistici

[9] JinyangLi et al. 2023. Graphix-T5: miscelazione di trasformatori pre-addestrati con livelli Graph-Aware per l'analisi da testo a SQL

[10] LangChain. 2023. LLM e SQL

[11] TaoYu et al. 2018. Spider: un set di dati con etichetta umana su larga scala per analisi semantiche complesse e interdominio e attività di conversione da testo a SQL

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

[13] Katherine Tian et al. 2023. Basta chiedere la calibrazione: strategie per ottenere punteggi di fiducia calibrati dai modelli linguistici ottimizzati con il feedback umano

[14] Braden Hancock et al. 2019. Imparare dal dialogo dopo l'implementazione: nutriti, chatbot!

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

[16] Janna Lipenkova. 2022. Parla con me! Conversazioni Text2SQL con i dati della tua azienda, parla al meetup di elaborazione del linguaggio naturale di New York.

Tutte le immagini sono dell'autore.

Questo articolo è stato pubblicato in origine Verso la scienza dei dati e ripubblicato su TOPBOTS con il permesso dell'autore.

Ti faremo sapere quando pubblicheremo altri articoli di riepilogo come questo.