DIN-SQL: Aprenentatge en context descompost per a Text-to-SQL

La setmana passada vaig parlar de BIRD, el referent que va revelar fins a quin punt els LLM trontollen quan el text-a-SQL passa de bases de dades de joguina curades a esquemes del món real amb noms desordenats, coneixement de domini i restriccions d'eficiència. DIN-SQL és l'article que hauria d'haver llegit primer: va definir el que pot aconseguir realment una canalització de prompteig d'LLM acuradament descomposada a Spider i BIRD, i va arribar a NeurIPS 2023 de la mà de Mohammadreza Pourreza i Davood Rafiei just quan el GPT-4 va començar a estar disponible de manera generalitzada. Llegir-lo ara —després que el BIRD n'hagi exposat el sostre— fa que les fortaleses i els límits es vegin molt més clarament.

L'article

DIN-SQL (arXiv:2304.11015) aborda una bretxa de rendiment pronunciada. A principis de 2023, els millors models ajustats finament —RESDSQL-3B+NatSQL— assolien un 79,9% de precisió d'execució en el conjunt de prova de Spider, mentre que el GPT-4 amb un prompteig ingenu de pocs exemples només aconseguia un 67,4% en el conjunt de desenvolupament. La hipòtesi de Pourreza i Rafiei és que aquesta bretxa és principalment un problema d'interfície: els LLM són prou capaços, però generar SQL en una sola passada els demana resoldre la vinculació d'esquemes, la classificació de complexitat i la síntesi de consultes alhora. Si es descomposen en subtasques seqüencials i es transmet cada solució com a context, la història canvia.

La seva canalització té quatre etapes: (1) un mòdul de vinculació d'esquemes que utilitza el prompteig de cadena de pensament per mapejar la pregunta en llenguatge natural a columnes i valors específics de l'esquema; (2) un mòdul de classificació i descomposició que classifica la consulta en fàcil (una sola taula, sense unions), complexa no niada (unions però sense subconsultes) o complexa niada (unions, subconsultes, operacions de conjunts) i, per a consultes niades, descomposa el problema en subconsultes; (3) un mòdul de generació de SQL que adapta l'estratègia de prompteig a la classe de complexitat —pocs exemples per a les fàcils, representació intermèdia NatSQL per a les no niades, cadena de pensament de múltiples passos per a les niades; i (4) un mòdul d'autocorrecció que demana al model que revisi la seva pròpia sortida per buscar errors menors com la falta de DISTINCT o un DESC mal col·locat.

Idees clau

• GPT-4 + DIN-SQL assoleix una precisió d'execució del 85,3% en el conjunt de prova reservat de Spider, un salt de +5,4 punts respecte al llavors SOTA ajustat finament RESDSQL-3B+NatSQL (79,9%), sense cap dada d'entrenament específica per a la tasca.
• A Spider dev, la canalització de descomposició fa que el GPT-4 passi del 67,4% (línia base de pocs exemples) al 74,2%, un guany net de +6,8 punts. CodeX Davinci passa del 61,5% al 69,9%.
• L'ablació confirma que cada etapa hi contribueix: eliminar només la vinculació d'esquemes fa caure CodeX del 69,9% al 65,9%; eliminar la classificació el fa baixar encara més fins al 63,1%.
• Els guanys es concentren en consultes fàcils i mitjanes. En consultes "extra difícils", fins i tot la canalització completa DIN-SQL + GPT-4 només arriba al 43,4% a Spider dev — la descomposició no resol la complexitat, només redueix els errors evitables en consultes tractables.
• L'autocorrecció és sensible al model: el GPT-4 respon a prompteigs "suaus" que demanen possibles millores; CodeX respon millor a prompteigs "genèrics" que assumeixen que el SQL és incorrecte. Això suggereix que el mòdul està fent una neteja estilística, no una verificació semàntica real.
• A BIRD dev, DIN-SQL + GPT-4 obté un 50,72% enfront d'una línia base de GPT-4 simple del 46,35%, una millora de +4,4 punts, substancialment menor que els guanys de Spider, un punt sobre el qual tornaré més endavant.

Què se sosté — i què no

El resultat principal és real. Descompondre el text-a-SQL en subtasques explícites millora el rendiment, i els estudis d'ablació són prou clars com per creure en les contribucions individuals dels mòduls. La vinculació d'esquemes és el que més importa per a les consultes difícils, la qual cosa té sentit: el model no pot generar JOINs correctes si primer no ha identificat correctament a quines taules i columnes es refereix la pregunta.

Però hi ha diverses coses que em fan dubtar. La discrepància del 74,2% en dev vs. el 85,3% en test és sospitosa. Els conjunts dev solen ser tan difícils o més que els de test perquè els models s'ajusten implícitament contra ells; un salt de +11 punts en passar de dev a test és inusual. Els autors no ho expliquen, i em fa preguntar-me si el conjunt de prova té una distribució diferent de dificultats de consulta, o si hi ha alguna cosa en la manera com s'avalua la prova reservada (a través del servidor oficial de classificació de Spider) que difereix de la seva avaluació del conjunt dev. No citaria el 85,3% sense aquest advertiment.

La bretxa de BIRD (50,72% dev) és notablement menor que els guanys de Spider. Les bases de dades de BIRD tenen esquemes del món real desordenats amb noms de columnes abreujats, terminologia específica del domini i valors ambigus. El mòdul de vinculació d'esquemes de DIN-SQL es va dissenyar tenint en compte els esquemes relativament nets de Spider; quan els esquemes s'embruten, la precisió de la vinculació cau i la resta de la canalització es degrada amb ella. Això és exactament el que va mesurar l'article de BIRD, i DIN-SQL no ho resol.

Les xifres de cost i latència són un problema per a qualsevol sistema de producció: aproximadament 0,50 $ i 60 segons per pregunta amb GPT-4. Això està bé per a un analista de dades que executi deu consultes al dia, però és completament inviable per a un ús interactiu. L'article ho presenta com una limitació coneguda però no proposa una via per reduir-ho. DAIL-SQL (arXiv:2308.15363), que va aparèixer uns mesos més tard, demostraria que una millor selecció d'exemples en lloc d'una descomposició explícita podria arribar al 86,6% a Spider, superant DIN-SQL amb un cost significativament menor.

El mòdul d'autocorrecció és la part més feble. Els autors reconeixen que detecta errors "menors". El que no pot fer és detectar errors semàntics —casos en què el SQL generat és sintàcticament vàlid i fins i tot s'executa, però respon a la pregunta equivocada. Aquest és el mode de fallada més difícil per als usuaris reals.

Per què això és important per a la IA financera

Beanquery (BQL) és un llenguatge de consultes similar a SQL per a les dades del llibre major de Beancount. Té la seva pròpia estructura de taules —transactions, postings, balance, prices— amb jerarquies de comptes, etiquetes i camps de metadades que no s'assemblen gens als esquemes de bases de dades genèriques. Una interfície de llenguatge natural per a BQL és quelcom real i útil (ja existeix un servidor experimental beanquery-mcp que implementa exactament això mitjançant MCP), i l'estratègia de descomposició de DIN-SQL és el punt de partida adequat.

La vinculació d'esquemes sobre BQL és el problema anàleg a la vinculació d'esquemes sobre taules relacionals, però amb dues complicacions addicionals: els noms dels comptes són camins jeràrquics com Assets:US:Checking:Bank, i l'esquema pertinent depèn de quin tipus de consulta estigui fent l'usuari (estat de resultats, balanç de situació, flux de caixa). El mòdul de classificació de DIN-SQL suggereix una adaptació directa: classificar primer la intenció de la consulta (balanç vs. flux vs. cerca de preus) i després derivar-la a diferents plantilles de prompteig.

La conclusió de l'estudi BIRD sobre com el desordre del món real perjudica el text-a-SQL dels LLM és directament rellevant. Un llibre major de Beancount també és "desordenat": noms de comptes definits per l'usuari, símbols de mercaderies inconsistents, claus de metadades personalitzades. La millora de 4,4 punts a BIRD enfront de la millora de 6,8 punts a Spider em diu que el règim d'esquemes nets i estructurats sobreestima quant ajudarà la descomposició en les consultes BQL reals. Cal esperar guanys més petits a la pràctica.

La restricció de cost és real però menys vinculant aquí. Un usuari de finances personals que executi entre 10 i 20 consultes al dia pot tolerar entre 5 i 10 $/dia en costos d'API si la interfície és realment útil. La latència (60 segons) és més aviat un problema per a l'ús interactiu; el processament per lots de consultes analítiques podria esquivar-ho.

Què llegir a continuació

• DAIL-SQL: Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation (arXiv:2308.15363) — estudi sistemàtic d'estratègies d'enginyeria de prompteigs; assoleix el 86,6% a Spider centrant-se en la selecció d'exemples en lloc de la descomposició arquitectònica, un contrapunt útil a DIN-SQL.
• RESDSQL: Decoupling Schema Linking and Skeleton Parsing for Text-to-SQL (arXiv:2302.05965, AAAI 2023) — la línia base ajustada finament que DIN-SQL va superar; entendre què fa bé l'enfocament d'ajust fin permet aclarir on el prompteig encara es queda curt.
• MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL (arXiv:2312.11242) — estén la idea de descomposició en múltiples passos cap a una canalització multi-agent explícita amb un Selector, un Descompositor i un Refinador; arriba al 59,59% a BIRD amb GPT-4 i és l'enfocament més centrat en agents en aquest àmbit.