Mantenimiento predictivo con machine learning clásico
Actualizado: 2026-05-03
El mantenimiento predictivo — predecir fallos de equipos antes de que ocurran — es una de las aplicaciones de Industria 4.0 con ROI medible más claro. La mayoría de proyectos exitosos no usan deep learning. Usan machine learning clásico bien diseñado: random forests, SVM, modelos de supervivencia. Entender por qué es útil para no caer en la trampa del “todo con redes neuronales”.
Puntos clave
- Un equipo industrial típico (motor, bomba, compresor) genera señales de vibración, temperatura, presión y consumo eléctrico que permiten tres formulaciones: clasificación binaria, regresión y modelos de supervivencia.
- El 80 % del éxito está en el feature engineering, no en el algoritmo elegido.
- Los random forests sobre features físicos extraídos superan en casos típicos a CNNs sobre series crudas.
- El pipeline de producción puede ejecutarse con ~50 MB de RAM en un gateway edge sin GPU.
- Deep learning solo aporta valor diferencial con sensores no estructurados, flotas masivas o transfer learning entre plantas.
El problema típico
Un equipo industrial (motor, bomba, compresor) tiene sensores midiendo vibración, temperatura, presión y consumo eléctrico. La pregunta central es: ¿cuándo fallará? Hay tres formulaciones:
- Clasificación binaria: “¿fallará en la próxima semana?”
- Regresión: “¿cuántos días hasta el siguiente fallo?”
- Supervivencia: “¿cuál es la probabilidad de fallo acumulada en el tiempo?”
Cada formulación requiere tratamiento distinto, pero todas se resuelven sin deep learning en la mayoría de casos.
Por qué ML clásico gana aquí
Tres razones por las que deep learning no es la respuesta primera:
- Volumen de datos limitado. Una planta industrial tiene quizás 50-500 equipos con historial de fallos. Deep learning necesita miles de ejemplos etiquetados para brillar; con 200 fallos documentados, un random forest generaliza mejor.
- Interpretabilidad. El operador de mantenimiento pregunta “¿por qué crees que va a fallar?”. Los features de un random forest son directamente interpretables (“aumento de vibración en banda 120-200 Hz”). Una red neuronal es un oráculo.
- Infraestructura edge. Los modelos suelen ejecutarse en controladores en la planta, no en el cloud. Un árbol de decisión ocupa kilobytes y corre en microsegundos; una red neuronal requiere GPU o aceleración dedicada.
Feature engineering: lo que realmente importa
El 80 % del éxito de un modelo de mantenimiento predictivo está en los features, no en el algoritmo. Features útiles extraíbles de señales de vibración:
- Estadísticas en dominio temporal: media, varianza, skewness, kurtosis, valor RMS, factor de cresta.
- Dominio frecuencial: energía en bandas específicas mediante FFT + integración. Los rodamientos defectuosos introducen frecuencias características.
- Envolvente de Hilbert: técnica clásica para extraer modulación de alta frecuencia, útil para defectos incipientes.
- Ratios y tendencias: vibración actual dividida por la baseline del equipo sano, pendiente de crecimiento en los últimos 30 días.
Un random forest sobre estos features bien extraídos supera en casos típicos a una CNN sobre las series crudas — porque las CNNs tienen que reaprender lo que ya sabemos por física.
Modelos de supervivencia
Para equipos donde “tiempo hasta el fallo” es la métrica relevante, los modelos de supervivencia son mejores que la clasificación binaria:
- Modelo de Cox de riesgos proporcionales: clásico de bioestadística, funciona bien aquí. Asume que los features ajustan proporcionalmente el riesgo base.
- Random Survival Forests: extensión del random forest para datos censurados (equipos que todavía no han fallado).
- Weibull Accelerated Failure Time: asume distribución paramétrica de tiempo hasta el fallo; útil cuando se tienen supuestos de fiabilidad bien fundados.
Librerías como lifelines[1] y scikit-survival[2] hacen estos modelos accesibles con APIs familiares para quienes ya usan scikit-learn.
Despliegue realista en producción
Un pipeline típico de producción tiene estos pasos:
- Edge gateway en la planta recibe datos de sensores vía Modbus/OPC-UA/MQTT.
- Agregación local: extrae features cada 5-15 minutos en una ventana deslizante.
- Inferencia local con modelo previamente entrenado (formato ONNX o joblib serializado).
- Alerta a SCADA/CMMS cuando la probabilidad de fallo supera el umbral, con recomendación de inspección.
- Feedback loop: registra si el fallo ocurrió o no y alimenta el reentrenamiento mensual.
Este flujo corre con ~50 MB de RAM en el edge, no requiere GPU y es totalmente auditable.
Cuándo sí compensa deep learning
Casos donde deep learning aporta sobre ML clásico:
- Sensores no estructurados: imágenes de cámaras termográficas o audio de vibración continua a alta frecuencia. CNNs y RNNs extraen patrones donde el feature engineering es más costoso que entrenar la red.
- Volúmenes masivos: flota de 10.000+ equipos con telemetría continua. Deep learning escala; el random forest empieza a saturar memoria.
- Transfer learning entre plantas: un modelo preentrenado en una flota puede adaptarse con menos datos de otra. Difícil de replicar con árboles.
Pero estos casos son la minoría. El 80 % de proyectos de mantenimiento predictivo se resuelven con ML clásico bien hecho.
Ver también nuestra cobertura de la revolución de la Industria 4.0 y gemelos digitales industriales — el contexto más amplio donde el mantenimiento predictivo cobra sentido.
Conclusión
El hype sobre deep learning tiende a obscurecer que el mantenimiento predictivo es un problema bien resuelto con técnicas clásicas. Los equipos que adoptan ML clásico primero obtienen valor antes, con menor inversión en datos e infraestructura, y con modelos que el personal de planta entiende. Deep learning queda reservado para casos genuinamente complejos.
