Benchmark SQL para LLMs: ¿Cuál es el mejor?

Un nuevo benchmark interactivo creado por Nick Lothian mide cuán bien generan SQL los LLMs pequeños en menos de 5 minutos, usando un loop agentico que detecta errores y permite que el modelo se corrija a sí mismo. A diferencia de benchmarks saturados que tardan horas, este prueba 25 preguntas en una base de datos real (AdventureWorks) y logra separar consistentemente incluso los modelos más fuertes.

Qué es el LLM SQL Benchmark

El LLM SQL Benchmark es una herramienta interactiva que evalúa qué tan bien un modelo de lenguaje puede transformar preguntas en lenguaje natural en consultas SQL funcionales. No es un test de memorización: toma una pregunta (“¿Cuál es el total de ventas por región?”), el modelo genera SQL, y acá viene lo importante — la herramienta ejecuta esa query contra datos reales en DuckDB, ve si el resultado es correcto, y si no, le devuelve el error al modelo para que se corrija.

Lo que lo diferencia es la velocidad. Ponele que tenés 30 modelos para testear. En benchmarks viejos (BIRD, Spider), te llevaba 2-3 horas esperar resultados. Acá, con 25 preguntas, terminás en menos de 5 minutos. No estamos hablando de que sea más rápido nada más — es que esa velocidad te permite iterar. Probás un modelo, ves que falla en JOINs, buscás otro modelo, lo probás de nuevo.

Por qué importa la velocidad en benchmarks de SQL

Suena al revés, pero benchmarks lento son el problema de hoy. Durante años fueron útiles: BIRD (247 bases de datos con queries reales de BI) y Spider (200+ esquemas) establecieron estándares. Pero los mejores modelos ya andan en el 95-98% de accuracy. A eso se le llama “saturación del benchmark” — cuando todos rajan bien, no podés diferenciar quién es mejor.

Además, la realidad operacional es distinta. Vos no necesitás un modelo que hable SQL a nivel BIRD. Necesitás un modelo que funcione en tu stack local — Ollama en una máquina sin GPU, llama.cpp en un servidor de bajo costo, o un modelo de 7B que quepas en VRAM limitada. Para eso, no te sirve “mejor en benchmark global”. Te sirve un test rápido que te diga: “este modelo falla en subconsultas, pero bien en agregaciones”.

Con un benchmark que tarda 5 minutos, podés testear 10 modelos en una hora. Con uno que tarda 2 horas, probás 1. La diferencia operacional es enorme. Si estás buildiendo una herramienta de análisis de datos sin código que corra local en la máquina del cliente, testear 10 opciones te da confianza de que elegiste bien. Testear 1 te deja dudando.

Arquitectura técnica: cómo funciona el loop agentico

Acá es donde el benchmark se separa del resto. Un test normal es: pregunta → modelo genera SQL → ¿es correcto? Fin. Si está mal, fracasa.

Este usa un loop agentico. Es decir: pregunta → modelo genera SQL → se ejecuta contra DuckDB → se valida el resultado contra la respuesta correcta → ¿es igual? → sí: devuelve resultado. No: le muestra el error al modelo, modelo intenta de nuevo. Tema relacionado: aspectos de privacidad en datos.

Eso requiere tres cosas: (1) un generador de SQL (el LLM), (2) un motor que ejecute SQL contra datos reales (DuckDB, PostgreSQL, lo que tengas), (3) un validador que compare el resultado actual con el esperado. Si alguno falla, el agente falla. Los errores típicos que detecta: JOINs incompletos (olvidas la tabla RIGHT), agregaciones mal (GROUP BY sin los campos correctos), WHERE clauses que filtran de más, HAVING sin GROUP BY. El dataset es AdventureWorks — nada exótico, el mismo que Microsoft usa para entrenar personas, así que los modelos no lo tienen memorizado.

Todo corre en el navegador gracias a DuckDB-WASM. Mandás un endpoint de LLM (OpenRouter, tu local Ollama, lo que sea), clave opcional, y la misma lógica TypeScript que corre en la línea de comandos se ejecuta en el browser. Eso significa: datos nunca dejan tu máquina, todo transparente.

Otros benchmarks principales: cuándo usar cada uno

Antes de decidir si este benchmark te sirve, conviene saber qué hace cada uno:

¿Qué significa esto? Si estás en una universidad publicando un paper sobre generación de SQL, usás BIRD o Spider. Si estás eligiendo un modelo de 7B para tu app local de análisis de datos, probás este benchmark 10 veces hasta encontrar el que ceda menos.

Modelos pequeños que realmente funcionan en SQL

La pregunta del millón es: ¿cuál recomendás? Acá están los contendientes serios en 2026.

DuckDB-NSQL-7B: Entrenadísimo específicamente en texto a SQL con 200K queries sintéticas. Viene de Narwhal (la abstracción de duckdb-python). Es gratuito, pesa 7B, y corrés en Ollama sin drama. Ojo: las queries son sobre DuckDB, así que la sintaxis es DuckDB-specific (no es SQL puro). Si tu base es PostgreSQL, probá primero.

Snowflake Arctic-Text2SQL-R1 7B: Lanzado por Snowflake a principios de 2025, fue entrenado con reasoning explícito (R1 = reasoning). Anda en 7B, y según el paper de Snowflake rinde bien incluso en queries complejas con múltiples tablas. Snowflake metió plata seria acá.

Prem-1B-SQL: Un modelo de solo 1B parámetros que genera SQL funcional. Sí, 1B — cabe en una Raspberry Pi. No va a ganar benchmarks complejos, pero si tu problema es “usuario me pide un reporte simple de ventas del mes”, con 1B sacas jugo.

¿El error que comete casi todo el mundo? Asumir que los modelos grandes son “mejor”. Claude o GPT-4 van a fallar en SQL también. El tema es otro: ¿cuál cuesta menos y funciona lo suficientemente bien para mi caso? Más contexto en herramientas de IA con GPU.

Agentes agenticos: por qué SQL necesita validación

Acá viene la parte que cambia el juego. Un LLM solo genera SQL. Un agente agentico lo valida, ejecuta, chequea resultados, y corrige.

¿Por qué importa? SQL es una de las pocas tareas donde la verdad es objetiva. “¿Generaste SQL correcto?” tiene una respuesta sí/no de 0-1. El modelo genera una query, la ejecutás contra datos reales, y si devuelve filas que el usuario no esperaba, falló. Con un loop agentico, el modelo ve ese fallo y lo intenta de nuevo.

El flujo es: pregunta natural → modelo genera SQL → ejecuta contra datos → valida resultado contra respuesta esperada → ¿es igual? → sí: devuelve resultado. No: le muestra el error al modelo, modelo intenta de nuevo.

Eso requiere tres cosas: (1) un generador de SQL (el LLM), (2) un motor que ejecute SQL contra datos reales (DuckDB, PostgreSQL, lo que tengas), (3) un validador que compare el resultado actual con el esperado. Si alguno falla, el agente falla.

Casos de uso reales: herramientas de análisis auto-hosted

¿Dónde usarías esto? Stack típico de 2026 para una herramienta de análisis sin código privada:

Streamlit o FastAPI en el frontend. LLM local (Ollama corriendo un modelo de 7B) en el backend. Base de datos que podría ser DuckDB (para datos en archivo), PostgreSQL (para datos empresariales), o Snowflake con tablas de staging. El usuario escribe “dame el top 10 de productos por ingresos este mes”, el agente traduce a SQL, lo ejecuta, valida y devuelve la tabla. Te puede servir nuestra cobertura de plataformas principales en desarrollo.

Las ventajas vs usar una API externa tipo OpenRouter: cero latencia de red (localhost), cero envío de datos sensibles a servidores ajenos, costo bajo (una sola máquina, sin API calls), control total sobre el modelo y el comportamiento. El tradeoff: la máquina tiene que tener suficiente VRAM y GPU. Con una RTX 3060 de 12GB sacás modelos de 7B sin drama.

¿Otro caso? Asistentes de datos internos en equipos de analytics. Alguien en el equipo no sabe SQL, pero necesita respuestas de datos rápido. En vez de abrir DBeaver y escribir queries, abre un chat, pregunta naturalmente, y el agente lo hace. Los datos nunca salen de los servidores internos.

Errores comunes con LLMs y SQL

Error 1: Asumir que “mejor en lenguaje” = “mejor en SQL”. Un modelo que te arma un essay genial puede ser un desastre generando SQL. La razón es que SQL requiere precisión determinística — cada carácter importa. Un typo en un nombre de columna hace que falle todo. Los modelos que andan bien en SQL fueron entrenados específicamente con queries reales o sintéticas.

Error 2: No validar las queries contra datos reales. El benchmark interactivo te muestra esto. Si generás SQL sin ejecutarlo primero, no sabés si funciona. “Se ve que está bien” no es suficiente. Necesitás el loop agentico.

Error 3: Esperar un modelo perfecto. No existe. Incluso Arctic-Text2SQL de Snowflake no acierta el 100%. Algunos tipos de queries son más difíciles (subconsultas anidadas, UNION ALL con múltiples tablas). Para esos casos, o mejorás el prompt, o escalás a un modelo más grande, o ajustás el loop agentico para reintentar.

Preguntas Frecuentes

¿Puedo correr el benchmark localmente sin internet?

Sí. Es código TypeScript abierto que ejecuta en DuckDB-WASM. Cloná el repositorio, instalá las dependencias (npm install), y corrés en local. El endpoint del LLM sí necesita estar disponible — si usás Ollama local, cero internet requerido. Si mandás requests a OpenRouter, necesitás conexión. Complementá con despliegue automatizado con containers.

¿Cuál es el mejor modelo para generar SQL?

Depende de tu constraint. Si querés lo mejor sin importar costo ni latencia, Claude 3.5 Sonnet o GPT-4 turbo. Si necesitás local con bajo costo, DuckDB-NSQL-7B o Arctic-Text2SQL-R1 7B. Si necesitás ultra-compacto (Raspberry Pi, IoT), Prem-1B-SQL. El benchmark te dice exactamente cómo rinde cada uno en tu caso específico.

¿Funciona con bases de datos que no son DuckDB?

El benchmark está armado para DuckDB porque corre en el navegador (WASM), pero el concepto aplica a cualquier base. Si querés validar un modelo contra PostgreSQL, MySQL o Snowflake, necesitás adaptar el validador — en vez de ejecutar SQL en WASM, ejecutás en tu servidor y comparás resultados. El loop agentico es el mismo.

¿Cuánto tarda en total evaluar 10 modelos?

Menos de 1 hora. Con este benchmark de 5 minutos por modelo, evalúas 10 en 50 minutos (con descansos de conexión). Con benchmarks antiguos, llevaba 20+ horas. Por eso es game-changer para iteración rápida.

¿Detecta todas las clases de errores en SQL?

Detecta errores funcionales — queries que devuelven resultados incorrectos o no devuelven nada. No detecta ineficiencia (una query que es correcta pero lenta). Para eso necesitarías otro tipo de análisis (explicación de planes, índices, estadísticas). El benchmark es para “¿genera SQL que funciona?”, no “¿genera SQL rápido?”.

Conclusión

El LLM SQL Benchmark cambia el juego para quienes estamos construyendo herramientas de análisis de datos locales o privadas. No es que sea el benchmark definitivo — BIRD y Spider siguen siendo valiosos para investigación. Pero para la realidad operacional de 2026, donde necesitás elegir un modelo de 7B que funcione en tu máquina en menos de 5 minutos, esto es exactamente lo que faltaba.

La velocidad es el feature. Permitirte iterar entre 10 modelos en una tarde, en vez de esperar 20 horas por benchmark. El loop agentico es el destino — las herramientas van a funcionar así, validando SQL contra datos reales, corrigiendo automáticamente. Si estás evaluando modelos hoy, probá este benchmark. Vas a ver más claro qué cede y qué no.

Fuentes

• LLM SQL Benchmark interactivo — benchmark de 25 preguntas en el navegador, <5 minutos
• LiveSQLBench — benchmark limpio sin contamination de datos
• BIRD: A Big-Bench for Large-Scale Database Grounding — 247 bases de datos con queries BI reales
• Snowflake Arctic-Text2SQL-R1 — modelo 7B especializado en generación de SQL
• Prem-1B-SQL: Local SQL Generation — modelo ultra-compacto de 1B parámetros