ML es poderoso pero fácil de usar mal. Muchos proyectos de ML fracasan porque eligen ML para un problema que reglas simples resuelven mejor.
Cuándo ML es la respuesta correcta
ML funciona bien cuando: hay muchos datos históricos, el patrón es complejo de codificar, aceptas margen de error, puedes validar resultados.
Predicción de demanda, detección de fraude, recomendaciones: ahí ML aporta valor.
- Datos históricos suficientes (100+ ejemplos).
- Patrón demasiado complejo para reglas.
- Tolerancia a falsos positivos / negativos.
El costo oculto de ML
ML no es solo entrenar un modelo. Es recolectar datos, labelarlos (a veces a mano), validar predicciones, monitorear degradación del modelo, reentrenar regularmente.
Si no planeas esos costos operacionales, ML se vuelve una máquina de malgastar dinero.
- Recolección de datos: trabajo manual o infraestructura.
- Validación: alguien verifica si modelo acertó.
- Reentrenamiento: periódicamente, con datos nuevos.
Model drift: el modelo se vuelve malo con el tiempo
Un modelo entrenado hace 6 meses puede tener precision del 95%. Hoy, con datos nuevos, tiene 70%. Eso es drift. Ocurre cuando el mundo cambió y el modelo no.
Monitorear drift es crítico. Si no lo haces, modelo degrada silenciosamente.
- Monitorea accuracy / AUC en tiempo real.
- Compara distribución de datos nuevos vs training data.
- Reentrenar cuando drift aparece.
ML como feature, no como producto completo
En lugar de "construir sistema de ML", considera ML como componente de un sistema más grande. El sistema decide si confiar en predicción o escalar a revisión humana.
Eso es más robusto que depender 100% de ML.
El mejor ML en producción es uno que sabes cuándo no confiar. Que tiene fallbacks, humanos en el loop, y supervisa su propio desempeño.
Herramientas y frameworks
Scikit-learn para modelos simples. TensorFlow/PyTorch para deep learning. MLflow para gestión de modelos. Hugging Face para NLP.
Elige según complejidad. Los mejores proyectos suelen empezar simple.