Toda demostración de texto-a-SQL funciona con doce tablas. Los catálogos empresariales tienen decenas de miles, y el enfoque estándar — volcar el esquema al contexto y dar al modelo una herramienta de consulta — falla en costo, latencia y precisión a la vez.
La brecha entre esas dos situaciones es donde mueren silenciosamente la mayoría de los proyectos de analítica conversacional. No es un problema de ingeniería de prompts, y ninguna cantidad de ajuste de instrucciones lo cierra.
Del estándar
“Pre-trained models with a differentiable access mechanism to explicit non-parametric memory can overcome this issue”
Por qué falla la inyección masiva de esquema
Tres fallas se combinan, y corregir una empeora otra.
No cabe. Un catálogo de cincuenta mil tablas con columnas, tipos y claves alcanza millones de tokens. Incluso donde la ventana es nominalmente suficiente, la calidad de recuperación se degrada mucho con tanto material indiferenciado.
Se paga en cada turno. El esquema se reenvía con cada pregunta, incluidas las de seguimiento que tocan dos tablas. El costo escala con el tamaño del catálogo y no con el trabajo realizado, que es la relación equivocada.
Reduce la precisión. Esta es la contraintuitiva. Ante miles de candidatos con nombres similares — fct_orders, fct_orders_v2, fct_orders_deprecated, stg_fct_orders — el modelo elige de forma plausible y no correcta. Más contexto hace la selección más difícil, no más fácil.
Qué hace en cambio un analista competente
Un analista ante la misma pregunta no lee el catálogo. Busca tablas probables, abre una y mira cinco filas, verifica si está poblada para el periodo en cuestión, revisa los valores distintos de una columna de estado, y solo entonces escribe la consulta.
Eso es un ciclo iterativo de sondeos baratos que se estrecha hacia una operación costosa. Darle al agente la misma forma es lo que lo hace funcionar a escala.
Descubrimiento guiado por recuperación
Indexe el catálogo una vez — nombres de tablas, de columnas, descripciones y linaje — en un almacén de recuperación. Una pregunta destaca entonces una lista corta y ordenada de quizá siete tablas candidatas. Esas siete entran al contexto. Las otras cincuenta y un mil no.
Un conjunto de sondeo, no una sola herramienta de consulta
Reemplace la herramienta de consulta monolítica por operaciones acotadas que el agente pueda componer: previsualizar las primeras filas, contar filas bajo un filtro, listar valores distintos de una columna, calcular un agregado, buscar texto. Cada una es barata, devuelve poco e informa a la siguiente.
El beneficio secundario es la auditabilidad. Un rastro de cinco sondeos nombrados es legible para un revisor de una forma en que una consulta generada que une nueve tablas no lo es.
El patrón de puntero
Cuando un conjunto de resultados supera un umbral, no lo devuelva. Materialícelo en almacenamiento de objetos y devuelva una URL prefirmada más estadísticas resumidas. El modelo recibe una referencia y agregados; nunca ve las filas. El costo queda acotado sin importar el tamaño de la respuesta y — la parte que le importa a seguridad — la carga sensible nunca entra en una ventana de contexto ni en los registros de un proveedor de modelos.
Tres ataques que este diseño debe resistir
La exploración iterativa introduce modos de falla que la inyección masiva no tiene. Cada uno tiene una mitigación específica.
El razonador ciego. Si el modelo nunca ve las filas, puede afirmar cosas que los datos no respaldan. La mitigación es devolver estadísticas resumidas junto al puntero — conteo de filas, tasas de nulos, rangos de valores, conteos distintos — para que la narrativa se fundamente en algo verificable y no en la expectativa del modelo sobre qué contiene una tabla así.
Salida a través del puntero. Una URL prefirmada mostrada como enlace es un canal de exfiltración si el destino puede influirse. Valide cada URL contra una lista permitida antes de renderizar, y limite la firma estrictamente en tiempo y objeto.
Evasión por subconsulta. Una regla que inspecciona el SQL generado como texto se burla anidando la operación restringida en una subconsulta. Analice la consulta en un árbol sintáctico y valide estructuralmente, para que una operación restringida se detecte donde sea que aparezca en el árbol.
Qué cambia operativamente
La exploración cuesta más viajes de ida y vuelta por pregunta — cinco o seis llamadas en lugar de una. A cambio, cada llamada es pequeña, el gasto total en tokens cae marcadamente, y la respuesta se alcanza en lugar de adivinarse. El rastro se vuelve además un artefacto de revisión: un lector puede ver que el agente verificó si la tabla estaba poblada para el tercer trimestre antes de agregarla.
La prueba práctica de si un proveedor resolvió esto es simple. Pregunte cuántas tablas inyecta su sistema al contexto para una pregunta que toca dos. Si la respuesta escala con su catálogo y no con la pregunta, no sobrevivirá a su almacén de datos.
Axionalytics
IA agéntica en producción para equipos empresariales de ingeniería, datos e ingresos.