💬 NLP

Test-Time Verification for Text-to-SQL via Outcome Reward Models

Este artículo presenta GradeSQL, un marco que aprovecha los Modelos de Recompensa por Resultado (ORM, por sus siglas en inglés) como calificadores semánticos aprendidos para mejorar la fiabilidad de Text-to-SQL, demostrando que la verificación basada en ORM supera significativamente a los métodos heurísticos tradicionales como Best-of-N basado en ejecución y el Voto de Mayoría en los benchmarks BIRD y Spider.

Autores originales: Mattia Tritto, Giuseppe Farano, Dario Di Palma, Gaetano Rossiello, Fedelucio Narducci, Dharmashankar Subramanian, Tommaso Di Noia

Publicado 2026-07-01

📖 4 min de lectura☕ Lectura para el café

CC BY 4.0

Autores originales: Mattia Tritto, Giuseppe Farano, Dario Di Palma, Gaetano Rossiello, Fedelucio Narducci, Dharmashankar Subramanian, Tommaso Di Noia

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 le estás pidiendo a un chef muy inteligente, pero a veces demasiado confiado (la IA), que cocine un plato específico siguiendo una receta que tú describes en lenguaje sencillo. El chef sabe cocinar, pero a veces se equivoca con los ingredientes o confunde los pasos.

En el mundo de la informática, esto se llama Text-to-SQL: traducir una pregunta humana en una consulta de base de datos (un conjunto de instrucciones para una base de datos de computadora). El problema es que si el chef comete incluso un error minúsculo, la computadora podría darte la respuesta incorrecta, o no darte nada en absoluto.

La forma antigua: "Adivinar y comprobar"

Normalmente, cuando el chef no está seguro, el sistema le pide que cocine el plato 32 veces (generando 32 consultas SQL diferentes). Luego, tiene que elegir la mejor.

Los métodos antiguos para elegir al ganador son como estos:

Votación por mayoría: "¿Quién cocinó el plato con más frecuencia?" Si 20 chefs dicen "añadir sal" y 12 dicen "añadir azúcar", el sistema asume que "sal" es lo correcto. Pero, ¿y si la receta en realidad necesitaba azúcar y la mayoría cometió el mismo error?
Éxito de ejecución: "¿Quién logró que la sartén funcionara?" Si una consulta se ejecuta sin fallar, el sistema la elige. Pero una consulta puede ejecutarse perfectamente y aun así darte los datos incorrectos (como servir un pastel cuando pediste sopa).

Estos métodos dependen de pistas simples y superficiales (heurísticas) en lugar de entender realmente si el plato es correcto.

La nueva forma: El crítico gastronómico "GradeSQL"

Este artículo presenta un nuevo sistema llamado GradeSQL. En lugar de solo contar votos o comprobar si la sartén funciona, entrenan a un Crítico Gastronómico especializado (llamado Modelo de Recompensa de Resultado o ORM).

Así es como funciona el sistema GradeSQL, paso a paso:

1. La clase de cocina (Entrenamiento)
Primero, el sistema necesita enseñarle al Crítico qué es "bueno" y qué es "malo".

Toma una pregunta y le pide al chef principal (la IA) que cocine 32 versiones diferentes del plato.
Luego, ejecuta todos los 32 platos contra el "Estándar de Oro" (la respuesta correcta).
Si un plato sabe exactamente igual al Estándar de Oro, el Crítico le da una Puntuación Alta. Si sabe diferente, recibe una Puntuación Baja.
El Crítico aprende de estos ejemplos para reconocer el sabor de una consulta correcta, no solo si falló al ejecutarse.

2. La sesión de degustación (Inferencia)
Ahora, cuando un usuario real hace una pregunta:

El chef cocina 32 versiones nuevas.
En lugar de solo comprobar si funcionan, el Crítico los degusta todos.
El Crítico les da una puntuación a cada plato basada en qué tan bien coinciden con la intención de la pregunta.
El sistema elige el plato con la puntuación más alta.

¿Por qué es mejor?

El artículo probó esto en dos bases de datos gigantes de preguntas (llamadas BIRD y Spider). Encontraron que el Crítico fue mucho mejor para detectar la respuesta correcta que los métodos antiguos de "conteo de votos" o "si falló al ejecutarse".

La analogía: Imagina un examen de opción múltiple. El método antiguo elige la respuesta que aparece más veces o la que no tiene errores tipográficos. El nuevo método (GradeSQL) realmente lee la pregunta y la respuesta para ver si tienen sentido entre sí.
Los resultados: En preguntas difíciles, el Crítico ayudó al sistema a obtener la respuesta correcta aproximadamente un 4% más a menudo en el conjunto de datos BIRD y un 2% más a menudo en el conjunto de datos Spider. Aunque un 2-4% parezca poco, en el mundo de la IA, eso es una mejora enorme, especialmente para las preguntas más difíciles donde los métodos antiguos suelen rendirse.

Conclusiones clave

Es un juez "aprendido": El Crítico no solo sigue reglas; aprendió qué aspecto tiene una consulta SQL correcta practicando con miles de ejemplos.
No se necesita un humano: El sistema se enseñó a sí mismo cómo ser un crítico comprobando automáticamente qué respuestas funcionaban, por lo que ningún humano tuvo que calificar manualmente la tarea.
Es escalable: Cuantas más opciones (candidatos) genera el chef, mejor es el desempeño del Crítico. Los métodos antiguos se estancan y dejan de mejorar, pero el Crítico se vuelve más inteligente a medida que tiene más opciones para elegir.

En resumen, GradeSQL es como contratar a un crítico gastronómico profesional para elegir el mejor plato de un lote de 32, en lugar de simplemente preguntar a la multitud o comprobar si la estufa está encendida. Hace que la IA sea más confiable cuando las preguntas se vuelven complicadas.

Resumen Técnico: Verificación en Tiempo de Prueba para Text-to-SQL mediante Modelos de Recompensa de Resultado

Declaración del Problema

La fiabilidad de los Modelos de Lenguaje Extensos (LLMs) en tareas de razonamiento estructurado, específicamente en Text-to-SQL, sigue siendo un desafío crítico. Aunque los LLMs han avanzado significamente, a menudo tienen dificultades con consultas complejas que involucran uniones de múltiples tablas (multi-table joins), subconsultas anidadas y restricciones sutiles. Las estrategias actuales de inferencia en tiempo de prueba, como el muestreo Best-of-N (BoN) y la Votación por Mayoría, intentan mitigar esto generando múltiples consultas SQL candidatas y seleccionando la mejor. Sin embargo, estos métodos dependen de señales heurísticas —principalmente la ejecución exitosa (¿se ejecuta la consulta sin errores?) o la frecuencia de salida (¿varias consultas devuelven el mismo resultado?).

Los autores argumentan que estas heurísticas proporcionan solo aproximaciones gruesas de la corrección semántica. A medida que los conjuntos de candidatos crecen, estas señales suelen saturarse y fallan al discriminar entre consultas semánticamente válidas e inválidas, particularmente cuando múltiples consultas incorrectas se ejecutan con éxito pero devuelven resultados erróneos, o cuando consultas semánticamente equivalentes tienen estructuras sintácticas diferentes. Existe la necesidad de un mecanismo de verificación aprendido que pueda calificar a los candidatos basándose en la alineación semántica específica de la tarea en lugar de métricas de ejecución superficiales.

Metodología: El Marco de Trabajo GradeSQL

Para abordar la escasez de datos etiquetados requeridos para entrenar verificadores en tareas estructuradas, los autores introducen GradeSQL, un marco escalable para entrenar Modelos de Recompensa de Resultado (ORMs). A diferencia de los Modelos de Recompensa de Proceso (PRMs) que califican pasos intermedios, los ORMs asignan puntuaciones escalares a las salidas finales. El marco opera en tres etapas:

Generación de Candidatos: Dada una pregunta en lenguaje natural y un esquema de base de datos, un LLM generador produce un conjunto diverso de $N$ consultas SQL candidatas utilizando estrategias de decodificación estocástica. Esta diversidad es crucial para exponer al verificador a una amplia gama de formulaciones correctas y errores de proximidad.
Etiquetado de Datos Automatizado: En lugar de la anotación manual, el marco etiqueta los candidatos mediante equivalencia de ejecución. Cada candidato es ejecutado contra la base de datos. Si el conjunto de resultados coincide con el de la consulta de referencia (gold-standard) ( $R(c_j) = R(y_{gold})$ ), el candidato se etiqueta como "Correcto"; de lo contrario, se etiqueta como "Incorrecto". Las consultas que causan errores de ejecución son descartadas. Esto crea un conjunto de datos a gran escala, automáticamente etiquetado, para el entrenamiento del verificador.
Ajuste Fino Supervisado (SFT): Un LLM verificador es ajustado (usando LoRA) como un clasificador autorregresivo binario. La entrada consiste en el esquema, la pregunta y una consulta candidata, y el modelo es entrenado para predecir la probabilidad del token "Yes" (indicando corrección).

Pipeline de Inferencia: En el tiempo de prueba, el generador produce $N$ candidatos. El ORM entrenado califica cada candidato basándose en la probabilidad del token "Yes". Se selecciona el candidato con la puntuación más alta, reemplazando la selección heurística con una calificación semántica aprendida.

Contribuciones Clave

El artículo realiza tres contribuciones primarias:

Verificación basada en ORM para Text-to-SQL: El estudio adapta los Modelos de Recompensa de Resultado como calificadores semánticos aprendidos para la selección de candidatos en tiempo de prueba en la generación de consultas estructuradas, demostrando su aplicabilidad más allá de su uso tradicional en tareas de alineación y razonamiento.
Pipeline de Curación de Datos Escalable: Los autores proponen GradeSQL, un marco automatizado que genera y etiqueta consultas SQL candidatas mediante equivalencia de ejecución. Esto permite el entrenamiento de ORMs específicos de la tarea sin la necesidad de una costosa anotación manual.
Análisis Empírico de la Verificación en Tiempo de Prueba: Una evaluación sistemática a través de múltiples familias de LLMs de código abierto (incluyendo Qwen, Granite, Llama y OmniSQL) y benchmarks (BIRD y Spider) muestra que la selección basada en ORM supera consistentemente a las baselines heurísticas.

Resultados Experimentales

El enfoque fue evaluado en los benchmarks BIRD y Spider utilizando múltiples modelos generadores. Hallazgos clave incluyen:

Ganancias de Rendimiento: La selección basada en ORM logró consistentemente una mayor Exactitud de Ejecución (EX) que la Votación por Mayoría y el BoN basado en ejecución.
- En BIRD dev, el ORM logró un 68.90%, una ganancia de +5.01% sobre la baseline ( $N=1$ ) y superando a la Votación por Mayoría (+3.06%) y al BoN basado en ejecución (+2.15%).
- En Spider test, el ORM alcanzó un 87.47%, superando a la Votación por Mayoría (85.47%) y al BoN basado en ejecución (85.14%).
Escalabilidad con Conjuntos de Candidatos: A diferencia de los métodos heurísticos que se saturan tempranamente, el rendimiento del ORM continuó mejorando a medida que el tamaño del grupo de candidatos ( $N$ ) aumentaba, acercándose al límite superior oracle definido por Pass@N. Esto indica que los ORMs aprovechan eficazmente el aumento del cómputo en tiempo de prueba.
Robustez: El método mostró mejoras consistentes a través de diferentes familias de generadores y escalas de modelos. Los beneficios de la selección basada en ORM persistieron incluso al usar generadores más grandes (hasta 32B de parámetros).
Dinámicas de Entrenamiento:
- Desequilibrio de Datos: Aunque los conjuntos de datos generados estaban desequilibrados (por ejemplo, ~69% correctos en Spider), el entrenamiento en subconjuntos equilibrados (50/50) no degradó el rendimiento y, en algunos casos, lo mejoró mientras reducía los costos de entrenamiento.
- Tamaño del Modelo: Aumentar el tamaño del ORM más allá de los 7B de parámetros produjo mejoras marginales e inconsistentes, lo que sugiere que los ORMs ligeros ofrecen un equilibrio favorable entre rendimiento y eficiencia.
- Diseño de Prompts: Los prompts que exponen directamente la estructura SQL ("SQL-Only") produjeron los mejores resultados en comparación con los prompts de estilo instrucción o de solo datos.

Significado y Reivindicaciones

El artículo afirma que la verificación aprendida proporciona una alternativa simple, efectiva y escalable a las estrategias de selección heurística en tiempo de prueba para Text-to-SQL. La importancia de este trabajo radica en demostrar que:

El etiquetado basado en ejecución es suficiente para entrenar verificadores efectivos para tareas estructuradas, eliminando la barrera de la anotación manual.
La discriminación semántica es posible en el tiempo de inferencia sin modificar el generador y sin requerir interacción adicional con el entorno más allá de la generación inicial de candidatos.
Los ORMs son particularmente efectivos para consultas complejas donde las señales heurísticas fallan, ofreciendo una forma fundamentada de manejar la ambigüedad y la complejidad estructural inherente a Text-to-SQL.

Los autores mantienen un tono modesto, reconociendo que las ganancias absolutas son moderadas (2–5%) y que el enfoque depende de la equivalencia de ejecución como una aproximación para la corrección semántica, lo que puede no distinguir entre consultas semánticamente equivalentes pero sintácticamente diferentes o recompensar coincidencias espurias. El trabajo se centra en mejorar la selección de los candidatos más que la capacidad de generación en sí misma.