Resumen Técnico: ¿Qué predice la corrección en Text-to-SQL? Un estudio de predicción selectiva

Definición del Problema

El artículo aborda el problema de la predicción selectiva en los sistemas text-to-SQL: determinar cuándo una consulta SQL generada es lo suficientemente correcta como para ser ejecutada y cuándo el sistema debe abstenerse. La corrección se define en el sentido estándar de los benchmarks: la consulta generada debe devolver el mismo conjunto de resultados que una consulta de referencia escrita por un humano al ejecutarse contra la base de datos. El objetivo es estimar la probabilidad de corrección ($P(\text{correct})$) para permitir que un sistema elija entre responder o declinar, en lugar de mejorar iterativamente la consulta (autocorrección).

Metodología

El estudio evalúa diversas señales para predecir la corrección en tareas de text-to-SQL de múltiples tablas "difíciles" utilizando dos benchmarks: BIRD (800 preguntas, 8 bases de datos) y Spider (490 preguntas, 20 bases de datos).

Señales Evaluadas

Los autores categorizan las señales en dos grupos:

1. Señales Estadísticas de Caja Negra (Black-box): Estas dependen de las estadísticas de salida del generador sin razonamiento externo.
   • Autoconsistencia (Self-consistency): Agrupación por cadena (consultas idénticas), estructural (estructura canónica) y de ejecución (conjunto de resultados).
   • Relevancia del Esquema (Schema Relevance): Similitud de embeddings entre la pregunta y las tablas/columnas utilizadas.
   • Ejecutabilidad (Executability): Si la consulta se ejecuta y devuelve filas.
   • Log-Probabilidad de Caja Blanca (White-box): La media de la log-probabilidad de la secuencia de la consulta generada.
2. Señales Basadas en Verificación: Estas involucran a un modelo separado (juez LLM) que inspecciona la pregunta, el esquema, la evidencia y la consulta candidata para juzgar la corrección.
   • Jueces: GPT-4o-mini, GPT-4o y Claude-Sonnet-4.6.
   • Ensamble: Una combinación de las puntuaciones de GPT-4o y Claude.
   • Verificadores Entrenados: Modelos codificadores y generativos (Qwen2.5-1.5B/7B) ajustados (fine-tuned) sobre pares etiquetados por ejecución.

Métricas de Evaluación

• AUROC: Área bajo la curva de la característica de tasa de verdaderos positivos (Receiver Operating Characteristic), que mide la capacidad de clasificar las consultas correctas por encima de las incorrectas.
• Calibración: Error de Calibración Esperado (ECE).
• Predicción Selectiva: Fronteras de riesgo-cobertura (tasa de error entre las preguntas respondidas frente a la fracción de preguntas respondidas).
• Significancia Estadística: Intervalos de confianza de bootstrap emparejados (2,000 muestras) para determinar si las diferencias entre señales son significativas.

Resultados Clave

1. El Techo de la Caja Negra

Las señales estadísticas de caja negra y la log-probabilidad de caja blanca se estancan en una estrecha banda de rendimiento, fallando en distinguir de manera fiable las consultas correctas de las incorrectas en tareas difíciles de múltiples tablas.

• Rango de Rendimiento: AUROC entre 0.61 y 0.68.
• Señal de Caja Negra más fuerte: Autoconsistencia de cadena (AUROC 0.675).
• Log-Probabilidad: Similar a la autoconsistencia (0.669), sin diferencia significativa.
• Ejcutabilidad: Esencialmente azar (0.500), ya que las consultas incorrectas a menudo se ejecutan con éxito.
• Conclusión: Estas señales miden la consistencia interna o la alineación con el esquema, pero no logran detectar errores lógicos en la computación o composición.

2. La Verificación Rompe el Techo

Las señales basadas en la verificación superan significativamente a las líneas base de caja negra al razonar sobre si la lógica del SQL coincide con la pregunta.

• Jueces Individuales:
  • GPT-4o-mini: 0.724 AUROC.
  • GPT-4o: 0.770 AUROC.
  • Claude-Sonnet-4.6: 0.776 AUROC.
• Ensamble: Combinar GPT-4o y Claude (que cometen errores diferentes, correlación $r=0.43$) produce la mejor señal: 0.822 AUROC con una excelente calibración (ECE 0.031).
• Robustez: Este patrón se mantiene a través de diferentes generadores (GPT-4o-mini vs. GPT-4.1-mini) y benchmarks (BIRD y Spider).

3. Verificadores Entrenados: In-Distribution vs. Transferencia

El estudio investiga si un verificador más económico y ajustado puede reemplazar al juez LLM congelado.

• In-Distribution (En distribución): Los modelos ajustados (codificadores y jueces generativos) funcionan bien en esquemas vistos, alcanzando un 0.77–0.80 AUROC.
• Transferencia de Esquema (Cross-Schema Transfer): Cuando se prueban en bases de datos no vistas (Leave-One-Database-Out), el rendimiento cae significativamente a ~0.66 AUROC.
• Escalado y Destilación: Aumentar el tamaño del modelo (de 1.5B a 7B), añadir diversidad de esquemas, destilar racionales o el entrenamiento cruzado de benchmarks no lograron cerrar la brecha de transferencia.
• Conclusión: Los verificadores ajustados capturan regularidades superficiales específicas del esquema en lugar de un razonamiento robusto entre esquemas. Para entornos abiertos/de esquemas cruzados, un modelo de razonamiento grande y congelado sigue siendo superior.

4. Predicción Selectiva y Abstención

• Autoconsistencia: No puede formar un subconjunto de bajo riesgo válido; incluso sus predicciones más confiadas son demasiado propensas a errores para una abstención segura.
• Ensamble de Verificación: Permite una abstención útil. Por ejemplo, ante un riesgo objetivo de 0.30, el ensamble responde el 27% de las preguntas con un riesgo selectivo observado de 0.24.
• Línea Base de Autocorrección: Una sola ronda de autocorrección apenas mejora la precisión (0.451 a 0.468) y produce una confianza severamente descalibrada (media 0.97, ECE 0.501), confirmando que la regeneración no sustituye la necesidad de un verificador calibrado.

5. Análisis de Errores

El artículo identifica que los principales modos de fallo en el text-to-SQL difícil son la computación y la composición (ratios, porcentajes, lógica condicional, agrupación, anidamiento), no el enlace al esquema o el conteo de joins.

• Las puntuaciones de relevancia del esquema son débiles porque los generadores suelen identificar las tablas correctas pero fallan en la lógica.
• Los verificadores sobresalen porque evalúan la computación expresada por el SQL frente a la pregunta.
• La ventaja del verificador es más pronunciada en preguntas aritméticas (AUROC 0.813) y consultas simples donde la autoconsistencia suele ser erróneamente confiada.

Significancia y Reclamaciones

El artículo afirma que para tareas de text-to-SQL difíciles:

1. La incertidumbre de la corrección es real pero no es capturada por señales baratas. El acuerdo de muestreo, la consistencia estructural y la log-probabilidad son insuficientes para un despliegue de alto riesgo.
2. Se requiere razonamiento. Las únicas señales que rompen el techo de rendimiento son aquellas que razonan explícitamente sobre la lógica de la consulta (verificación).
3. Los regímenes de despliegue difieren.
   • Fijo/En-Dominio: Un verificador ajustado es una herramienta rentable y precisa para la abstención.
   • Abierto/Esquema-Cruzado: Actualmente es necesario un modelo de razonamiento grande y congelado (juez LLM) para una generalización fiable.
4. Los ensambles mejoran la fiabilidad. Combinar jueces independientes (diferentes proveedores) produce la señal más calibrada y discriminativa, lo que sugiere que la incertidancia de la verificación no es un artefacto de una sola familia de modelos.
5. La autocorrección no es un sustituto. Incluso los sistemas que regeneran consultas necesitan un verificador calibrado al final del proceso para decidir si confían en el resultado final.

El estudio concluye que si un sistema debe decidir si confiar en un SQL generado, debe invertir en un verificador consciente de la lógica y calibrarlo para la predicción selectiva, en lugar de confiar en la confianza de muestreo.