Por qué la IA se equivoca con los números de tu negocio y cómo encontrar el problema

Un agente de IA puede ejecutar SQL válido y dar una respuesta convincente que esté equivocada. Antes de cambiar el modelo o las instrucciones, hay que ubicar el error: interpretación, definición del negocio, consulta, datos de origen o explicación.

Cada problema necesita una solución diferente. Un modelo más potente puede seguir usando una métrica ambigua. Una consulta perfecta no recupera las transacciones que todavía no llegaron al almacén de datos.

Primero, reproducí la respuesta

Guardá la pregunta original, el alcance permitido al usuario, la definición de la métrica, la consulta o solicitud a la herramienta, las filas devueltas y la respuesta final. Registrá la actualización de los datos y la configuración del modelo. Protegé esos registros: pueden contener información sensible.

Repetí el cálculo sobre la misma versión de los datos. Comparar una respuesta de ayer con un tablero actualizado hoy puede mostrar una diferencia que no es un error de la IA.

Si no se puede identificar la consulta detrás de una respuesta, la primera mejora es la trazabilidad.

Error 1: el término de negocio es ambiguo

«Ventas» puede significar pedidos brutos, mercadería pagada, facturación o dinero cobrado. Cada concepto puede tener una fecha y un tratamiento de reembolsos distintos.

Para una tienda ficticia, definimos ventas netas de mercadería como pedidos pagados que no son de prueba, después de descuentos y menos reembolsos completados atribuidos al pedido original. Excluimos impuestos y envío; todos los importes están en USD.

Dos pedidos elegibles tienen importes de 100 y 60. El primero tiene un reembolso de 20. La respuesta correcta es 140. Un resultado de 160 podría ser correcto para ventas brutas, pero respondería otra pregunta.

Solución: ofrecer métricas con nombre y definición, y pedir aclaración cuando haya varias interpretaciones razonables. La capa semántica ayuda a establecer ese acuerdo.

Error 2: un join multiplica el importe

El primer pedido tiene dos artículos y el segundo tiene uno. Al unir un importe neto calculado por pedido con sus artículos, aparecen tres filas:

Fila resultante	Importe neto del pedido
A100, primer artículo	80
A100, segundo artículo	80
A101, único artículo	60

La suma pasa a ser 220. El SQL puede ser perfectamente válido, aunque cuente dos veces el primer pedido.

Solución: identificar qué representa cada fila y comparar los recuentos antes y después de cada unión. Agregar en la granularidad correcta o configurar las funciones de modelado correspondientes. SUM(DISTINCT amount) no es una solución general: dos pedidos distintos pueden tener exactamente el mismo importe.

La documentación de relaciones de Looker explica la importancia de modelar correctamente la cardinalidad de las uniones.

Error 3: los períodos no son equivalentes

El agente puede comparar el mes actual incompleto con todo el mes anterior, usar UTC cuando el negocio reporta en hora local o asignar los reembolsos a un período diferente del tablero.

Solución: establecer fecha de inicio, límite final, zona horaria y campo de fecha. Decidir si los reembolsos posteriores modifican reportes históricos y explicitar esa convención en la respuesta.

Error 4: faltan datos

Un conector atrasado puede parecer una caída de ventas. Una unión interna puede eliminar pedidos cuyo cliente aún no se cargó. Una conversión de monedas puede fallar porque falta un tipo de cambio.

Solución: revisar actualización, completitud, claves sin correspondencia y cobertura cambiaria antes de interpretar tendencias. «Los datos del período están incompletos» puede ser la respuesta correcta.

Error 5: el número está bien, pero la explicación no

Una caída de ventas y un cambio de precios pueden coincidir sin que los datos demuestren causalidad. Separá cambios observados, posibles explicaciones y evidencia necesaria para investigarlas. Identificar qué región contribuyó más a una caída no demuestra por qué ocurrió.

Convertí los errores en pruebas

Armá un conjunto con los dos pedidos del ejemplo, varios artículos, un pedido cancelado, uno de prueba, un reembolso tardío, un período vacío y una solicitud de datos restringidos. Definí el resultado o comportamiento esperado para cada caso.

Probá varias formas de hacer la misma pregunta. Medí por separado exactitud numérica, elección de la definición, permisos y sustento de la explicación. Un promedio puede ocultar una falla grave.

El siguiente paso es construir una capa semántica con pruebas explícitas. Timewise Labs puede ayudarte a evaluar la implementación.

Adaptado del artículo de Labs4Change.