AWS Certified AI Practitioner
Anatomía de un pipeline de ML
Las etapas que llevan un modelo de los datos crudos al monitoreo en producción: recolección, EDA, preprocesamiento, ingeniería de características, entrenamiento, ajuste, evaluación, despliegue y monitoreo, y por qué el pipeline es un ciclo y no una línea.
- Enumerar las etapas de un pipeline de ML en orden, de la recolección de datos al monitoreo
- Distinguir EDA, preprocesamiento e ingeniería de características, que se confunden todo el tiempo
- Explicar por qué el despliegue no es la meta final y el monitoreo cierra el ciclo de vuelta a los datos
- Ubicar una actividad descrita en la etapa del pipeline a la que pertenece
Un modelo con 95% de exactitud en un notebook de tu computadora no es un producto. Entre ese resultado prometedor y un sistema en el que tus usuarios puedan confiar hay una serie de pasos que la mayoría de los principiantes subestima: conseguir los datos correctos, limpiarlos, darles forma, entrenar, probar, publicar y después vigilar el modelo en el mundo real para que no se pudra en silencio. Esa serie de pasos es el pipeline de ML, y el examen espera que nombres sus etapas, distingas las que se confunden y entiendas por qué nunca termina del todo. Esta lección recorre el camino completo una vez, de punta a punta.
Fija una meta concreta que ancle cada etapa: un banco quiere un modelo que prediga qué clientes están a punto de cerrar su cuenta, para contactarlos antes de que se vayan. Vamos a seguir ese modelo de churn desde los datos crudos hasta producción.
El pipeline de un vistazo
El pipeline tiene un orden natural, y el orden importa: cada etapa depende de la anterior y no puedes saltarte pasos.
Léelo en tres bloques. Primero preparas los datos (recolección, EDA, preprocesamiento, ingeniería de características). Después construyes el modelo (entrenamiento, ajuste, evaluación). Y luego lo corres en producción (despliegue, monitoreo). Y el monitoreo vuelve al inicio. Ahora recorramos cada etapa con el modelo de churn en la mano.
Preparar los datos
La recolección de datos va primero porque un modelo solo puede aprender de lo que le das. Para el modelo de churn eso significa reunir el historial de cuentas, los registros de transacciones, los tickets de soporte y la actividad de login, y juntarlo todo en un mismo lugar. La regla que gobierna toda esta fase: basura entra, basura sale. Ninguna etapa posterior puede rescatar un modelo entrenado con datos equivocados o incompletos.
El análisis exploratorio de datos (EDA) es la etapa de mirar antes de saltar. Antes de cambiar un solo valor, exploras qué contienen realmente los datos: cuántas cuentas tienes, qué campos faltan, si "saldo" a veces es negativo, si los clientes que se fueron son pocos (normalmente lo son). El EDA no transforma los datos. Construye tu entendimiento de ellos, y ese entendimiento moldea cada decisión que sigue.
El preprocesamiento de datos es la etapa de limpieza. Los datos reales son un desorden: valores faltantes, filas duplicadas, formatos inconsistentes ("USA" contra "EE.UU." contra "Estados Unidos"), errores obvios como una edad de 200 años. El preprocesamiento corrige todo eso para que los datos queden consistentes y usables. Completas o descartas valores faltantes, estandarizas formatos y eliminas registros malos.
La ingeniería de características es donde construyes las entradas reales de las que aprenderá el modelo, llamadas features. Esto no es limpieza; es creación. De una marca de tiempo cruda de "último login" puedes derivar "días desde el último login". De un año de transacciones puedes calcular "gasto mensual promedio" y "tendencia del gasto en los últimos 3 meses". Las buenas características son muchas veces lo que separa un modelo mediocre de uno fuerte, porque le entregan al algoritmo la señal en una forma que puede usar.
Estas tres etapas de datos se confunden constantemente, así que fija la distinción ahora. EDA es entender, preprocesamiento es limpiar, ingeniería de características es crear. Un valor faltante: el EDA lo detecta, el preprocesamiento lo completa, la ingeniería de características no tiene nada que ver con él. Ese ejemplo mínimo separa las tres.
Construir el modelo
El entrenamiento del modelo es la etapa que casi todos imaginan cuando piensan en machine learning, aunque a estas alturas ya ves que es solo un paso entre muchos. Le das los datos preparados a un algoritmo y este aprende los patrones que unen las características con el resultado (aquí, las características con "se fue o se quedó"). La salida es un modelo entrenado.
El ajuste de hiperparámetros afina la configuración que controla cómo ocurre el entrenamiento. Estos valores no se aprenden de los datos; los defines tú. Piensa en el número de capas de una red o en qué tan rápido se corrige el modelo durante el entrenamiento. El ajuste prueba distintas combinaciones para encontrar las que producen el mejor modelo, muchas veces de forma automática. Son las perillas del proceso de entrenamiento, no de los datos.
La evaluación es la prueba de honestidad. Mides el modelo con datos que nunca vio durante el entrenamiento, un conjunto de prueba apartado, porque un modelo que memorizó sus datos de entrenamiento puede verse perfecto y aun así fallar con clientes reales. Si el modelo de churn atrapa solo al 40% de los clientes que de verdad se van, la evaluación es donde te enteras antes que tus usuarios. La lección de métricas profundiza en esto; por ahora, quédate con que la evaluación es la puerta entre "entrenado" y "confiable".
Correr en producción
El despliegue pone el modelo a trabajar. Lo dejas disponible para que el resto de los sistemas del banco le manden un cliente y reciban de vuelta un score de churn, ya sea con un endpoint siempre activo que responde en tiempo real o con un job nocturno que califica todas las cuentas de una vez. La lección siguiente cubre esas opciones de despliegue en detalle.
El monitoreo es la etapa que los principiantes olvidan, y es donde los modelos fallan en silencio. Un modelo de churn entrenado con el comportamiento del año pasado puede ir perdiendo exactitud a medida que los clientes cambian, la economía se mueve o el banco lanza productos nuevos. Esto se llama drift. El monitoreo vigila el modelo en vivo para que detectes la caída y actúes, normalmente reuniendo datos frescos y reentrenando. Esa es la flecha que vuelve al inicio.
Aquí está la idea equivocada que conviene matar: creer que publicar el modelo es la meta final. No lo es. Un modelo desplegado es un activo perecedero. El pipeline es un ciclo, no una línea, porque el mundo que el modelo describe sigue moviéndose, y un modelo que nunca se reentrena es un modelo que se va quedando viejo.
Consejos para el examen
- Conoce el orden de las etapas y prepárate para ubicar una actividad en él. "Graficar distribuciones para entender los datos" es EDA; "completar valores faltantes" es preprocesamiento; "crear un campo de días desde la última compra" es ingeniería de características.
- La trampa más común es mezclar EDA, preprocesamiento e ingeniería de características. Fija los verbos: entender, limpiar, crear. Un enunciado que describe limpieza es preprocesamiento, aunque use la palabra "preparar".
- "La exactitud del modelo cayó tres meses después del lanzamiento" es un escenario de monitoreo y drift, y la solución es reentrenar, no volver a desplegar el mismo modelo.
- Ojo con las respuestas que tratan el despliegue como la última etapa. El monitoreo viene después, y el pipeline vuelve a los datos.
Llévate una sola imagen de esta lección: entran datos, sale un modelo, va a producción y regresa a los datos. Cada servicio de AWS de las próximas lecciones se conecta a una de estas etapas, y MLOps (más adelante en este tema) es la disciplina de correr todo este ciclo de forma confiable y repetible. Lo que sigue es de dónde salen esos modelos y cómo los pones realmente en producción.
