Casi todos los programas de aprendizaje automático estancados a los que nos llaman tienen la misma forma. Hay un modelo. Funciona bien sobre un conjunto de validación. Alguien hizo una demo hace ocho meses y todos coincidieron en que era impresionante. No está en producción, y nadie da una respuesta clara sobre por qué.
La razón casi nunca es el modelo. Es que la distancia entre un notebook y un sistema de producción es un problema de ingeniería que nadie estaba dotado para resolver, y tiene una estructura predecible. Si conoces la estructura, puedes planificar para ella en lugar de descubrirla una sorpresa dolorosa cada vez.
Las cuatro distancias
En la práctica la distancia se descompone en cuatro problemas separados que se agrupan y se llaman «puesta en producción», que es por lo que nunca se planifican como es debido.
- Reproducibilidad. ¿Puedes reconstruir el modelo exacto que está sirviendo tráfico ahora mismo, a partir de los datos exactos con los que se entrenó? Si la respuesta implica el portátil de alguien, no tienes un modelo: tienes un artefacto que nadie puede regenerar.
- Servicio. El modelo tiene que ejecutarse en algún sitio con un presupuesto de latencia, una historia de escalado y un techo de coste. Un modelo que tarda cuatro segundos es un producto distinto de uno que tarda cuarenta milisegundos, y esa diferencia suele descubrirse tarde.
- Evaluación. No la métrica sin conexión del notebook, sino una barrera automática que se ejecuta en cada cambio y bloquea un lanzamiento que empeore. Sin ella, cada despliegue es un juicio hecho bajo presión de tiempo.
- Monitorización. El mundo se mueve. Las entradas derivan, los esquemas de origen cambian, una variable empieza a llegar nula en silencio. Necesitas enterarte por un panel, no por un cliente.
Cada una de estas es abordable por sí sola. Juntas representan una plataforma, y las plataformas tienen que ser el trabajo de alguien. El fallo organizativo más común que vemos es un equipo de ciencia de datos al que se mide por la calidad del modelo y del que se espera implícitamente que entregue también las cuatro, sin apoyo de ingeniería de plataforma y sin tiempo asignado para ello.
La reproducibilidad es la primera que arreglar
Si solo puedes abordar una distancia este trimestre, que sea la reproducibilidad, porque las otras tres dependen de ella. No puedes evaluar de forma significativa un modelo que no puedes reconstruir. No puedes revertir a una versión anterior que no puedes reconstruir. No puedes investigar una alerta de deriva sin saber exactamente con qué se entrenó el modelo.
En concreto, esto significa un registro que recoja, para cada versión de modelo: la instantánea de los datos de entrenamiento, el commit de código, los hiperparámetros, el entorno y los resultados de evaluación. Nada exótico: es un problema resuelto con varias buenas opciones de código abierto. La parte difícil es la disciplina de encaminar cada modelo por él, incluido el urgente que alguien quiere lanzar el viernes.
Un modelo que no puedes reconstruir no es un activo. Es una dependencia con una fecha de caducidad desconocida.
Las barreras de evaluación cambian el comportamiento del equipo
El segundo cambio de mayor palanca es poner una barrera de evaluación automática en tu canal de despliegue. No un informe que alguien lee: una comprobación que hace fallar la construcción.
El efecto sobre el comportamiento del equipo es mayor que el efecto técnico. Una vez que una regresión bloquea un merge, la calidad del modelo deja de ser una cuestión de opinión en una reunión de revisión y se convierte en una propiedad del canal. Las discusiones sobre si un cambio es una mejora se resuelven ejecutándolo. Los equipos que adoptan esto de forma consistente informan de que su frecuencia de lanzamiento sube, no baja, porque el riesgo de cada lanzamiento individual cae.
Diseña la barrera para que pruebe lo que de verdad te importa. Un umbral de precisión agregada es una barrera débil: oculta regresiones en los subgrupos que más importan. Divide tu conjunto de evaluación por las dimensiones donde un fallo sería caro y pon la barrera en la peor porción, no en la media.
Monitorización: vigila las entradas, no solo las salidas
La mayoría de los equipos que instrumentan algo instrumentan las distribuciones de predicción. Merece la pena hacerlo, pero es un indicador retrasado: para cuando la distribución de salida ha cambiado visiblemente, el modelo lleva un tiempo tomando peores decisiones.
La monitorización de entradas detecta los problemas antes y los diagnostica más rápido. Sigue las distribuciones de variables, las tasas de nulos y la cardinalidad en la ruta de inferencia en vivo. La inmensa mayoría de los incidentes de producción reales que hemos investigado fueron problemas de datos de origen, no degradación del modelo: un cambio de esquema que nadie anunció, un join que empezó a descartar filas en silencio, un cambio de unidad en un sistema de origen.
Cómo es un primer trimestre razonable
Para un equipo con modelos en producción y sin plataforma, un primer trimestre realista es: un registro con todos los modelos de producción actuales registrados y reproducibles, un modelo llevado a una ruta de despliegue automática con una barrera de evaluación, y monitorización de entradas sobre el tráfico en vivo de ese modelo. Eso es de verdad alcanzable en doce semanas, y establece el patrón que sigue el resto de tus modelos.
Lo que no funciona es intentar las cuatro distancias en todos los modelos a la vez. Eso es una reescritura de plataforma disfrazada de un trimestre de trabajo, y tiende a terminar con un patrimonio parcialmente migrado que es más difícil de operar que aquello de lo que partiste.
