MLOps para visión artificial en obra: cómo detectar drift y reentrenar modelos de inteligencia artificial en construcción sin downtime

Un modelo de visión artificial desplegado en obra pierde precisión de forma silenciosa. No hay una alarma que se dispare cuando el mAP (mean Average Precision) cae de 0,89 a 0,71 en detección de EPIs porque, en producción, no existe ground truth con el que comparar cada predicción. El equipo descubre el problema semanas después, cuando un supervisor detecta que el sistema deja pasar cascos mal colocados que hace un mes habría marcado.

Este es el punto ciego que la mayoría de despliegues de inteligencia artificial en construcción no resuelve: se trata la visión artificial como un proyecto con fecha de entrega, no como una pieza de infraestructura que requiere mantenimiento continuo. Se monitoriza la disponibilidad del servicio (uptime, latencia) pero no la calidad de las predicciones, que se degrada por polvo, cambios de iluminación estacional, reposicionamiento de cámaras o la simple llegada de una nueva fase de obra con objetos que el modelo nunca vio.

Este artículo describe un framework de MLOps para visión artificial en obra: cómo detectar ese deterioro sin necesidad de etiquetas nuevas constantes, y cómo actualizar el modelo en producción combinando edge y cloud híbrido sin interrumpir la inspección activa.

El problema técnico en detalle

El fenómeno se llama drift y tiene dos variantes relevantes en obra. El covariate shift ocurre cuando la distribución de las imágenes de entrada cambia (polvo en el sensor, luz rasante al atardecer, lluvia) pero las clases a detectar siguen siendo las mismas. El concept drift ocurre cuando cambia lo que hay que detectar: una nueva fase de obra introduce maquinaria, materiales o configuraciones de EPI que no estaban en el dataset de entrenamiento.

Los benchmarks de robustez sobre corrupciones de imagen (ruido, blur, niebla, cambios de brillo) muestran caídas de mAP de entre el 15% y el 30% en modelos de detección de objetos entrenados sobre condiciones limpias, cuando se evalúan sobre variantes corruptas del mismo dataset. En obra, donde el polvo y la iluminación variable son la norma y no la excepción, ese rango es conservador.

El coste de gestionarlo mal tiene dos direcciones. Si el sistema genera falsos negativos en detección de EPI, hay un riesgo de seguridad directo. Si genera falsos positivos, el equipo de obra sufre fatiga de alertas y termina ignorando el sistema o pidiendo que se desactive. En ambos casos, la inversión en visión artificial se pierde no por el modelo en sí, sino por falta de mantenimiento.

Cómo funciona el método

El enfoque combina detección de drift sin etiquetas, validación con canary deployment y actualización sin downtime mediante arquitectura edge-cloud híbrida.

Detección de drift no supervisada. En lugar de esperar accuracy en producción (que requiere etiquetas), se monitorizan proxies estadísticos de la distribución de entrada y de salida:

• Distribución de los embeddings de la capa penúltima del backbone (CNN o Transformer visual), comparada con la distribución de referencia mediante Maximum Mean Discrepancy o test de Kolmogorov-Smirnov.
• Population Stability Index (PSI) sobre la distribución de scores de confianza de las predicciones; un PSI superior a 0,2 suele indicar cambio significativo respecto a la ventana base.
• Entropía media de las predicciones: un aumento sostenido indica que el modelo está “dudando” más, señal temprana de drift antes de que caiga el rendimiento observable.

Es la misma lógica que recalibrar un nivel láser en obra: no se espera a que el error visual sea evidente en la pared, se revisa la desviación de la burbuja de forma periódica.

Shadow deployment. Antes de sustituir el modelo en producción, la versión candidata se ejecuta en paralelo sobre el mismo stream de vídeo, sin actuar sobre las alertas reales. Se compara su distribución de predicciones contra la versión activa mediante divergencia KL y tasa de acuerdo (agreement rate). Solo si supera un umbral definido (por ejemplo, mejora de F1 por clase superior a 5 puntos sin degradar ninguna clase crítica) se promueve a producción.

Actualización sin downtime. El swap de modelos se hace mediante despliegue blue-green: dos contenedores de inferencia activos (por ejemplo, sobre NVIDIA Triton Inference Server con TensorRT), y un balanceador que redirige el tráfico de cámara al nuevo modelo de forma gradual, con rollback inmediato si las métricas de shadow mode se degradan en producción real.

Arquitectura edge-cloud híbrida. El edge (Jetson u equivalente) ejecuta la inferencia en tiempo real con baja latencia y registra telemetría (embeddings, confianza, metadatos de cámara y hora). El cloud agrega esa telemetría de todas las cámaras del proyecto, ejecuta el análisis de drift, orquesta el reentrenamiento y empuja el modelo actualizado de vuelta al edge mediante un registro de modelos versionado (MLflow o DVC).

Integración práctica

Una empresa constructora que ya tiene visión artificial en producción puede adoptar este framework en fases, sin sustituir su infraestructura actual:

1. Instrumentar telemetría: registrar embeddings, confianza y metadatos (cámara, zona BIM, hora, fase de obra) de cada inferencia, no solo la predicción final.
2. Establecer la línea base: capturar la distribución de referencia durante las primeras 2-4 semanas de operación estable.
3. Desplegar el servicio de detección de drift: job batch diario o semanal en cloud que compara la ventana reciente contra la base.
4. Cola de etiquetado activo: los frames con mayor incertidumbre se envían a un pipeline de revisión humana ligera, no a un reentrenamiento masivo.
5. Reentrenamiento disparado por umbral: fine-tuning incremental sobre el subconjunto activo, no reentrenamiento completo desde cero.
6. Validación en shadow mode y rollout blue-green antes de sustituir el modelo activo.

Señal de cambio de entorno	Métrica de detección	Acción recomendada
Polvo, niebla en cámara	PSI sobre confianza, MMD sobre embeddings	Recalibración de preprocesado + fine-tuning ligero
Cambio de iluminación estacional	Entropía media de predicciones	Ampliar dataset con augmentation de brillo/contraste
Reposicionamiento de cámara	Cambio brusco en distribución espacial de detecciones	Reentrenar con nuevo ángulo o recalibrar homografía
Nueva fase de obra	Aumento de detecciones de baja confianza en clases nuevas	Reentrenamiento completo con nuevas clases

La integración con BIM e inteligencia artificial aporta contexto estructural útil: asociar cada cámara a una zona del modelo BIM permite anticipar qué fase de obra viene y preparar el reentrenamiento antes de que el drift ya haya degradado el sistema. El enfoque de adaptación de dominio descrito en BIM-to-scan gap: escaneo virtual físico y adaptación de dominio para segmentar nubes de puntos es directamente aplicable aquí: el problema de fondo (distribución sintética vs. distribución real) es el mismo que el de un modelo entrenado en condiciones limpias frente a obra activa.

Para proyectos que ya combinan visión artificial en obra con seguimiento de trabajadores, el pipeline de aprendizaje incremental descrito en aprendizaje incremental en edge AI para el seguimiento de trabajadores y la productividad comparte la misma infraestructura de actualización continua en edge, y puede reutilizarse como base técnica.

Limitaciones y condiciones de uso

Este framework tiene requisitos que conviene dejar claros antes de implementarlo:

• Volumen de cámaras: con menos de 4-5 cámaras activas, las pruebas estadísticas de drift (KS, MMD) tienen poca potencia; el ruido se confunde con señal real.
• Validación etiquetada periódica: la detección no supervisada indica cambio de distribución, no necesariamente caída de accuracy. Se necesita una muestra pequeña etiquetada mensualmente (50-100 frames) para correlacionar ambas señales.
• Riesgo de feedback loop: reentrenar automáticamente sobre las propias predicciones del modelo sin supervisión humana puede reforzar errores sistemáticos. El active learning con revisión humana no es opcional.
• Cómputo en edge: el cálculo de embeddings para drift añade carga sobre hardware ya dimensionado para inferencia. En dispositivos con recursos ajustados, conviene usar un backbone distillado solo para el scoring de drift.
• Concept drift severo: si una nueva fase de obra introduce clases completamente nuevas, el fine-tuning incremental no basta. Se requiere reentrenamiento completo con dataset ampliado.

Lo que esto significa para el sector

La madurez de MLOps se está convirtiendo en un diferenciador competitivo tan relevante como el propio modelo. Una constructora que trata sus modelos de visión artificial como infraestructura viva, con monitorización continua y actualización sin downtime, mantiene la fiabilidad del sistema durante todo el ciclo de obra, no solo en el piloto inicial.

Esto también afecta a la confianza operativa: cuando un jefe de obra pregunta por qué el sistema marcó (o no marcó) una incidencia, la trazabilidad de versiones de modelo y las métricas de drift permiten responder con datos. La explicabilidad de estas decisiones conecta directamente con los métodos descritos en inteligencia artificial explicable en construcción: qué revelan SHAP, LIME y Grad-CAM, que ayudan a auditar por qué un modelo cambió su comportamiento tras un reentrenamiento.

En última instancia, la inteligencia artificial en construcción solo genera valor sostenido si se mantiene fiable a lo largo del tiempo de vida de la obra, no solo en el momento de la demo.

Si tu organización ya tiene visión artificial en producción y necesita una capa de monitorización y reentrenamiento continuo, podemos ayudarte a diseñar el pipeline de MLOps adaptado a tu infraestructura edge-cloud actual.