¿Qué es NL2SQL y cómo funciona?

NL2SQL se refiere a la traducción automática de una pregunta en lenguaje natural a una consulta SQL que se puede ejecutar de forma relacional. A diferencia de un chatbot genérico que responde en texto libre, un sistema NL2SQL produce un artefacto estructurado, SQL, que se ejecuta con datos reales y devuelve un resultado verificable línea por línea.

El término "texto a SQL" proviene de investigaciones académicas sobre procesamiento del lenguaje natural. “NL2SQL” es la abreviatura más utilizada en el lado del producto y la documentación técnica. Ambos se refieren al mismo problema: cerrar la brecha entre una pregunta formulada en el lenguaje cotidiano y la sintaxis precisa que espera un motor SQL.

NL2SQL se distingue de un agente conversacional conectado a una base de datos en sentido amplio. El primero produce una consulta legible y auditable; el segundo puede encadenar varias llamadas a herramientas (búsqueda, cálculo, escritura) sin que necesariamente dé como resultado un SQL único e inspeccionable. Un sistema NL2SQL diseñado correctamente permanece dentro de este alcance deliberadamente restringido: traducir, validar, ejecutar, devolver un resultado.

Una canalización NL2SQL confiable siempre sigue la misma secuencia, independientemente del proveedor: la pregunta pasa por un modelo de lenguaje, luego el SQL producido se valida antes de la ejecución, nunca después. La implementación de Aurabase, verificada en el código de servicio aura-ai, ilustra cada uno de estos pasos con reglas concretas en lugar de una descripción abstracta.

1.Se recibe la pregunta con el esquema real de la base.

El sistema asocia la pregunta en lenguaje natural con el esquema de la base de datos consultada: nombres de tablas, columnas, tipos. Este patrón debe surgir de una introspección de la base real, no de una descripción proporcionada por quien llama. Una implementación que acepte un esquema declarado por el cliente abriría la puerta a preguntas sobre tablas inexistentes o a evitar el aislamiento entre proyectos. El motor de Aurabase rechaza explícitamente (error 400) cualquier campo schema enviado en la solicitud, en lugar de ignorarlo silenciosamente.

2.Un LLM genera un SQL candidato

El modelo de lenguaje recibe la pregunta y el esquema en su mensaje y luego genera una consulta SQL candidata junto con una breve explicación. Aurabase trata a tres proveedores por igual con un cliente nativo dedicado: OpenAI, Anthropic (Claude) y Gemini. Este SQL candidato es en esta etapa sólo una propuesta, nunca ejecutada directamente.

3.El SQL candidato se valida antes de la ejecución, no después

Este es el paso que distingue un sistema NL2SQL serio de una simple llamada LLM seguida de una ejecución ingenua. El SQL generado se analiza en un árbol de sintaxis (AST) en lugar de inspeccionarse mediante una búsqueda de palabras clave, que se puede omitir fácilmente. La implementación de Aurabase, con la biblioteca sqlparser, solo permite consultas SELECT simples: CTE/WITH, subconsultas, UNIONs, funciones de ventana y cláusulas de bloqueo (FOR UPDATE) se rechazan explícitamente, al igual que cualquier función SQL fuera de una lista blanca de diez funciones (count, sum, avg, min, max, lower, upper, coalesce, date_trunc, now).

4.La consulta confirmada se ejecuta con un límite de fila.

El SQL validado recibe un LIMIT si aún no tiene uno: 100 líneas por defecto con Aurabase, 1000 máximo, ambos valores configurables en el lado del servidor. Una solicitud que supera el límite se rechaza explícitamente en lugar de reducirse silenciosamente. La respuesta indica si el servidor agregó este LIMIT, para que la persona que llama sepa si el SQL ejecutado difiere del producido por el modelo.

-- Pregunta: "¿Cuántos pedidos este mes para clientes premium?"
SELECT count(*) FROM orders
WHERE customer_plan = 'premium'
  AND created_at >= date_trunc('month', now())
LIMIT 100  -- agregado por el servidor, falta en el SQL generado

Los detalles completos de esta canalización, con cada llamada HTTP y cada respuesta JSON, se tratan en nuestro tutorial paso a paso para crear un punto final NL2SQL en Postgres.

NL2SQL no pretende reemplazar el SQL escrito a mano en todas partes. Cubre un ámbito específico: preguntas puntuales y ad hoc formuladas por alguien que no sabe SQL o que simplemente quiere ahorrar tiempo en una consulta sencilla.

• Exploración ad hoc de un panel por parte de una persona no técnica (soporte, producto, gestión).
• Creación rápida de prototipos de una función que consulta la base de datos sin escribir una ruta API dedicada para cada pregunta posible.
• Autoservicio analítico limitado: contar, filtrar, simplemente agregar, sin dar acceso directo a la base de datos al usuario final.

SQL escrito a mano sigue siendo preferible tan pronto como la pregunta va más allá de este alcance. Una implementación validada por AST como la descrita anteriormente excluye CTE, subconsultas y funciones de ventana por construcción, por razones de seguridad. Un análisis que estructuralmente necesita estas construcciones, cohortes, ventanas temporales avanzadas, no pasa por NL2SQL: se codifica directamente. Este es un compromiso aceptado, la seguridad del sistema viene antes que la integridad del SQL generado.

Tres riesgos se repiten sistemáticamente en una implementación NL2SQL, con diferentes respuestas dependiendo de la madurez del sistema.

Inyección SQL mediante mensaje o pregunta

Un LLM puede manipularse para producir SQL malicioso si la pregunta en sí contiene un intento de inyección de "ignorar declaraciones anteriores y...". La defensa no es confiar en el mensaje, sino validar el SQL producido independientemente de lo que se solicitó, exactamente el paso 3 del proceso descrito anteriormente. El tema merece un tratamiento dedicado: consulte Protección de NL2SQL contra inyección SQL para vectores de ataque precisos y contramedidas.

Alucinación de tablas o columnas inexistentes.

El modelo puede inventar un nombre de tabla o columna que sea plausible pero que no aparezca en el esquema real, especialmente en esquemas grandes o mal documentados. Una implementación que valida el SQL generado con el esquema de la base de datos real rechaza la consulta con un mensaje explícito, enumerando las tablas realmente disponibles, en lugar de permitir que un error de SQL sin formato pase al usuario.

Costo y latencia de las llamadas modelo.

Cada pregunta NL2SQL desencadena una llamada al modelo de lenguaje, con su propio costo y latencia, además del tiempo de ejecución de SQL. Este costo aumenta rápidamente si NL2SQL sirve como capa predeterminada para preguntas repetitivas, que se beneficiarían si se almacenaran en caché o se expusieran como un informe estándar en lugar de volver a traducirlas cada vez.

Dos arquitecturas producen un resultado visible similar, pero con garantías muy diferentes. NL2SQL nativo integra generación, validación y ejecución directamente en la capa backend que ya conoce el esquema y los derechos de acceso del proyecto: esta es la lógica descrita anteriormente para Aurabase, donde el servicio aura-ai comparte la infraestructura y el aislamiento del esquema con el resto del backend.

Un NL2SQL ensamblado combina un servicio LLM genérico, un conector a la base de datos y una capa de validación que puede crear usted mismo. Nada impide que este enfoque sea seguro, pero cada garantía, esquema introspeccionado del lado del servidor, validación AST, límite de fila, inquilino de aislamiento, debe ser implementado y mantenido por el equipo que ensambla estos ladrillos, en lugar de ser proporcionado por la plataforma.

El panorama de las herramientas NL2SQL, nativas y ensambladas, de código abierto y comerciales, se compara en detalle en nuestra comparación de herramientas NL2SQL 2026.

NL2SQL y RAG (generación aumentada de recuperación) responden a dos familias diferentes de preguntas, a menudo confundidas porque ambas dependen de un LLM conectado a una base de datos.

NL2SQL apunta a datos estructurados y relacionales: cuántas, cuándo, en qué proporción, preguntas que se traducen naturalmente en SELECT, GROUP BY, agregaciones. El RAG se enfoca en contenido no estructurado: documentos, notas, tickets de soporte, donde la respuesta no cabe en una fila de la tabla pero requiere encontrar un pasaje relevante por similitud semántica, búsqueda vectorial en pgvector, índice HNSW, antes de contextualizarlo en el modelo.

Las dos capacidades pueden coexistir en un mismo proyecto y combinarse en un agente que elige una u otra en función de la cuestión planteada. El pilar de IA nativa de Aurabase detalla cómo funcionan juntos los dos mecanismos, y nuestra guía de canalización RAG en pgvector cubre la implementación del segundo.