Como funciona realmente la decision intelligence: desde una pregunta en lenguaje natural, a traves de la capa semantica de metricas, hasta una respuesta fundamentada, con deteccion de anomalias y forecasting con incertidumbre declarada. Escrita para que entiendas el motor antes de compartir un solo byte de datos con nosotros.
Durante anos, obtener una respuesta de los datos requeria un analista, una cola de tickets y varios dias de ida y vuelta. Las herramientas han cambiado lo suficiente como para que nada de eso sea ya necesario. Lo que no ha cambiado es la disciplina necesaria para que las respuestas sean fiables: no basta con apuntar un modelo de lenguaje a una base de datos sin procesar y llamarlo analytics. Esta guia describe el metodo completo.
La decision intelligence es la practica de hacer que los datos de negocio sean consultables en lenguaje natural, con las respuestas basadas en definiciones acordadas para que signifiquen lo mismo para cualquiera que pregunte. Es una capa que se coloca sobre tu data warehouse y lo transforma de un lugar donde se almacenan los datos a un lugar donde se toman decisiones.
Conviene separar tres cosas que a menudo se comprimen en un solo pitch:
Cada uno puede funcionar por separado, pero se multiplican. Un equipo que puede hacer cualquier pregunta, recibe alertas cuando algo falla y tiene una prevision de lo que viene opera de forma fundamentalmente diferente a uno que espera la revision semanal.
Cada proyecto empieza con un analisis gratuito, porque es la unica forma honesta de definir el alcance del trabajo. Compartes una muestra de tus datos y una lista de las preguntas que tu equipo actualmente le pide a una persona que responda. Modelamos las metricas, ejecutamos el analisis y volvemos con respuestas reales basadas en tus numeros, anomalias detectadas en tu historia y una prevision con su precision medida.
Te quedas con el resultado independientemente de como sigas. Un analisis medido sobre tus datos reales es un artefacto util por si mismo, y pone fin a las conjeturas que destruyen la mayoria de los proyectos de datos antes de empezar. Si los numeros se sostienen y las respuestas son genuinamente utiles, definimos el alcance de la construccion completa desde ahi.
La interfaz que la mayoria de las personas ve primero es el campo de pregunta. Escribes "por que cayeron los ingresos en marzo?" en lenguaje natural y llega una respuesta. El mecanismo detras es un modelo de lenguaje que traduce tu pregunta a SQL, lo ejecuta contra tus datos y devuelve el resultado con un grafico.
Aqui es donde la mayoria de las demos se detienen y donde la mayoria de los proyectos fracasan. Un modelo de lenguaje que traduce una pregunta en formato libre a SQL contra una base de datos no documentada y sin etiquetas producira SQL que se ejecuta pero devuelve el numero equivocado con alta confianza. Une las tablas equivocadas, aplica el filtro de fecha incorrecto y pierde la logica de negocio que hace que "ingresos" signifique bruto o neto segun el contexto. La salida parece plausible. No es fiable.
La solucion no es un modelo mas inteligente. Es una capa semantica de metricas, que se explica en la seccion siguiente.
La capa semantica de metricas es el conjunto de definiciones que se situan entre tus tablas sin procesar y la interfaz de preguntas. Aqui es donde "ingresos" se define como orders.amount menos refunds.amount, filtrado a pedidos completados, con la regla de que un reembolso aplicado a un pedido de un periodo anterior ajusta el periodo actual en lugar del original. Esa definicion se codifica una vez, se prueba y luego cada consulta la utiliza.
Construir esta capa constituye la mayor parte del trabajo del proyecto, y tambien es donde reside la mayor parte del valor. Una vez que las metricas estan definidas, un usuario de negocio que pregunta "cuales fueron los ingresos en marzo?" y un analista de datos que escribe la misma consulta obtendran el mismo numero, porque ambos corren contra la misma definicion. Esa consistencia es lo que hace que las respuestas sean lo suficientemente fiables como para incluirlas en un informe ejecutivo o en una presentacion al consejo.
La capa tambien lleva la granularidad (es esta metrica diaria, mensual, por region, por producto?), las reglas de acceso (quien puede ver que metricas?) y los mapeos de dimensiones (cuando alguien dice "UK", a que valores de columna corresponde?). Estos son los detalles que una consulta de modelo de lenguaje en bruto errara, y la capa es lo que hace que acertarlos sea fiable en lugar de afortunado.
Basar significa que cada numero en una respuesta puede rastrearse hasta el SQL que lo produjo, y ese SQL puede rastrearse hasta la definicion de metrica que lo informo. Un usuario que cuestiona un numero puede ver exactamente como se calculo, de que columna proviene y que filtro se aplico. Esa es la diferencia entre un resultado en el que confias y uno que verificas cada vez.
Esto importa mas en los margenes: cuando una prevision parece sorprendente, cuando salta una alerta de anomalia, cuando un directivo cuestiona un numero en un informe. En cada caso, la respuesta a "como obtuviste esto?" es una cadena limpia y auditable desde la definicion hasta la consulta y el resultado. Esa cadena es lo que gana la confianza organizacional en el sistema con el tiempo.
La deteccion de anomalias es el sistema que monitoriza continuamente tus metricas y avisa cuando un valor sale de su rango esperado. La alerta incluye la metrica afectada, la dimension que esta impulsando la desviacion, la magnitud de la variacion y una descripcion en lenguaje natural de la causa probable basada en patrones historicos.
La ingenieria detras es sencilla en concepto: para cada metrica, ajustamos un modelo de comportamiento normal sobre tus datos historicos, establecemos umbrales de alerta basados en tu tolerancia a los falsos positivos y luego comparamos cada nueva observacion con ese modelo. En la practica, el trabajo interesante esta en el analisis de dimensiones: no solo "los ingresos estan bajando" sino "los ingresos estan bajando y se explica enteramente por un pico en la tasa de reembolso en UK, que ha ocurrido tres veces antes cuando una categoria de producto especifica tenia un problema de calidad."
La tasa de falsos positivos importa. Un sistema de alertas que salta cada dos dias entrena a las personas a ignorarlo. Calibramos los umbrales durante la fase Build usando tus datos historicos y tu tolerancia declarada, y los revisamos durante Operate conforme cambia el negocio.
Una prevision es una afirmacion sobre el futuro, y la incertidumbre declarada es la cosa mas util que puede contener. Una prediccion de punto unico ("los ingresos del proximo trimestre seran EUR 2,4M") es menos util que un rango ("el modelo concentra el 80% de la masa de probabilidad entre EUR 2,1M y EUR 2,7M, segun este error de backtest"). El rango es lo que planificas.
Nuestras previsiones se construyen sobre tres disciplinas:
Lo que cambia la precision de una prevision es la calidad de los datos de entrada y la estabilidad del proceso subyacente, no la sofisticacion del modelo. Una empresa que cambia su estrategia de precios cada trimestre tendra mas dificultades para predecir los ingresos que una con una estructura de precios estable. Esto lo dejamos claro durante el analisis en lugar de prometer una precision que no podemos entregar.
Sobre el backtest. La cifra de backtest que te mostramos en el analisis gratuito es el mean absolute percentage error (MAPE) del modelo sobre periodos retenidos de tus datos historicos. Es el numero que debes usar para juzgar si la prevision es util para tu horizonte de planificacion, no una cifra que elegimos para embellecer el pitch.
Una vez que la capa de metricas esta en marcha y las consultas funcionan, generar un informe ejecutivo semanal o mensual es un paso de composicion. El sistema extrae las metricas clave, las compara con el periodo anterior y la prevision, sennala las anomalias disparadas y escribe una breve narrativa que describe lo que paso, lo que hay que vigilar y lo que muestra la prevision. Se envia a una hora fija o bajo demanda.
El informe no es escritura creativa. Es un resumen estructurado de los datos, escrito en lenguaje natural, con los numeros basados en las mismas definiciones que responden las consultas interactivas. Un directivo puede leerlo en dos minutos y entrar a la revision de liderazgo conociendo los numeros sin haber construido una presentacion.
El valor aqui no es que la narrativa este brillantemente escrita. Es que esta lista a las 07:00 del lunes en lugar de a las 11:00 despues de que alguien haya pasado la manana preparandola. El tiempo que libera es real y se acumula en cada semana que el sistema funciona.
El sistema se coloca sobre tu data warehouse existente en lugar de reemplazarlo. Nos conectamos a BigQuery, Snowflake y Postgres como objetivos principales, con Redshift y Databricks disponibles para equipos que ya corren en esas plataformas. La capa semantica de metricas es el artefacto portable: puede definirse una vez y consultarse desde la interfaz de lenguaje natural, desde una herramienta BI como Looker o Metabase a traves de su API, o directamente via SQL para equipos que quieran combinar ambos enfoques.
| Capa | Que hace | Que conservas |
|---|---|---|
| Warehouse (tuyo) | Almacena los datos brutos y transformados | Propiedad total, sin migracion |
| Capa semantica de metricas | Define metricas, granularidad, acceso, dimensiones | Definiciones YAML o SQL portables |
| Motor de consultas | Traduce preguntas a SQL, las ejecuta, devuelve resultados | Acceso API para integracion en otro lugar |
| Servicio de alertas y previsiones | Monitoriza metricas, dispara alertas de anomalia, ejecuta previsiones | Reglas y umbrales de alerta configurados |
| Generador de informes | Compone y distribuye el informe ejecutivo a una hora fija | Plantillas de informe que posees y editas |
Nada en este stack requiere mover tus datos. La capa de consultas se conecta a tu warehouse con credenciales de solo lectura. Los datos permanecen donde estan.
El control de acceso no es un pensamiento posterior en una capa de metricas bien construida, es parte del esquema. Cada metrica esta etiquetada con los roles que tienen permiso para verla. La capa de consultas comprueba esas etiquetas en tiempo de ejecucion: un usuario que pregunte sobre compensaciones ejecutivas o PII de clientes sin tener el rol correcto recibe una respuesta que le dice que la metrica existe pero no esta disponible para el, en lugar de un error o una fuga de datos.
El modelo de gobierno que recomendamos es sencillo: empieza con el acceso mas amplio que sea seguro, mide que consultas se ejecutan y por quien, y restringe donde los datos muestran un uso que no estaba previsto. Un acceso excesivamente restrictivo desde el primer dia mata la adopcion antes de que el sistema tenga la oportunidad de demostrar su valor.
Para empresas sujetas al RGPD u otras obligaciones de residencia de datos, la conexion de solo lectura al warehouse y la ausencia de una copia de los datos en nuestra infraestructura son los hechos clave. Documentamos el flujo de datos en el proyecto y podemos proporcionar la arquitectura tecnica para una revision de cumplimiento.
Un sistema que nadie usa no es un exito, por muy buena que sea la tecnologia subyacente. Hacemos seguimiento de dos categorias de metrica durante la fase Operate:
| Metrica | Que te dice |
|---|---|
| Tiempo hasta el insight | Cuanto tarda desde una pregunta hasta una respuesta, frente a la linea base pre-sistema |
| Volumen de consultas por equipo | Si el sistema se esta usando y por quien, como indicador anticipador de adopcion |
| MAPE de prevision por metrica | Como evoluciona la precision de la prevision conforme el modelo se reentrena con mas datos |
| Precision de alertas | La proporcion de alertas de anomalia que llevaron a una investigacion real (verdaderos positivos) |
| Tasa de apertura de informes | Si los informes ejecutivos se leen, como indicador de su utilidad |
La metrica de adopcion importa tanto como la de precision. Un sistema tecnicamente excelente que se obvia en favor de una hoja de calculo no ha generado valor. Revisamos ambas categorias en el informe mensual Operate y ajustamos la configuracion cuando cualquiera de ellas va en la direccion equivocada.
Una lista breve de enfoques que parecen razonables y fallan en la practica:
La forma del trabajo: un analisis gratuito para demostrar el enfoque sobre tus propios datos, una Build de alcance fijo que conecta el warehouse y entrega la capa de metricas, la interfaz de lenguaje natural, las alertas de anomalia y el primer informe ejecutivo, y luego una fase Operate que mantiene metricas y previsiones fiables conforme cambian tu negocio y tus datos. Tienes un unico punto de contacto, software que corre sobre tu infraestructura y la medicion para demostrar que funciona.
AI Analytics es nuestro segundo servicio de AI. La misma metodologia que hace fiable a Document AI, empezar con un pilot gratuito, medir antes de comprometerse, entregar un flujo de trabajo real, ser dueno del resultado, es lo que hace fiable a AI Analytics. Los servicios se complementan: Document AI convierte documentos en datos, AI Analytics convierte datos en decisiones. Empieza con un analisis gratuito.
Ese es el motor completo. El siguiente paso es un analisis gratuito sobre tus propios datos: respuestas reales a tus preguntas reales, las anomalias detectadas, las previsiones backtestadas, y sin compromiso.
Un analisis gratuito sobre tus datos reales, las metricas modeladas y backtestadas, las anomalias detectadas. Luego construimos la capa que hace cada respuesta inmediata.
Solicitar analisis gratuito