DIN-SQL: Aprendizaje en Contexto Descompuesto para Text-to-SQL

La semana pasada cubrí BIRD, el benchmark que reveló cuán gravemente tropiezan los LLM cuando el text-to-SQL pasa de bases de datos de juguete seleccionadas a esquemas del mundo real con nombres desordenados, conocimiento de dominio y restricciones de eficiencia. DIN-SQL es el artículo que debería haber leído primero: definió lo que un pipeline de prompts de LLM cuidadosamente descompuesto puede lograr realmente en Spider y BIRD, y llegó a NeurIPS 2023 de la mano de Mohammadreza Pourreza y Davood Rafiei justo cuando GPT-4 estuvo ampliamente disponible. Leerlo ahora —después de que BIRD expusiera el límite— hace que las fortalezas y debilidades sean mucho más fáciles de ver con claridad.

El artículo

DIN-SQL (arXiv:2304.11015) aborda una brecha de rendimiento pronunciada. A principios de 2023, los mejores modelos ajustados —REDSQL-3B+NatSQL— alcanzaron un 79.9% de precisión de ejecución en el conjunto de prueba de Spider, mientras que GPT-4 con prompts simples de pocos ejemplos (few-shot) solo logró un 67.4% en el conjunto de desarrollo. La hipótesis de Pourreza y Rafiei es que esta brecha es principalmente un problema de interfaz: los LLM son lo suficientemente capaces, pero generar SQL en una sola pasada les pide resolver la vinculación de esquemas (schema linking), la clasificación de complejidad y la síntesis de consultas, todo a la vez. Al descomponer esas tareas en sub-tareas secuenciales y alimentar cada solución como contexto, la historia cambia.

Su pipeline tiene cuatro etapas: (1) un módulo de vinculación de esquemas que utiliza prompts de cadena de pensamiento (chain-of-thought) para mapear la pregunta en lenguaje natural a columnas y valores específicos en el esquema; (2) un módulo de clasificación y descomposición que clasifica la consulta en fácil (una sola tabla, sin joins), compleja no anidada (joins pero sin subconsultas) o compleja anidada (joins, subconsultas, operaciones de conjunto) y, para consultas anidadas, descompone el problema en subconsultas; (3) un módulo de generación de SQL que ajusta la estrategia de prompts a la clase de complejidad: few-shot simple para las fáciles, representación intermedia NatSQL para las no anidadas, cadena de pensamiento de múltiples pasos para las anidadas; y (4) un módulo de autocorrección que pide al modelo revisar su propio resultado en busca de errores menores como la falta de DISTINCT o un DESC mal colocado.

Ideas clave

• GPT-4 + DIN-SQL alcanza un 85.3% de precisión de ejecución en el conjunto de prueba retenido de Spider, un salto de +5.4 puntos sobre el entonces estado del arte ajustado RESDSQL-3B+NatSQL (79.9%), sin ningún dato de entrenamiento específico para la tarea.
• En Spider dev, el pipeline de descomposición eleva a GPT-4 del 67.4% (línea base few-shot) al 74.2%, una ganancia neta de +6.8 puntos. CodeX Davinci pasa del 61.5% al 69.9%.
• La ablación confirma que cada etapa contribuye: eliminar solo la vinculación de esquemas baja a CodeX de 69.9% a 65.9%; eliminar la clasificación lo baja aún más a 63.1%.
• Las ganancias se concentran en consultas fáciles y medias. En consultas "extra difíciles", incluso el pipeline completo de DIN-SQL + GPT-4 solo alcanza el 43.4% en Spider dev; la descomposición no resuelve la complejidad, solo reduce errores evitables en consultas tratables.
• La autocorrección es sensible al modelo: GPT-4 responde a prompts "suaves" que piden mejoras potenciales; CodeX responde mejor a prompts "genéricos" que asumen que el SQL es incorrecto. Esto sugiere que el módulo está haciendo una limpieza estilística, no una verificación semántica real.
• En BIRD dev, DIN-SQL + GPT-4 obtiene un 50.72% frente a una línea base de GPT-4 simple de 46.35%, una mejora de +4.4 puntos, sustancialmente menor que las ganancias de Spider, a lo que volveré más adelante.

Qué se mantiene — y qué no

El resultado central es real. Descomponer text-to-SQL en sub-tareas explícitas mejora el rendimiento, y los estudios de ablación son lo suficientemente claros como para creer en las contribuciones de los módulos individuales. La vinculación de esquemas es lo más importante para las consultas difíciles, lo cual tiene sentido: el modelo no puede generar JOINs correctos si primero no ha identificado correctamente a qué tablas y columnas se refiere la pregunta.

Sin embargo, varias cosas me hacen dudar. La discrepancia entre el 74.2% del conjunto dev frente al 85.3% del test es sospechosa. Los conjuntos de desarrollo suelen ser más difíciles o al menos tan difíciles como los de prueba porque los modelos se ajustan implícitamente a ellos; un salto de +11 puntos al pasar de dev a test es inusual. Los autores no explican esto, y me hace preguntarme si el conjunto de prueba tiene una distribución diferente de dificultades de consulta, o si hay algo en la forma en que se evalúa la prueba retenida (a través del servidor oficial del leaderboard de Spider) que difiere de su evaluación del conjunto dev. No citaría el 85.3% sin esa advertencia.

La brecha de BIRD (50.72% dev) es notablemente menor que las ganancias de Spider. Las bases de datos de BIRD tienen esquemas desordenados del mundo real con nombres de columnas abreviados, terminología específica del dominio y valores ambiguos. El módulo de vinculación de esquemas de DIN-SQL se diseñó teniendo en cuenta los esquemas relativamente limpios de Spider; cuando los esquemas se ensucian, la precisión de la vinculación cae y el resto del pipeline se degrada con ella. Esto es exactamente lo que midió el artículo de BIRD, y DIN-SQL no lo resuelve.

Los números de costo y latencia son un problema para cualquier sistema de producción: aproximadamente $0.50 y 60 segundos por pregunta con GPT-4. Eso está bien para un analista de datos que ejecuta diez consultas al día, pero es completamente inviable para un uso interactivo. El artículo presenta esto como una limitación conocida pero no propone un camino para reducirlo. DAIL-SQL (arXiv:2308.15363), que apareció unos meses después, demostraría que una mejor selección de ejemplos en lugar de una descomposición explícita podría alcanzar el 86.6% en Spider, superando a DIN-SQL a un costo significativamente menor.

El módulo de autocorrección es la parte más débil. Los autores reconocen que detecta errores "menores". Lo que no puede hacer es detectar errores semánticos —casos en los que el SQL generado es sintácticamente válido e incluso se ejecuta, pero responde a la pregunta equivocada. Ese es el modo de fallo más difícil para los usuarios reales.

Por qué esto es importante para la IA financiera

Beanquery (BQL) es un lenguaje de consulta similar a SQL sobre datos del libro mayor de Beancount. Tiene su propia estructura de tablas —transactions, postings, balance, prices— con jerarquías de cuentas, etiquetas y campos de metadatos que no se parecen en nada a los esquemas de bases de datos genéricas. Una interfaz de lenguaje natural para BQL es algo real y útil (ya existe un servidor experimental beanquery-mcp que implementa exactamente esto a través de MCP), y la estrategia de descomposición de DIN-SQL es el punto de partida adecuado.

La vinculación de esquemas sobre BQL es el problema análogo a la vinculación sobre tablas relacionales, pero con dos complicaciones adicionales: los nombres de las cuentas son rutas jerárquicas como Assets:US:Checking:Bank, y el esquema relevante depende de qué tipo de consulta esté haciendo el usuario (estado de resultados, balance general, flujo de caja). El módulo de clasificación de DIN-SQL sugiere una adaptación directa: clasificar primero la intención de la consulta (balance vs. flujo vs. búsqueda de precios) y luego dirigirla a diferentes plantillas de prompts.

El hallazgo del benchmark BIRD de que el desorden del mundo real perjudica el text-to-SQL de los LLM es directamente relevante. Un libro mayor de Beancount también es "desordenado": nombres de cuentas definidos por el usuario, símbolos de commodities inconsistentes, claves de metadatos personalizadas. La mejora de 4.4 puntos en BIRD frente a la mejora de 6.8 puntos en Spider me indica que el régimen de esquemas limpios y estructurados sobreestima cuánto ayudará la descomposición en las consultas BQL reales. Espere ganancias menores en la práctica.

La restricción de costos es real pero menos vinculante aquí. Un usuario de finanzas personales que ejecute 10–20 consultas al día puede tolerar $5–10 al día en costos de API si la interfaz es genuinamente útil. La latencia (60 segundos) es más un problema para el uso interactivo; el procesamiento por lotes de consultas analíticas podría evitarlo.

Qué leer a continuación

• DAIL-SQL: Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation (arXiv:2308.15363) — estudio sistemático de estrategias de ingeniería de prompts; alcanza el 86.6% en Spider centrándose en la selección de ejemplos en lugar de la descomposición arquitectónica, un contrapunto útil a DIN-SQL.
• RESDSQL: Decoupling Schema Linking and Skeleton Parsing for Text-to-SQL (arXiv:2302.05965, AAAI 2023) — la línea base ajustada que DIN-SQL superó; entender lo que el enfoque ajustado hace bien aclara dónde el prompting todavía se queda corto.
• MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL (arXiv:2312.11242) — extiende la idea de descomposición de múltiples pasos a un pipeline multi-agente explícito con un Selector, Decomponedor y Refinador; alcanza el 59.59% en BIRD con GPT-4 y es el enfoque más centrado en agentes en este espacio.