Cortex Analyst: quién garantiza tus métricas

La consulta se ejecuta, devuelve una cifra y pasa una prueba de comparación. En la reunión, finanzas pregunta por qué esa cifra representa cobros cuando se habían pedido ventas reconocidas. La conversación con el asistente ha funcionado. El acuerdo sobre lo que significa la respuesta sigue sin existir.

Ese es el límite que interesa al llevar Cortex Analyst a una decisión de negocio. Podemos comprobar que una consulta responde igual que otra consulta de referencia. Para confiar en el resultado también necesitamos justificar por qué esa referencia representa la pregunta que queremos resolver.

Una consulta verificada necesita un contrato de significado y una prueba de sus límites. Si solo conservamos el SQL que una vez pareció correcto, la evaluación puede proteger con mucha consistencia una definición equivocada.

La documentación de estas evaluaciones recomienda ahora pasar a Cortex Agents. Conviene considerar esa recomendación al elegir una nueva integración, sin confundirla con una retirada anunciada de Cortex Analyst. Aquí utilizamos su mecanismo de evaluación para analizar una responsabilidad que sigue siendo necesaria al cambiar de herramienta: justificar qué significa la consulta de referencia y qué decisiones permite aceptar.

La referencia también tiene un responsable

La documentación de evaluaciones de Cortex Analyst describe un mecanismo que ejecuta el SQL generado y contrasta sus resultados con consultas verificadas. Permite observar aciertos, regresiones y latencia. Durante la evaluación, las consultas seleccionadas como referencia se retiran de la copia temporal de la vista semántica utilizada para generar respuestas; las no seleccionadas pueden seguir orientando la generación.

Esa separación evita que el ejemplo evaluado se use directamente como guía dentro de aquella copia. No convierte la respuesta de referencia en una definición de negocio independiente. Si quien preparó el conjunto confundió dos conceptos, retirar el ejemplo de la entrada no corrige el error de criterio.

El Verified Query Repository relaciona preguntas con consultas SQL que pueden orientar respuestas a preguntas similares. Snowflake advierte que las consultas deben ser correctas y responder realmente a la pregunta; una referencia incorrecta puede perjudicar el comportamiento del sistema. La etiqueta «verificada» describe un trabajo que alguien debe haber realizado, no una propiedad que aparezca al guardar el ejemplo.

Por eso separaría dos responsabilidades. El equipo técnico acredita la ejecución y la correspondencia entre datos, modelo y consulta. El responsable de la métrica acepta población, momento, unidad y tratamiento de excepciones. Pueden coincidir en una persona; sus comprobaciones siguen siendo distintas.

Dos cifras correctas para preguntas diferentes

Imagina una empresa con estos tres movimientos, expresados en euros.

Con las reglas del ejemplo, el importe neto reconocido en septiembre es 100 − 20 = 80 euros. El flujo neto de caja de septiembre es 80 − 20 = 60 euros. Ambos cálculos son reproducibles a partir de la tabla. No son resultados de una ejecución de Cortex Analyst.

Si alguien pregunta «¿cuánto vendimos en septiembre?», elegir una columna temporal no es un detalle de implementación. Determina qué decisión estamos ayudando a tomar. Para discutir tesorería puede interesar el segundo resultado; para otra definición interna de actividad, el primero. Antes de evaluar la generación necesitamos resolver esa ambigüedad o permitir que el sistema pida aclaración.

La dificultad aumenta cuando el conjunto de evaluación contiene únicamente meses en los que reconocimiento y cobro coinciden. Dos consultas con significados diferentes pueden devolver exactamente lo mismo sobre esos datos. La igualdad del resultado observado no demuestra equivalencia para todos los periodos.

Un ejemplo de contraste debe romper esa coincidencia. En nuestra tabla, A y B separan los calendarios y C obliga a decidir el tratamiento de las devoluciones. Cada fila añade una condición que una muestra cómoda podría ocultar. La profundidad de la evaluación depende tanto de estas diferencias como del número de preguntas.

Contrato de evaluación de una métrica

Propongo un contrato de evaluación de una métrica como síntesis de trabajo entre negocio y plataforma. Su unidad es una decisión y su definición, no una consulta aislada.

No es una función de Snowflake ni una certificación. Organiza la evidencia que la herramienta no puede inventar por nosotros. En el ejemplo, evita que «ventas de septiembre» se use indistintamente para los dos calendarios.

El contrato tampoco sustituye al control de acceso. Una respuesta puede tener el significado correcto y exponerse a una persona sin permiso. Esa frontera requiere sus propias pruebas; no queda cubierta por obtener el importe esperado.

Una evaluación útil debe poder discrepar con nosotros

Empezaría con preguntas que hagan fallar la definición incompleta: periodo sin actividad, devolución posterior, entidad sin relación, cambio de unidad y término ambiguo. No todas requieren un número como respuesta. En una pregunta sin el periodo necesario, una aclaración puede ser la conducta correcta.

La evaluación debería registrar qué condición cubre cada caso. Diez paráfrasis de una pregunta conocida pueden ayudar a estudiar variación lingüística, pero no aportan diez fronteras de negocio distintas. Mezclar ambas coberturas en un único porcentaje facilita presentar amplitud donde solo hay repetición.

También conservaría ejemplos fuera del conjunto usado para ajustar la definición. No porque exista una partición que garantice calidad, sino para reducir el riesgo de escribir un modelo que solo explica los ejercicios con los que lo hemos afinado. El equipo debe conocer cómo se eligieron los casos y qué situaciones siguen sin representación.

Una regresión exige mirar la definición vigente. Si cambió legítimamente la política sobre devoluciones, recuperar el número anterior podría ser un error. En cambio, modificar la referencia solo para que vuelva a pasar una prueba escondería un fallo. La decisión necesita un motivo y una revisión identificable.

El umbral de aceptación depende del uso

Un asistente exploratorio puede mostrar una interpretación y permitir discutirla antes de actuar. Una cifra que fija una provisión o dispara un proceso automático necesita un acuerdo más exigente sobre ambigüedad, cobertura y revisión. El mismo porcentaje global de acierto puede esconder riesgos muy distintos en ambos usos.

Para decidir el siguiente paso, separaría preguntas respondidas correctamente, preguntas aclaradas y respuestas incorrectas que el sistema presenta con seguridad. Después miraría qué decisiones quedan expuestas en cada grupo. Un promedio puede mejorar mientras empeora precisamente la pregunta de mayor consecuencia.

Esto amplía el problema que ya aparece en los contratos de datos y sus cambios de significado: aquí hay que sostener además el vínculo entre una pregunta variable y la definición que debe interpretar. No basta con que el dato conserve su unidad si el asistente elige otra población o fecha.

La inversión útil no termina al conseguir que una consulta funcione. Termina, para una versión concreta, cuando podemos explicar qué decisión representa su resultado, qué ejemplos han puesto esa interpretación a prueba y quién acepta los límites que todavía quedan. Esa explicación es la que permite discutir una cifra sin tener que confiar en lo convincente que suena el asistente.