La mayoría de los proyectos de ML no muere por falta de un buen modelo. Muere por descuidar las cosas aburridas: datos que se filtran, experimentos que nadie puede reproducir y modelos en producción que se deterioran en silencio. Las buenas prácticas que siguen tratan precisamente de esas cosas aburridas, y son las que separan un prototipo bonito de un sistema capaz de aguantar el tirón.
Empieza con un baseline simple
Antes de sacar la artillería pesada, construye la versión más tonta posible de tu predictor. Adivinar la media, predecir siempre la clase mayoritaria o aplicar una regla de negocio de dos líneas. Puede parecer una tontería, pero este baseline te da lo único que importa al principio: un número real que superar.
Mucha gente entrena un modelo complejo, ve un 87 % de accuracy y lo celebra. Después descubre que predecir «siempre no» ya daba un 86 %. Sin baseline, no tienes idea de si tu modelo está aprendiendo algo o simplemente memorizando lo obvio.
Divide los datos con honestidad
El data leakage es el error más caro y silencioso del ML. Ocurre cuando información del futuro —o del conjunto de prueba— se escapa al entrenamiento e infla tus métricas. El modelo parece genial en el notebook y se viene abajo en producción.
La regla es fácil de explicar y fácil de incumplir: separa los conjuntos de entrenamiento, validación y prueba antes de tocar los datos. La normalización, la imputación de valores faltantes y la selección de features se ajustan únicamente con el conjunto de entrenamiento y después se aplican a los demás conjuntos. Si tienes datos temporales, divídelos por tiempo, nunca de forma aleatoria; predecir el pasado con información del futuro es hacer trampa. Y cuidado con las features que solo existen después del evento que quieres predecir: son una fuga de datos disfrazada de oro.
Haz seguimiento de tus experimentos
Sin seguimiento, te vas a engañar. Está garantizado. Después de veinte rondas cambiando hiperparámetros, features y seeds, nadie recuerda qué combinación produjo aquel buen resultado de hace tres días.
Guarda, para cada experimento, la versión de los datos, el código (commit), los hiperparámetros, las métricas y el artefacto del modelo. Puede ser MLflow, Weights & Biases o una hoja de cálculo obstinada: la herramienta importa menos que el hábito. La prueba definitiva es sencilla y honesta: ¿puedes reproducir el número que pusiste en el informe? Si la respuesta es «creo que sí», la respuesta es no.
Modelo simple primero, siempre
Existe una tentación casi irresistible de empezar directamente con la arquitectura más nueva que viste en Twitter. Resiste. La regresión logística, los árboles y el gradient boosting resuelven una cantidad enorme de problemas reales y ofrecen ventajas que el deep learning cobra caras: entrenan rápido, son más fáciles de depurar y puedes explicar al equipo por qué el modelo tomó una determinada decisión.
La complejidad es un coste, no una medalla. Cada capa adicional significa más cosas que pueden romperse, un servicio más lento y una investigación más difícil cuando la métrica cae. Aumenta la complejidad solo cuando el modelo simple se quede definitivamente corto. Y cuando eso ocurra, tendrás un baseline sólido para demostrar que el esfuerzo valió la pena.
Producción no es la línea de llegada
Poner el modelo en producción es la mitad del camino, no el final. El mundo cambia, el comportamiento de los usuarios cambia y los datos de entrada cambian; el pobre modelo no sabe nada de eso. Eso es el drift, y va erosionando tu rendimiento poco a poco, sin activar ninguna alarma evidente.
Monitoriza las distribuciones de entrada y las métricas de negocio, no solo la accuracy offline. Define umbrales para el reentrenamiento y ten un plan de rollback para cuando un modelo nuevo rinda peor que el anterior. Un modelo sin monitorización es una deuda técnica que genera intereses en silencio.
Aprende cuándo NO usar ML
A veces, la mejor práctica de ML es no usar ML. Si un if lo resuelve, usa el if. Si una regla de negocio, una consulta SQL o una heurística sencilla ofrecen el resultado, acabas de ahorrarte meses de recopilación de datos, entrenamiento, deploy y mantenimiento de un sistema que tendría que vigilarse para siempre.
El ML tiene sentido cuando el patrón es demasiado complejo para escribirlo a mano, cuando tienes datos de calidad en cantidad suficiente y cuando equivocarse de vez en cuando es aceptable. No tiene sentido cuando necesitas una garantía determinista, cuando no tienes datos o cuando el problema es, en el fondo, un if vestido de gala.
Al final, las buenas prácticas de ML tratan casi siempre de disciplina, no de astucia. Baselines, datos honestos, experimentos rastreados, simplicidad y vigilancia en producción no aparecen en un paper ni impresionan a nadie durante el café, pero son exactamente lo que hace que tu modelo sobreviva al contacto con el mundo real.