Por qué los «récords» en Text-to-SQL son engañosos
Cada mes aparecen nuevas afirmaciones de que alguna LLM casi ha igualado a los humanos en los benchmarks de SQL. Pero si se mira de cerca, detrás de estas cifras se esconden condiciones muy diferentes: algunos usan un prompt simple sin acceso a la base de datos, otros permiten que el modelo ejecute consultas de forma iterativa, y otros han integrado el razonamiento directamente en los pesos del modelo. Comparar estos resultados directamente es como poner lado a lado un automóvil con un mecánico y un vehículo autónomo que se repara a sí mismo mientras conduce.
Los autores de un reciente preprint en arXiv (2608.15389) han llamado la atención precisamente sobre este problema. Proponen dejar de medir el «progreso» por la altura abstracta en una tabla de clasificación y, en cambio, registrar primero honestamente cuánta autonomía tenía el sistema al generar SQL. Sin esta salvedad, cualquier comparación entre trabajos resulta inestable: un cambio en el benchmark, en el modelo base o incluso en un protocolo de inferencia ligeramente diferente puede alterar las conclusiones.
El eje de la autonomía: de los prompts a los agentes autosuficientes
En lugar de simplemente reunir todas las cifras en una sola tabla, los investigadores redefinen el propio campo de Text-to-SQL como una «agregación de leaderboard». Recopilan métricas que los autores de los sistemas reportan por sí mismos y las distribuyen a lo largo del eje de autonomía de la inferencia. El resultado son cinco niveles:
- Constrained generation — el modelo solo elige una respuesta de un espacio de consultas permitidas estrictamente limitado, a menudo con verificación externa de sintaxis.
- In-context generation — el SQL se construye en una sola pasada sobre el contexto con ejemplos y la descripción del esquema.
- Iterative generation — el sistema puede hacer varios intentos, refinando la consulta según los resultados de la ejecución o la respuesta de la base de datos.
- Agentic generation — el modelo actúa como un agente: explora el esquema de la base de datos por sí mismo, ejecuta consultas, reacciona a los errores y planifica los siguientes pasos.
- Reasoning-internalized generation — el «razonamiento» está integrado previamente en el modelo, por lo que en la inferencia genera la consulta directamente, sin orquestaciones externas ni pasos intermedios.
Esta escala no implica que un nivel sea «mejor» que otro. Solo fija las condiciones para una comparación justa: un sistema con razonamiento interno no puede enfrentarse en igualdad de condiciones a una salida single-shot sin razonamiento, del mismo modo que un circuito agéntico con derecho a ejecutar consultas no debe compararse con un modelo al que no se le ha otorgado ese derecho.
Es importante que para cada celda de este leaderboard se conserve la procedencia trazable de la métrica. Esto significa que el lector siempre puede entender qué configuración exacta produjo el resultado, en lugar de intentar adivinarlo a partir de fragmentos de la sección experimental.
Qué mostró el experimento en Spider y más allá
Para vincular la agregación de métricas con la realidad, los autores llevaron a cabo un estudio específico en el benchmark Spider. Compararon modelos abiertos de 8B —con y sin supervisión CoT— contra líneas base few-shot basadas en DeepSeek V3 y GLM-4. Es interesante que se usaron protocolos few-shot, no versiones completamente fine-tuned, por lo que la comparación resultó bastante limpia.
Del experimento se extraen cuatro patrones importantes para los profesionales.
En primer lugar, las mejoras obtenidas en Spider se transfieren de manera desigual a BIRD y Spider 2.0. Un modelo puede mostrar un aumento notable en un conjunto de consultas y apenas moverse en otro. Esto confirma una vez más que la búsqueda ciega de una puntuación única en un benchmark popular crea la ilusión de un progreso general.
En segundo lugar, la autonomía añade robustez, pero a un costo no trivial. Los circuitos agénticos realmente manejan mejor las tareas de múltiples pasos y ambiguas; sin embargo, los costos de tokens y el tiempo de ejecución aumentan considerablemente. Si para un analista interactivo este costo está justificado, para el procesamiento por lotes puede consumir toda la ventaja de tener errores menos frecuentes.
En tercer lugar, el modo reasoning internalized ocupa una posición intermedia inesperada. Se sitúa entre la decodificación «simple» de la respuesta sin razonamiento y los agentes orquestados externamente. Para varias tareas, este modo ofrece una calidad casi de agente, pero sin la necesidad de construir un circuito complejo con herramientas. Aunque no hay un «almuerzo gratis» universal: el razonamiento integrado también tiene sus limitaciones.
En cuarto lugar, las ganancias de la supervisión CoT se concentran en las consultas de niveles Hard y Extra-Hard. En preguntas simples, la diferencia es casi imperceptible o incluso negativa: ¿para qué razonar en voz alta cuando la respuesta es evidente? Pero en tareas complejas de múltiples pasos, la capacidad de verbalizar los pasos ofrece una ventaja notable. Esta es una señal importante para quienes construyen asistentes SQL: hay que centrar la potencia computacional adicional en las consultas de alta complejidad, no gastarla en casos simples típicos.
Cómo usar esta escala en la práctica
La consecuencia más útil del trabajo no es ni siquiera la taxonomía en sí, sino el harness público de Python que los autores publicaron junto con el preprint. El harness reproduce el eje de autonomía y permite añadir nuevos métodos al leaderboard sin reescribir todo el entorno. Si estás desarrollando otro enfoque de Text-to-SQL, basta con indicar en qué nivel de autonomía opera —y la comunidad podrá compararte con los sistemas anteriores en igualdad de condiciones.
Es evidente que las agregaciones basadas en métricas auto-reportadas deben tratarse con cautela. No todos tienen el presupuesto para repetir experimentos ajenos, pero una anotación unificada ya es un gran paso adelante. Por ahora, al leer el último «state-of-the-art», ten en mente una pregunta simple: ¿qué podía hacer exactamente el modelo durante la generación de la consulta? Si la respuesta a esta pregunta no aparece, entonces la cifra del artículo es solo un número bonito sin una base sólida.
