Show HN: Natural-SQL-7B, un potente modelo de texto a SQL
Un nuevo modelo de texto a SQL de 7B parámetros, Natural-SQL-7B, busca permitir que usuarios no técnicos consulten bases de datos en lenguaje natural mientras se ejecuta localmente, lo que genera expectativas de analítica más barata y privada que las soluciones basadas en GPT‑4. Los comentaristas cuestionan su licencia personalizada “source available”, su enfoque actual en PostgreSQL y si una precisión de ~75% es suficiente para uso en producción, especialmente cuando la lógica de negocio y los KPI son sutiles o específicos del dominio. Muchos ven valor en usar estos modelos como herramientas de redacción o combinados con capas semánticas, RAG y una fuerte gobernanza de datos, más que como sustitutos autónomos de analistas expertos.
Capacidades y alcance del modelo
- Modelo de texto a SQL de 7B, afinado con ~20k pares sintéticos PostgreSQL texto→SQL en distintas categorías de SQL y tipos de preguntas.
- Evaluado en ~76.5% en SQL-Eval, ligeramente por debajo de GPT‑4 y sqlcoder‑15B.
- Actualmente centrado en Postgres; se desea y en parte se planea un soporte más amplio de dialectos (MySQL, DuckDB, MSSQL, BigQuery, Trino).
- Maneja consultas con múltiples joins, agregaciones y subconsultas que son “difíciles” para usuarios no técnicos, pero no está garantizado en esquemas muy complejos o consultas con mucha lógica de negocio.
Licencia y debate sobre “open source”
- La licencia incluye restricciones de uso (por ejemplo, no militar), heredadas del modelo base.
- Varios comentaristas argumentan que esto no es “open source”, sino “source/weights available”.
- Preocupa que las licencias no estándar obliguen a revisiones legales frente a las conocidas MIT/Apache/GPL.
- Algunos también señalan que solo se proporcionan los pesos del modelo, no el código ni los datos de entrenamiento.
Casos de uso, precisión y fiabilidad
- Se ve como útil para:
- Redactar SQL para desarrolladores/analistas que puedan revisarlo y corregirlo.
- Impulsar herramientas locales/cli donde los esquemas no deban enviarse a LLMs en la nube.
- Los escépticos cuestionan qué se puede automatizar de forma segura con ~75% de acierto, especialmente en analítica crítica para el negocio y KPIs.
- Otros señalan que los humanos también cometen errores; el valor está en acelerar pasos “simples”, con personas validando los resultados.
- Ideas planteadas: ensembles/consenso, validación mediante restricciones fuertes de la base de datos, usarlo sobre todo donde la corrección sea fácil de comprobar.
Esquema, longitud de contexto y semántica
- Un contexto de 4k es demasiado pequeño para muchos esquemas reales; se comenta usar RAG sobre DDL o querer 32k+ de contexto.
- Patrón típico: pasar el CREATE TABLE DDL (con comentarios) como prompt; algunos usan RAG sobre documentación/wiki/dbt para enseñar semántica.
- Varios sostienen que el problema real no es la sintaxis SQL, sino entender el significado de los datos (“¿qué significa realmente este campo ‘price’ o ‘active’?”).
- Fuerte apoyo a capas semánticas / grafos de conocimiento / ORMs que codifiquen la lógica de negocio, con SQL generado de forma determinista desde esa capa en lugar de directamente por LLMs.
Nube vs local, privacidad y confianza
- Algunos se niegan a enviar esquemas o datos a OpenAI, citando cambios de términos, preocupaciones regulatorias o posible acceso gubernamental.
- Azure OpenAI se percibe por algunos como más seguro, pero rezagado en funciones/modelos.
- La configuración local y con pesos disponibles de este modelo resulta atractiva para quienes tienen restricciones de privacidad o gobernanza.
Reflexiones más amplias sobre SQL y herramientas
- Debate sobre aprender SQL frente a depender de ORMs o LLMs; muchos enfatizan el valor duradero de SQL y sus beneficios de rendimiento.
- Otros destacan los problemas de ergonomía de SQL y prefieren abstracciones.
- Varios señalan que los LLM ya son útiles para explicar SQL complejo, depurar errores y generar consultas complicadas con ventanas/percentiles.