¿Cómo aplicar machine learning en un proyecto real desde cero?

Aplicar machine learning en un proyecto real significa seguir un proceso ordenado de seis etapas, desde definir el problema hasta poner el modelo en producción.

¿Cuántos proyectos de ML fracasan antes de llegar a producción?

Adivina: ¿qué porcentaje de proyectos de machine learning nunca llega a usarse en el mundo real?

La respuesta sorprende: según análisis de firmas como Gartner y McKinsey, entre el 70% y el 85% de los proyectos de ML jamás se despliegan. No fallan por falta de datos ni por algoritmos débiles. Fallan porque el equipo no siguió un proceso estructurado desde el inicio.

Eso significa que la habilidad técnica importa menos de lo que crees. Lo que separa a los proyectos exitosos es el orden en que se toman las decisiones.

En esta lección vas a aprender ese orden con un caso real ambientado en México.

El Marco FLUJO: las seis etapas de un proyecto de ML

Llama a este proceso el Marco FLUJO. Cada letra representa una etapa:

• Formulair el problema
• Limpiar y explorar los datos
• Usar un modelo base
• Justar y evaluar
• Optimizar para producción

Cada etapa tiene una salida concreta. Si no tienes esa salida, no avanzas a la siguiente.

Etapa 1 — Formular el problema

Un analista de Liverpool quiere predecir qué clientes van a cancelar su tarjeta de crédito departamental en los próximos 30 días. El objetivo parece claro, pero aún no lo es.

Antes de tocar datos, debes responder tres preguntas:

1. ¿Qué variable voy a predecir? En este caso: si el cliente cancela (sí/no). Eso es clasificación binaria.
2. ¿Qué decisión tomará el negocio con esa predicción? Liverpool enviará una oferta de retención solo a clientes con probabilidad mayor al 60%.
3. ¿Cómo se mide el éxito? El equipo define que el modelo debe tener un recall mínimo del 75% para clientes que sí cancelan.

Si no defines la métrica de éxito aquí, cualquier resultado parecerá bueno después. Ese es el error más común en esta etapa.

Salida de la Etapa 1: un documento de una página con el objetivo, la variable objetivo, la métrica de éxito y las restricciones del negocio (por ejemplo: el SAT exige que el modelo sea auditable, así que una red neuronal profunda queda descartada).

Etapa 2 — Limpiar y explorar los datos

Liverpool tiene registros de $2,400,000$ clientes activos. El equipo extrae una muestra de 80,000 clientes del último año.

Al explorar los datos encuentran tres problemas típicos:

• El 12% de los registros tiene el campo "meses de antigüedad" en blanco.
• La variable "monto de compra mensual" tiene valores extremos: algunos clientes muestran $0$ y otros muestran $180,000$ al mes.
• Solo el 8% de los clientes en la muestra canceló. Los datos están desbalanceados.

Para el primer problema: imputan la mediana (14 meses). Para el segundo: aplican un recorte al percentil 99, dejando el máximo en $42,000$. Para el tercero: usarán la técnica SMOTE para generar ejemplos sintéticos de la clase minoritaria.

Una regla práctica: dedica el 40% del tiempo total del proyecto a esta etapa. Los datos sucios producen modelos sucios, sin importar qué tan sofisticado sea el algoritmo.

Salida de la Etapa 2: un conjunto de datos limpio con al menos 15 variables relevantes, un reporte de distribuciones y una matriz de correlación.

Etapa 3 — Usar un modelo base

Antes de probar redes neuronales o gradient boosting, siempre empieza con el modelo más simple posible. Esto se llama el principio de la línea base.

El equipo de Liverpool entrena una regresión logística en 30 minutos. Resultado: accuracy del 82%, pero recall de la clase "cancela" del 41%. Eso no cumple el objetivo del 75%.

¿Por qué importa esto? Porque ahora sabes exactamente cuánto necesitas mejorar. Sin línea base, no hay referencia.

Salida de la Etapa 3: métricas del modelo base documentadas. Cualquier modelo posterior debe superar estas métricas para justificar su complejidad adicional.

Etapa 4 — Ajustar y evaluar

Con la línea base definida, el equipo prueba tres modelos:

XGBoost cumple el objetivo de recall del 75%. Random Forest queda cerca pero no llega.

Aquí aplica una lección del curso: la métrica correcta depende del problema. En este caso, un falso negativo (predecir que el cliente no cancela cuando sí lo hará) cuesta más que un falso positivo (enviar una oferta innecesaria). Por eso el recall manda sobre el accuracy.

El equipo también hace validación cruzada con 5 folds para confirmar que el resultado no es producto del azar. El recall promedio en los 5 folds es del 77%. El modelo es estable.

Salida de la Etapa 4: el modelo seleccionado con sus hiperparámetros finales y las métricas de validación cruzada.

Etapa 5 — Optimizar para producción

Esta etapa es la que más equipos ignoran. Entrenar un modelo en un notebook de Jupyter es muy diferente a ejecutarlo en un sistema real.

El equipo de Liverpool necesita que el modelo haga predicciones nuevas cada noche, sobre los clientes activos del día. Para eso:

1. Serializa el modelo con la librería joblib de Python. Esto guarda el modelo entrenado en un archivo .pkl.
2. Crea una función de predicción que recibe los datos de un cliente nuevo y devuelve la probabilidad de cancelación.
3. Envuelve la función en una API usando FastAPI. Ahora cualquier sistema interno de Liverpool puede consultar el modelo enviando una solicitud HTTP.
4. Monitorea el modelo en el tiempo. Con el tiempo, los hábitos de los clientes cambian y el modelo se degrada. El equipo programa una alerta automática si el recall cae por debajo del 70%.

El costo total de infraestructura en la nube para este sistema es de $3,200$ al mes, mucho menor que los $28,000$ que costaría una red neuronal profunda para el mismo volumen de datos.

Salida de la Etapa 5: un sistema en producción que recibe datos nuevos, genera predicciones y tiene monitoreo activo.

Los tres errores que destruyen proyectos reales

Error 1: Saltarse la línea base. Muchos equipos van directo a XGBoost o redes neuronales. Sin línea base, no puedes demostrar que la complejidad extra valió la pena.

Error 2: Optimizar la métrica equivocada. Un modelo con 95% de accuracy en datos desbalanceados puede tener 0% de recall en la clase que importa. Siempre define la métrica de negocio antes de entrenar.

Error 3: Considerar el proyecto terminado al terminar el notebook. El modelo en producción necesita mantenimiento. En México, el IMSS y el SAT exigen que los sistemas automatizados tengan bitácoras de auditoría. Si tu modelo toma decisiones sobre crédito o empleo, necesitas registrar cada predicción con su fecha y los datos de entrada.

Lo que aprendiste en este curso

Este es el final del curso, y vale la pena mirar hacia atrás.

Empezaste aprendiendo qué es el machine learning y por qué importa en México, donde empresas como FEMSA y Bimbo ya lo usan para optimizar rutas y predecir demanda. Aprendiste la diferencia entre aprendizaje supervisado y no supervisado, y cuándo usar cada uno.

Después viste los algoritmos clave: regresión lineal para predecir números, regresión logística para clasificar, árboles de decisión para explicar, y redes neuronales para problemas complejos con grandes volúmenes de datos.

Aprendiste que preparar datos consume el 60–80% del tiempo real de un proyecto, que el overfitting es el enemigo silencioso del ML, y que la métrica correcta depende del problema, no del algoritmo.

Y ahora tienes el Marco FLUJO para estructurar cualquier proyecto nuevo.

Tus próximos pasos concretos

El conocimiento sin práctica no sirve. Aquí tienes tres acciones que puedes hacer esta semana:

1. Elige un conjunto de datos mexicano. El INEGI publica datos abiertos en datos.gob.mx. Descarga el dataset de empresas exportadoras y practica las etapas 1 y 2 del Marco FLUJO.
2. Entrena tu primer modelo completo. Usa scikit-learn en Python. Regresión logística primero, siempre. Documenta tus métricas base.
3. Aprende a desplegar. Busca el tutorial oficial de FastAPI y despliega tu modelo como una API local. Eso ya te coloca en el 15% de practicantes que llegan a producción.

El machine learning no es magia. Es un proceso. Y ahora tú conoces ese proceso.