El camino completo

Ana quiere vender unos tenis que ya no usa. Abre la app de un marketplace (una tienda en línea donde cualquiera puede vender), les toma una foto, la sube y, antes de terminar de escribir el título, la app ya le sugiere la categoría: Calzado › Tenis.

Para Ana eso no fue nada. Para que pasara, alguien tuvo que juntar millones de fotos, enseñarle a un programa a reconocerlas, ponerlo a responder en computadoras que nunca se apagan, cuidar que conteste en más o menos lo que dura un parpadeo y revisar cada día que siga acertando.

Ese es el caso que vamos a seguir en todo Sensei. Se llama C01. Es el mismo caso que el Dojo (la parte de TrueML donde practicas con código) simula en pequeño: un marketplace que recibe unos 2.5 millones de publicaciones al día y le sugiere a quien vende la categoría de su foto, entre 500 posibles.

Qué es un modelo

A un programa normal tú le escribes las reglas: «si la compra pasa de 1,000 pesos, el envío es gratis». A un modelo no le escribes reglas. Le muestras miles de ejemplos con su respuesta correcta y él solo encuentra la manera de pasar de la entrada a la respuesta.

¿Por qué no escribir las reglas a mano? Intenta escribir la regla para reconocer unos tenis en una foto. ¿Por la forma? ¿Por las agujetas? ¿Y si es una bota? ¿Y si la foto está oscura, o de lado, o el tenis está dentro de su caja? Hay cosas que es mucho más fácil mostrar que explicar.

Por dentro, un modelo es un montón de números que se llaman parámetros. Piensa en ellos como perillas: cada combinación de perillas hace que el modelo responda distinto. El modelo de C01 tiene unos 25 millones.

Entrenar y usar

Todo modelo vive dos momentos muy distintos, y casi todo lo demás en esta app depende de no confundirlos.

1. 1

   Entrenar

   El entrenamiento es mostrarle muchos ejemplos de los que ya sabes la respuesta: fotos con su categoría correcta, que se llama su etiqueta. El modelo adivina, compara su respuesta con la correcta y mueve sus perillas un poquito para equivocarse menos. Eso se repite millones de veces. Es lento y caro, así que se hace de vez en cuando: en C01, una vez al mes.

2. 2

   Usar

   La inferencia es usar el modelo ya entrenado. Recibe una foto nueva, sin respuesta, y da su predicción. Las perillas ya no se mueven: solo calcula. Es rápido y pasa todo el tiempo: en C01, millones de veces al día.

Que un modelo funcione en tu laptop no significa que esté listo. Está en producción cuando gente real lo usa todos los días y, si falla, alguien lo nota.

Por eso existe el trabajo de ml engineer. No se trata solo de que el modelo acierte, sino de que todo lo que lo rodea funcione. Un artículo científico famoso de Google («Hidden Technical Debt in Machine Learning Systems», Sculley y otros, 2015) lo dibujó así: el código del modelo es una cajita chica en medio de todo lo demás, que son los datos, la configuración, los servidores y el monitoreo.

Deploy: cambiar de versión sin que nadie lo sufra

Pasar algo de tu laptop a producción, o cambiar la versión que está respondiendo por una nueva, se llama deploy (desplegar). Suena a apretar un botón, pero en un sistema que atiende a millones casi nunca se hace de golpe: si la versión nueva trae un error, le pegaría a todos a la vez.

En C01 se hace poco a poco. El modelo nuevo primero responde 5 de cada 100 fotos. Si sigue respondiendo rápido, sin errores y con respuestas sensatas, pasa a 25 de cada 100 y después a todas. Si algo empeora, el sistema regresa solo a la versión anterior. A esa primera prueba chiquita se le llama canary (canario), por los canarios que los mineros bajaban a la mina: si había gas, el pájaro lo resentía antes que ellos.

Todo lo que rodea al modelo se puede ordenar en seis etapas. En TrueML (el conjunto de herramientas al que pertenece Sensei) cada etapa tiene su color, y juntas forman la T del logo: la verás arriba de cada lección, con las etapas que toca encendidas.

Una cadena de pasos así, donde lo que sale de uno entra al siguiente, se llama pipeline. Veamos qué pasa en cada etapa.

1 · Datos

Todo empieza con ejemplos. Hay que juntar fotos, ponerles su categoría correcta (muchas veces una persona lo hace a mano), revisar que estén bien y guardarlas como una versión fija que ya nadie modifica, para saber después exactamente con cuáles se entrenó. Sale: un dataset, la colección de fotos con su categoría.

2 · Modelo

Con el dataset se entrena el modelo. Luego se examina con fotos que nunca vio, y solo si pasa el examen se aprueba. Al final se convierte a un formato que hace casi los mismos cálculos con mucho menos trabajo, para que responda más rápido, y se comprueba que sus respuestas no cambien. Sale: el modelo aprobado, guardado en un archivo.

3 · API

El modelo solo, en un archivo, no le sirve a nadie si nadie le puede preguntar. Se escribe un programa que lo carga y lo pone a responder: recibe una foto por la red (internet, o la red interna de la empresa) y regresa la categoría. La «ventanilla» por donde se le pregunta es su API, y a tener el modelo respondiendo así se le llama serving. Sale: el programa que responde.

4 · Contenedor

El programa funciona en tu máquina, pero ¿funcionará igual en otra? Se empaqueta con todo lo que necesita (la versión exacta de Python, las librerías, que son código que otros ya escribieron y tu programa usa, y el modelo) en un contenedor, que corre igual en cualquier máquina que sepa correr contenedores. La herramienta más usada para crearlos es Docker. Sale: el paquete probado, listo para copiarse a cualquier servidor.

5 · Orquestación

Una sola computadora tiene dos problemas: puede no aguantar todas las peticiones de la hora pico y, si se apaga, se apaga todo. En C01 pesa más el segundo: una sola máquina con el modelo aguantaría el tráfico, pero se usan dos para que, si una falla, la otra siga respondiendo. Así que se corren varias copias del contenedor en varias máquinas, y un sistema de orquestación decide cuántas hacen falta, les reparte el trabajo y reemplaza a las que fallan. También cambia a la versión nueva poco a poco, sin apagar nada. El orquestador más usado es Kubernetes. Sale: el servicio funcionando para todo el mundo.

6 · Monitoreo

Ya en producción se mide todo: cuánto tarda cada respuesta, cuántas fallan y si el modelo sigue acertando. Eso es el monitoreo. Y aquí viene lo que más sorprende al principio: aunque nadie toque el modelo, con el tiempo empieza a fallar más, porque el mundo cambia y llegan fotos distintas a las de su entrenamiento. A ese cambio en lo que llega se le llama drift. Cuando pasa, se juntan datos nuevos y se vuelve a la etapa 1: es el reentrenamiento. Sale: la señal de que hay que reentrenar y las fotos nuevas para etiquetar.

Ahora juntemos todo en la escena del principio. Cuando Ana sube la foto, pasa esto:

El mensaje que los servidores del marketplace le mandan a la API se llama request, y lo que regresa se llama response. El tiempo que pasa entre una request y su response es la latencia. C01 se compromete a que 99 de cada 100 respuestas tarden menos de 200 milisegundos, más o menos lo que dura un parpadeo, sin contar el viaje por internet hasta el celular de Ana.

Fíjate en dos detalles de esa promesa. Tiene un número que se puede medir: no dice «rápido», dice «menos de 200 ms, 99 de cada 100 veces». Y dice dónde se mide: del lado del servidor, desde que la request completa llega hasta que sale la respuesta. Lo que tarda la foto en subir depende de la señal del celular de Ana, y eso nadie en el marketplace lo controla. En la Ronda, a una promesa así, con número y con lugar donde se mide, se le llama SLO.

¿Y por qué «99 de cada 100» y no el promedio? Porque el promedio esconde a quienes esperan mucho. Lo ves con números en la sección extra «El presupuesto de 200 milisegundos».

Cuando la respuesta no llega a tiempo

¿Y si un día el modelo tarda 2 segundos, o no contesta? Ana no debería quedarse viendo una pantalla trabada. Por eso los servidores del marketplace esperan la respuesta un tiempo máximo: 300 ms. A ese tiempo máximo de espera se le llama timeout. Si se cumple y no llegó nada, dejan de esperar y le muestran a Ana el selector de categorías de siempre, para que la elija a mano.

Ese plan B es el fallback. Es peor que la sugerencia, pero Ana puede publicar igual: el sistema se degrada, no se cae. Y no es un detalle para casos rarísimos. Además de la de velocidad, C01 tiene una segunda promesa: que el 99.9 % de las requests respondan sin error y antes de los 300 ms. Suena a casi siempre, pero C01 responde unos 10 millones de fotos al día (cada publicación trae varias fotos, y otros equipos también le preguntan), unos 300 millones al mes. El 0.1 % que queda son hasta 300 mil fotos al mes sin sugerencia: 300,000,000 × 0.001 = 300,000. Todo lo que está en el camino de una persona que espera necesita su fallback.

¿Por qué 300 ms y no 5 segundos? Porque la sugerencia solo sirve mientras Ana todavía no elige la categoría. Si llega tarde, ya no le ayuda a nadie.

Hasta aquí seguiste a una sola foto. Pero un sistema de ML hace dos trabajos muy distintos a la vez, cada uno con su propio reloj.

El camino online es todo lo que pasa mientras alguien espera la respuesta: llega la request, se prepara la foto, el modelo calcula y sale la respuesta. Su reloj son los milisegundos.

El camino offline es todo lo que prepara la siguiente versión del modelo sin que nadie esté esperando: juntar fotos nuevas, ponerles su etiqueta, entrenar, examinar y aprobar. Su reloj son las horas, los días y las semanas.

Sus reglas son distintas, y casi todas salen de esa diferencia de relojes:

La pregunta que decide en qué camino vive algo es una sola: ¿alguien está esperando la respuesta? Sugerir la categoría mientras Ana escribe: sí, así que va online, con su presupuesto de tiempo y su fallback. Clasificar de una vez las ≈ 200 millones de fotos viejas del catálogo, publicadas antes de que existiera el modelo: nadie espera cada respuesta, así que va offline, en tandas y sin tocar el camino de Ana. En la Ronda a ese trabajo se le llama backfill.

Las seis etapas, en los dos caminos

Las seis etapas y los dos caminos son dos formas de cortar el mismo sistema. Las etapas responden «¿qué hay que construir, y en qué orden?». Los caminos responden «¿cuándo corre cada pieza, y con qué reloj?».

• Datos y Modelo viven en el camino offline: juntar, etiquetar, entrenar y examinar.
• API, Contenedor y Orquestación se construyen una vez por versión, pero lo que construyen trabaja en el camino online, en cada request.
• Monitoreo mira a los dos: mide cada request y avisa cuando toca darle otra vuelta al camino offline.

Los dos puentes

Los dos caminos no viven aislados: se tocan en dos puntos.

1. 1

   Del online al offline: el registro

   Cada request deja una línea: cuándo llegó, qué respondió el modelo, con qué versión y cuánto tardó. Se escribe aparte, sin hacer esperar a Ana. De esas líneas salen las fotos nuevas, las pistas para etiquetarlas y las alarmas de drift: lo que el camino offline sabe de lo que está pasando en producción, lo sabe por aquí.

2. 2

   Del offline al online: el deploy

   La versión que pasó el examen se pone a responder poco a poco, como viste en «¿Qué significa producción?». Es la única puerta por la que algo del camino offline le llega a Ana.

Sin el primer puente, el modelo nunca aprende nada nuevo. Sin el segundo, lo que aprende nunca le llega a nadie. En la Ronda, dibujar solo el camino online es el error más común de quien viene de entrenar modelos, y el entrevistador anota «no closed loop»: el ciclo no se cierra.

Por qué nunca se termina

De los dos caminos sale una idea que conviene llevarse: un modelo en producción no es un proyecto que se termina, es algo que se cuida.

Aunque nadie toque el modelo, el mundo sí cambia: salen modelos nuevos de tenis, cambian las modas, los celulares toman fotos con otra luz. Las fotos que llegan se van pareciendo menos a las del entrenamiento y el modelo acierta un poco menos cada mes. Nadie rompió nada. El monitoreo lo detecta, se etiquetan fotos nuevas, se reentrena y la versión nueva reemplaza a la anterior. Y el ciclo vuelve a empezar.

En el Dojo pasa además otra cosa: el 1 de octubre el negocio agrega la categoría «bolsas». El modelo no puede sugerir «bolsas» porque esa opción ni siquiera existe entre sus respuestas, así que elige la más parecida que conoce. Eso no es drift: es un cambio en las categorías, y obliga a reentrenar antes de lo planeado.

Las confusiones que más se repiten al empezar, y cómo evitarlas.

1. Confundir entrenar con usar. «El modelo aprende de cada foto que le subes», o «responder tarda horas». Entrenar mueve las perillas y se hace de vez en cuando; usar solo calcula y pasa millones de veces al día. Cómo evitarlo: pregúntate «¿se mueven las perillas?». Si sí, es entrenamiento; si no, es inferencia.
2. Creer que 95 % en tu laptop significa «listo». Ese número dice que el modelo acierta en tus fotos de prueba. No dice si responde en 200 ms, si aguanta cientos de fotos por segundo en la hora pico, si sigue acertando con las fotos borrosas de celulares reales ni qué pasa cuando falla. Cómo evitarlo: recorre las seis etapas y pregunta en cada una «¿esto ya existe?».
3. Creer que el modelo aprende en vivo. El modelo que responde tiene sus perillas fijas. Lo que aprende del mundo entra por el camino offline, con datos revisados y un examen, y llega como versión nueva. Aprender en vivo existe, pero es raro y arriesgado: sin examen, un error o un ataque se vuelve parte del modelo al instante. Cómo evitarlo: cuando oigas «aprende de los usuarios», pregunta cada cuánto se reentrena y quién aprueba la versión nueva.
4. Ignorar el drift. «Nadie lo ha tocado, así que sigue igual de bien». El mundo cambia aunque el modelo no, y el modelo puede equivocarse más sin lanzar ningún error. Cómo evitarlo: vigila al modelo y no solo al servidor: mide con etiquetas nuevas y compara las fotos de hoy con las del entrenamiento.
5. Olvidar el fallback. Sin plan B, el día que el modelo tarda o se cae, la persona se queda viendo una pantalla trabada. Cómo evitarlo: para cada pieza que está en el camino de alguien que espera, decide cuánto se espera como máximo y qué se hace si la respuesta no llega.
6. Dibujar solo el camino online. Foto → API → modelo → respuesta, y listo. Falta de dónde salen las etiquetas, cómo se entrena la próxima versión, cómo sabes que es mejor y cómo te enteras de que la actual empeoró. Cómo evitarlo: dibuja siempre los dos caminos con sus dos puentes: el registro (de online a offline) y el deploy (de offline a online).

Resuelve cada uno en papel antes de abrir la solución. Los medios te piden razonar con dos ideas a la vez, y los retos, usar todo el camino en un caso nuevo.

1. 1Fácil

   Para cada frase, di si es entrenamiento o inferencia. (a) El modelo de C01 recibe la foto de Ana y responde «Calzado › Tenis, 94 %». (b) Se le muestran 1.8 millones de fotos con su categoría y sus perillas cambian un poquito con cada grupo. (c) Una app de galería ordena tus fotos por tema mientras el celular se carga de noche, con un modelo que ya trae instalado. (d) Un equipo ajusta un modelo de lenguaje con 10 mil conversaciones de su área de soporte.

   Ver la solución paso a paso

   La pregunta que decide es una: ¿se mueven las perillas?

   • (a) Inferencia. El modelo ya entrenado solo calcula.
   • (b) Entrenamiento. Ver ejemplos con su respuesta y ajustar las perillas es justo eso.
   • (c) Inferencia. El modelo ya viene entrenado y solo calcula, aunque nadie mire la pantalla.
   • (d) Entrenamiento. Ajustar con datos propios un modelo que ya existía también mueve perillas: es un fine-tuning.
2. 2Fácil

   ¿En qué etapa del camino vive cada cosa? (a) Docker. (b) Kubernetes. (c) Personas que revisan si una foto es «Tenis» o «Botas». (d) El examen del modelo nuevo con fotos que nunca vio. (e) Medir cuánto tarda cada respuesta. (f) El programa que recibe la foto y regresa la categoría.

   Ver la solución paso a paso

   • (a) Contenedor. Docker es la herramienta más usada para crear contenedores.
   • (b) Orquestación. Kubernetes decide cuántas copias correr, en qué máquinas y cuáles reemplazar.
   • (c) Datos. Están poniendo etiquetas.
   • (d) Modelo. El modelo nuevo se aprueba solo si pasa el examen.
   • (e) Monitoreo.
   • (f) API. Es la ventanilla por donde se le pregunta al modelo.
3. 3Fácil

   Otro marketplace, más chico, recibe 400 mil publicaciones al día, con 5 fotos cada una, y su modelo responde cada foto por separado. (a) ¿Cuántas fotos por segundo le llegan en promedio? (b) Si en la hora pico llega el triple del promedio, ¿para cuántas por segundo tiene que estar listo?

   Ver la solución paso a paso

   Fotos al día

   400,000 × 5

   =2,000,000

   Un día, en segundos

   24 × 60 × 60

   =86,400 s

   Promedio

   2,000,000 ÷ 86,400 s

   ≈ 23 por segundo

   Hora pico

   23 × 3

   ≈ 69 por segundo

   Resultado

   Tiene que aguantar ≈ 70 fotos por segundo, aunque el promedio sea 23.

4. 4Fácil

   En un rato llegan 100 fotos: 95 tardan 40 ms y 5 tardan 1 segundo. (a) ¿Cuánto tardan en promedio? (b) Ordenadas de la más rápida a la más lenta, ¿cuánto tarda la número 99? (c) ¿Se cumple la promesa de C01?

   Ver la solución paso a paso

   • (a) Promedio: (95 × 40 + 5 × 1,000) ÷ 100 = (3,800 + 5,000) ÷ 100 = 88 ms. Se ve muy bien.
   • (b) Las 95 rápidas ocupan los lugares 1 a 95 y las 5 lentas, del 96 al 100. La número 99 es lenta: 1,000 ms.
   • (c) No. La número 99 tarda 1,000 ms, no menos de 200. Además, las 5 lentas pasan de 300 ms: a esas 5 personas el marketplace les mostró el selector manual. El promedio escondía todo eso.
5. 5Medio

   Los dos ejes. Para cada caso di dos cosas: si es entrenar o usar, y si es online u offline. (a) Ana sube su foto y recibe la sugerencia. (b) El reentrenamiento del mes. (c) El examen del mes: el modelo nuevo responde las 50 mil fotos del golden set. (d) Clasificar de una vez las ≈ 200 millones de fotos viejas del catálogo. (e) Un modelo que ajusta sus perillas con cada clic de los usuarios, al instante.

   Ver la solución paso a paso

   Hay que hacer dos preguntas por separado: «¿se mueven las perillas?» y «¿alguien está esperando?».

   Caso	¿Entrenar o usar?	¿Online u offline?
   (a) La foto de Ana	Usar	Online: Ana espera
   (b) El reentrenamiento	Entrenar	Offline
   (c) El examen del mes	Usar: las perillas no se mueven	Offline: nadie espera cada respuesta
   (d) Las fotos viejas	Usar	Offline: va en tandas, sin tocar el camino de Ana
   (e) Ajustar con cada clic	Entrenar	Online: en vivo, dentro del sistema que responde

   El (e) existe y se llama aprendizaje en línea (online learning). Ahí «en línea» quiere decir que se ajusta en vivo, en el mismo sistema que responde: nadie espera el ajuste, pero le pega al instante a la siguiente respuesta. Es raro: necesita la respuesta correcta en segundos o minutos (en fraude tarda meses) y, sin examen de por medio, un error o un ataque se vuelve parte del modelo al instante. C01 no lo hace.

6. 6Medio

   Esta vez Ana publica desde la web, no desde la app, y sube la foto original de su cámara, de muchos megapíxeles. En el caso lento, el preprocesamiento tarda 120 ms en lugar de 52. Los demás pasos quedan como en el presupuesto de C01: red y entrada 40 ms, modelo 27 ms, respuesta 3 ms y el propio programa 30 ms. (a) ¿Cuánto suma? (b) ¿Se cumple la promesa? (c) ¿Ana recibe sugerencia? (d) ¿Qué cambiarías?

   Ver la solución paso a paso

   Los otros pasos

   40 + 27 + 3 + 30

   =100 ms

   Total

   100 + 120

   =220 ms

   Contra la promesa

   220 − 200

   =20 ms de más

   Contra los 300 ms del marketplace

   300 − 220

   =80 ms de sobra

   Resultado

   En ese caso lento la promesa de 200 ms no se cumple, pero Ana sí recibe su sugerencia.

   (d) El problema está en lo que entra, así que se ataca ahí: achicar la foto antes de subirla (la app de C01 ya la reduce a 1024 píxeles de lado largo) y ponerle un límite de tamaño a lo que llega de la web. Compruébalo en la calculadora: con el preprocesamiento en 120 ms, el margen sale en −20 ms.

7. 7Medio

   ¿Es drift? Para cada situación di si es drift y, si no, qué es. (a) Llega diciembre y suben las fotos de adornos, suéteres y juguetes. (b) El negocio agrega la categoría «bolsas». (c) Sale un celular muy popular que toma fotos más brillantes y con más contraste. (d) Alguien cambia el código de la API y ahora la foto le llega al modelo con los colores en otro orden. (e) Las respuestas tardan más en la hora de más tráfico.

   Ver la solución paso a paso

   • (a) Drift. Las fotos que llegan cambiaron con la temporada. Más adelante verás que tiene un nombre más exacto: cuando cambia sobre todo cuánto llega de cada categoría, se llama label shift.
   • (b) No es drift: es un cambio en las categorías. El modelo ni siquiera tiene «bolsas» entre sus respuestas. Toca reentrenar con la categoría nueva.
   • (c) Drift. Las fotos se parecen menos a las del entrenamiento, aunque los productos sean los mismos.
   • (d) No es drift: es un bug. El mundo no cambió; cambió cómo el programa prepara la foto, que ya no es igual que en el entrenamiento. Tiene nombre: training-serving skew. Se arregla el código, no se reentrena.
   • (e) No es drift: es carga. El modelo acierta igual; lo que faltan son copias. Es trabajo de la orquestación.
8. 8Reto

   Una app de comida a domicilio muestra «Llega en 35 min» cuando confirmas tu pedido. (a) ¿Qué parte es el camino online y qué tan rápido tendría que ser? (b) ¿De dónde salen las etiquetas del camino offline? (c) ¿Qué fallback pondrías? (d) ¿Cuáles son los dos puentes?

   Ver la solución paso a paso

   • (a) Online: al confirmar, la app manda el restaurante, tu dirección y la hora, y el modelo predice el tiempo. Tú estás esperando esa pantalla, así que tiene que ser rápido: del orden de cientos de milisegundos, como C01 (es un supuesto razonable, no un dato).
   • (b) Etiquetas: el tiempo real de entrega, que se sabe cuando el pedido llega a tu puerta. Hay que guardar cada predicción y, cuando llegue el tiempo real, juntar las dos.
   • (c) Fallback: un tiempo fijo por zona o el promedio de ese restaurante, como «30–45 min». Es peor que el modelo, pero nunca deja la pantalla vacía.
   • (d) Puentes: el registro de cada predicción con su tiempo real (de online a offline) y el deploy del modelo reentrenado (de offline a online).
9. 9Reto

   Moderación quiere revisar con otro modelo si cada foto trae un producto prohibido. En el caso lento, ese modelo tarda 60 ms. (a) Si va en el camino de Ana, después del clasificador, ¿cuánto suma el caso lento de C01, que era de 152 ms, y qué margen queda contra los 200 ms? (b) ¿Ana está esperando esa respuesta? ¿Dónde lo pondrías y qué ganas?

   Ver la solución paso a paso

   Presupuesto de C01, caso lento

   40 + 52 + 27 + 3 + 30

   =152 ms

   Con el modelo de moderación

   152 + 60

   =212 ms

   Contra la promesa

   200 − 212

   =−12 ms

   Resultado

   En el caso lento ya no cabe en los 200 ms, y todo por un modelo que Ana ni siquiera necesita.

   (b) No. Para sugerirle «Tenis» no hace falta saber si el producto está prohibido, así que ese modelo va aparte, sin que nadie espere cada respuesta: otro servicio revisa la foto segundos o minutos después (y si hubiera que frenar la publicación, al publicar, con su propio reloj).

   Ganas tres cosas: Ana conserva sus 48 ms de margen, si moderación falla ella ni se entera, y moderación puede usar un modelo más lento y más preciso. La Ronda hace lo mismo: en C01, la moderación es otro sistema, fuera de la API de categorías.

• En Sensei. La siguiente lección, «Qué es un modelo», abre la caja: qué hace el modelo por dentro y qué significa de verdad el «94 %». Después vienen cómo ve una foto, con qué aprende, cómo aprende y cómo saber si aprendió. Las cuentas de esta lección (percentiles, requests por segundo, qué tan seguido falla algo) se hacen a fondo en el módulo «Números y estadística para producción».
• En la Ronda. M01 · El mapa y la entrevista arranca justo aquí: el ciclo de vida, la figura de Sculley y los dos caminos separados, que es lo primero que un entrevistador busca en tu diagrama. Su arquitectura de referencia es este mismo camino con más cajas (una puerta de entrada o gateway, un registro con las versiones aprobadas del modelo, un feature store que guarda datos ya preparados y una tarea diaria que busca drift), y sus estimaciones son las de la sección de números: 116, 350 y 500 requests por segundo. M02 · Patrones de inferencia desarrolla la pregunta «¿alguien está esperando?», M03 · Latencia y capacidad reparte el presupuesto de 200 ms tramo por tramo, M11 · Despliegue seguro hace el deploy poco a poco y M12 · Monitoreo caza el drift.
• En el Dojo. Practicas el mismo C01 estación por estación, con código de verdad: son las 12 estaciones de esta lección.

Estos son los conceptos que presentó esta lección. Cada uno tiene una lección donde se ve a fondo, más adelante.

Intenta responder en tu cabeza antes de abrir cada respuesta.

1. 1¿Cuál es la diferencia entre entrenar un modelo y usarlo?Ver respuesta

   Al entrenar, el modelo ve ejemplos con su respuesta correcta y ajusta sus parámetros. Es lento y se hace de vez en cuando. Al usarlo (inferencia), recibe un caso nuevo sin respuesta y solo calcula, con los parámetros fijos. Es rápido y pasa millones de veces.

2. 2Un modelo acierta 95 % en tu laptop. ¿Ya está en producción?Ver respuesta

   No. Le falta todo lo demás: que alguien le pueda preguntar (API), que corra igual en otras máquinas (contenedor), que aguante a millones de personas sin caerse (orquestación) y que alguien vigile que siga acertando (monitoreo).

3. 3¿Qué es el camino online, qué es el offline y cuál es el reloj de cada uno?Ver respuesta

   El online es lo que pasa mientras alguien espera la respuesta: milisegundos (en C01, 99 de cada 100 fotos en menos de 200 ms). El offline prepara la siguiente versión sin que nadie espere, con datos, etiquetas, entrenamiento y examen: horas, días o semanas (en C01, una vuelta al mes).

4. 4¿Cuáles son los dos puentes entre los dos caminos?Ver respuesta

   El registro de cada request, que lleva lo que pasó en el online hacia el offline, y el deploy, que lleva la versión aprobada del offline al online. Sin el primero el modelo no aprende nada nuevo; sin el segundo, lo que aprende no le llega a nadie.

5. 5¿Qué pasa si la API de C01 no contesta en 300 ms, y por qué existe ese plan?Ver respuesta

   El marketplace deja de esperar y le muestra a Ana el selector de categorías: es el fallback. Existe porque todo falla alguna vez: aun cumpliendo su promesa del 99.9 %, hasta 300 mil fotos al mes se quedan sin sugerencia.

6. 6¿Por qué un deploy se hace poco a poco y no de golpe?Ver respuesta

   Para que, si la versión nueva trae un problema, solo le pegue a unos pocos. En C01 responde primero 5 de cada 100 fotos, luego 25 y luego todas; si algo empeora, se regresa sola a la anterior.

7. 7Nadie ha tocado el modelo en seis meses y ahora se equivoca más. ¿Cómo puede ser?Ver respuesta

   Porque el mundo cambió: llegan fotos distintas a las del entrenamiento. Eso es drift. La solución es juntar y etiquetar datos nuevos y reentrenar. (Si además aparece una categoría nueva, el modelo ni siquiera puede elegirla: también toca reentrenar.)