Resumen Técnico: UNIQL

Planteamiento del Problema

Los benchmarks actuales de text-to-SQL, como Spider y BIRD, están predominantemente centrados en el dialecto SQLite. Esta dependencia crea una brecha de evaluación significativa: no está claro si los modelos de lenguaje de gran tamaño (LLMs) pueden generalizar sus capacidades a través de dialectos SQL heterogéneos. Los sistemas de bases de datos del mundo real (por ejemplo, PostgreSQL, MySQL, Oracle, Hive) difieren sustancialmente en sintaxis, funciones integradas, sistemas de tipos y semántica de ejecución. En consecuencia, la misma intención de lenguaje natural a menudo requiere realizaciones SQL específicas de cada dialecto. Los benchmarks existentes se centran en un solo dialecto o cubren múltiples sistemas sin alinear las mismas intenciones de lenguaje natural entre ellos, lo que hace imposible aislar la variación del dialecto de las diferencias en esquemas o tareas. Esta limitación conduce a una sobreestimación de la robustez y universalidad de los sistemas actuales de text-to-SQL.

Metodología

Los autores presentan UNIQL, un benchmark ejecutable verificado por humanos diseñado para la evaluación de text-to-SQL entre dialectos. La construcción de UNIQL involucra un pipeline híbrido que extiende el conjunto de desarrollo de BIRD a 16 dialectos SQL.

Pipeline de Construcción del Dataset

1. Migración de Bases de Datos: Las bases de datos originales de BIRD (basadas en SQLite) se migran a 15 sistemas de bases de datos objetivo (incluyendo ClickHouse, Doris, Drill, Druid, DuckDB, Hive, MySQL, Oracle, PostgreSQL, Presto, Spark, StarRocks, Teradata, Trino y T-SQL). Este proceso implica adaptación de esquemas, mapeo de tipos, normalización de identificadores y adaptación de namespaces para asegurar la ejecutabilidad preservando la semántica de los datos.
2. Traducción y Verificación Automatizada:
   • Traducción Basada en Reglas: Se utiliza una herramienta determinista (SQLGlot) para generar consultas iniciales del dialecto objetivo.
   • Verificación Guiada por Ejecución: Las consultas traducidas se ejecutan en la base de datos objetivo. Una consulta solo se acepta automáticamente si se ejecuta con éxito y produce resultados estrictamente equivalentes a la consulta SQLite de origen. El protocolo preserva la semántica de ordenamiento y las multiplicidades de duplicados, evitando los falsos positivos comunes en las comparaciones de conjuntos no ordenados.
   • Traducción Basada en LLM: Para las consultas que fallan la traducción basada en reglas, un LLM (GPT-5-mini) genera traducciones condicionadas al SQL de origen, el esquema objetivo y el conjunto de reglas actual.
   • Autorreflexión: Si las traducciones del LLM fallan la verificación de equivalencia, el modelo entra en un bucle de autorreflexión acotado (hasta 3 rondas) utilizando retroalimentación de ejecución (errores o discrepancias de resultados) para refinar la consulta.
3. Evolución Iterativa de Reglas: Las traducciones fallidas se analizan para abstraer patrones de error recurrentes en reglas de transformación de dialectos reutilizables. Estas reglas se actualizan iterativamente (usando Gemini-2.5-Pro) para manejar problemas de la "larga cola" específicos de cada dialecto, tales como la reescritura de funciones, conversión de tipos y comportamiento de agregación.
4. Verificación Humana: Los casos que no pueden resolverse mediante traducción automatizada, reflexión o refinamiento de reglas se derivan a anotadores humanos. Dos anotadores independientes revisan la ejecutabilidad y la consistencia semántica, reescribiendo las consultas según sea necesario para asegurar que coincidan con la intención original del lenguaje natural.

Estadísticas del Benchmark

• Origen: 1,534 preguntas de lenguaje natural del conjunto de desarrollo de BIRD.
• Cobertura: 16 dialectos SQL (1 origen + 15 objetivos).
• Total de Anotaciones: 24,544 consultas SQL ejecutables y específicas de cada dialecto.
• Alineación: Todos los dialectos comparten intenciones de lenguaje natural idénticas, esquemas alineados y contenido de base de datos.

Protocolo de Evaluación

El artículo evalúa los modelos utilizando la Exactitud de Ejecución (EX). A diferencia de los benchmarks previos que convierten las salidas en conjuntos no ordenados, el protocolo de UNIQL preserva el orden cuando existen cláusulas ORDER BY explícitas y mantiene las multiplicidades de duplicados para salidas no ordenadas. Los modelos se evalúan en un entorno de solo inferencia sin ajuste fino específico de la tarea, selección de pocos disparos (few-shot) o adaptación específica del dialecto.

Resultados Clave

Los autores evaluaron un amplio conjunto de LLMs de código abierto (ej. Qwen3, Llama-3, DeepSeek) y de código cerrado (ej. GPT-5, Gemini, Claude).

1. Limitada Universalidad de Dialectos: Incluso los modelos más fuertes (ej. Claude-4.5-Sonnet) logran una exactitud de ejecución promedio de solo ~54.63%. Esto indica que la generación de text-to-SQL entre dialectos ejecutable está lejos de estar saturada.
2. Sesgo Centrado en SQLite: El rendimiento en SQLite no predice de manera confiable el rendimiento en otros dialectos. Por ejemplo, un modelo puede lograr un 59.84% en SQLite pero solo un 37.74% en Teradata. Los benchmarks de un solo dialecto no logran capturar estas significativas interacciones modelo-dialecto.
3. Efectos de Escala: Los modelos más grandes dentro de las familias (ej. de Qwen3-1.7B a Qwen3-32B) muestran un rendimiento mejorado, pero el escalado potencia principalmente la capacidad general en lugar de eliminar las debilidades específicas de cada dialecto. Los dialectos difíciles como Druid, Presto y Teradata siguen siendo desafiantes incluso para los modelos más grandes.
4. Familiaridad con el Dialecto: El rendimiento se correlaciona con la familiaridad del modelo. Oracle, que posee abundante documentación pública y exposición de entrenamiento, genera una mayor exactitud que Teradata o Druid, que pueden estar subrepresentados en los corpora de preentrenamiento e involucran funciones complejas específicas del sistema.
5. Consistencia entre Dialectos: Una alta exactitud promedio no implica corrección universal de dialectos. Para el mejor modelo, solo ~20% de las preguntas se responden correctamente en los 16 dialectos. Además, el éxito en la realización en SQLite de una intención no garantiza el éxito en otros dialectos (por ejemplo, solo ~33% de las preguntas correctas en SQLite siguen siendo correctas en todos los demás dialectos para Claude-4.5-Sonnet).

Significado y Contribuciones

El artículo realiza tres contribuciones principales:

1. Benchmark UNIQL: La introducción de un benchmark ejecutable verificado por humanos que alinea las mismas intenciones de lenguaje natural con realizaciones SQL en 16 dialectos, permitiendo una evaluación controlada de la generalización de dialectos.
2. Marco de Construcción: Un novedoso marco de traducción SQL que integra traducción basada en herramientas, traducción basada en LLM, verificación basada en ejecución, autorreflexión, evolución iterativa de reglas y validación humana para construir datasets de alta calidad entre dialectos.
3. Evaluación Diagnóstica: Una evaluación exhaustiva que muestra que los LLMs actuales luchan con la generación de text-to-SQL universal de dialectos. Los hallazgos resaltan que las consultas robustas entre sistemas requieren la evaluación y el modelado explícito de la robustez entre dialectos, en lugar de depender únicamente de los benchmarks centrados en SQLite.

Los autores concluyen que, si bien los modelos actuales muestran potencial, aún no son universales de dialecto. La variación sustancial en el rendimiento a través de los sistemas de bases de datos subraya la necesidad de benchmarks alineados entre dialectos y el desarrollo de métodos de text-to-SQL más conscientes de los dialectos.