150 — Registro y promoción champion-challenger

← Clase anterior · Índice de la parte · Clase siguiente →

Parte: 12 — Ingeniería de IA, MLOps, LLMOps y AgentOps
Nivel: experto · Horas estimadas: 6
Laboratorio: workflow · Estado: EXECUTABLE_CORE

🎯 Propósito

Comprender registro y promoción champion-challenger dentro de la evolución de la inteligencia artificial, implementar un experimento mínimo verificable y distinguir qué parte constituye evidencia frente a una afirmación todavía no comprobada.

📚 Resultados de aprendizaje

Al finalizar podrás:

  1. Explicar registro y promoción champion-challenger usando los conceptos registry, version, champion, challenger.
  2. Ejecutar el laboratorio con una semilla explícita y revisar su contrato JSON.
  3. Identificar al menos un supuesto, una limitación y un riesgo de aplicación.
  4. Comparar el enfoque con la etapa anterior de la ruta de aprendizaje.
  5. Producir una evidencia reproducible y una conclusión que no exceda los datos.

🧩 Conceptos centrales

registry, version, champion, challenger

🗺️ Ubicación en el mapa de la IA

Con experimentos trazables (clase 149) el problema pasa a ser de gobierno: ¿qué versión del modelo sirve tráfico real y quién decide el reemplazo? El registro de modelos y el patrón champion-challenger trasladan a ML una idea vieja de la banca y el control de riesgo: la versión titular solo cede su puesto ante un retador que la supera bajo reglas acordadas de antemano. Es la antesala del CI/CD (151) y del serving (152).

📖 Fundamentos

🗃️ Registro de modelos

Un registro (model registry) es la fuente de verdad sobre qué modelos existen, en qué versión y en qué estado. A diferencia del tracking (que guarda todos los runs), el registro guarda los candidatos con nombre y contrato:

modelo registrado: "churn"
 ├── v6  — alias: (ninguno)     archivada
 ├── v7  — alias: champion      sirviendo producción
 └── v8  — alias: challenger    en evaluación en sombra
metadatos por versión: run de origen (linaje), firma de entrada/salida,
métricas de aceptación, aprobador, fecha de promoción

Los estados/alias forman una máquina de estados con transiciones explícitas: registrada → en evaluación → champion → archivada, y cada transición exige evidencia (métricas) y autorización (humana o automática con reglas). MLflow implementa esto con versiones y alias sobre un nombre de modelo.

🥊 Champion-challenger

El patrón separa dos preguntas que suelen mezclarse: «¿el challenger es mejor?» (estadística) y «¿lo promovemos?» (decisión de negocio con costos asimétricos).

📏 Criterio de promoción

Una regla de promoción seria tiene cuatro componentes:

  1. Métrica primaria y umbral de mejora mínima (Δ mínimo que paga el costo del cambio), evaluada con incertidumbre (varias semillas o intervalo por bootstrap).
  2. Guardas (guardrails): métricas que no pueden empeorar más de X aunque la primaria mejore — latencia p95, calibración, equidad por segmento, tasa de errores.
  3. Ventana y población de evaluación: mismo periodo, mismo segmento; nunca comparar el champion de diciembre con el challenger de enero.
  4. Reversibilidad: la promoción anterior queda archivada y re-desplegable (rollback en minutos, clase 158).
PROMOVER si:
  metrica_primaria(challenger) − metrica_primaria(champion) ≥ delta_min
  y para toda guarda g:  degradacion_g ≤ tolerancia_g
  y evaluacion hecha en la misma ventana/poblacion
EN OTRO CASO: mantener champion, archivar evidencia del challenger

🌓 Modos de evaluación en producción

🧮 Ejemplo trabajado

Modelo de riesgo crediticio. Regla acordada: promover si el AUC sube ≥ 0.005, con guardas: tasa de falsos negativos (FN) en el segmento «jóvenes sin historial» no puede subir más de 1 punto porcentual, y latencia p95 ≤ 150 ms.

Evaluación en la misma ventana (4 semanas de tráfico en sombra, n = 48 000):

                       champion v7    challenger v8    Δ
AUC                    0.831          0.842            +0.011  ✓ (≥ 0.005)
FN jóvenes sin hist.   8.2 %          9.9 %            +1.7 pp ✗ (tolerancia 1.0)
latencia p95           110 ms         128 ms           +18 ms  ✓ (≤ 150)

Decisión: NO promover, aunque la métrica primaria mejora claramente. La guarda de equidad se viola: v8 gana AUC global empeorando justo el segmento protegido. Acciones posibles: reentrenar v8 con re-ponderación del segmento, o renegociar la guarda con quien es dueño del riesgo (decisión de negocio explícita, no default silencioso). El registro archiva la evaluación completa: dentro de seis meses alguien preguntará por qué v8 no se promovió, y la respuesta debe estar escrita.

📊 Propiedades y comparación

Modo de evaluación Riesgo para usuarios Mide impacto causal Costo Cuándo usar
Replay offline nulo no bajo primer filtro de candidatos
Shadow nulo no (solo acuerdo y métricas técnicas) medio (2× cómputo) validar contrato y estabilidad
Canario 1-5 % bajo y acotado sí, con muestra suficiente medio antes de promoción total
A/B formal medio sí, con potencia estadística alto cambios de alto impacto 
stateDiagram-v2
    [*] --> Registrada: registrar run ganador
    Registrada --> Challenger: asignar a evaluación
    Challenger --> Champion: regla de promoción cumplida + aprobación
    Challenger --> Archivada: pierde vs champion (evidencia archivada)
    Champion --> Archivada: reemplazado por nuevo champion
    Archivada --> Champion: rollback de emergencia

⚠️ Errores conceptuales frecuentes

  1. «Gana la métrica primaria, se promueve.» Sin guardas, se promueven modelos que mejoran el promedio degradando latencia, calibración o segmentos sensibles.
  2. «Comparar el AUC de validación del challenger con el AUC histórico del champion.» Ventanas y poblaciones distintas no son comparables; la evaluación debe ser simultánea y sobre la misma población.
  3. «Shadow mode demuestra impacto en negocio.» Solo demuestra estabilidad técnica y acuerdo; el impacto causal exige exponer tráfico (canario/A-B).
  4. «El registro es una carpeta de ficheros de pesos.» Sin linaje, firma, estados y aprobadores, es almacenamiento, no gobierno: nadie sabe qué se puede desplegar.
  5. «Un delta positivo cualquiera justifica el cambio.» Cambiar de modelo tiene costo (riesgo, revalidación, documentación); por eso existe delta_min > 0.

🚀 Del aprendizaje a la operación

El laboratorio decide una promoción con números deterministas; en producción se añade la incertidumbre muestral (intervalos, potencia estadística), aprobaciones humanas con segregación de funciones (quien entrena no aprueba), auditoría regulatoria en dominios como crédito o salud, y automatización del despliegue del nuevo champion con rollback listo. La regla de promoción escrita antes de ver los números es lo que separa un proceso de gobierno de una discusión post-hoc.

🧪 Laboratorio

python lab.py

El laboratorio llama a ai_evolution.labs.run_lab("workflow"). Esta decisión evita 183 implementaciones divergentes: cada clase tiene un entrypoint propio, pero los motores didácticos se prueban como una biblioteca común.

🔍 Evidencia esperada

📓 Notebooks

📝 Evaluación

Criterio Peso
Comprensión conceptual 25 %
Ejecución reproducible 25 %
Interpretación basada en evidencia 25 %
Riesgos, límites y mejora propuesta 25 %

Consulta assessment.md para preguntas y criterio de aceptación.

⚠️ Errores comunes

Síntoma Causa probable Corrección
El código corre, pero no hay conclusión Se confundió ejecución con aprendizaje Explica qué demuestra y qué no demuestra
El resultado cambia sin explicación No se registró semilla o configuración Conserva semilla, versión y parámetros
Se promete uso real Se extrapoló desde una demo educativa Declara entorno, datos, límites y revisión humana
Se copia una métrica aislada No existe baseline ni costo de error Añade comparación y criterio de decisión

❓ Preguntas frecuentes

¿Debo usar una API comercial?
No. El núcleo funciona localmente. Las extensiones LIVE se documentan por separado.

¿El laboratorio representa una implementación industrial?
No por sí solo. Enseña el contrato y el patrón; producción exige integración, seguridad, observabilidad, pruebas y operación.

¿Dónde profundizo?
Revisa las especializaciones enlazadas en el README raíz y la ruta siguiente.

🔗 Referencias

📜 Papers que fundamentan esta clase

Bloque generado por python scripts/link_papers_to_classes.py. La fuente es papers/catalog/papers.json.

Paper Año Qué desbloqueó Miniatura
P114 · Tarjetas de modelo para el reporte de modelos 2019 Propone un documento corto y estandarizado que acompaña a cada modelo, con evaluación desagregada por subgrupo y usos fuera de alcance declarados. notebook

Cada ficha explica el problema anterior, la matemática mínima, los límites y los errores de atribución más frecuentes. Para leerlas con método: cómo leer un paper de IA · anexos matemáticos.

📚 Bibliografía de apoyo

Bloque generado por python scripts/link_sources_to_classes.py. Cada obra lleva su localizador verificado en sources/bibliography.json.

Los papers dicen de dónde salió el mecanismo. Estas obras lo desarrollan con el espacio que una clase no tiene: teoría completa, demostraciones y ejercicios.

Obra Edición Localizador Papel en esta clase
Huyen, Chip — Designing Machine Learning Systems 2022 ISBN 9781098107956 · web de la obra · pendiente de confirmar en su catálogo citada en las referencias de esta clase · obra de referencia de la parte 12

⬅️ Clase anterior

149 — Experimentos, semillas y trazabilidad

➡️ Siguiente clase

151 — CI/CD y pruebas para sistemas de IA

📝 Evaluación completa

❓ Preguntas

  1. Define registro y promoción champion-challenger sin usar una marca o framework como definición.
  2. Explica la relación entre registry, version, champion, challenger.
  3. Ejecuta lab.py dos veces con la misma semilla. ¿Qué debe conservarse?
  4. Identifica una afirmación permitida y una afirmación exagerada sobre el resultado.
  5. Propón una prueba negativa o un caso límite.

🏆 Reto verificable

Amplía el resultado del laboratorio con una clave student_extension que incluya:

✅ Criterio de aceptación