Cuando un modelo de machine learning no llega a producción, el motivo casi nunca es la precisión. El modelo funciona en el notebook, la métrica es buena, la presentación gusta y seis meses después nadie lo usa. Lo que falta es todo lo que debe existir a su alrededor para que una predicción se convierta en una acción dentro de la empresa.
Lo que dicen los números
Una encuesta de Gartner publicada en agosto de 2022 indicó que, de media, el 54% de los proyectos de IA pasan del piloto a producción, prácticamente el mismo nivel que la edición de 2019 de la encuesta, que había registrado un 53%. Cerca de la mitad se queda por el camino, y la cifra apenas cambió en tres años.
El informe de RAND Corporation de 2024 sobre las causas de fracaso de los proyectos de IA cita estimaciones según las cuales más del 80% de estos proyectos fracasan, el doble que los proyectos de TI sin IA. A partir de entrevistas con 65 científicos de datos e ingenieros, los autores señalan cinco causas principales: entender mal el problema a resolver, no disponer de los datos necesarios, centrarse en la tecnología de moda en lugar del problema, invertir poco en infraestructura y aplicar IA a tareas que todavía no resuelve bien.
Hay una explicación más antigua para el mismo fenómeno. En 2015, ingenieros de Google publicaron en NeurIPS el artículo Hidden Technical Debt in Machine Learning Systems, que mostraba que, en sistemas reales, el código del modelo es una parte pequeña del conjunto. A su alrededor están la recogida y validación de datos, la extracción de features, la configuración, la infraestructura de serving y la monitorización. La guía de MLOps de Google Cloud recoge la misma idea. Quien presupuesta solo el modelo presupuesta la parte más pequeña del trabajo.
Los motivos reales, en el orden en que aparecen
Nadie diseñó la acción
Un modelo de abandono con buena precisión no reduce el abandono. Lo reduce el equipo de retención que llama al cliente adecuado con la oferta adecuada. Si ese equipo puede hacer 50 llamadas a la semana, lo que importa es si los 50 primeros de la lista son de verdad los que iban a darse de baja, no la precisión media sobre toda la base de clientes.
Eso cambia la métrica (precisión en los primeros puestos del ranking, no una métrica global como el AUC), el formato de entrega (una lista semanal en el CRM, no una API) y quién tiene que estar en la sala desde el principio. Es la primera causa de RAND en versión práctica: un modelo optimizado para la métrica equivocada, fuera del flujo de trabajo real.
Los datos de producción no son los de entrenamiento
El modelo se entrena con un histórico limpio, exportado de una sola vez. En producción, los datos llegan incompletos, con retraso, con un campo que cambió de formato tras una actualización del ERP. La guía de Google llama a uno de estos síntomas training-serving skew: la feature se calcula de una forma en el entrenamiento y de otra en producción.
Un ejemplo típico es la feature "días desde la última compra". En el notebook se calcula sobre toda la base, a veces usando sin querer información posterior a la fecha de la predicción. En producción se calcula en el día, con los datos disponibles en ese momento. El modelo que parecía excelente en las pruebas pierde rendimiento sin que nada se rompa de forma visible.
La corrección es de ingeniería: la misma función calcula la feature en entrenamiento y en producción, la entrada se valida antes de llegar al modelo y se monitoriza la distribución de las variables principales. Cuando cambia el perfil de los datos (un canal de venta nuevo, un cambio de precios, una estacionalidad que el histórico no tenía), alguien recibe una alerta.
No hay responsable después del lanzamiento
Un modelo en producción es un sistema que se degrada con el tiempo, porque el mundo que describe cambia. Necesita a alguien que vigile la monitorización, decida cuándo reentrenar y responda cuando el negocio diga que "el modelo hace cosas raras". Si el científico de datos que lo construyó ya está en otro proyecto y nadie heredó la responsabilidad, el modelo sigue funcionando hasta que alguien lo apaga por desconfianza.
Nadie planificó el paso del notebook a ingeniería
La guía de Google describe el nivel 0 de madurez en MLOps: todo manual, el científico de datos entrega un archivo de modelo al equipo de ingeniería para que lo despliegue, sin pipeline, sin CI/CD, con lanzamientos poco frecuentes. Es donde están muchas empresas, y donde mueren muchos modelos, en la cola de un equipo que no participó en su construcción y no lo tiene como prioridad.
La métrica offline no conecta con el indicador de negocio
Un modelo de recomendación puede mejorar su métrica offline sin mover los ingresos. Sin una prueba controlada en producción (un test A/B, o al menos un periodo en shadow mode, funcionando en paralelo sin afectar a las decisiones), nadie puede afirmar que el modelo generó valor. Y sin esa evidencia, no sobrevive a la primera revisión de presupuesto.
Antes de entrenar, empiece sin machine learning
Las Rules of Machine Learning, guía de Martin Zinkevich publicada por Google, empiezan con una regla que evitaría muchos proyectos parados: no tenga miedo de lanzar un producto sin machine learning. Una heurística sencilla, como "clientes sin compras en 60 días y con una reclamación abierta", puesta en producción primero, resuelve tres problemas a la vez. Obliga a diseñar la acción, crea el pipeline de datos que usará el modelo y fija la línea base que el modelo tendrá que superar. Si el modelo no supera a la regla, se ha ahorrado el proyecto.
Un checklist de preparación
El artículo The ML Test Score, también de investigadores de Google, propone 28 pruebas y comprobaciones de monitorización para medir si un sistema de ML está listo para producción. Para una empresa que empieza, una versión reducida ya filtra buena parte de los problemas:
- La decisión que apoya el modelo está escrita, con quién actúa y con qué capacidad (cuántos casos al día o a la semana).
- La métrica de evaluación refleja esa capacidad, y existe una línea base sin ML para comparar.
- El código que calcula las features es el mismo en entrenamiento y en producción.
- Los datos de entrada se validan antes de la predicción: nulos, valores fuera de rango, categorías nuevas.
- El modelo está versionado y se puede volver a la versión anterior en minutos.
- Se monitoriza la distribución de entradas y predicciones, con alertas.
- Hay un criterio escrito para reentrenar: calendario, caída de rendimiento o cambio en los datos.
- El modelo tiene un responsable con nombre después del lanzamiento.
- El impacto se midió en producción frente a un grupo de control, o hay un plan para medirlo.
MLOps sin exagerar
Nada de esto exige una plataforma sofisticada para el primer modelo. En muchas empresas medianas basta con un proceso programado que ejecute la predicción por lotes cada noche, escriba el resultado en una tabla que el CRM o el ERP ya leen, registre la versión del modelo utilizada y alimente un panel semanal de monitorización. La automatización completa del pipeline y del reentrenamiento, lo que Google llama niveles 1 y 2, tiene sentido cuando hay varios modelos en producción o cuando los datos cambian lo bastante rápido como para exigir reentrenamientos frecuentes.
El error contrario también existe: montar una plataforma completa de MLOps antes de que el primer modelo genere valor. Infraestructura sin caso de uso es coste fijo esperando una justificación.
Por dónde empezar
Tome el modelo que está parado en un notebook y responda por escrito: quién actúa sobre la predicción, con qué frecuencia, dentro de qué sistema y quién responderá por él dentro de seis meses. Si alguna respuesta queda en blanco, ahí está bloqueado el proyecto, y ninguna mejora de precisión lo va a desbloquear.
Si quiere apoyo para llevar un modelo a la operación, con pipeline, monitorización y responsable definidos, ese es el trabajo de nuestro servicio de Machine learning. Si la duda todavía es si el caso de uso es rentable, una PoC Factory lo responde en pocas semanas, con datos reales y criterios acordados de antemano.