Último caso de estudio del módulo. En el módulo 5 entrenaste clasificadores, regresores, redes y clustering sobre el dataset de 2000 entregas de Rutalia — en un notebook, con datos limpios y una métrica al final. Esta lección trata de lo que pasa después: cuando ese modelo tiene que tomar decisiones cada minuto, con datos que cambian, usuarios que dependen de él y consecuencias si se equivoca. Veremos qué cambia del laboratorio a producción, recorreremos los grandes dominios de aplicación conectándolos con lo que ya construiste (desarrollando de verdad uno nuevo: el filtrado colaborativo de los sistemas de recomendación), estudiaremos el ciclo de vida real de un modelo —drift, reentrenamiento, monitorización—, aprenderemos de fallos célebres, y terminaremos con lo que ninguna métrica captura: la ética y la regulación de las decisiones automatizadas sobre personas.

1. Del notebook a producción: qué cambia
2. Mapa de dominios: dónde trabaja cada algoritmo del módulo 5
3. Caso desarrollado: un sistema de recomendación con filtrado colaborativo
4. El ciclo de vida real: drift, reentrenamiento y monitorización
5. Fallos célebres y sus lecciones
6. Ética y regulación: decidir sobre personas
7. El caso Rutalia: dos usos del mismo modelo, dos veredictos
8. Cierre del módulo: los cuatro casos de estudio

El modelo es el mismo; el entorno lo cambia todo:

La consecuencia práctica: en producción, el modelo es la pieza pequeña. La mayor parte del sistema es fontanería de datos (el módulo 6-03 que acabas de ver: ingesta, deduplicación, agregación), validación, monitorización y gobernanza. Los equipos que fracasan suelen fracasar en la fontanería, no en el algoritmo.

Tres notas de modelado antes del caso desarrollado:

• ETA en logística es la versión en producción de lo que ya hiciste: el modelo de minutos_entrega de 05-03 sirviendo predicciones en tiempo real. Las apps de reparto y navegación hacen exactamente eso, con más variables (tráfico en vivo) y reentrenamiento continuo.
• Fraude es el reino de la trampa de la exactitud de 05-02: con un 0,3 % de positivos, el modelo "nunca es fraude" tiene 99,7 % de exactitud y valor cero. En producción se opera sobre precision/recall eligiendo el umbral según el coste asimétrico (dejar pasar un fraude cuesta X, molestar a un cliente legítimo cuesta Y) — y DBSCAN (05-05) aporta la vía no supervisada: el fraude nuevo no está etiquetado, pero suele ser ruido que no encaja en ningún patrón de comportamiento.
• Visión y lenguaje: solo panorama. Las redes que escribiste en numpy en 05-04 son, conceptualmente, lo que hay dentro — backprop y descenso de gradiente no cambian; cambian la arquitectura (convoluciones, atención), la escala (miles de millones de parámetros) y el hardware. No lo desarrollamos aquí: el punto del caso de estudio es que ya conoces el mecanismo básico.

La pieza nueva de la lección, ligera pero completa. Rutalia reparte para un marketplace y quiere recomendar productos: "quien compró esto también compró...". La técnica clásica es el filtrado colaborativo: no necesita saber nada de los productos (ni categoría, ni precio) — solo la matriz usuario-ítem de interacciones. La hipótesis: usuarios con historial parecido seguirán pareciéndose en el futuro.

¿Te suena la receta? Es el k-NN de 05-01 con dos cambios: el "espacio" son las filas de la matriz usuario-ítem, y la distancia se sustituye por la similitud coseno (el ángulo entre vectores, que ignora cuánto compra cada uno y mira solo el patrón). Y es también, en el fondo, la recomendación de amistades de 06-02 —vecindarios que se solapan—, con matriz en lugar de grafo.

Lee el resultado de U-305 (mochila, funda): sus vecinos son U-301 (comparte ambas) y U-302 (comparte la mochila), así que le recomienda botella con fuerza — el patrón "mochila+funda" arrastra al de U-301. Nadie le recomienda el cargador: sus compradores no se parecen a U-305 en nada. Eso es filtrado colaborativo: la estructura de co-compras hace todo el trabajo, sin una sola etiqueta ni descripción de producto.

Lo que separa este juguete de un sistema real (y dónde encajan piezas del curso):

• Escala: millones de usuarios × millones de ítems, matriz 99,9 % vacía. Se usan representaciones dispersas, hashing (01-04) y vecinos aproximados; el cálculo de similitudes por lotes es un trabajo divide-agrupa-combina (06-03).
• Arranque en frío: un usuario nuevo no tiene fila. Se cubre con popularidad o con atributos del ítem (contenido) hasta acumular historial.
• Realimentación: el sistema recomienda → el usuario ve solo lo recomendado → los datos futuros reflejan las recomendaciones, no las preferencias. Los sesgos de esta lección empiezan aquí.

En el laboratorio, el flujo era lineal: datos → entrenar → evaluar → fin. En producción es un ciclo, porque el mundo no firma un contrato de estabilidad con tu modelo:

Drift es el nombre del enemigo, en dos sabores:

• Drift de datos: la distribución de entrada cambia. Rutalia abre reparto en una ciudad nueva: las distancias y zonas ya no se parecen a las del dataset de 2000 entregas. El modelo no "se rompe": responde con seguridad sobre un mundo que ya no existe — está extrapolando, el pecado que ya viste en la regresión de 05-03.
• Drift de concepto: cambia la relación entre entrada y salida. Mismo tráfico, mismas distancias, pero se reforman las calles del centro: los mismos rasgos ahora implican otros tiempos.

Defensas estándar, todas con herramientas que ya tienes:

• Monitorizar la entrada, no solo la salida: comparar la distribución reciente de cada variable con la de entrenamiento (medias, percentiles, histogramas — los resúmenes de una pasada de 06-03). Las alarmas de drift de datos no necesitan etiquetas y avisan antes de que el error suba.
• Monitorizar dos capas de métricas: las del modelo (error de predicción cuando llega la etiqueta real: el minutos_entrega observado) y las de negocio (quejas por retraso no avisado, tasa de clics de las recomendaciones). Pueden divergir — un modelo puede mejorar su MSE y empeorar la experiencia si mejora donde no importa. Manda la métrica de negocio.
• Reentrenar con criterio: con calendario (semanal/mensual) o disparado por alarmas de drift. Siempre contra un conjunto de validación temporal — entrenar con pasado, validar con presente; nunca al revés (es la versión temporal del train/test de 05-02).
• Pipeline reproducible: datos versionados, código versionado, semillas fijas, modelo etiquetado. Si el modelo de la semana 12 falla, tienes que poder reconstruirlo exactamente para diagnosticar. Sin reproducibilidad no hay depuración, solo arqueología.

Casos genéricos, todos documentados en la industria repetidas veces:

• Sesgo en los datos → modelo sesgado. Una empresa entrena un filtro de currículums con sus contrataciones históricas; como históricamente contrató a pocos perfiles de cierto grupo, el modelo aprende a penalizar rasgos correlacionados con ese grupo. El modelo no "se equivocó": aprendió exactamente lo que había en los datos — el sesgo histórico era el patrón dominante. Lección: los datos son un espejo del pasado; si el pasado es injusto, el modelo automatiza la injusticia con apariencia de objetividad. La auditoría del dato (¿a quién representa? ¿a quién no?) va antes que la del modelo.
• Data leakage: el modelo que copiaba. Un modelo hospitalario "predecía" perfectamente una enfermedad… usando una variable que solo se rellenaba después del diagnóstico. En Rutalia: predecir el retraso usando la hora real de entrega, o una media de retrasos calculada sobre TODO el histórico (incluido el futuro del registro). Resultados de test espectaculares, producción inútil. Lección: por cada variable, pregunta "¿estaría disponible en el momento de predecir?". Un resultado demasiado bueno no se celebra: se investiga.
• Correlación ≠ causalidad. El modelo detecta que las entregas con embalaje de regalo llegan más tarde y alguien propone "eliminar el embalaje de regalo para reducir retrasos". Pero el embalaje no causa el retraso: los pedidos de regalo se concentran en campañas de picos de demanda. Quitar el embalaje no moverá nada. Lección: los modelos del módulo 5 son máquinas de correlación excelentes para predecir; usarlos para intervenir ("si cambio X, pasará Y") exige análisis causal o un experimento controlado (A/B test). Predicción e intervención son preguntas distintas.

Cuando la salida de un modelo afecta a personas —un precio, un crédito, una sanción, una oportunidad—, la conversación deja de ser solo técnica:

• Transparencia: quien recibe la decisión debe poder saber que hubo un sistema automatizado implicado y, en lo esencial, qué factores pesaron. Los modelos interpretables (los árboles y regresiones de 05-02/05-03, cuyos coeficientes y reglas se leen) tienen aquí una ventaja real sobre cajas más negras: a igualdad aproximada de rendimiento, el interpretable suele ser mejor elección en decisiones sensibles.
• Supervisión humana: las decisiones con efectos significativos sobre personas no deberían ser completamente autónomas. El patrón sano es el que ya viste en 06-01 con la optimización: el sistema recomienda, la persona decide — y la persona debe tener información y autoridad reales para contradecirlo, no ser un sello de goma.
• Regulación: en Europa, el RGPD limita las decisiones basadas únicamente en tratamiento automatizado con efectos significativos, y el Reglamento europeo de IA clasifica los sistemas por nivel de riesgo e impone a los de alto riesgo (empleo, crédito, servicios esenciales...) obligaciones de gestión de riesgos, calidad del dato, documentación y supervisión humana. No hace falta memorizar el articulado; hace falta el reflejo: si tu modelo puntúa personas, asume que estás en terreno regulado y que las decisiones de diseño (qué datos, qué métrica, qué umbral) tendrán que explicarse ante alguien. Para el detalle de un caso concreto, consulta a los especialistas legales de tu organización — es su terreno, no el del algoritmo.

El clasificador de retrasos de 05-02 (¿llegará tarde esta entrega?) puede desplegarse de dos maneras. Mismo modelo, mismo F1 — y veredictos opuestos:

Este contraste es la síntesis de la lección: la pregunta ética no es "¿es bueno el modelo?" sino "¿qué decisión alimenta y sobre quién recae el error?". El mismo F1 puede ser un buen producto o un problema legal y moral, según el uso. Y nota la ironía técnica del uso B: el retraso depende de la zona, la zona la asignó un algoritmo, y el modelo se la cobraría al repartidor — un sistema penalizando a una persona por las decisiones de otro sistema. Cuando encadenas algoritmos (que es justo lo que este módulo enseña), también encadenas sus responsabilidades.

El patrón común a los cuatro: ningún problema real se resolvió con un algoritmo. Se resolvió modelando (traducir el negocio a problemas canónicos), combinando (encadenar piezas de módulos distintos) y midiendo (línea base honesta, métrica de negocio, validación temporal). Esa tríada es lo que este módulo añadió sobre los cinco anteriores.

• Optimizar la métrica del modelo e ignorar la de negocio. Un F1 mejor que no mueve las quejas de clientes es un número de vanidad. Define la métrica de negocio antes de entrenar.
• Evaluar sin respetar el tiempo. Mezclar pasado y futuro en train/test (o dejar que una variable "del futuro" se cuele: leakage) infla los resultados. Validación temporal siempre que los datos tengan fecha.
• Confiar en un modelo que extrapola. Si la entrada actual no se parece a la de entrenamiento (drift), la confianza del modelo no vale nada. Monitoriza la distribución de entrada, no solo el error.
• Usar predicciones para intervenir. "El modelo dice que X se asocia a retraso" no implica que cambiar X reduzca retrasos. Para intervenciones, experimenta (A/B) o analiza causalmente.
• Automatizar la decisión cuando bastaba automatizar la recomendación. El salto de "el sistema sugiere" a "el sistema decide" es el que dispara el riesgo ético y regulatorio. Dalo solo deliberadamente, con supervisión y vía de apelación.
• Consejo: ante cualquier despliegue, escribe en una página: qué decide el sistema, sobre quién recae cada tipo de error, cómo se detectará que se degrada y quién puede pararlo. Si no puedes escribir esa página, no estás listo para producción.

1. Recomendador ítem-ítem. El filtrado del ejemplo compara usuarios. Impleméntalo al revés: similitud coseno entre columnas (ítems), y recomienda a cada usuario los ítems más similares a los que ya compró. Compara las recomendaciones para U-305 con las del enfoque usuario-usuario. ¿Por qué el enfoque ítem-ítem suele preferirse en producción cuando hay muchos más usuarios que ítems?
2. Detector de drift. Con el generador del dataset de 2000 entregas de 05-01, crea un "mes nuevo" con las distancias aumentadas un 40 % (la ciudad creció). Sin usar la etiqueta, detecta el drift comparando media y percentiles 10/50/90 de cada variable entre el histórico y el mes nuevo, y define un umbral de alarma. Comprueba después cuánto empeora el error del modelo de regresión de 05-03 sobre el mes nuevo.
3. Caza el leakage. Un compañero propone estas variables para predecir retraso en el momento de asignar el pedido: (a) distancia del pedido, (b) hora de salida planificada, (c) media de retrasos del repartidor en los últimos 30 días, (d) minutos reales de la entrega, (e) media de retrasos de la zona calculada sobre todo el dataset, (f) día de la semana. Clasifica cada una como válida, leakage directo o leakage sutil, y justifica.

1. Para U-305 (mochila, funda), la matriz de co-compra da como ítems más cercanos a los suyos la botella (co-comprada con mochila y con funda vía U-301) — coincide con el enfoque usuario-usuario, como es habitual en matrices pequeñas. La preferencia industrial por ítem-ítem: con muchos más usuarios que ítems, la matriz de similitud ítem-ítem es pequeña y estable (los gustos agregados sobre un ítem cambian despacio; un usuario cambia con cada compra), así que puede precalcularse por lotes (06-03) y servirse al instante; además es explicable: "porque compraste una mochila" es una justificación que el usuario entiende — transparencia, que conecta con la sección de ética.
2. Esquema: genera hist y nuevo (con distancia * 1.4), y para cada variable calcula (media_nuevo - media_hist) / desviacion_hist y las diferencias de percentiles. La distancia saltará varias desviaciones (alarma clara con umbral tipo |z| > 0,5); las demás variables no. Al aplicar el modelo antiguo al mes nuevo, el error de minutos_entrega sube de forma notable, porque el modelo extrapola fuera del rango de distancias visto (05-03). El orden importa: la alarma de entrada dispara antes de que exista etiqueta con la que medir el error — esa antelación es el valor del monitoreo de drift.
3. (a) válida — se conoce al asignar. (b) válida — planificada, no real. (c) válida con cuidado — es legítima si la media usa solo los 30 días anteriores a ese pedido; si se calcula sobre una ventana que incluye el propio pedido o fechas posteriores, se vuelve leakage sutil. Además, como puntúa a una persona, arrastra las implicaciones éticas de la lección. (d) leakage directo — es (casi) la respuesta: no existe hasta que la entrega termina. (e) leakage sutil — el agregado "sobre todo el dataset" incluye el futuro del registro que se está prediciendo; en test lucirá de maravilla y en producción no estará disponible tal cual. Debe calcularse solo con datos anteriores a cada pedido. (f) válida. Regla general aplicada: reconstruye el instante de la predicción y pregunta a cada variable "¿ya existías?".

Con esta lección se cierra el módulo de casos de estudio. Has llevado el aprendizaje automático del módulo 5 al mundo real: viste qué cambia del notebook a producción (los datos se mueven, la métrica que manda es la de negocio, el modelo es la pieza pequeña del sistema), desarrollaste un sistema de recomendación por filtrado colaborativo reutilizando el k-NN de 05-01 con similitud coseno sobre la matriz usuario-ítem, aprendiste a vigilar el drift y a reentrenar con validación temporal, extrajiste las lecciones de los fallos célebres —sesgo en los datos, leakage, correlación que no es causalidad— y contrastaste dos usos del mismo modelo de retrasos de Rutalia: avisar a un cliente (bajo riesgo, buen producto) frente a penalizar a un repartidor (decisión automatizada sobre una persona, sesgada por decisiones de otro algoritmo y en terreno regulado). El módulo entero deja una sola idea repetida cuatro veces: los problemas reales no se resuelven con un algoritmo, sino modelando, combinando y midiendo — optimización en la industria (06-01), grafos en redes sociales (06-02), datos que no caben en una máquina (06-03) y modelos con consecuencias (06-04). Ya no queda nada del curso por presentarte: en el módulo 7 el caso de estudio lo eliges tú. Definirás un proyecto final integrador (07-01), lo desarrollarás combinando las piezas de estos seis módulos (07-02) y lo presentarás midiendo resultados como hemos hecho aquí (07-03). Las herramientas son tuyas; ahora, a construir.