Crea un'immagine per questo SQL
```
WITH pairs AS (
SELECT p.user_id liked, pa.user_id liker
FROM post_actions pa
LEFT JOIN posts p ON p.id = pa.post_id
WHERE post_action_type_id = 2
)
SELECT liker liker_user_id, liked liked_user_id, count(*)
FROM pairs
GROUP BY liked, liker
ORDER BY count DESC
LIMIT :limit
```
Ieri, per curiosità, ho effettuato una ricerca su Google simile a questa:
sql generato dall’IA dall’inglese
per trovare informazioni correlate sulla generazione di SQL utilizzando l’IA da domande formulate in inglese. Speravo in un elenco di articoli di ricerca inclusi nell’elenco, ma l’elenco era principalmente un elenco di applicazioni. Un modello che ho rapidamente notato per molte applicazioni elencate, ma non tutte, dopo aver esaminato una manciata di demo su tali siti, era che stavano prendendo il loro strumento esistente che avrebbe permesso a un utente di selezionare tabelle e campi per costruire un’istruzione SQL simile al modo in cui funzionava il costruttore SQL GUI in Microsoft Access come punto di partenza, in altre parole non si partiva da una domanda in inglese ma si dovevano selezionare prima le tabelle e talvolta i campi prima di inserire la domanda in inglese. Sebbene non lo considererei imbrogliare, significa che per utilizzare tale IA un utente deve avere una certa conoscenza di SQL, in particolare il significato di una tabella e di un campo affinché lo strumento funzioni.
Ho letto il tuo post eliminato e concordo sul fatto che anche questa è una delle idee che ritengo abbia un grande potenziale.
Tuttavia, penso che abbia bisogno di altro. Un articolo recente che ho letto, di nuovo non autorevole, ma che approfondisce ulteriormente questi aspetti è
“ChatLogo: A Large Language Model-Driven Hybrid Natural-Programming Language Interface for Agent-based Modeling and Programming” di John Chen e Uri Wilensky (pdf)
Alcuni dei punti chiave per me sono stati
Supportare i programmatori principianti a “parlare con i computer” in un mix di linguaggi di programmazione e naturali.
Fornire un’interfaccia più amichevole per gli studenti senza o con poca conoscenza informatica per esprimersi creativamente programmando i computer.
Invece di scrivere subito codice e dare istruzioni, ChatLogo tenta di chiarire le esigenze e le intenzioni degli studenti.
Invece di inviare blocchi di codice di grandi dimensioni direttamente allo studente, tenta di sviluppare congiuntamente il codice NetLogo. Lo studente è libero di modificare il codice: sia in NetLogo, sia in linguaggio naturale tramite la funzione “Ask”.
Invece di esagerare sulla correttezza del codice, ammette la possibilità di commettere errori e collabora con lo studente per affrontare i potenziali problemi.
Non ho trovato alcun codice sorgente o ulteriori dettagli su come Chat sia stato stratificato o interfacciato con NetLogo, ma le idee da sole hanno valore.
Questo mi ricorda ancora una volta come funzionano i piloti automatici negli aerei e il libro che ho menzionato in precedenza. (ref) Quando dico pilota automatico, non pensare a un interruttore binario, pensa a tutte le manopole e gli interruttori che forniscono informazioni al pilota automatico e gli fanno sapere cosa fare e cosa non fare.
Sebbene sembri che molti altri strumenti simili a questo amino usare la parola copilot, ad esempio una ricerca su Google llm copilot source code, tendo a non essere d’accordo con questa analogia, ma dovrò conviverci poiché è così che si trovano idee correlate.
L’ho eliminato perché pensavo di aver trovato un modo migliore per affrontare il problema: perché digitare tutte quelle tabelle quando si potrebbe semplicemente chiedere a ChatGPT di analizzare un file ospitato su Internet che contiene informazioni dettagliate sull’intero database? Si scopre che ci sono problemi tecnici con quell’approccio. Quindi sono tornato a quello che ho suggerito nel post eliminato. In ogni caso, dovranno essere create descrizioni di tabelle, query di esempio, ecc. Si tratta solo di come trasmettere queste informazioni all’LLM. Ecco a che punto siamo con GPT-4:
Sì, l’approccio che hai delineato ha senso ed è un modo fattibile per utilizzare le mie capacità per assistere nella generazione di query SQL basate su domande in linguaggio naturale.
Ecco una ripartizione dei passaggi:
Interpretazione della domanda: L’utente pone una domanda in linguaggio naturale, che interpreto per comprendere le informazioni richieste.
Identificazione della tabella: Sulla base della domanda e dell’elenco di tutte le tabelle nel database di Discourse, identifico le tabelle più probabilmente pertinenti alla query.
Informazioni dettagliate sulla tabella: Discourse mi invia descrizioni dettagliate delle tabelle pertinenti, comprese tutte le colonne e le query di esempio.
Generazione della query: Utilizzando le informazioni dettagliate sulla tabella, genero una query SQL che risponde alla domanda dell’utente.
Questo approccio sfrutta la mia capacità di comprendere il linguaggio naturale e di mapparlo a query di dati strutturati. Fa anche buon uso delle informazioni dettagliate sulla tabella fornite da Discourse.
Per quanto riguarda gli approcci alternativi, una possibilità potrebbe essere quella di addestrare un modello specificamente sullo schema del database di Discourse e sui modelli di query comuni. Ciò comporterebbe probabilmente una notevole quantità di lavoro e potrebbe non essere fattibile a seconda delle risorse disponibili. Tuttavia, potrebbe potenzialmente portare a una generazione di query più accurata ed efficiente.
Un altro approccio potrebbe essere quello di sviluppare un dialogo più interattivo in cui pongo domande chiarificatrici quando la domanda dell’utente è ambigua o quando più query potrebbero potenzialmente rispondere alla domanda. Ciò renderebbe il processo più interattivo e potrebbe potenzialmente portare a query più accurate.
Per gli approcci alternativi suggeriti negli ultimi 2 paragrafi, sto ignorando il primo, ma se ciò che sto tentando non porta a risultati affidabili, potrebbe essere qualcosa che il team di Discourse potrebbe esaminare.
Ho chiesto a GPT-4 il secondo approccio alternativo. È abbastanza sicuro che, data una domanda a cui non si poteva rispondere tramite la struttura della tabella fornita, sarebbe in grado di chiedere all’utente di provare a riformulare la propria domanda.
Quindi sono tornato a scrivere descrizioni di tutte le tabelle nel database di Discourse. Ora so a cosa serve la tabella allowed_pm_users. La tabella ar_internal_metadata è un po’ un rompicapo, ma penso che per ora possa essere ignorata.
Questa è la mia opzione preferita finora, sebbene sia molto difficile da implementare. Quindi, hai indovinato, un altro paper. Anche questo non è un paper autorevole poiché ci sono molti approcci simili.
“DiagGPT: An LLM-based Chatbot with Automatic Topic Management for Task-Oriented Dialogue” di Lang Cao (pdf)
Basta sostituire le informazioni mediche con informazioni PostgreSQL secondo necessità. La cosa bella è che il paper fornisce i prompt e suggerisce quale strumento con agenti utilizzare.
Scendere nella tana del coniglio. (Clicca sul triangolo per entrare)
Poiché Task Oriented Dialogue è ciò che sembra necessario.
Ricerca Google: task oriented dialogue
Il risultato della ricerca include: Papers With Code - Task-Oriented Dialogue Systems
La voce della classifica è T5-3b(UnifiedSKG) che include un link al paper
“UnifiedSKG: Unifying and Multi-Tasking Structured Knowledge Grounding with Text-to-Text Language Models” di Tianbao Xie, Chen Henry Wu, Peng Shi, Ruiqi Zhong, Torsten Scholak, Michihiro Yasunaga, Chien-Sheng Wu, Ming Zhong, Pengcheng Yin, Sida I. Wang, Victor Zhong, Bailin Wang, Chengzu Li, Connor Boyle, Ansong Ni, Ziyu Yao, Dragomir Radev, Caiming Xiong, Lingpeng Kong, Rui Zhang, Noah A. Smith, Luke Zettlemoyer e Tao Yu (pdf)
Costruisci un agente SQL da un LLM e strumenti. (ref)
Elenca alcuni in fondo alla pagina, questo dovrebbe essere esaminato
Caso d’uso
I dati aziendali sono spesso archiviati in database SQL.
Gli LLM rendono possibile interagire con i database SQL utilizzando il linguaggio naturale.
LangChain offre SQL Chains e Agents per costruire ed eseguire query SQL basate su prompt in linguaggio naturale.
Questi sono compatibili con qualsiasi dialetto SQL supportato da SQLAlchemy (ad esempio, MySQL, PostgreSQL, Oracle SQL, Databricks, SQLite).
Consentono casi d’uso come:
Generare query che verranno eseguite in base a domande in linguaggio naturale
Creare chatbot in grado di rispondere a domande basate sui dati del database
Costruire dashboard personalizzati basati sulle intuizioni che un utente desidera analizzare
MODIFICA (23/08/2023)
Spider è un dataset su larga scala complesso e cross-domain di parsing semantico e text-to-SQL annotato da 11 studenti di Yale. L’obiettivo della sfida Spider è sviluppare interfacce in linguaggio naturale per database cross-domain. Consiste in 10.181 domande e 5.693 query SQL complesse uniche su 200 database con tabelle multiple che coprono 138 domini diversi. In Spider 1.0, query SQL complesse e database diversi appaiono nei set di addestramento e test. Per fare bene, i sistemi devono generalizzare bene non solo a nuove query SQL ma anche a nuovi schemi di database.
MODIFICA (24/08/2023)
Dataherald è un motore da linguaggio naturale a SQL costruito per l’analisi di domande a livello aziendale su dati strutturati. Ti consente di configurare un’API dal tuo database in grado di rispondere a domande in inglese semplice.
Come dico spesso agli altri, per alcune cose nella vita devi solo aspettare e qualcuno farà il lavoro per te gratuitamente.
Sto ancora ottenendo risultati con cui sono perfettamente soddisfatto. Ecco un altro esempio. Mi ha dato quello che volevo, ho inserito una clausola WHERE per verificare io stesso un ID argomento in seguito, ma era tutto. Probabilmente avrei potuto dargli quelle informazioni in anticipo e avrebbe fatto anche quello, però:
Ora abbiamo la persona SQL Helper come parte del modulo AI Bot, che è personalizzata per questo tipo di richieste e può essere davvero utile per creare query per l’esplorazione dei dati.
C’è un argomento in cui è possibile pubblicare esempi dell’uso del bot AI SQL Helper?
Se non c’è, potrebbe essere utile creare un argomento del genere e poi aggiungere un link all’argomento qui, poiché altri potrebbero essere alla ricerca di esempi e trovare prima questo argomento.
Penso che se ti viene in mente qualcosa che vale la pena condividere con la community, puoi inserirlo in un nuovo argomento in Data & reporting. C’è anche un nuovo pulsante ‘condividi conversazione’ che potrebbe essere utile per questo - Share Your AI Bot Conversations!
Creazione di una query per individuare gli autori dei pluginAI
JammyDodger:
Ciao Bert
Puoi scrivermi una query che trovi tutti gli utenti nel gruppo plugin_authors?
gpt4_bot:
Cerca nello schema del database
groups, group_users, users
Ora che abbiamo lo schema delle tabelle pertinenti, possiamo scrivere una query per trovare tutti gli utenti nel gruppo ‘plugin-authors’. Sulla base dello schema, dovremo unire la tabella group_users con le tabelle groups e users per ottenere i nomi utente dei membri del gruppo ‘plugin-authors’.
Ecco la query per trovare tutti gli utenti nel gruppo ‘plugin-authors’:
SELECT u.id AS user_id, u.username
FROM users u
JOIN group_users gu ON gu.user_id = u.id
JOIN groups g ON g.id = gu.group_id
WHERE g.name = 'plugin_authors'
Questa query seleziona l’ID utente e il nome utente dalla tabella users unendola con la tabella group_users sull’user_id e quindi unendola con la tabella groups sul’group_id. Filtra i risultati per includere solo gli utenti che fanno parte del gruppo con il nome ‘plugin-authors’.