Saltar al contenido principal
Esencial•6–10 horas

Laboratorio de reconciliación de métricas con IA

Valida SQL y métricas generados por IA mediante un contrato semántico, controles deterministas, reconciliación autoritativa y casos de regresión antes de que una cifra llegue a un dashboard o decisión.

contratos de métricasvalidación SQLreconciliación de datosanálisis de fallospruebas de regresión

Escenario

Tarea

La IA generó SQL para un KPI clave, pero el dashboard muestra otro valor. La consulta se ejecuta sin errores, aunque eso no prueba nada: la diferencia puede estar en el grain, la zona horaria, la cardinalidad de joins, los filtros, los datos tardíos o la propia definición de negocio. Construye una verificación que separe el éxito sintáctico de la corrección semántica y deje un rastro de evidencia reproducible.

Ejecución paso a paso

1. Congela la semántica antes de generar SQL

Resultado: La IA recibe un contrato de métrica explícito y no adivina reglas de negocio desde nombres de columnas.

Tareas

  • →Documenta grain y unidad de análisis
  • →Fija numerador, denominador, filtros y exclusiones
  • →Define zona horaria, cierre de periodo y freshness
  • →Nombra tabla o informe autoritativo y owner

Comprobaciones

  • ✓Una métrica tiene un único contrato versionado
  • ✓Las reglas indefinidas se marcan como preguntas abiertas
  • ✓La IA no puede resolver por sí sola ambigüedad de política

2. Trata el SQL generado como artefacto candidato

Resultado: La ejecución exitosa deja de ocultar errores lógicos.

Tareas

  • →Guarda prompt, contexto y query exacta
  • →Valida schema y campos referenciados
  • →Añade checks de row count, nulls y duplicados
  • →Comprueba join keys y fan-out one-to-many o many-to-many

Comprobaciones

  • ✓Query success no es un criterio de aceptación
  • ✓Campos desconocidos o casts implícitos fallan explícitamente
  • ✓La cardinalidad de joins se verifica por separado de los totales

3. Ejecuta reconciliación autoritativa

Resultado: La cifra clave se reproduce por una vía independiente y cualquier diferencia queda explicada.

Tareas

  • →Compara el KPI con la fuente o informe autoritativo
  • →Recalcula totales con query o fórmula independiente
  • →Comprueba segmentos extremos y fechas límite
  • →Usa tolerancia solo con justificación de dominio

Comprobaciones

  • ✓Un mismatch nunca se redondea a PASS
  • ✓La tolerancia tiene owner y rationale
  • ✓Cada diferencia se localiza en definición, datos, query o estado de la fuente

4. Convierte fallos en una suite de regresión

Resultado: Cambios posteriores de SQL, schema o modelo no reintroducen silenciosamente un error conocido.

Tareas

  • →Simula wrong join, partición stale, cambio de zona horaria, filtro omitido y filas duplicadas
  • →Registra la señal determinista esperada
  • →Asigna severidad y acción de release
  • →Versiona fingerprints de dataset, query y contrato

Comprobaciones

  • ✓Un fallo crítico de reconciliación bloquea publication
  • ✓Los casos de regresión se reproducen sin LLM judge
  • ✓Cambiar el contrato de métrica fuerza una nueva baseline verification

Criterios de aceptación

  • El contrato incluye grain, definiciones, filtros, semántica temporal, freshness y fuente autoritativa
  • El SQL generado se guarda como artefacto candidato versionado con sus supuestos
  • Cardinalidad de joins, duplicados, nulls, totales y edge segments tienen checks deterministas
  • El KPI clave está reconciliado de forma independiente o conserva una discrepancia explícita sin resolver
  • Al menos cinco casos de fallo pasan a ser pruebas de regresión permanentes