Tu agente escribe SQL válido. Tus ventas pueden estar mal

Una consulta que funciona también puede dar una cifra equivocada

El SQL puede ejecutarse sin errores y devolver un total de ventas incorrecto. Basta con incluir pedidos cancelados o sumar varias veces el importe de un pedido al cruzarlo con sus líneas. Un agente necesita conocer la definición del indicador, además de los nombres de las tablas.

Google acaba de anunciar la disponibilidad general de la indexación de LookML en Knowledge Catalog para Looker Core en Google Cloud. Permite recuperar definiciones de métricas y relaciones como contexto para los agentes. La integración de Gemini Enterprise con Knowledge Catalog sigue documentada como Preview: son dos piezas con estados distintos.

La novedad merece atención porque acerca las reglas ya usadas en analítica a las consultas en lenguaje natural. No convierte cualquier SQL generado en un cálculo correcto. La diferencia se ve con seis filas.

De 500 euros a 180 sin cambiar de modelo

Este ejemplo propio usa tres pedidos ficticios y una única moneda. A suma 100 euros y tiene dos líneas; B suma 80 y tiene tres; C suma 60, tiene una línea y está cancelado. El indicador que queremos calcular es el importe de pedidos completados. Su resultado es 180 euros.

Al unir pedidos y líneas, los 100 euros de A aparecen dos veces y los 80 de B aparecen tres. Sumar la columna del pedido sobre ese resultado devuelve 500 euros, incluido C. Si solo excluimos el cancelado, todavía obtenemos 440. La consulta sigue contando importes repetidos.

El grano de una tabla indica qué representa cada fila. El importe total pertenece al pedido, no a cada línea. Para este indicador basta con sumar una vez cada pedido completado: 100 más 80. Las tres consultas se han ejecutado con SQLite sobre esos datos sintéticos; no son resultados de una prueba con un modelo ni cifras de un cliente.

Qué aporta una capa semántica

Una capa semántica recoge cómo se calculan las métricas y cómo se relacionan los datos. En este caso tendría que fijar el identificador del pedido, los estados admitidos y el nivel al que se suma el importe. Para otro indicador también podrían importar devoluciones, impuestos, moneda y fecha de reconocimiento.

Esta idea ya existe fuera de los agentes. dbt Semantic Layer centraliza métricas y utiliza MetricFlow para resolver consultas y relaciones entre modelos. Looker incorpora agregaciones simétricas para evitar ciertos errores al cruzar tablas; dependen de claves primarias únicas y relaciones bien definidas.

La calidad de esa definición sigue siendo trabajo de ingeniería y negocio. Si se considera completado un pedido que aún no lo está, el sistema puede aplicar fielmente una regla equivocada. Tampoco basta con eliminar importes repetidos: dos pedidos distintos pueden tener el mismo total.

Lo que cambia con LookML y Knowledge Catalog

La indexación incorpora metadatos del LookML de producción: modelos, vistas, Explores, campos, filtros y relaciones. Cuando cambia el modelo publicado, se sincroniza su contexto con el catálogo. La documentación advierte de que la disponibilidad inicial puede tardar hasta un día tras habilitar la integración.

En Gemini Enterprise, el catálogo permite localizar datos accesibles y recuperar esquemas, descripciones, glosarios y consultas de referencia. El conector de datos se ocupa después de la consulta. Ese recorrido permite aportar la definición del indicador antes de generar SQL.

Conviene distinguir recuperar una definición de invocar una métrica ya implementada. Si el modelo recibe contexto y escribe SQL libre, aún puede usar mal un filtro. Cuando la aplicación solo necesita indicadores conocidos, una herramienta con métricas y parámetros admitidos reduce las decisiones que quedan abiertas al modelo. Esta última es una recomendación de diseño, no una garantía automática de la indexación.

Mejores definiciones no amplían los permisos

La integración de Gemini Enterprise utiliza credenciales del usuario y limita la búsqueda del catálogo según sus permisos. Ver metadatos y leer datos son capacidades que hay que comprobar por separado. Una consulta de solo lectura también puede revelar información que esa persona no debería recibir.

Antes de llevarlo a producción, probaría el mismo indicador con cancelaciones, pedidos sin líneas y dos pedidos con igual importe. Compararía el total con una consulta de referencia y comprobaría el acceso con usuarios de distinto alcance. Eso permite detectar un cálculo incorrecto aunque la respuesta esté bien redactada.

Si ya tienes métricas mantenidas en Looker o dbt, reutilizarlas puede evitar que cada agente invente su propia definición. Si todavía no existen, empezaría por los indicadores que realmente necesita la aplicación. El primer avance puede estar en acordar qué significa ventas y cómo se calcula, antes de cambiar el modelo que escribe la consulta.

Fuentes