Nel mio ultimo post su Text-to-SQL utilizzando GPT-3.5, ho sottolineato il problema con la metrica di valutazione del benchmark esistente: rifiuta le query SQL perfettamente corrette per non avere lo stesso risultato di esecuzione rigoroso delle query golden (ovvero etichettate). In questo post, discuto una nuova metrica che ho creato per valutare meglio le prestazioni da testo a SQL.

Ecco un esempio dal mio ultimo post:

-- (Hard) 
-- Question: Which grade has the most high schoolers?
-- pred:
SELECT grade, COUNT(*) AS num_highschoolers
FROM Highschooler
GROUP BY grade
ORDER BY num_highschoolers DESC
LIMIT 1;
-- gold:
SELECT grade
FROM Highschooler
GROUP BY grade
ORDER BY count(*) DESC
LIMIT 1;

Per ricapitolare i numeri del mio ultimo post: ho testato GPT-3.5 su 96 domande dal benchmark Spider (86 dal set di addestramento e 10 dal set di sviluppo) e ho scoperto che ha ottenuto il 41,7% nella precisione di esecuzione e il 38,5% nella corrispondenza esatta precisione. Tuttavia, dopo un'ulteriore analisi dei casi di errore, mi è diventato chiaro che la maggior parte delle query generate da GPT-3.5 andavano perfettamente bene dal punto di vista umano. Ciò evidenzia il problema con le nostre metriche di valutazione esistenti per Text-to-SQL, poiché non misurano accuratamente le preferenze umane.

Questo problema di disallineamento tra le metriche di valutazione del benchmark e l'effettiva preferenza umana è ben noto nella comunità di ricerca. Ad esempio, nei benchmark di riepilogo dei documenti, la metrica di valutazione standard è ROUGE , che si basa sul conteggio delle frasi di parole sovrapposte tra un riepilogo generato e un riepilogo dorato. Questo approccio non riesce a rilevare i riassunti corretti scritti in termini e frasi diversi dal riassunto aureo. Nonostante ciò, i punteggi ROUGE sono ancora utilizzati da articoli recenti.

La valutazione umana rimane il gold standard nella ricerca ML e le metriche automatiche sono i "test unitari" per i nuovi modelli. È possibile avere una via di mezzo, come un "ambiente di staging" per i nuovi modelli?

GPT-3.5 per la valutazione

GPT-3.5 è stato messo a punto per allinearsi alle preferenze umane , rendendolo molto più efficace nel seguire le istruzioni rispetto a GPT-3, che richiede un'attenta progettazione rapida per funzionare in modo efficace. Questo mi ha fatto pensare: possiamo sfruttare GPT-3.5 per creare una metrica di valutazione per Text-to-SQL che si allinei con le preferenze umane? Analizziamolo passo dopo passo:

Innanzitutto, dobbiamo considerare cosa è in grado di fare GPT-3.5:

• Può trasformare i dati strutturati in testo e viceversa.
• Può ragionare sulla base di fatti forniti direttamente nel contesto immediato.

• Una domanda di input nel testo in linguaggio naturale.
• Generazione di una query SQL.
• Esecuzione della query SQL e ottenimento di dati strutturati (ad esempio, righe).

Il diagramma seguente illustra questo design:

Utilizzando GPT-3.5 in questo modo, possiamo creare una metrica di valutazione per Text-to-SQL che si allinei meglio con le preferenze umane.

Risultati sperimentali

Ho esteso la valutazione del benchmark Spider con questa nuova metrica, che ho chiamato Answer Accuracy , come parte del progetto open source LlamaIndex . Il codice che ho usato può essere trovato qui .

Utilizzando questa nuova metrica, ho valutato le query SQL generate delle stesse 96 domande. L'accuratezza complessiva della risposta per GPT-3.5 text-davinci-003è di un impressionante 88,54%. Infatti, esaminando i casi di errore elencati nel mio ultimo post sul blog, ho scoperto che i casi che ho indicato come corretti erano effettivamente contrassegnati come tali e che l'unico vero caso di errore è stato rilevato correttamente

Per convalidare ulteriormente questa nuova metrica, l'ho testata sugli output di altri modelli GPT, incluso GPT-4. Ecco la trama delle loro accuratezze di risposta:

Le precisioni delle risposte risultanti sono le seguenti: code-davinci-002al 79,17%, text-davinci-003all'88,54%, gpt-3.5-turboall'85,42% e gpt-4all'89,58%. Come previsto, GPT-4 ha sovraperformato gli altri modelli, il che è in linea con la nostra esperienza pratica delle prestazioni relative di questi modelli.

Al contrario, le accuratezze di esecuzione e le accuratezze di corrispondenza dei modelli GPT non sono in linea con la nostra esperienza pratica. Ecco un grafico che mostra queste metriche utilizzate sui modelli GPT.

Se usiamo queste metriche come misura primaria delle prestazioni di Text-to-SQL, penseremmo che gpt-4sia meno potente di code-davinci-002. Questi risultati chiaramente non corrispondono alla nostra esperienza pratica con questi modelli.

Implicazioni chiave

Quali sono le principali implicazioni di questo esperimento Text-to-SQL?

In primo luogo, abbiamo scoperto che le metriche automatiche esistenti, vale a dire l'accuratezza dell'esecuzione e l'accuratezza della corrispondenza esatta, sono disallineate con le preferenze umane. Di conseguenza, non dovrebbero essere considerati il ​​modo principale per valutare i modelli da testo a SQL.

In secondo luogo, mentre la valutazione umana rimane il gold standard, i modelli di linguaggio di grandi dimensioni (LLM) come GPT-3.5 e versioni successive possono approssimare accuratamente la preferenza umana. Questo è un potenziale punto di svolta, perché ci consentono di valutare i modelli Text-to-SQL e stimare il risultato della valutazione umana prevista. Ciò è particolarmente utile quando la valutazione umana non è fattibile a causa della limitazione del budget.

In terzo luogo, ed è qui che le cose si fanno interessanti, il nostro uso di LLM sintonizzati sull'istruzione per la valutazione potrebbe essere generalizzato a molti altri compiti. Questo approccio è particolarmente utile per le attività il cui output è costituito da semplici istruzioni che possono essere ragionate direttamente dai LLM. E c'è un documento di ricerca proprio su questo argomento chiamato "GPTScore", che addestra GPT-3.5 a valutare le attività di PNL utilizzando l'apprendimento contestuale.

Nota

Questo post ha lo scopo di provocare una conversazione sulla valutazione da testo a SQL, non per affermare che la metrica di accuratezza della risposta è al 100% allineata agli umani o addirittura robusta. Sono felice di collaborare se desideri fare un ulteriore passo avanti verso una migliore valutazione.