MLOps industrial: monitorización de drift y human-in-the-loop

Un modelo de IA industrial no falla el día que se despliega: falla seis meses después, cuando cambia la materia prima, se sustituye un rodamiento o entra un producto nuevo y nadie lo está mirando. El MLOps industrial es la disciplina que mantiene los modelos vivos en planta: monitorizar el drift de datos y de concepto, fijar umbrales de confianza para que el modelo sepa cuándo abstenerse, incorporar la corrección del operario al ciclo de aprendizaje y decidir con criterio cuándo reentrenar y cuándo retirar un modelo.

Por qué los modelos industriales dejan de funcionar

Todo modelo de aprendizaje automático es una fotografía. Aprende la relación entre unas entradas (vibración, temperatura, imágenes de la pieza, consumos) y una salida (fallo inminente, pieza defectuosa, demanda prevista) tal y como esa relación existía en los datos de entrenamiento. El problema es que una planta no es una fotografía: es una película. Los proveedores cambian, las máquinas se desgastan, los útiles se sustituyen, las recetas se ajustan y las estaciones alteran la temperatura del taller. Cada uno de esos cambios separa un poco más la realidad de la fotografía que el modelo aprendió.

Esta degradación es silenciosa, y ahí está el peligro. Un rodamiento roto se oye; un modelo degradado no. El sistema sigue devolviendo predicciones con la misma apariencia de seguridad que el primer día, solo que ahora son peores. Si nadie mide la calidad de esas predicciones de forma continua, la primera señal de que el modelo ha muerto suele ser un lote rechazado por el cliente o una avería que el predictivo no avisó. Por eso el trabajo serio con IA industrial no termina en el despliegue: empieza ahí. Los modelos avanzados de IA que valen para producción son los que llegan acompañados de su sistema de vigilancia, no los que mejor puntúan en el laboratorio.

Para aterrizar las ideas usaremos un ejemplo a lo largo de todo el artículo: una línea de inyección de plástico con un modelo de visión que clasifica piezas en buenas y defectuosas a la salida del molde. El modelo se entrenó con imágenes de seis meses de producción y en validación superaba con holgura al inspector humano en consistencia. Veremos cómo ese modelo se degrada, cómo detectarlo y qué hacer en cada fase.

Drift de datos y drift de concepto, con ejemplos de planta

La literatura distingue dos formas principales de degradación, y la distinción importa porque se detectan y se corrigen de manera distinta.

Drift de datos: cambia lo que entra

El drift de datos (o covariate shift) ocurre cuando la distribución de las entradas se desplaza respecto a la que el modelo vio en entrenamiento, aunque la relación entre entrada y salida siga siendo la misma. En nuestra línea de inyección: el departamento de compras cambia de proveedor de granza. El polímero nuevo cumple la misma ficha técnica, pero su tono base es ligeramente más opaco. Las piezas siguen siendo buenas o malas por las mismas razones de siempre, pero todas las imágenes que llegan al modelo están ahora un punto fuera de la distribución de entrenamiento. El modelo empieza a marcar como sospechosas piezas perfectamente válidas, porque su superficie ya no se parece a nada de lo que aprendió.

Otros ejemplos habituales en planta: una cámara que se sustituye por otro modelo con distinta óptica, un sensor de vibración recolocado tras un mantenimiento, una luminaria LED nueva sobre la estación de inspección, o un cambio de turno que modifica los parámetros de máquina dentro de tolerancias. Nada de esto es un fallo de nadie: es la vida normal de una fábrica.

Drift de concepto: cambia lo que significa

El drift de concepto es más profundo: cambia la propia relación entre entradas y salida. Lo que ayer era un defecto hoy no lo es, o al revés. Siguiendo con el ejemplo: el cliente principal endurece su criterio estético y una veta superficial que antes se aceptaba pasa a ser motivo de rechazo. Las imágenes no han cambiado en absoluto; ha cambiado la definición de pieza mala. El modelo puede estar viendo exactamente lo mismo que en entrenamiento y aun así equivocarse en todas las piezas con veta, porque aprendió una regla que ya no rige.

En mantenimiento predictivo el drift de concepto aparece cuando se sustituye una máquina o un componente crítico: el patrón de vibración que anticipaba el fallo del rodamiento antiguo no anticipa nada en el rodamiento nuevo, que fallará de otra manera y con otras firmas espectrales. También lo provoca un cambio de régimen de operación: pasar de producir series largas a series cortas altera qué significa un arranque normal.

Cómo detectar el drift: métricas y monitorización

La detección se organiza en tres capas, de la más barata a la más fiable.

Primera capa: vigilar las entradas. No hace falta saber si la predicción fue correcta para notar que los datos han cambiado. Se comparan de forma continua las distribuciones de las variables de entrada (o de los embeddings, en visión) contra una ventana de referencia del entrenamiento. Herramientas estadísticas habituales: el test de Kolmogorov-Smirnov para variables continuas, el índice de estabilidad poblacional (PSI) que la banca lleva décadas usando para sus modelos de riesgo, o distancias entre distribuciones como la de Wasserstein. Esta capa detecta el drift de datos casi en tiempo real y es la primera alarma razonable.

Segunda capa: vigilar las salidas del modelo. Sin conocer aún la verdad, la propia distribución de predicciones informa. Si el clasificador de piezas pasaba de marcar un porcentaje estable de rechazos a duplicarlo en dos días sin que haya cambiado nada conocido en el proceso, algo ocurre: o el proceso se ha degradado de verdad o el modelo está desorientado. Ambas cosas merecen una visita a la línea. La caída de la confianza media de las predicciones es otra señal útil de esta capa.

Tercera capa: comparar contra la realidad. Es la única que detecta el drift de concepto, y exige etiquetas: saber, para una muestra de predicciones, qué ocurrió de verdad. En inspección visual, un muestreo periódico revisado por un inspector humano. En predictivo, el contraste entre alarmas emitidas y averías reales registradas en el GMAO. Esta capa es más lenta (la verdad tarda en llegar) pero es la que mide lo que importa: precisión, exhaustividad, falsos positivos por turno. Conviene definir desde el despliegue qué métrica es la crítica y qué valor dispara una revisión, igual que se hace con cualquier otro indicador de proceso.

Estas tres capas no son solo teoría de MLOps: son la misma mecánica que sostiene el módulo de detección de anomalías de Captia.ai, que compara cada señal contra la normalidad histórica del activo y expone la desviación como evento y alerta dentro de la plataforma. Ahí se ve el detalle de qué datos consume, cómo se ajusta la sensibilidad y cuándo el módulo no aplica.

Umbrales de confianza: decidir cuándo el modelo no decide

Un modelo bien operado no responde siempre. La mayoría de los modelos de clasificación devuelven, junto a la predicción, una puntuación de confianza. El diseño operativo consiste en convertir esa puntuación en tres zonas de decisión:

1. Confianza alta en pieza buena: la pieza pasa sin intervención humana. Es la zona que genera el ahorro.
2. Confianza alta en pieza mala: rechazo automático, con la pieza apartada para verificación por muestreo.
3. Zona intermedia: el modelo se abstiene y la pieza va a revisión humana. Aquí el sistema reconoce que no sabe.

Los umbrales que separan estas zonas no son un parámetro técnico: son una decisión de negocio. Subir el umbral de la zona automática reduce el riesgo de dejar pasar un defecto, pero envía más piezas a revisión y erosiona el ahorro. El punto de equilibrio depende del coste de cada tipo de error: en una pieza estética de bajo valor se toleran umbrales laxos; en un componente de seguridad, la zona de abstención debe ser generosa. Y hay un efecto secundario valioso: el tamaño de la zona intermedia es en sí mismo un detector de drift. Si el porcentaje de piezas en las que el modelo se abstiene pasa del 5 % habitual al 20 %, el modelo está gritando que el mundo ha cambiado, antes incluso de que ninguna métrica de acierto lo confirme.

Human-in-the-loop: el operario corrige y el sistema aprende

La zona de abstención tiene una segunda función, más importante que la primera: fabrica datos de entrenamiento. Cada vez que el operario revisa una pieza dudosa y dicta el veredicto, está etiquetando exactamente los casos donde el modelo es más débil. Un sistema human-in-the-loop bien diseñado captura ese veredicto de forma estructurada (no en una libreta ni en la cabeza del inspector) y lo incorpora al conjunto de datos del siguiente reentrenamiento. El resultado es un ciclo que se refuerza: el modelo deriva los casos difíciles al humano, el humano los resuelve, y esos casos resueltos hacen que la siguiente versión del modelo tenga menos casos difíciles.

Para que el ciclo funcione en planta hay tres condiciones prácticas. Primera: la corrección tiene que costar segundos, no minutos. Si validar una pieza exige abrir una aplicación aparte y rellenar cuatro campos, el operario dejará de hacerlo al tercer día, y con razón. Un botón físico o dos toques en la pantalla de la estación. Segunda: el operario tiene que ver que sus correcciones sirven. Cuando la versión nueva del modelo deja de cometer el error que él corrigió cuarenta veces, el sistema se gana su confianza; si sus correcciones caen en un pozo, se gana su desprecio. Tercera: las correcciones también se auditan. Los inspectores humanos discrepan entre sí (cualquier estudio de repetibilidad y reproducibilidad de atributos lo confirma), así que las etiquetas humanas contradictorias deben detectarse y arbitrarse antes de entrenar con ellas, o el modelo aprenderá la inconsistencia.

Este patrón de colaboración es el mismo que sostiene a los agentes de IA en operaciones: el sistema actúa solo dentro de su zona de competencia demostrada, escala al humano lo que queda fuera, y la frontera entre ambas zonas se desplaza con la evidencia, no con el entusiasmo.

Reentrenamiento y validación antes de volver a producción

Detectado el drift y acumuladas las correcciones, toca reentrenar. Dos errores simétricos conviene evitar. El primero es reentrenar en caliente y a ciegas: volcar los datos nuevos, entrenar y desplegar sin más. Un reentrenamiento puede empeorar el modelo (datos nuevos mal etiquetados, sobreajuste a un episodio transitorio) y sin validación no hay forma de saberlo hasta que el daño está hecho. El segundo error es no reentrenar nunca por miedo a tocar lo que funciona, que es como no cambiar el aceite para no abrir el motor.

El proceso disciplinado tiene cuatro pasos:

1. Congelar un conjunto de validación honesto. Piezas etiquetadas de las últimas semanas, que reflejen la realidad actual (con la granza nueva, con el criterio nuevo), separadas del entrenamiento. Contra ese conjunto se comparan modelo viejo y modelo nuevo con las mismas métricas.
2. Entrenar como candidato, no como sucesor. La versión nueva no hereda el trono por ser nueva: tiene que batir a la actual en el conjunto de validación y no degradarse en los casos que la actual ya resolvía bien.
3. Desplegar en sombra. Antes de darle el mando, el candidato corre en paralelo sobre la producción real sin actuar: predice, se registra, y sus predicciones se comparan con las del modelo activo y con los veredictos humanos durante días o semanas según el riesgo del proceso.
4. Promocionar con vuelta atrás preparada. Cada versión queda registrada con sus datos, su código y sus métricas (aquí ayudan las prácticas de versionado de modelos y los registries habituales en MLOps), de modo que volver a la versión anterior sea una operación de minutos, no un proyecto.

La cadencia depende del proceso: hay plantas donde un reentrenamiento trimestral programado basta, y procesos con drift estacional o de materia prima frecuente donde el disparador debe ser la métrica de monitorización, no el calendario. Lo importante es que exista un disparador definido, sea cual sea.

Cuándo retirar un modelo (y cómo hacerlo sin drama)

No todos los modelos merecen ser rescatados. Hay tres situaciones donde la decisión correcta es la retirada, y conviene reconocerlas pronto porque un modelo degradado que sigue operando destruye dos cosas a la vez: calidad y confianza de la plantilla en la IA.

• El problema ya no existe. La máquina que vigilaba el predictivo se ha sustituido, el producto que inspeccionaba se ha descatalogado. Mantener el modelo en marcha es puro coste y ruido de alarmas sin sentido.
• El reentrenamiento ya no compensa. Si cada pocos meses hay que reetiquetar miles de muestras para perseguir un proceso que cambia más deprisa de lo que el modelo aprende, el coste de mantenimiento supera al beneficio. A veces la respuesta correcta es un enfoque distinto (otras variables, otro tipo de modelo, o una mejora del proceso físico que reduzca la variabilidad de origen).
• La confianza operativa se ha roto. Si los operarios han aprendido a ignorar las alarmas porque fallan demasiado, el modelo ya está retirado de facto; formalizarlo es más honesto que fingir que sigue en servicio.

La retirada ordenada replica el despliegue a la inversa: se devuelve el proceso al procedimiento manual o al sistema anterior de forma explícita y comunicada, se archiva la versión final con sus datos y métricas (el histórico vale oro para el siguiente intento) y se documenta por qué se retiró. Un modelo retirado con su autopsia escrita es un activo; un modelo abandonado en producción es un pasivo.

La arquitectura mínima de MLOps para una planta

Nada de lo anterior exige una plataforma faraónica. Para una pyme industrial con uno o dos modelos en producción, la arquitectura mínima viable se resume en cinco piezas:

Obsérvese que tres de las cinco piezas son organizativas más que tecnológicas. El MLOps industrial se parece menos a comprar una plataforma que a extender a los modelos la misma disciplina que la planta ya aplica a sus calibraciones de instrumentos: patrón de referencia, verificación periódica, registro y criterio de intervención. Quien opera bien sus básculas ya sabe operar sus modelos; solo necesita trasladar el hábito.

Preguntas frecuentes sobre MLOps industrial

Si tienes modelos en producción sin monitorización de drift, o proyectos de IA que no pasaron del piloto porque nadie definió cómo mantenerlos, en Captia AI acompañamos todo ese ciclo: del despliegue a la operación continua, con el operario dentro del bucle desde el primer día.