🤖 AI

SIRIUS-SQL: Anchoring Multi-Candidate Text-to-SQL in Execution Feedback

SIRIUS-SQL es un novedoso marco de trabajo de Text-to-SQL que mejora la precisión en esquemas complejos al abordar las limitaciones de los sistemas de múltiples candidatos existentes mediante una estrategia de entrenamiento de RL de suavizado de dificultad para la generación diversa, un ciclo de vida basado en la ejecución para la reparación de errores dirigida y un selector híbrido con compuerta de confianza, logrando un rendimiento de vanguardia en los benchmarks BIRD y SPIDER.

Autores originales: Leo Luo, Haining Xie, Siqi Shen, Zhipeng Ma, Rui Ling, Hang Xu, Hefeng Jiang, Dingwei Chen, Yang Li, Peng Chen, Jie Jiang

Publicado 2026-06-02

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Leo Luo, Haining Xie, Siqi Shen, Zhipeng Ma, Rui Ling, Hang Xu, Hefeng Jiang, Dingwei Chen, Yang Li, Peng Chen, Jie Jiang

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás intentando dar una instrucción muy específica y compleja a un robot chef (la IA) para cocinar una comida (escribir una consulta SQL) basada en un libro de recetas masivo y desordenado (la base de datos).

Si le pides al robot que cocine solo una vez, suele cometer errores porque el libro de recetas es confuso, los ingredientes tienen nombres extraños o las instrucciones son vagas.

La forma antigua: El problema del "voto de la multitud"
Recientemente, otros sistemas intentaron solucionar esto pidiéndole al robot que cocinara la comida 16 veces en lugar de una sola. Luego, observaban los 16 platos y elegían aquel con el que la mayoría estuviera de acuerdo (votación por mayoría).

Los autores de este artículo, SIRIUS-SQL, dicen que este enfoque de "voto de la multitud" tiene tres grandes problemas:

La cámara de eco: Si le pides al mismo robot que cocine 16 veces, seguirá cometiendo los mismos 16 errores. Es como pedirle a una sola persona que adivine una contraseña 16 veces; es probable que adivine lo mismo incorrecto una y otra vez.
La solución de "talla única": Cuando un plato sale mal, los sistemas antiguos simplemente dicen: "Oh, está roto, inténtalo de nuevo", sin mirar cómo se rompió. ¿Se quemó la olla? ¿Olvidaron la sal? ¿Usaron la sartén equivocada? Todos estos necesitan arreglos diferentes, pero el sistema antiguo los trata a todos por igual.
El ganador equivocado: A veces, el plato correcto está de hecho sentado en la mesa entre la pila de 16, pero la multitud vota por el equivocado porque están mirando las cosas incorrectas (como el sabor frente a la lista de ingredientes).

La solución de SIRIUS-SQL: Un Maestro Chef y un Generalista
SIRIUS-SQL soluciona estos problemas con una estrategia de tres partes:

1. El "Especialista" y el "Generalista" (Solucionando la Cámara de Eco)

En lugar de pedirle a un solo robot que cocine 16 veces, utilizan dos chefs diferentes:

El Especialista (SIRIUS-32B): Este es un robot entrenado específicamente en cocina (SQL). Fue enseñado utilizando un "sistema de recompensa" especial (Aprendizaje por Refuerzo) donde solo recibe un premio si el plato realmente funciona. Aprende a crear muchas versiones diferentes del plato correcto, no solo el mismo error.
El Generalista: Este es un robot superinteligente y de propósito general (como un modelo de IA famoso) que es bueno entendiendo lenguaje complejo e instrucciones extrañas.
El Resultado: Al combinar el conocimiento profundo del Especialista con la comprensión amplia del Generalista, obtienen una variedad mucho mayor de intentos. Es como tener a un maestro chef de sushi y a un creativo chef francés trabajando juntos; tienes una mejor oportunidad de que uno de ellos logre la receta.

2. El sistema de la "Enfermera de Triaje" (Solucionando la Talla Única)

Cuando un plato sale mal, SIRIAS-SQL no solo dice "inténtalo de nuevo". Actúa como una enfermera de triaje en un hospital, diagnosticando exactamente qué salió mal:

Error de ejecución (La olla se quemó): El robot intentó usar una herramienta que no existe. El sistema corrige la sintaxis inmediatamente.
Tiempo de espera agotado (La estufa es demasiado lenta): La receta es demasiado complicada y tarda demasiado tiempo. El sistema reescribe la receta para que sea más eficiente sin cambiar el sabor.
Resultado vacío (La sartén está vacía): El robot siguió la receta perfectamente, pero el resultado fue vacío porque buscó el ingrediente equivocado. El sistema intenta arreglos "estructurales" específicos para encontrar el ingrediente correcto.

Solo después de que el robot intenta estos arreglos específicos, se le permite intentar de nuevo. Esto ahorra tiempo y evita que el sistema desperdicie esfuerzo en arreglos imposibles.

3. El "Juez Inteligente" (Solucionando el Ganador Equivocado)

Finalmente, cuando llega el momento de elegir el mejor plato de la pila, el sistema utiliza un proceso de votación de dos pasos:

Paso 1: La prueba de sabor: Observa los resultados reales. Si 10 platos saben igual, reciben una puntuación alta.
Paso 2: El desempate: Si dos grupos de platos tienen la misma puntuación de sabor, el sistema no adivina. Observa el plano (la estructura) de las recetas. Pregunta: "¿Varios chefs diferentes (el Especialista y el Generalista) llegaron de forma independiente al mismo plano?". Si es así, ese plano es probablemente el verdadero ganador.

Los Resultados
Al utilizar este equipo de "Especialista + Generalista", el sistema de reparación de la "Enfermera de Triaje" y el "Juez Inteligente", SIRIUS-SQL se convirtió en el mejor sistema en su trabajo.

En la prueba BIRD (una prueba difícil con datos reales desordenados), obtuvo un 75.88% de precisión, superando al sistema anterior más avanzado.
En la prueba SPIDER (una prueba estándar), obtuvo un 91.20% de precisión.

En resumen, SIRIUS-SQL deja de confiar en un solo robot adivinando 16 veces. En su lugar, utiliza un equipo de diferentes expertos, diagnostica errores específicos para arreglarlos adecuadamente y utiliza un sistema de votación inteligente de múltiples pasos para encontrar la única respuesta verdadera.

Resumen Técnico: SIRIUS-SQL

Planteamiento del Problema

Los sistemas de Text-to-SQL tienen dificultades con esquemas complejos en bases de datos del mundo real, donde la generación de un solo paso suele fallar debido a la heterogeneidad del esquema, las restricciones implícitas y las referencias de valores ambiguas. Aunque enfoques recientes mitigan esto generando múltiples candidatos de SQL y utilizando votación para filtrar errores, el artículo identifica tres debilidades estructurales acopladas en los procesos actuales de múltiples candidatos:

Muestreo de Rendimientos Decrecientes (L1): El muestreo de más candidatos desde un único generador produce salidas cada vez más redundantes porque la distribución del generador está fijada por su entrenamiento. Simplemente aumentar el presupuesto de muestreo ( $k$ ) no logra presentar nuevas hipótesis correctas fuera de la región preferida del generador.
Señal de Ejecución Desperdiciada (L2): Los procesos actuales aplican una estrategia de corrección única y genérica a todos los resultados de ejecución que no son limpios. Sin embargo, diferentes modos de fallo —errores de tiempo de ejecución (errores de sintaxis/tipos), tiempos de espera (planes ineficientes) y resultados vacíos (deriva semántica)— indican diferentes distancias hacia la corrección y requieren estrategias de reparación distintas.
Brecha de Votación-Oráculo (L3): Incluso cuando el SQL correcto existe dentro del conjunto de candidatos, la votación por mayoría suele fallar al seleccionarlo. Esto ocurre porque la selección requiere un juicio conjunto en dos espacios: el espacio de resultados (donde diferentes SQL pueden producir salidas idénticas) y el espacio lógico (donde la misma intención admite muchas formas superficiales). Los selectores existentes suelen operar en solo uno de estos espacios.

Metodología: SIRIUS-SQL

SIRIUS-SQL aborda estas limitaciones anclando cada etapa del proceso en la retroalimentación de la ejecución. El sistema consta de tres componentes principales:

1. Construcción de Candidatos Complementarios de la Fuente

Para superar los rendimientos decrecientes (L1), el sistema construye un conjunto inicial de candidatos a partir de dos fuentes complementarias:

Especialista ( $G_{sp}$ ): Un modelo especializado en la tarea (SIRIUS-32B) entrenado con Aprendizaje por Refuerzo con Recompensas de Ejecución Verificables (RLVR). El entrenamiento emplea una estrategia de síntesis de datos suavizada por dificultad para centrarse en instancias donde la política puede mejorar, y un cronograma DAPO de dos etapas con regularización de entropía controlada por umbral para evitar el colapso de la entropía mientras se mantienen candidatos diversos y ejecutables.
Generalista ( $G_{ge}$ ): Un LLM fuerte y comercial (ej. Qwen3-235B, Gemini-3.1) con prompts de demostración de pocos disparos (few-shot) para cubrir frases de cola larga y restricciones implícitas que el especialista podría omitir.
La unión de estas fuentes asegura que los candidatos expongan diferentes modos de fallo, reduciendo la correlación de errores.

2. Ciclo de Vida de Candidatos Basado en la Ejecución

En lugar de tratar la ejecución como una comprobación binaria final, el sistema utiliza los resultados de la ejecución para impulsar un bucle de reparación dinámico (L2):

Filtrado Pre-ejecución: Filtros deterministas basados en reglas eliminan SQL malformado (ej. errores de sintaxis, desajustes de esquema) antes de la ejecución para ahorrar presupuesto de reparación.
Diagnóstico y Tipado: Los candidatos supervivientes se ejecutan y se clasifican en cuatro categorías: limpio, error de tiempo de ejecución, tiempo de espera y resultado vacío.
Reparación Específica por Tipo:
- Errores de Tiempo de Ejecución: El texto de la excepción del motor se entrega de forma literal a un corrector.
- Tiempos de Espera: La reescritura preserva la intención pero reestructura los órdenes de unión (join) o las formas de las subconsultas para mejorar la eficiencia.
- Resultados Vacíos: Se utiliza un enfoque de dos etapas: primero, operadores estructurales de alta precisión (ej. re-vinculación de literales, ajuste de predicados) intentan la recuperación local; si esto falla, se activa un respaldo de LLM condicionado por el diagnóstico.
Consolidación del Conjunto: Los candidatos reparados son re-ejecutados y re-admitidos en el conjunto. Si el conjunto colapsa, un generador de recuperación utiliza retroalimentación negativa condensada para regenerar los candidatos.

3. Selección Híbrida con Control de Confianza

Para cerrar la brecha de votación-oráculo (L3), el sistema emplea un selector de dos etapas que combina señales de nivel de resultado y de nivel lógico:

Etapa 1 (Puntuador de Nivel de Resultado): Calcula una puntuación gruesa ( $S_{coarse}$ $S_{co a r se}$ ) sumando:
- Consenso a Nivel de Tupla ( $S_{maj}$ ): Frecuencia de triples de nivel de celda a través del conjunto de candidatos.
- Preferencia Pareada Desviada de Posición ( $S_{rm}$ ): Un juez LLM compara representantes de clases de equivalencia de firma de resultado para clasificar la calidad lógica.
Etapa 2 (Reclasificador de Soporte Estructural): Un mecanismo de control de confianza. Si los principales candidatos están empatados en todas las señales (margen bajo), un reclasificador determinista, libre de LLM, interviene. Analiza la firma estructural a nivel de AST (tablas, proyecciones, agregaciones) y selecciona el candidato respaldado por el mayor número de grupos de procedencia distintos (acuerdo entre generadores). Esto actúa como un desempate de coste cero.

Principales Contribuciones

Receta de RL Suavizada por Dificultad: Una metodología de entrenamiento para SIRIUS-32B que produce una distribución de candidatos amplia pero validada por recompensas, mitigando eficazmente los rendimientos decrecientes en el muestreo.
Ciclo de Vida Basado en la Ejecución: Un marco de reparación que clasifica los resultados de ejecución y aplica reparaciones específicas por tipo (tiempo de ejecución, tiempo de espera, vacío) antes de re-admitir candidatos, maximizando la utilidad de las señales de ejecución.
Selector Híbrido con Control de Confianza: Un mecanismo de selección que fusiona el consenso de tuplas con la preferencia de SQL pareada, escalando solo los casos ambiguos a un control estructural determinista, resolviendo así la brecha de votación-oráculo sin un coste computacional excesivo.

Resultados

SIRIUS-SQL alcanza el estado del arte en rendimiento en los bancos de pruebas estándar:

BIRD Dev: 75.88% de precisión de ejecución (usando SIRIUS-32B + Gemini-3.1 Pro), superando al sistema de múltiples candidatos publicado más fuerte, Agentar-Scale-SQL (74.90%), por 0.98 puntos porcentuales. También muestra ganancias significativas sobre las líneas base de un solo paso (ej. +11.54% sobre Qwen3-Coder).
SPIDER Test: 91.20% de precisión de ejecución, demostrando una fuerte generalización sin reajuste específico de la tarea.
Estudios de Ablación:
- La síntesis de datos suavizada por dificultad mejoró las recompensas de validación en 1.8 pp en BIRD y 0.5 pp en SPIDER durante el entrenamiento.
- La construcción de candidatos complementarios (Especialista + Generalista) superó el escalado de fuente única, demostando que los modos de fallo diversos son más valiosos que el simple recuento de muestras.
- El ciclo de vida específico por tipo superó a las estrategias de corrección unificadas por 0.13–0.71 pp.
- El selector híbrido (fusión + control) proporcionó una ganancia de 0.20 pp sobre los selectores de señal única, principalmente resolviendo empates de margen bajo.

Significancia

El artículo argumenta que el cuello de botella principal en el Text-to-SQL de múltiples candidatos no es la generación de más candidatos, sino la utilización sistemática insuficiente de las señales de ejecución a través del entrenamiento, la reparación y la selección. Al anclar todo el proceso en la retroalimentación de la ejecución —entrenando a un especialista para producir candidatos ejecutables diversos, reparando fallos basados en tipos de error específicos y seleccionando basándose en un híbrido de consenso de resultados y lógica estructural— SIRIUS-SQL demuestra que el refinamiento basado en la ejecución es un factor crítico para mejorar la fiabilidad en esquemas complejos. La capacidad del sistema para superar bases fuertes con dos de sus tres combinaciones de generalistas sugiere una arquitectura robusta y agnóstica al socio para aplicaciones de Text-to-SQL de alto nivel.