Text-to-SQL en producción: 5 errores que matan la precisión
20 de mayo de 2025 · 10 min
El 94% de precisión no sale de el prompt mágico
Cuando vendemos D4ta Oracle, no prometemos que un LLM “entienda tu negocio”. Prometemos que un operador puede preguntar “¿cuántas unidades del SKU X hay en el almacén de Barcelona?” y obtener la cifra correcta en segundos.
Eso requiere ingeniería. Estos son los cinco errores que más suelen romper proyectos Text-to-SQL en producción.
1. Schema crudo sin contexto de negocio
Enviar el CREATE TABLE completo al modelo es insuficiente. Los nombres de columna (qty_avail, wh_loc_cd) no significan nada para el LLM ni para el usuario.
Solución: capa semántica con descripciones de negocio, sinónimos (“stock” = qty_avail, “Barcelona” = warehouse_id = 3) y ejemplos de preguntas frecuentes indexados con pgvector.
2. Sin permisos por rol
Un chat que puede ejecutar SELECT * sobre tablas de costes o nóminas es un incidente de seguridad esperando a ocurrir.
Solución: políticas por rol antes de generar SQL. El modelo solo ve tablas y columnas permitidas para ese usuario. La validación ocurre después de generar y antes de ejecutar.
3. Confundir lenguaje natural con lenguaje legal
“Pendiente de envío” puede significar distintas cosas según el ERP: pedido confirmado, picking iniciado, o albarán generado sin salida de almacén.
Solución: definiciones de negocio explícitas en el RAG. Si hay ambigüedad, el sistema debe preguntar, no adivinar.
4. No validar SQL antes de ejecutar
Un DELETE mal generado o un JOIN cartesiano puede tumbar rendimiento o exponer datos.
Solución: allowlist de statements (SELECT only), LIMIT por defecto, timeout de query, y revisión de planes de ejecución para consultas costosas.
5. Medir “respuestas bonitas” en lugar de “respuestas correctas”
Una respuesta fluida en español que cite un número inventado es peor que un error visible.
Solución: golden set de preguntas con respuestas esperadas. Regression tests en cada cambio de schema o de modelo. Métrica principal: exactitud numérica, no perplexity.
Stack de referencia (D4ta Oracle)
Pregunta → Embedding → Recuperación de contexto (pgvector)
→ Generación SQL con schema acotado
→ Validación + permisos
→ Ejecución PostgreSQL
→ Respuesta en lenguaje natural + trazabilidad¿Cuándo tiene sentido Oracle para tu empresa?
- Tienes datos en ERP/PostgreSQL pero el equipo consulta en Excel
- Más de 10h/mes en preguntas repetitivas de stock, pedidos o rotación
- Necesitas autoservicio sin formar a cada usuario en SQL
Si aún no tienes el dato digitalizado, Oracle no es el primer paso — primero hay que construir el pipeline de datos.