Selección, Entrenamiento y Evaluación de Modelos de Machine Learning

Un modelo de Random Forest en un dataset de crédito bancario puede alcanzar 81.5% de accuracy —y tener un MCC de apenas 0.38. Eso significa que la métrica que aparece en el reporte dice que el modelo funciona bien, mientras que la métrica que realmente importa dice que apenas supera el azar en la clase que más cuesta equivocarse.

Eso no es un caso hipotético. Es uno de los resultados experimentales de Evaluating Supervised Machine Learning Models: Principles, Pitfalls, and Metric Selection (Liu et al., 2026), un estudio reciente que usó 15 datasets reales para documentar exactamente cuándo y por qué los rankings de modelos cambian dependiendo de qué métrica uses. La conclusión central es incómoda: la evaluación de modelos no es un paso rutinario. Es una decisión metodológica que puede hacer que un sistema parezca listo cuando no lo está.

Este artículo es un mapa completo del problema: cómo seleccionar modelos, cómo diseñar una evaluación que no te mienta, qué métricas usar según el dominio, y cómo saber cuándo un modelo realmente está listo para producción.

Tabla de contenido:

• Cómo seleccionar el modelo correcto según el dataset
• Cómo dividir los datos sin contaminar la evaluación
• Métricas de clasificación: cuándo cada una importa
• La trampa del accuracy y el desbalance de clases
• Métricas de regresión: MAE, RMSE y R² no son intercambiables
• Cómo detectar overfitting cuando las métricas parecen correctas
• Cómo comparar modelos de forma robusta
• Hyperparameter tuning sin sobreajustar la evaluación
• Data leakage: el error silencioso que destruye modelos en producción
• Cuándo un modelo está listo para producción
• Cómo monitorear un modelo después del deployment
• Preguntas frecuentes

🔵 ¿Cómo seleccionar el mejor modelo de machine learning según tu dataset?

La pregunta correcta no es "¿qué modelo es el mejor?" Es: ¿qué modelo falla menos bajo mis condiciones reales? La diferencia no es semántica. El paper de Liu et al. (2026) lo demuestra empíricamente: el mismo conjunto de modelos producen rankings distintos en los mismos datos dependiendo exclusivamente de qué métrica se usa para ordenarlos. No hay un ganador universal.

¿Qué señales del dataset determinan qué algoritmo usar?

En proyectos reales, las decisiones de selección no empiezan en el algoritmo sino en el análisis del dataset. Las señales más determinantes son:

• Volumen de datos: con pocos datos, los modelos complejos (redes neuronales, gradient boosting con muchos estimadores) tienen alta varianza y tienden a sobreajustar. Modelos simples —regresión logística, árboles poco profundos— generalizan mejor cuando el dataset no supera algunos miles de registros.
• Tipo de features: para datos tabulares bien preprocesados, los modelos basados en árboles (Random Forest, XGBoost, LightGBM) dominan consistentemente en benchmarks. Para datos secuenciales o con dependencias temporales, esta ventaja desaparece y se necesitan modelos con memoria explícita.
• Estructura del target: un target con distribución muy sesgada (fraude, detección de anomalías, enfermedades raras) cambia completamente qué modelo es viable, no solo qué métrica usar.
• Interpretabilidad requerida: en sectores regulados —salud, crédito, seguros— la capacidad de explicar cada predicción puede eliminar opciones técnicamente superiores. No es una restricción técnica: es una restricción del dominio.

¿Existe un modelo universalmente mejor?

No. Y la evidencia experimental reciente lo respalda con datos concretos. En el estudio de Liu et al., un mismo modelo de Random Forest obtuvo 90.3% de accuracy en el dataset Bank Marketing y solo 0.446 de MCC en el mismo dataset. Esos dos números corresponden al mismo modelo, los mismos datos, el mismo fold de validación. La conclusión no es que el modelo sea bueno o malo: es que la respuesta depende de qué aspecto del rendimiento te importa medir.

Esto también ocurre entre modelos. Un Decision Tree puede superar levemente a un Random Forest en accuracy (91.67% vs 90.39% en Car Evaluation) y al mismo tiempo producir un Log Loss de 3.00 frente a 0.33 del Random Forest. El árbol acierta casi tan seguido, pero cuando falla lo hace con una confianza extrema que el sistema penaliza duramente. Cuál modelo elegirías depende de si tu sistema necesita decisiones correctas frecuentes o predicciones de probabilidad confiables.

🔵 ¿Cómo dividir correctamente los datos en train, validation y test?

El split de datos es donde se cometen los errores más costosos y más difíciles de detectar. Un split mal diseñado produce estimaciones optimistas que solo se descubren cuando el modelo falla en producción.

Por qué no debes usar el test set para tomar decisiones

Este error es más común de lo que parece, y ocurre de formas sutiles. El caso obvio es ajustar hiperparámetros evaluando directamente en test. Pero también ocurre cuando seleccionas el mejor modelo entre diez candidatos usando sus métricas en test: cada vez que usas el test para decidir, introduces un sesgo de selección. Al final, el "mejor modelo en test" lo es porque tuvo suerte con esa partición, no porque generalice mejor.

El paper lo describe como una de las fuentes más comunes de resultados irreproducibles: Kapoor y Narayanan documentan que el data leakage a través del test set ha contaminado resultados publicados en múltiples disciplinas científicas que usan ML. La solución estructural es usar un conjunto de validación separado para todas las decisiones de desarrollo y reservar el test únicamente para el reporte final del modelo ya elegido.

¿Cuándo usar cross-validation vs holdout?

• Cross-validation (k-fold): reduce la dependencia del resultado a una sola partición. Con 5 folds, cada observación aparece exactamente una vez en test, y el promedio de los cinco resultados es un estimador más estable. Es el estándar para datasets de tamaño moderado.
• Holdout simple: válido para datasets grandes donde el costo computacional de entrenar k modelos es prohibitivo. La clave es que la partición sea representativa: stratified split en clasificación para preservar proporciones de clase.
• Nested cross-validation: cuando necesitas tanto seleccionar hiperparámetros como estimar performance de generalización, el loop externo evalúa el modelo y el loop interno hace el tuning. Evita sobreestimar el rendimiento del modelo seleccionado.

El caso especial de series de tiempo y datos geoespaciales

Un shuffle aleatorio en series de tiempo es un error grave: las observaciones cercanas en el tiempo comparten información, y un modelo puede aprender a "ver el futuro" si los datos de entrenamiento contienen observaciones posteriores a las de prueba. La validación correcta es siempre temporal: entrenar con el pasado y evaluar con el futuro.

El mismo principio aplica a datos geoespaciales. Meyer et al. muestran que la validación cruzada estándar sobreestima significativamente el rendimiento en predicción espacial porque observaciones cercanas en el espacio comparten autocorrelación. La estrategia correcta es la validación por regiones geográficas, no por observaciones individuales.

🔵 ¿Qué métricas de clasificación usar y cuándo?

Elegir la métrica equivocada es uno de los errores más costosos en ML porque sus consecuencias son invisibles hasta que el modelo llega a producción. Cada métrica tiene una estructura de penalización diferente, y esa estructura interactúa de forma distinta con la distribución de los datos.

El mapa de métricas según el tipo de problema

Accuracy

La proporción de instancias correctamente clasificadas. Simple e intuitiva, pero engañosa cuando las clases no están balanceadas. Con 95% de clase negativa, un clasificador que siempre predice "negativo" tiene 95% de accuracy y cero utilidad. El paper documenta esto experimentalmente: con el dataset Default de Crédito (distribución aproximadamente 78/22), el Random Forest alcanza 81.5% de accuracy mientras que su MCC es solo 0.385 —cuatro veces más bajo en términos comparables.

Precision y Recall

Precision mide qué fracción de las predicciones positivas son correctas. Recall mide qué fracción de los positivos reales fueron detectados. Son complementarias y generalmente inversas: aumentar uno reduce el otro. La decisión depende de qué error es más costoso en tu dominio:

• Si el costo de un falso positivo es alto (spam que elimina un correo importante, alarma de fraude que bloquea una compra legítima), prioriza Precision.
• Si el costo de un falso negativo es alto (no detectar un tumor, no identificar una transacción fraudulenta), prioriza Recall.

En el experimento sobre diagnóstico de cáncer de mama, el modelo alcanzó 96.48% de accuracy y 95.80% de Precision. Pero el Recall bajó a 94.81% —y en un fold específico cayó a 92.86%. En términos clínicos: uno de cada catorce casos malignos no fue detectado. La métrica que aparece en el reporte dice que el modelo es excelente. La métrica que importa dice que hay pacientes sin diagnóstico.

F1 Score y F2 Score

El F1 Score es la media armónica de Precision y Recall: penaliza cuando cualquiera de los dos es bajo. Útil cuando no hay una razón clara para priorizar uno sobre el otro. El F2 Score pondera el Recall el doble que la Precision, y es más apropiado en contextos médicos o de seguridad donde los falsos negativos son más graves. En el estudio, el F2 Score del modelo de cáncer de mama fue 0.9498, un número que refleja mejor la realidad clínica que el F1 de 0.9526.

MCC (Matthews Correlation Coefficient)

El MCC incorpora los cuatro elementos de la matriz de confusión (TP, TN, FP, FN) en una sola medida. Su rango va de -1 a +1, donde 0 equivale a predicción aleatoria. Es especialmente informativo en datasets desbalanceados porque no puede inflarse artificialmente por la clase mayoritaria. El paper lo identifica como una de las métricas más robustas para clasificación binaria desbalanceada: un MCC de 0.38 sobre un dataset financiero es una evaluación honesta donde el 81.5% de accuracy es una ilusión.

ROC AUC y PR AUC

ROC AUC mide la capacidad del modelo de separar clases a través de todos los umbrales posibles. Es robusto pero tiene una debilidad importante: normaliza la tasa de falsos positivos por el total de negativos, lo que en datasets muy desbalanceados puede resultar en un ROC AUC alto aunque el modelo produzca muchos falsos positivos en términos absolutos.

PR AUC trabaja directamente con Precision y Recall, lo que lo hace más informativo cuando la clase positiva es la minoría. En el dataset de marketing bancario, el Random Forest obtuvo un ROC AUC de 0.916 —que suena excelente— pero un PR AUC de solo 0.586. La diferencia entre esos dos números es la diferencia entre un sistema de marketing que parece funcionar y uno que realmente identifica clientes que van a convertir.

🔵 La trampa del accuracy: datos desbalanceados y métricas engañosas

Este es el error más documentado en evaluación de ML y sigue siendo uno de los más frecuentes. El paper lo llama "the accuracy trap" y dedica un escenario experimental completo a documentarlo con dos datasets financieros reales.

El experimento que lo demuestra

Con el dataset Default of Credit Card Clients (30,000 observaciones, distribución aproximada 78/22 entre no-default y default), el Random Forest alcanzó:

• Accuracy: 81.50% — sugiere un modelo competente
• ROC AUC: 75.65% — sugiere capacidad de separación razonable
• PR AUC: 52.30% — revela que la mitad del tiempo el modelo confunde positivos con negativos
• MCC: 0.385 — indica que el modelo apenas supera el nivel de un clasificador simple

Con Bank Marketing (45,211 observaciones, fuertemente desbalanceado hacia "no suscribió"), el patrón es aún más pronunciado: ROC AUC de 91.58% conviviendo con PR AUC de 58.55%. Un sistema de marketing construido sobre ese modelo y evaluado solo con ROC AUC parecería excelente, pero convertiría cerca de la mitad de las veces que espera.

Por qué el desbalance de clases crea esta ilusión

Accuracy y ROC AUC se inflan porque el volumen de verdaderos negativos es tan grande que cualquier mejora en detectarlos domina el cómputo de la métrica. El modelo puede ignorar casi completamente la clase minoritaria y aun así obtener números aparentemente buenos. MCC y PR AUC son menos susceptibles a esto porque sus denominadores incluyen directamente el rendimiento en la clase positiva.

Estrategias reales cuando las clases están desbalanceadas

• Cambiar la métrica de evaluación antes de ajustar el modelo: usar F1, MCC o PR AUC desde el inicio cambia qué modelos y qué hiperparámetros se ven favorables.
• Ajustar los pesos de clase: la mayoría de frameworks permiten asignar mayor penalización a errores en la clase minoritaria. El modelo optimiza su función de pérdida con esa penalización, lo que redistribuye su atención hacia la clase que importa.
• Ajustar el umbral de decisión: el umbral por defecto de 0.5 no es óptimo con clases desbalanceadas. Moverlo hacia abajo captura más positivos a costo de más falsos positivos; la decisión correcta depende del costo relativo de cada tipo de error en el dominio.
• Sobremuestreo o submuestreo: SMOTE genera instancias sintéticas de la clase minoritaria; el submuestreo reduce la mayoritaria. Ambas estrategias deben aplicarse solo en los datos de entrenamiento, nunca antes del split.

🟡 Métricas de regresión: MAE, RMSE y R² no son intercambiables

En regresión, el equivalente de la trampa del accuracy es usar R² como indicador único de calidad. Un R² alto puede coexistir con patrones de error sistemáticos que solo son visibles en el análisis de residuos. Y MAE y RMSE pueden llevar a conclusiones opuestas sobre qué modelo es mejor, dependiendo de si los datos tienen outliers.

MAE vs RMSE: cuándo importa la diferencia

La diferencia matemática entre MAE y RMSE es que RMSE eleva al cuadrado cada error antes de promediar, lo que hace que errores grandes contribuyan de forma desproporcionada. En datos con distribuciones bien comportadas, ambas métricas se comportan de forma similar. Con outliers, la brecha puede ser enorme.

El paper lo documenta con dos datasets reales. En California Housing, el Random Forest obtuvo un MAE promedio de 0.331 y un RMSE de 0.509. En Individual Household Electric Power Consumption (más de dos millones de observaciones), el MAE fue 0.0216 y el RMSE 0.0401. En ambos casos, RMSE es significativamente mayor que MAE, lo que refleja que el modelo comete errores pequeños con alta frecuencia y errores grandes con baja frecuencia. La pregunta relevante para selección de métricas es si esos errores grandes son anomalías sin consecuencia o fallos operativos costosos.

• Usar MAE cuando quieres un reporte robusto del error promedio y los outliers en los datos son ruido, no señal crítica. MAE es más fácil de interpretar: un MAE de 0.33 en precios normalizados es directamente el error esperado en una predicción típica.
• Usar RMSE cuando los errores grandes son operacionalmente peligrosos y deberían penalizarse más fuertemente: predicción de consumo eléctrico donde los picos causan fallos de red, estimación de inventario donde los errores grandes generan roturas de stock costosas.

La ilusión del R² alto

En el dataset de Parkinson Telemonitoring, el Random Forest alcanzó un R² promedio de 0.967 y un MAE de 0.840. A primera vista parece un modelo casi perfecto. Pero un R² alto indica que el modelo explica la varianza global del target; no garantiza que el error sea uniforme a lo largo del rango de predicción.

El análisis de residuos —graficar el error en función del valor predicho— puede revelar que el modelo es sistemáticamente peor para pacientes con síntomas severos (valores altos de la escala UPDRS), precisamente el subgrupo donde más importa acertar. Ese patrón no aparece en el R² ni en el MAE global. Solo aparece cuando miras los residuos desagregados.

La regla práctica: R² y MAE/RMSE son métricas necesarias pero no suficientes. El análisis de residuos no es opcional en aplicaciones donde el error en ciertos rangos del target tiene consecuencias distintas al error en otros rangos.

El problema con MAPE en datos con valores bajos

MAPE (Mean Absolute Percentage Error) tiene un problema estructural: cuando el valor real se acerca a cero, el denominador hace que errores absolutamente pequeños produzcan porcentajes enormes. En Seoul Bike Sharing, el modelo obtuvo un MAE de 14.57 bicicletas —que en horas de alta demanda es un error marginal— pero un MAPE de 16.62%, dominado por los periodos nocturnos de demanda casi cero donde cualquier predicción produce un porcentaje alto. Usar MAPE en ese contexto llevaría a rechazar un modelo que funciona bien cuando importa.

🟡 ¿Cómo detectar overfitting cuando las métricas parecen correctas?

El overfitting clásico —alta performance en train, baja en test— es fácil de detectar. El overfitting moderno es más sutil y se detecta con otras señales.

Señales de overfitting que las métricas no muestran directamente

• Resultados muy buenos pero difíciles de reproducir: si el modelo varía significativamente entre runs con distintas semillas aleatorias, la varianza del estimador es alta aunque el promedio sea bueno. Estabilidad y reproducibilidad son condiciones necesarias de un modelo útil.
• Alta variabilidad entre folds de cross-validation: si los cinco folds dan 0.92, 0.93, 0.91, 0.94 y 0.90 de F1, el modelo es estable. Si dan 0.95, 0.88, 0.93, 0.72, 0.91, hay inestabilidad estructural que el promedio de 0.878 oculta.
• Performance que cae ante perturbaciones mínimas en los datos: añadir un 1% de ruido a las features, cambiar la distribución del test levemente, o introducir valores fuera del rango de entrenamiento debería producir degradaciones graduales. Colapsos abruptos indican que el modelo memorizó el training set más que aprender el problema.
• Benchmark overfitting: el modelo mejora continuamente en el dataset de evaluación pero sin mejorar en datos realmente nuevos. Ocurre cuando el conjunto de validación se usa repetidamente para tomar decisiones de diseño.

Curvas de aprendizaje como diagnóstico

Las curvas de aprendizaje grafican la performance en train y en validación en función del tamaño del dataset de entrenamiento. Los patrones diagnósticos son:

• Train alto, validación bajo, brecha constante al añadir datos → overfitting claro: el modelo necesita regularización o simplificación.
• Ambos bajos y convergiendo → underfitting: el modelo es demasiado simple para el problema.
• Ambos mejoran al añadir datos y la brecha se reduce → el modelo está aprendiendo; más datos ayudarán.
• Performance inestable (zigzag) en validación → posible problema en los datos, no en el modelo.

🟡 ¿Cómo comparar modelos de machine learning de forma robusta?

Comparar modelos con un solo split produce decisiones aleatorias. El paper lo demuestra directamente: los resultados de evaluación dependen del split, y con un solo holdout el "mejor modelo" puede ser simplemente el que tuvo suerte con la partición.

Por qué los rankings cambian con el split

La varianza de un estimador de performance calculado sobre un solo conjunto de prueba es alta. Dos modelos con una diferencia de 0.5% en F1 pueden revertir su ranking en otro split del mismo dataset. Esto no es un problema teórico: es una de las razones por las que resultados de ML son difícilmente reproducibles entre equipos que trabajan con los mismos datos pero con distintas semillas o particiones.

La solución es cruzar la evaluación: 5-fold o 10-fold cross-validation produce cinco o diez estimaciones independientes. La decisión correcta no es solo mirar el promedio, sino también la dispersión: un modelo con promedio de 0.88 F1 y desviación estándar de 0.01 es preferible a uno con promedio de 0.89 y desviación de 0.06, porque el segundo es menos confiable.

Micro F1 vs Macro F1 en clasificación multiclase

El estudio incluye cuatro datasets multiclase y documenta sistemáticamente cuándo Micro F1 y Macro F1 divergen. La conclusión es estructural: Micro F1 es matemáticamente idéntico a Accuracy global en clasificación multiclase, lo que significa que está dominado por las clases más frecuentes. Macro F1 da igual peso a todas las clases, lo que expone rendimiento débil en clases minoritarias.

En el dataset Covertype (distribución de clases marcadamente desigual), el Random Forest obtuvo Micro F1 de 0.892 y Macro F1 de 0.843 —una brecha de 4.9 puntos porcentuales que indica rendimiento significativamente peor en los tipos de cobertura forestal menos frecuentes. En Letter Recognition (distribución casi uniforme de 26 letras), los dos valores convergieron: 0.9615 vs 0.9614. La divergencia entre los dos es, en sí misma, información sobre la distribución del problema.

Tests estadísticos para comparar modelos

Con k resultados de cross-validation por modelo, es posible hacer tests estadísticos para determinar si la diferencia entre modelos es significativa o ruido. Rainio et al. (citados en el paper) documentan procedimientos de testing apropiados para evaluación de ML. La práctica recomendada es no declarar un modelo como ganador si la diferencia no es estadísticamente significativa, especialmente cuando la mejora es marginal.

🟡 ¿Cómo hacer hyperparameter tuning sin sobreajustar la evaluación?

El tuning de hiperparámetros es una de las fuentes más frecuentes de overfitting encubierto. Cada vez que ajustas un hiperparámetro basándote en la performance en validación, estás usando esa información para tomar una decisión. Si lo haces suficientes veces con el mismo conjunto de validación, acabas sobreajustando al conjunto de validación aunque nunca hayas entrenado con él.

Grid search, random search y bayesian optimization

• Grid search: exhaustivo pero exponencialmente costoso. Para un modelo con 4 hiperparámetros y 5 valores cada uno, son 625 evaluaciones. Cada evaluación en cross-validation multiplica eso por k. Reservado para espacios de búsqueda pequeños con modelos ligeros.
• Random search: muestrea aleatoriamente el espacio de hiperparámetros. Bergstra y Bengio demostraron que en la práctica cubre el espacio relevante más eficientemente que grid search cuando muchos hiperparámetros tienen poco impacto. Es el estándar para la mayoría de casos prácticos.
• Bayesian optimization: usa el historial de evaluaciones anteriores para decidir qué región del espacio explorar a continuación. Más eficiente que random search cuando el espacio es grande y cada evaluación es costosa.

El insight clave: más tuning no siempre mejora la generalización. En algún punto, el modelo empieza a ajustarse a las particularidades del conjunto de validación. La nested cross-validation es la herramienta estructural para evitar esto: el loop interno hace el tuning y el externo evalúa la generalización del modelo ya tuneado.

Calibración de probabilidades

El paper dedica un escenario experimental completo a la calibración, y los resultados son llamativos. El Decision Tree superó marginalmente al Random Forest en accuracy en dos datasets (91.67% vs 90.39% en Car Evaluation, ventaja similar en Adult Census). Pero su Log Loss fue 3.00 frente a 0.33 del Random Forest. Eso significa que el árbol, cuando se equivoca, lo hace con una confianza del 95-99% en la predicción incorrecta.

En cualquier sistema que use las probabilidades predichas para tomar decisiones —ordenar casos por riesgo, generar alertas con umbral ajustable, calcular valor esperado de una acción— un modelo mal calibrado es operativamente peligroso aunque su accuracy sea aceptable. Técnicas como Platt scaling e isotonic regression permiten recalibrar las probabilidades después del entrenamiento.

🔴 Data leakage: el error silencioso que destruye modelos en producción

Data leakage es el único error en ML que produce resultados mejores de lo real durante el desarrollo. Todo lo demás —overfitting, métricas incorrectas, split mal diseñado— genera problemas visibles durante la evaluación. Leakage los oculta hasta producción.

Las fuentes más comunes de leakage

• Preprocesamiento antes del split: normalizar, imputar o aplicar cualquier transformación al dataset completo antes de dividirlo entre train y test. Los parámetros aprendidos (media, desviación, rangos) incluyen información del test y el modelo puede explotarlos indirectamente. La solución es encapsular todas las transformaciones en un pipeline que se ajuste solo con los datos de entrenamiento.
• Features que encapsulan el target: incluir variables que solo existen porque ya conoces el resultado del evento que estás prediciendo. En predicción de impago, incluir si el cliente fue contactado por el departamento de cobranza es leakage: ese contacto ocurrió precisamente porque ya había impagado.
• Información temporal del futuro: en series de tiempo, cualquier feature calculada sobre un ventana que incluye observaciones posteriores al momento de predicción. Un promedio móvil de 7 días centrado en t incluye observaciones de t+1 a t+3 que no existirían en producción.
• Duplicados que cruzan el split: si el mismo registro aparece en train y en test con pequeñas variaciones, el modelo aprende a memorizar esas instancias. La deduplicación debe hacerse antes del split.

Por qué es difícil detectar

Kapoor y Narayanan documentan casos de leakage en estudios publicados en revistas científicas revisadas por pares. El problema no es ignorancia sino que el leakage muchas veces no tiene una señal obvia: el pipeline corre sin errores, los resultados son buenos y coherentes. La única señal es que el modelo funciona mejor de lo que el estado del arte en el dominio sugeriría que es posible.

Un heurístico práctico: si tus métricas son significativamente mejores que los mejores resultados publicados para el mismo tipo de problema, investigar leakage antes de celebrar.

🔴 ¿Cuándo un modelo de machine learning está realmente listo para producción?

Un modelo está listo para producción cuando es reproducible, estable, tiene métricas alineadas al objetivo operativo y puede monitorearse. La precisión máxima es irrelevante si el modelo no cumple esas condiciones.

La diferencia entre generalizar y funcionar en producción

El paper define generalización como rendimiento consistente en datos no vistos. Pero producción añade condiciones que los experimentos de evaluación offline no reproducen: el volumen de predicciones es mayor, los datos de entrada cambian gradualmente con el tiempo, hay latencia requerida, puede haber restricciones regulatorias sobre las predicciones individuales y el sistema que consume el modelo puede tener requisitos específicos sobre el formato de la salida.

Muchos modelos que pasan validación offline nunca llegan a producción por problemas operativos, no técnicos. El coste de despliegue, el mantenimiento del pipeline de datos, la necesidad de auditar las predicciones o el costo computacional de inferencia pueden hacer que un modelo técnicamente superior sea inviable.

Criterios concretos para declarar un modelo listo

• Estabilidad entre folds: la varianza del estimador de performance debe ser baja. Un modelo que fluctúa mucho entre folds tiene un comportamiento impredecible en datos reales.
• Alineación de métricas con el objetivo de negocio: las métricas que guiaron el desarrollo deben corresponder al costo real de los errores en el dominio. Un modelo optimizado para F1 macro en un problema donde solo importa la clase minoritaria no está alineado aunque el F1 sea alto.
• Reproducibilidad: el mismo pipeline, los mismos datos, la misma semilla debe producir exactamente los mismos resultados. Esto es un requisito de auditoría en sectores regulados y una condición de depuración en cualquier sistema.
• Plan de monitoreo definido: qué métricas se monitorearan en producción, con qué frecuencia, y qué umbrales disparan una revisión o reentrenamiento. Un modelo sin plan de monitoreo tiene fecha de caducidad desconocida.

¿Se debe reentrenar con todo el dataset antes del deployment?

Después de seleccionar el modelo y los hiperparámetros con el conjunto de entrenamiento y validación, es común reentrenar con todos los datos disponibles (train + validation) antes del deployment final. La idea es maximizar la información disponible para el modelo que va a producción. El test set nunca debe incluirse en este reentrenamiento: sigue siendo la estimación honesta del rendimiento esperado en producción.

🔴 ¿Cómo monitorear un modelo después del deployment?

La evaluación no termina cuando el modelo llega a producción. Los datos cambian, los patrones evolucionan y el modelo que era preciso hace seis meses puede estar produciendo predicciones sistemáticamente erróneas hoy sin que ninguna alarma lo señale.

Data drift y concept drift

• Feature drift: la distribución de las variables de entrada cambia. El modelo recibe datos que están fuera del rango que vio durante el entrenamiento, y sus predicciones en ese territorio son extrapolaciones no validadas.
• Label drift: la relación entre features y target cambia. Lo que predecía fraude hace un año ya no lo predice porque los patrones de fraude evolucionaron. El modelo sigue siendo técnicamente correcto respecto a lo que aprendió; el problema es que lo que aprendió ya no es válido.
• Concept drift: el concepto subyacente al problema cambia. Modelos entrenados con datos prepandemia fallaron en aplicaciones de demanda, logística y salud durante 2020-2021 porque el comportamiento humano cambió de forma abrupta. No hubo error de desarrollo: el mundo dejó de comportarse como el training set.

Qué monitorear en producción

• Distribución de las features de entrada: comparar la distribución actual con la del training set usando tests estadísticos (KS test, Population Stability Index). Una deriva significativa es una señal de que las predicciones pueden estar en territorio no validado.
• Distribución de las predicciones: si el modelo empieza a predecir casi siempre la misma clase o si la distribución de probabilidades cambia, algo está cambiando en los datos o en el modelo.
• Performance en ground truth cuando está disponible: cuando los resultados reales de las predicciones se vuelven disponibles (el fraude se confirma, el churn ocurre o no ocurre), recalcular las métricas del modelo sobre esa muestra.
• Latencia y errores operativos: un modelo que empieza a tardar más de lo esperado o que produce errores en inferencia tiene problemas de infraestructura que afectan tanto la disponibilidad como la calidad de las predicciones.

Cuándo reentrenar

El reentrenamiento no debería ser un proceso manual disparado por intuición. Lo ideal es definir umbrales: si el performance estimado cae más del X% respecto a la línea base, o si la deriva de features supera un umbral estadístico, el sistema dispara un proceso automático de reentrenamiento o alerta a un responsable para revisar. Los umbrales específicos dependen del dominio y del costo de las predicciones incorrectas versus el costo del reentrenamiento.

Preguntas frecuentes sobre selección y evaluación de modelos de ML

¿Cómo seleccionar el mejor modelo de machine learning?

No existe un modelo universalmente mejor. La selección depende del tipo de datos, el volumen, las restricciones de interpretabilidad y el costo de los errores en tu dominio. El paso crítico es definir primero qué métrica refleja el éxito real antes de comparar modelos.

¿Por qué un modelo con buen accuracy puede ser inútil?

Porque accuracy ignora la distribución de clases. Con datos desbalanceados, un modelo puede predecir siempre la clase mayoritaria, obtener 80–95% de accuracy y fallar completamente en detectar la clase que importa. MCC y PR AUC revelan esto; accuracy lo oculta.

¿Cuál es la diferencia entre MAE y RMSE?

MAE penaliza todos los errores de forma lineal; RMSE penaliza los errores grandes cuadráticamente. Con outliers, RMSE puede ser sustancialmente más alto que MAE para el mismo modelo. Si los errores grandes son operacionalmente peligrosos, RMSE es más apropiado. Si son anomalías sin consecuencia, MAE da un estimado más honesto del error típico.

¿Qué es data leakage y cómo evitarlo?

Data leakage ocurre cuando información del test contamina el entrenamiento, produciendo métricas artificialmente buenas que no se reproducen en producción. La forma más robusta de prevenirlo es usar pipelines donde todas las transformaciones se ajustan exclusivamente con datos de entrenamiento y se aplican al test sin reajuste.

¿Cuándo usar cross-validation?

Cuando el dataset es de tamaño moderado y necesitas un estimador estable de performance. Con datasets de series temporales o espaciales, usar cross-validation estándar es un error: el split debe respetar la estructura temporal o geográfica de los datos para evitar sobreestimar la generalización.

¿Cómo saber si un modelo está listo para producción?

Cuando es reproducible, estable entre folds, tiene métricas alineadas al objetivo operativo real y existe un plan de monitoreo para detectar degradación después del deployment. La precisión máxima no es el criterio: la confiabilidad y operabilidad sí lo son.

Si tienes un modelo que funciona bien en evaluación pero que no genera el impacto esperado cuando se usa en práctica, el problema suele estar en el diseño de la evaluación, no en el modelo. Puedes escribirme directamente: muchas veces revisar la métrica y el split es suficiente para diagnosticar el problema.