Presentación del módulo: enviar un modelo, no solo una feature

Por qué este módulo, ahora

Los seis módulos anteriores construyeron, pieza por pieza, la disciplina completa de lanzar una feature sin romper a nadie: el lanzamiento como decisión de riesgo (M1), el feature flag que desacopla deploy de release (M2), el rollout gradual con su radio de impacto creciente (M3), el monitoreo de guardrails en vivo mientras la rampa sube (M4), el rollback y el proceso de incidentes cuando algo se rompe (M5), y el postmortem blameless que cierra el ciclo aprendiendo del resultado (M6). Con esas seis piezas, sabes lanzar recommendations — el carrusel de productos recomendados de Mercado — con flags, canary, guardrails vigilados, un plan de reversa y un postmortem si algo sale mal.

Pero hay una pregunta que ningún módulo anterior contestó todavía, y que este caso trae escondida desde el principio: recommendations no es solo código. Detrás del flag, detrás del rollout, hay un modelo — recs-v1 — que decide, para cada comprador, qué productos recomendar. Y en algún momento, ese modelo va a cambiar: Mercado va a querer reentrenarlo con datos más frescos, o reemplazarlo por una arquitectura nueva, recs-v2, que promete mejores recomendaciones. Cuando eso pase, ¿aplica exactamente el mismo marco de M1 a M6 —flag, canary, guardrails, rollback— sin ningún ajuste? Casi. Pero no del todo, y la diferencia importa.

Un modelo no es un if que puedes leer línea por línea para saber qué va a hacer con cualquier entrada. Es una función aprendida de datos, cuyo comportamiento puede cambiar sin que nadie toque una línea de código —basta con reentrenarlo— y cuyas salidas, en ciertas arquitecturas modernas, ni siquiera son las mismas dos veces para la misma entrada. Migrar un modelo trae consigo dos preguntas nuevas que un rollout de feature normal no tiene que contestar: ¿el modelo nuevo decide distinto que el viejo, y en qué casos? (eso se mide antes de exponer a nadie, con shadow mode). Y si algo sale mal —una recomendación sesgada, una salida fuera de lugar—, ¿cómo investigas un incidente cuya causa no se reproduce igual dos veces? Este módulo contesta esas dos preguntas, más una tercera que todo lanzamiento de IA arrastra en silencio: ¿qué datos del comprador terminan en un log solo porque alguien quiso "guardar todo por si acaso"?

Conexión con el módulo 6. El módulo 6 cerró el loop ship → measure → learn para una feature ya lanzada: mide el resultado, aprende, itera. Ese mismo loop aplica a un modelo — con una vuelta más. Cuando lo que iteras no es un botón de UI ni un umbral de negocio, sino el modelo mismo, la primera iteración razonable casi nunca es "cambiarlo en producción y ver qué pasa". Es correrlo en la sombra, medir qué tan distinto decide, y recién después dejarlo tomar decisiones reales para una fracción de compradores. Este módulo es esa vuelta adicional, aplicada al caso que arrastra la guía completa: Mercado, tarde o temprano, va a querer mejorar recommendations cambiando el modelo que la impulsa.

Una analogía: cambiar el motor sin detener el vuelo

Ya sabes pilotar el avión con seguridad: subir altitud gradualmente, vigilar el tablero, tener un plan de aterrizaje de emergencia, investigar cualquier incidente sin culpar al piloto. Eso es todo lo que construyeron los módulos 1 a 6. Pero hay un tipo de cambio que ese entrenamiento no cubrió todavía: cambiar el motor del avión, en pleno vuelo, por uno de un modelo distinto. El motor nuevo promete más eficiencia — pero responde a los controles de forma un poco distinta, y nadie a bordo sabe todavía, con certeza, en qué maniobras exactas se comporta diferente del motor de siempre.

Ningún piloto responsable haría ese cambio a mitad de un vuelo con pasajeros, confiando en que "seguramente es mejor, lo dice el fabricante". Lo que hace, en cambio, es correr el motor nuevo en un simulador —o en un vuelo de prueba sin pasajeros— comparando, maniobra por maniobra, cómo responde distinto del motor de siempre. Solo después de esa comparación, con los números en la mano, decide si vale la pena instalarlo en un avión real, y todavía entonces empieza con un solo vuelo de prueba, no con toda la flota de una vez. Ese es exactamente el arco de este módulo: recs-v2 es el motor nuevo, el simulador es el shadow mode, y el primer vuelo de prueba es el canary.

El mapa de las ocho lecciones de este módulo

Lección   Pregunta que contesta
────────  ──────────────────────────────────────────────────────────────
L1        (esta) ¿Por qué migrar un modelo no es igual que lanzar una feature?
L2        ¿Qué significa, en la práctica, que un modelo "no sea código estático"?
L3        ¿Cómo corre un modelo nuevo SIN afectar al usuario todavía?
L4        ¿Cómo se mide si el modelo nuevo decide distinto, y dónde?
L5        ¿Cómo se investiga un incidente de IA que no se reproduce igual dos veces?
L6        ¿Qué datos del comprador terminan en un log, y por qué debería importarte?
L7        ¿Cómo se junta todo esto en un proceso completo de migración?
L8        Proyecto: migra recommendations de recs-v1 a recs-v2, con shadow y datos limpios

La lección 2 desarma la intuición de que "un modelo es solo una función más" — muestra, con datos reales de recs-v1 a lo largo de tres reentrenamientos, cómo su comportamiento se mueve con el tiempo sin que nadie haya deployado nada. La lección 3 construye el mecanismo central del módulo: correr recs-v2 en paralelo a recs-v1, sin que ninguna decisión suya llegue todavía al comprador. La lección 4 toma esas salidas paralelas y las compara con shadowCompare() — la función que vas a ejecutar más veces en lo que resta de la guía —, calculando la tasa de acuerdo entre los dos modelos y aislando exactamente dónde difieren. La lección 5 cambia de tema hacia lo que pasa cuando algo sale mal: un incidente de IA no se investiga como un bug de código, porque la misma entrada puede producir salidas distintas en llamadas distintas. La lección 6 se detiene en una pregunta que casi nadie hace a tiempo: ¿qué datos del comprador quedaron en el log de este experimento, y hacía falta guardarlos todos? La lección 7 junta las piezas en un proceso de migración de principio a fin, con una función de decisión que cruza la tasa de acuerdo contra un umbral antes de autorizar un canary. La lección 8, el proyecto, reutiliza esa función de decisión, shadowCompare() y la limpieza de datos, sin cambiarles una línea, sobre el caso completo: decidir si recs-v2 está listo para migrar.

La frontera: qué NO entra en este módulo

Este módulo enseña el proceso de migrar un modelo con seguridad — no construye el modelo, ni resuelve su ética a fondo:

• Entrenar, evaluar offline o construir la arquitectura del modelo (recs-v1, recs-v2 o cualquier otro) es trabajo del ecosistema Fullstack / ingeniería de IA. Aquí el modelo ya existe, entrenado y evaluado offline; este módulo enseña cómo llevarlo a producción sin romper a nadie.
• El rollout gradual del modelo una vez que sale de shadow —el canary, las etapas, el radio de impacto— reutiliza exactamente el marco de los módulos 2 y 3: un modelo nuevo, detrás de un flag, con la misma rampa. Este módulo no repite esa mecánica; se apoya en ella y agrega lo que es específico de un modelo: comparar antes de exponer.
• Vigilar los guardrails de negocio durante ese rollout —latencia, quejas, márgenes— es el módulo 4, sin cambios: un modelo migrando a producción vigila exactamente los mismos guardrails que cualquier otra feature.
• La ética y la gobernanza de IA a fondo —sesgo algorítmico como campo completo, regulación de IA, equidad como disciplina— quedan fuera de esta guía. Aquí se tocan las bases prácticas que un ingeniero de producto necesita para no lanzar un modelo a ciegas: comparar antes de cambiar, investigar un incidente sabiendo que es probabilístico, y no registrar más datos personales de los necesarios.
• A/B testing formal para confirmar que el modelo nuevo es mejor —no solo distinto— es el territorio de la guía de métricas y experimentación. shadowCompare() mide acuerdo y diferencia, no cuál de los dos modelos genera más conversión; esa pregunta, una vez que decides exponer una fracción real de tráfico, se contesta con el mismo rigor estadístico de esa guía.

Errores comunes

Tratar la migración de un modelo como "otro deploy más", sin ninguna capa adicional de cuidado. Qué pasa: el equipo, ya cómodo con flags y rollouts después de los módulos 2 a 5, pone recs-v2 detrás de un flag y sube el porcentaje exactamente como haría con cualquier otra feature — sin haber comparado nunca sus decisiones contra las de recs-v1. Por qué pasa: el flag y el rollout se sienten como la parte difícil ya resuelta, y es tentador asumir que un modelo nuevo es solo "otro valor detrás del mismo interruptor". Cómo detectarlo: si nadie en el equipo puede decir, con un número concreto, en qué porcentaje de los casos recs-v2 recomienda algo distinto de recs-v1 antes de que el canary arranque, la comparación nunca ocurrió. Cómo corregirlo: como vas a construir en la lección 3 y 4, el shadow mode corre antes del flag — mide el acuerdo entre los dos modelos con tráfico real, sin que ningún comprador vea todavía la diferencia.

Asumir que "el modelo nuevo es mejor" porque el equipo que lo entrenó dice que sí. Qué pasa: alguien reporta que recs-v2 tiene mejor precisión offline, en un conjunto de datos de prueba, y el equipo de producto lo toma como suficiente evidencia para migrar en producción, sin correrlo en shadow contra tráfico real. Por qué pasa: una métrica offline —precisión, recall, la que sea— se siente como una prueba objetiva y suficiente, y correr shadow en producción se siente como un paso extra, burocrático. Cómo detectarlo: la justificación para migrar cita un número de un entorno de prueba, pero ningún número de shadow mode sobre tráfico real de Mercado. Cómo corregirlo: una métrica offline confirma que el modelo aprendió algo razonable en el laboratorio — no dice nada sobre cómo se comporta con el catálogo real, los compradores reales y los casos raros que solo aparecen en producción. El shadow mode de este módulo es exactamente el puente entre esas dos cosas.

Investigar una salida mala de un modelo exactamente como se investigaría un bug de código. Qué pasa: un usuario reporta una recomendación fuera de lugar, y el equipo de ingeniería intenta "reproducir el bug" con los mismos pasos exactos que usaría para un error de código — y cuando no logra reproducirlo en el primer intento, cierra el ticket como "no reproducible, posiblemente un caso aislado". Por qué pasa: la disciplina de depuración que la mayoría de los ingenieros aprendió primero es la de código determinista: mismo input, mismo output, siempre. Cómo detectarlo: el ticket de un incidente de IA se cierra después de un solo intento fallido de reproducción, sin ninguna nota sobre si el componente que falló es probabilístico. Cómo corregirlo: la lección 5 de este módulo construye el criterio correcto — antes de descartar un incidente por "no reproducible", confirma si el componente responsable puede, por diseño, dar respuestas distintas a la misma entrada.

Ejercicios

Ejercicio 1 — Ubica la pregunta. Para cada una de estas preguntas sobre recs-v2, di si la contesta este módulo 7, o un módulo/guía anterior ya visto:

• (a) "¿Qué tan distinto decide recs-v2 de recs-v1 sobre el mismo tráfico, antes de exponer a nadie?"
• (b) "¿En qué porcentaje de compradores conviene empezar a exponer recs-v2 una vez que decidimos migrar?"
• (c) "¿recs-v2 genera más conversión que recs-v1, con significancia estadística confirmada?"

Ver solución

• (a) Este módulo 7 — es exactamente lo que shadowCompare() mide en las lecciones 3 y 4, antes de que el flag se encienda para nadie.
• (b) Módulos 2 y 3 — una vez que el modelo sale de shadow, el "cuánto exponer y en qué orden" reutiliza el mismo mecanismo de flags y rollout gradual que cualquier otra feature.
• (c) La guía de métricas y experimentación — confirmar que un resultado es mejor, con p-value y tamaño de muestra, es exactamente el trabajo que esa guía ya resolvió; este módulo mide acuerdo y diferencia, no significancia estadística de una métrica de negocio.

Ejercicio 2 — La analogía, en tus palabras. Usando la analogía del motor de avión, explica en dos o tres frases por qué un piloto no instalaría el motor nuevo directamente en un vuelo con pasajeros, aunque el fabricante asegure que es mejor.

Ver solución

Aunque el fabricante tenga razón en que el motor nuevo es, en promedio, mejor, "mejor en promedio" no dice nada sobre cómo responde en las maniobras específicas del vuelo real que se avecina — y un piloto no puede permitirse descubrir esa diferencia con pasajeros a bordo. Por eso corre el motor nuevo primero en un simulador o en un vuelo sin pasajeros, comparando maniobra por maniobra contra el motor de siempre, y solo después de esa comparación decide si lo instala, empezando con un solo vuelo de prueba. Es la misma lógica detrás de por qué recs-v2 corre primero en shadow, sobre tráfico real, antes de que un solo comprador vea una recomendación que produjo.

Ejercicio 3 — Predicción. Sin haber leído todavía la lección 2, ¿por qué crees que un modelo de recomendaciones como recs-v1 podría cambiar su comportamiento con el tiempo, incluso si nadie del equipo de ingeniería toca ni una línea del código que lo sirve?

Ver solución

Un modelo de recomendaciones aprende patrones de los datos con los que fue entrenado — qué compran los usuarios, qué combinaciones de productos se repiten. Si el equipo lo reentrena periódicamente con datos más recientes (una práctica común: el catálogo cambia, las tendencias de compra cambian), el modelo resultante puede tomar decisiones distintas al de la versión anterior, aunque el código que lo sirve —el endpoint, la lógica que lo llama— no haya cambiado ni una línea. El "comportamiento" vive en los pesos aprendidos, no en el código fuente, y esos pesos pueden moverse sin ningún deploy de por medio. La lección 2 desarrolla esto con un caso concreto de recs-v1 a lo largo de tres reentrenamientos.

Resumen y siguiente paso

En esta lección ubicaste este módulo en el arco completo de la guía: los módulos 1 a 6 construyeron la disciplina de lanzar una feature con seguridad; este módulo 7 agrega la capa que un modelo de IA necesita encima de esa disciplina, porque un modelo no es código estático que puedas leer línea por línea, y sus salidas pueden ser probabilísticas. Viste la analogía del motor de avión —comparar en simulador antes de instalar, empezar con un vuelo de prueba antes que la flota completa— y el mapa de las ocho lecciones que siguen: shadow mode, la tasa de acuerdo, el postmortem de un incidente de IA, y los datos que terminan en un log sin que nadie lo haya decidido a propósito.

Antes de avanzar deberías poder: explicar por qué migrar un modelo necesita una capa de cuidado que un rollout de feature normal no necesita; nombrar, en orden, los tres pasos de una migración segura (comparar en shadow, medir el acuerdo, recién entonces exponer con canary); y ubicar la frontera exacta entre este módulo y lo que ya construyeron los módulos 1 a 6.

La lección 2 arranca por el principio: qué significa, con datos concretos de recs-v1, que un modelo "no sea código estático" — y por qué esa propiedad es la razón de fondo de todo lo que sigue en este módulo.

Recursos

• Chip Huyen, Designing Machine Learning Systems (O'Reilly, 2022) — oreilly.com/library/view/designing-machine-learning/9781098107956. El libro de referencia sobre por qué un modelo en producción necesita un ciclo de vida distinto al de código tradicional — monitoreo continuo, reentrenamiento, y despliegue gradual —, la base conceptual de todo este módulo. En inglés.
• Amazon SageMaker AI, "Shadow tests" — docs.aws.amazon.com/sagemaker/latest/dg/shadow-tests.html. Documentación de una plataforma real que automatiza exactamente el mecanismo central de este módulo: correr un modelo nuevo en paralelo al de producción, sin impacto en el usuario, para comparar antes de promoverlo. En inglés.