Del modelo al producto: machine learning en operación

Hace unos meses revisé, junto a un equipo de datos, un modelo de predicción de fuga de clientes que llevaba casi un año "terminado". Funcionaba muy bien en el cuaderno del científico de datos, con un acierto que enorgullecía a todos. El problema es que vivía ahí: en un cuaderno, en un portátil, ejecutándose a mano cuando alguien se acordaba. Nunca había tocado un cliente real. Esa escena, que se repite en tantas organizaciones de la región, resume el reto de 2018: ya sabemos entrenar modelos; lo que casi nadie sabe es ponerlos a trabajar.

En corto: La mayoría de los modelos de machine learning nunca llegan a producción porque tratamos un sistema vivo como si fuera un entregable de una sola vez. Operacionalizar exige resolver datos, despliegue, monitoreo y reentrenamiento como un ciclo continuo. Un modelo que no se gobierna se degrada en silencio.

¿Por qué tantos modelos mueren en el laboratorio?

El entrenamiento de un modelo es la parte glamorosa y, en realidad, la más corta del trabajo. El laboratorio es un entorno amable: los datos están limpios, congelados en un archivo, y el científico ejecuta el código cuando quiere. La producción es exactamente lo contrario. Allí los datos llegan sucios y en movimiento, otros sistemas dependen de la respuesta, y nadie está mirando la pantalla a las tres de la madrugada cuando algo falla.

He visto varios patrones que matan modelos prometedores antes de que generen un solo peso de valor:

• El abismo entre el cuaderno y el sistema. El código de experimentación rara vez es código que pueda desplegarse. Falta empaquetado, manejo de errores, pruebas.
• Datos que en producción no existen. El modelo usó variables que se calcularon a mano o que no estarán disponibles en el momento de la predicción real.
• Nadie es dueño de la operación. El científico de datos entrega y se va al siguiente proyecto; el equipo de sistemas no sabe qué hace ese artefacto ni cómo mantenerlo.
• Se confunde "preciso" con "útil". Un modelo excelente que tarda diez minutos en responder no sirve para una decisión que necesita ocurrir en un segundo.

El denominador común es tratar el modelo como un proyecto con fecha de cierre, cuando en realidad es un producto que apenas empieza a vivir el día que se despliega.

Los datos no terminan de prepararse el día del entrenamiento

En el laboratorio uno trabaja con una foto: un conjunto de datos extraído un martes cualquiera. En producción uno trabaja con una película. Las fuentes cambian de esquema, un proveedor deja de enviar un campo, alguien renombra una columna en el sistema de origen y, de repente, el modelo recibe basura sin enterarse.

Operacionalizar empieza por construir una tubería de datos confiable y repetible, no un script que se corre a mano. Eso implica:

• Definir claramente qué variables se calculan y cómo, de forma idéntica en entrenamiento y en producción. La diferencia entre ambos momentos es una de las causas más silenciosas de error.
• Validar la entrada antes de que llegue al modelo: rangos esperados, valores nulos, categorías nuevas que el modelo nunca vio.
• Versionar los datos, no solo el código. Saber con qué se entrenó cada versión del modelo es indispensable cuando algo sale mal y hay que entender por qué.

Si la cimentación de datos es frágil, todo lo que construyamos encima lo será también.

¿Qué significa realmente desplegar un modelo?

Desplegar no es copiar un archivo a un servidor. Es exponer el modelo de manera que otros sistemas o personas puedan consumir sus predicciones de forma fiable. En la práctica hay dos grandes formas, y conviene elegir conscientemente:

• Predicción por lotes. El modelo procesa periódicamente un volumen grande de registros, por ejemplo cada noche calcula la probabilidad de fuga de toda la base. Más simple de operar; adecuado cuando la decisión no necesita ser instantánea.
• Predicción en tiempo real. El modelo se expone como un servicio que responde a cada solicitud en el momento. Más exigente en latencia y disponibilidad; necesario cuando la decisión ocurre durante una interacción.

En ambos casos, el modelo deja de ser un objeto de investigación para convertirse en un componente de software con responsabilidades: tiene que estar disponible, responder a tiempo, registrar lo que hace y poder revertirse a una versión anterior si la nueva falla. Esa disciplina de ingeniería es justamente lo que falta cuando un proyecto se queda en el cuaderno. En nuestra práctica de inteligencia artificial insistimos en que el despliegue se diseñe desde el primer día, no al final.

El modelo se degrada: por qué el monitoreo no es opcional

Aquí está la diferencia más profunda entre el software tradicional y un modelo. Un programa que ordena una lista la ordenará igual de bien dentro de cinco años. Un modelo, no. El mundo que aprendió cambia: los clientes se comportan distinto, aparece un competidor, cambia la economía, se modifica un proceso interno. A esto lo llamamos deriva, y ocurre sin avisar. El modelo sigue respondiendo con total confianza mientras sus predicciones se vuelven cada vez peores.

Por eso un modelo en producción necesita monitoreo en dos planos:

• Salud técnica. ¿Está respondiendo? ¿En cuánto tiempo? ¿Hay errores? Esto es vigilancia de sistemas clásica.
• Salud del modelo. ¿Cambió la distribución de los datos de entrada respecto a lo que vio en entrenamiento? ¿Siguen siendo acertadas las predicciones cuando por fin conocemos el resultado real?

El segundo plano es el que casi siempre se descuida, porque exige comparar las predicciones de hace semanas con lo que efectivamente sucedió. Sin ese circuito de retroalimentación, uno descubre que el modelo se rompió cuando un cliente molesto lo señala, y eso es demasiado tarde.

Reentrenar y gobernar: el ciclo que nunca se cierra

Si el modelo se degrada, la consecuencia lógica es que hay que renovarlo. El reentrenamiento no debería ser una heroicidad ocasional sino un proceso previsto: con qué frecuencia, con qué datos, quién aprueba el cambio y cómo se valida que el modelo nuevo es de verdad mejor que el que está en producción.

Y aquí entra una palabra que en 2018 todavía suena rara aplicada a la analítica: gobierno. Gobernar un modelo significa poder responder, en cualquier momento, preguntas incómodas:

• ¿Qué versión está corriendo ahora y desde cuándo?
• ¿Con qué datos se entrenó y quién la aprobó?
• ¿Por qué tomó esta decisión sobre este caso concreto?
• ¿Cómo volvemos atrás si algo sale mal?

Esto no es burocracia: es lo que separa un experimento de un activo del que la organización puede depender. La madurez para sostener ese ciclo no se improvisa, y es exactamente lo que medimos en un ejercicio de evaluación de preparación para IA: ¿tiene la empresa los datos, los procesos y los roles para operar modelos, no solo para construirlos?

Personas y procesos, no solo tecnología

Ninguna herramienta resuelve esto sola. Llevar modelos a producción es, sobre todo, un problema de colaboración entre tres mundos que históricamente no se hablan: quienes entienden los datos, quienes operan los sistemas y quienes son dueños del negocio. Cuando esos tres conversan desde el inicio, el modelo nace pensado para vivir en producción. Cuando no, nace condenado al cuaderno.

Mi recomendación práctica para esta época: empiece pequeño, con un solo modelo que importe de verdad, y recórralo de punta a punta hasta producción. Es mucho más valioso un modelo modesto que toma decisiones reales todos los días que diez modelos brillantes archivados.

Preguntas frecuentes

¿Cuál es la diferencia entre entrenar un modelo y ponerlo en producción?
Entrenar es enseñarle a partir de datos históricos en un entorno controlado. Ponerlo en producción es integrarlo a la operación para que tome o apoye decisiones reales de forma confiable, continua y monitoreada. Lo primero es un evento; lo segundo es un ciclo de vida.

¿Por qué se degrada un modelo si el código no cambia?
Porque el modelo aprendió de un mundo que cambia. Cuando el comportamiento de los clientes o las condiciones del entorno se alejan de los datos con los que se entrenó, sus predicciones pierden precisión aunque el código sea idéntico. A eso se le llama deriva.

¿Cada cuánto hay que reentrenar un modelo?
No hay una regla única: depende de qué tan rápido cambie el fenómeno que predice. Lo correcto no es fijar un calendario arbitrario, sino monitorear el desempeño y reentrenar cuando los indicadores muestren que se está deteriorando. El monitoreo le dice cuándo.

¿Necesito un equipo enorme para operar modelos?
No. Necesita disciplina más que tamaño: tuberías de datos confiables, despliegue versionado, monitoreo y roles claros de responsabilidad. Una organización pequeña que cierra bien ese ciclo supera a una grande que entrega cuadernos sueltos.

El primer paso

Si en su organización hay modelos prometedores que nunca terminan de salir del laboratorio, el problema casi nunca es el algoritmo: es la falta de un camino claro hacia producción y de un mecanismo para gobernarlos una vez allí. Ese camino se puede diseñar, y conviene hacerlo antes de acumular más experimentos huérfanos.

En SUMāTO acompañamos ese tránsito del modelo al producto, con un diagnóstico que identifica dónde está atascado su ciclo de datos, despliegue y monitoreo. Si quiere poner a trabajar sus modelos en lugar de archivarlos, conversemos sobre un primer diagnóstico para su caso.