LogoIngeniería de Software Estadístico
Buscar

Guía de Resolución de Problemas Comunes en Ingeniería de Software Estadístico

Esta guía es un runbook práctico para diagnosticar y resolver incidentes típicos en pipelines de datos, modelos y despliegues. Cada problema incluye síntomas, causas probables y pasos concretos de verificación y corrección.

Flujo general de diagnóstico

1. Problemas con Data Drift

1.1. Alerta de drift en feature crítica

Síntomas:

  • Evidently / WhyLabs reporta Hellinger distance > 0.1 o PSI > 0.25 para una o más variables.
  • El dashboard de monitoreo muestra cambio en la distribución de una feature.

Causas probables:

  • Cambio en el sistema upstream (ej. nueva versión de API que modifica formato).
  • Error en pipeline de transformación (ej. imputación incorrecta).
  • Cambio estacional real en los datos (ej. comportamiento de clientes).

Diagrama de diagnóstico:

Pasos de diagnóstico:

  1. Comparar distribuciones visualmente
python
  1. Revisar logs de ingesta de datos
bash
  1. Verificar fechas y ventanas temporales (point‑in‑time correctness)
sql

Acciones correctivas:

  • Drift estacional: ajustar umbrales o reentrenar con datos recientes.
  • Error en pipeline: revertir cambio y reprocesar datos.
  • Cambio upstream: contactar al equipo propietario y adaptar el contrato de datos.

2. Fallos en Validación de Datos (Contrato)

2.1. Contrato de datos falla en ingesta

Síntomas:

  • Pipeline falla con error "Columnas faltantes: X" o "Tipo inesperado en columna Y".
  • Log de auditoría registra validation_status: failed.

Causas probables:

  • Cambio de esquema en la fuente (nueva columna, cambio de tipo, columna renombrada).
  • Versión incorrecta del contrato.
  • Problema de codificación o formato en el archivo fuente.

Diagrama de diagnóstico:

Pasos de diagnóstico:

  1. Obtener esquema real de los datos entrantes
python
  1. Comparar con el contrato esperado (contracts/data_contract.yaml):
  • Columnas faltantes o extra.
  • Tipos de datos (object vs string, int64 vs float64).
  1. Revisar el historial del contrato en Git
bash

Acciones correctivas:

  • Cambio legítimo: actualizar el contrato y versionarlo.
  • Error temporal: rechazar el archivo y notificar al proveedor.
  • Coerción de tipos automática (si es seguro): implementar y registrar advertencia.

3. Degradación del Rendimiento del Modelo

3.1. AUC / precisión cae por debajo del umbral

Síntomas:

  • Métricas de rendimiento (ground truth diferido) caen >5% respecto al champion.
  • Aumento de falsos positivos o falsos negativos en el dashboard.

Causas probables:

  • Concept drift (cambio en la relación features → target).
  • Data drift no detectado previamente.
  • Error en la obtención de ground truth (etiquetas incorrectas o atrasadas).

Diagrama de diagnóstico:

Pasos de diagnóstico:

  1. Comparar curvas de rendimiento por cohorte temporal
python
  1. Analizar matriz de confusión reciente
python
  1. Revisar si el problema es global o solo en un segmento (ej. caída solo en una región).

Acciones correctivas:

  • Concept drift: reentrenar con datos más recientes.
  • Segmento específico: modelo específico o añadir nuevas features.
  • Error en etiquetas: corregir pipeline de anotación y regenerar ground truth.

4. Problemas en Despliegue o Rollback

4.1. El nuevo modelo no recibe tráfico después del canary

Síntomas:

  • canaryTrafficPercent > 0 pero todas las solicitudes van al champion.
  • El endpoint del canary no aparece en los logs de acceso.

Causas probables:

  • Error en configuración de KServe / Istio (virtual service mal definido).
  • Contenedor del canary en crash loop.
  • Versión del modelo no existe en el storage URI.

Diagrama de diagnóstico:

Pasos de diagnóstico:

  1. Verificar el estado del InferenceService
bash
  1. Revisar logs del pod canary
bash
  1. Probar el endpoint del canary directamente (port‑forward)
bash

Acciones correctivas:

  • Corregir storageUri o definición del virtual service.
  • Reconstruir imagen si faltan dependencias.
  • Temporalmente, poner canaryTrafficPercent=0 y depurar en staging.

5. Fallos en Feature Store (Feast)

5.1. Materialización falla (offline → online)

Síntomas:

  • Job de materialización (Airflow) falla con error de conexión a Redis o BigQuery.
  • Valores online desactualizados o ausentes.

Causas probables:

  • Credenciales de base de datos expiradas.
  • Timeout en consulta a offline store (dataset muy grande).
  • Inconsistencia en el esquema de feature views.

Diagrama de diagnóstico:

Pasos de diagnóstico:

  1. Revisar logs del job de materialización
bash
  1. Probar conexión a Redis
bash
  1. Ejecutar la consulta SQL manualmente en BigQuery
sql

Acciones correctivas:

  • Rotar credenciales e inyectarlas mediante Vault.
  • Particionar la materialización en rangos más pequeños (por horas).
  • Actualizar la definición de feature view si el esquema cambió.

6. Problemas con Logs y Auditoría

6.1. No se encuentran logs de un incidente específico

Síntomas:

  • El audit trail no contiene una predicción concreta.
  • Logs rotos o incompletos.

Causas probables:

  • Volumen de logs excedió la retención configurada.
  • Error en la aplicación de logging (logger no inicializado).
  • Log escrito en archivo local dentro de contenedor efímero.

Diagrama de diagnóstico:

Pasos de diagnóstico:

  1. Verificar que el logger está configurado para stdout
yaml
  1. Comprobar la política de retención de logs (ej. Loki, Elasticsearch).
bash
  1. Buscar logs en el sistema de archivos del pod (si aún existe)
bash

Acciones correctivas:

  • Aumentar retención (ej. 30 días para logs de auditoría).
  • Configurar la aplicación para escribir logs en stdout y que un recolector (Fluentd, Logstash) los envíe a almacenamiento central.
  • Implementar logging estructurado con trace_id para correlacionar eventos.

7. Checklist de Diagnóstico Rápido

SíntomaPrimer comando / acción
Alerta de driftkubectl logs -n monitoring drift-detector
Fallo en ingesta de datoscat audit/data_ingestion.log | tail -50
Modelo lento en inferenciakubectl top pod -l app=model
No se actualiza el alias championmlflow models get-version --model-name X --version Y
Feast materialization timeoutkubectl logs -n feast job-xxxx | grep "timeout"
Error de conexión a base de datoskubectl exec -it pod-name -- nc -zv db-host 5432
Rollback no funcionaVerificar que el alias @champion apunta a la versión correcta: mlflow models get-versions --model-name X

8. Recursos y enlaces útiles

Herramienta / TemaEnlace de referencia
Evidently AI (drift)Documentación oficial
Great Expectations (contratos)Great Expectations Docs
MLflow (model registry)MLflow Tracking
KServe (canary deployments)KServe Documentation
Feast (feature store)Feast Troubleshooting
OpenTelemetry (logging)OpenTelemetry Logs
Prometheus (alertas)Prometheus Alerting
HashiCorp Vault (secretos)Vault Documentation

Buenas Prácticas para Dashboards Analíticos en R/Shiny

Documentos relacionados