AWS muestra Text-to-SQL en Amazon Bedrock para traducir preguntas de negocio a SQL

AWS publicó un desglose detallado de una solución Text-to-SQL en Amazon Bedrock, que traduce preguntas de negocio en lenguaje natural a consultas SQL y devuelve inmediatamente la respuesta de forma comprensible. Este no es un nuevo producto separado, sino una arquitectura práctica para empresas que tienen datos pero aún carecen de respuestas rápidas a preguntas comerciales.

Por Qué el BI Se Queda Corto

AWS explica el problema de manera simple: incluso en empresas con análisis sólido, los usuarios siguen enfrentándose a un cuello de botella esperando analistas o lidian con las limitaciones de los dashboards preestructurados. Si una pregunta va más allá de un informe prearmado, necesitas joins, cortes de tiempo, métricas calculadas y conocimiento de la lógica interna de las tablas. Para ventas, finanzas u operaciones, esto significa perder horas o incluso días en una consulta única que no justifica un desarrollo separado por sí sola.

Según AWS, aquí es donde el BI de autoservicio estándar comienza a flojear. El lenguaje natural en interfaces de BI funciona bien con capas semánticas prepreparadas, pero tiene dificultades con tablas sin procesar, terminología interna y métricas que se calculan de manera diferente en cada empresa. Por eso AWS propone construir no solo un generador de SQL, sino un sistema que comprenda el contexto empresarial: qué es el ingreso, cómo se calcula el pipeline y qué tablas se pueden unir.

Cómo Funciona el Pipeline

En el núcleo de la arquitectura se encuentra Amazon Bedrock como capa de inferencia y orquestación, más un grafo de conocimiento para contexto empresarial y un almacén analítico para ejecución de consultas. El AgentCore Runtime juega un papel central: recibe la pregunta, decide si necesita desglosarse en subtareas, llama a la búsqueda de contexto, activa la generación de SQL y devuelve la respuesta final. Para las empresas, esto es importante porque la lógica no está codificada en un único prompt: puede desglosarse en pasos separados y controlarse en cada etapa.

• clasificación de la pregunta como simple o compleja
• búsqueda de contexto empresarial a través de GraphRAG
• generación de SQL en formato estructurado
• validación determinística de la consulta antes de la ejecución
• síntesis de la respuesta en lenguaje natural basada en resultados de la consulta

Para el contexto, AWS utiliza una combinación de Amazon Neptune y OpenSearch: el grafo almacena relaciones entre tablas, columnas, métricas, términos e jerarquías dentro de la empresa. Luego, el sistema realiza una búsqueda vectorial en descripciones y valores, atraviesa relaciones del grafo y proporciona al modelo solo tablas, campos, rutas de join y reglas empresariales relevantes. Para preguntas complejas, la arquitectura puede ejecutar múltiples agentes en paralelo y seleccionar el resultado más confiable por votación mayoritaria.

Producción y Control

La parte más práctica del post no es sobre LLM, sino sobre capas de protección. AWS enfatiza específicamente que los prompts por sí solos no pueden captar de manera confiable SQL semánticamente incorrecto: una consulta puede ser sintácticamente válida pero entregar un resultado peligroso o simplemente falso. Por lo tanto, después de la generación de SQL, se verifica con validadores determinísticos a nivel AST.

Si el sistema detecta un riesgo—por ejemplo, un escaneo demasiado amplio, agregación incorrecta o filtros necesarios faltantes—corrige automáticamente la consulta e intenta de nuevo. El segundo tema es la latencia y los accesos. Según datos de AWS, las consultas SQL simples en tal esquema se generan típicamente en aproximadamente 3 a 5 segundos, aunque el tiempo total depende del modelo, del tamaño del grafo de conocimiento y de la velocidad del almacén.

Para mantener la interactividad, AWS recomienda paralelizar subtareas, ahorrar tokens y no inflar el contexto del agente. En paralelo, la arquitectura incluye inmediatamente filtros Row-Level Security para que los usuarios vean solo las filas a las que ya tienen acceso según las reglas corporativas.

Lo Que Esto Significa

AWS muestra efectivamente que Text-to-SQL deja de ser una demostración en sandbox y se convierte en un patrón de ingeniería para escenarios reales de BI. La principal conclusión no es que LLM puede escribir SQL, sino que un sistema funcional requiere un grafo de conocimiento, verificaciones, orquestación y control de acceso. Para equipos que deseen dar al negocio una interfaz de chat a los datos, este es un buen punto de referencia: menos magia, más infraestructura y reglas.