Mantenimiento predictivo basado en agentes con OpenVINO: un pipeline, cinco casos de uso industriales.
Cómo un pipeline de OpenVINO y LangGraph convierte las predicciones en evidencias e informes a través de pipelines, paneles solares, líneas eléctricas, datos de audio y raster en hardware Intel.
Fuentes: Building an Agentic AI Predictive Maintenance Pipeline with OpenVINO™ and Intel® Metro AI Suite
Las tuberías, las instalaciones y otros activos críticos requieren inspecciones constantes para evitar fallos, fugas e incidentes de seguridad. El mantenimiento puramente reactivo o basado en el calendario implica desplazamientos repetidos en camión, señales tempranas de defectos que pasan desapercibidas y evidencias dispersas cuando llega una auditoría. La IA agente ofrece una forma de monitorear continuamente y actuar antes, lo que permite reducir las visitas al sitio, acortar los tiempos de inactividad, mejorar la seguridad y dejar un registro listo para auditorías.
Este artículo trata sobre un proyecto del Google Summer of Code 2026 que tomó el modelo de mantenimiento predictivo Intel Metro AI Suite, desarrollado sobre OpenVINO, y lo amplió con nuevos casos de uso y conjuntos de datos.
La brecha entre una predicción y una decisión
Un modelo puede generar miles de predicciones, pero la persona que las recibe sigue necesitando tres respuestas: qué sucedió, por qué y qué inspeccionar a continuación. Una etiqueta con un puntaje de confianza no proporciona eso. Un pipeline práctico debe conservar las pruebas detrás de cada resultado, aceptar diferentes tipos de entrada y permitir que las personas analicen los resultados sin necesidad de comprender el código subyacente.
El proyecto apuntaba exactamente a eso. Vinculó la inferencia del modelo con un almacenamiento estructurado, coordinó agentes de IA, preguntas en lenguaje natural y tickets basados en pruebas, todo dentro de un único flujo de trabajo.
Cómo se construye el pipeline
El procesamiento comienza con un modelo OpenVINO cuyos resultados se guardan en archivos JSONL y en una base de datos SQLite. A continuación, un flujo de trabajo LangGraph coordina a tres agentes: uno para la política, otro para el análisis y otro para las pruebas. Los usuarios pueden explorar los resultados a través de un chat o presentar un ticket respaldado por las pruebas correspondientes.
Cuatro mejoras dieron forma al trabajo, orientadas a la usabilidad, la explicabilidad, la extensibilidad y el alcance de las aplicaciones. Se trata de correcciones diferentes, pero todas forman parte del mismo flujo integral.
Cuatro contribuciones
Un campo para cada tipo de pregunta
Anteriormente, el usuario tenía que elegir entre el modo de análisis, pruebas y SQL antes de escribir algo. Eso significaba conocer cómo estaban divididos los componentes internos, lo cual es algo difícil de exigir a un operador. La versión actual detecta la intención y envía la pregunta automáticamente al backend adecuado, tanto en la línea de comandos como en la interfaz web. Ya nadie tiene que seleccionar un modo.
Preguntas sobre lecturas brutas de sensores
El esquema configurable de SQLite se amplió para conservar los valores brutos de los sensores, la confianza por modalidad y los metadatos sobre el caso de uso. Eso hace posibles preguntas como esta: ¿qué muestras tuvieron una mayor confianza en los sensores que en las imágenes? La condición en lenguaje natural se convierte en una consulta a la base de datos que devuelve las lecturas, etiquetas y registros de origen correspondientes. El mismo contexto también llega a los agentes de políticas y análisis. Lo importante es la trazabilidad, ya que los valores brutos y los metadatos almacenados vinculan cada respuesta con los registros de los que proviene.
Nuevos modelos sin reconstrucción
El punto de entrada original para la inferencia gestionaba demasiadas tareas. Se dividió en partes distintas: configuraciones, enrutamiento, manejadores por modelo, el paso de ejecución, escritura de resultados y generación de gráficos. Ahora un distribuidor elige un manejador pequeño y específico, mientras que los componentes compartidos se encargan del comportamiento común a cada caso de uso. Agregar un nuevo tipo de datos ahora implica escribir un manejador y una configuración, reutilizando el resto del ciclo de vida.
Cinco casos de uso industriales en un mismo entorno de ejecución
Las entradas, los objetivos de predicción y las pruebas difieren entre los cinco casos, pero comparten la misma infraestructura. Se abordan cuatro patrones de entrada: datos tabulares, imágenes, audio con texto y datos ráster con texto.
Tuberías de petróleo y gas. Los datos tabulares sobre operación y materiales se alimentan a un MLP de OpenVINO que predice dos cosas al mismo tiempo: el estado de la tubería y la pérdida de espesor de su pared. Las entradas incluyen valores relacionados con la geometría, el material, las condiciones de operación y la corrosión. Cada registro procesado genera una clase que indica el estado de la tubería y una estimación de la pérdida de espesor, y ambos resultados permanecen vinculados a las mediciones originales. Esa relación permite que los agentes posteriores expliquen un resultado utilizando las cifras reales de operación, y el flujo de trabajo incluye análisis centrados en la corrosión.
Panels solares. Un detector OpenVINO de estilo YOLO busca defectos en imágenes de electroluminiscencia de canal único de las celdas solares y conserva los cuadros delimitadores como evidencia. En una muestra, un cuadro rojo marca una grieta real en forma de estrella que se espera que el detector detecte. Una evaluación realizada en las 19,150 imágenes de prueba arrojó un valor F1 de 0.8277. El cuadro predicho se almacena junto con su clase y nivel de confianza, para que el usuario pueda ver dónde se encontró el defecto.
Transmisión de energía. Un modelo YOLOv8s-cls ajustado específicamente clasifica las imágenes de líneas de transmisión en tres categorías de circuitos. Puede manejar tanto imágenes sintéticas como reales, lo que permite comprobar si un clasificador es capaz de procesar vistas de circuitos generadas por ordenador y fotografías obtenidas en inspecciones en campo. En 348 imágenes de prueba, acertó en 334 casos, logrando una precisión del 0.9598. Ambas fuentes de imágenes pasan por el mismo proceso de preprocesamiento e inferencia.
Mantenimiento del entorno operativo. Este caso combina un clip de audio con una leyenda. Ambos se procesan por separado, se clasifican mediante dos ramas MLP de OpenVINO y luego se combinan mediante fusión tardía. Una muestra etiquetada como maquinaria rotativa venía con la leyenda de una herramienta eléctrica vibrando mientras funciona. Un frame de video proporciona contexto para el lector humano, pero la entrada del modelo es el audio del clip más el texto. Las ramas permanecen inspeccionables por separado hasta que se fusionan sus puntuaciones.
Tratamiento de aguas. Un parche rasterizado de 15 canales de Sentinel-2 se combina con una descripción textual ambiental, por ejemplo una que describe un condado en Arizona con datos de evaporación-transpiración, precipitaciones, profundidad del agua subterránea y profundidad del agua superficial. Las características estadísticas del raster y las características TF-IDF del texto pasan por ramas separadas de OpenVINO antes de una fusión posterior, lo que mantiene la confianza de cada rama. Se genera una vista previa en JPEG para que las personas puedan observar la muestra, pero el modelo mismo utiliza el arreglo multicanal original de NumPy. La vista previa también puede adjuntarse a un ticket, proporcionando evidencia visual de una predicción multimodal.
Ejecución en hardware Intel
Cada modelo se implementó en formato OpenVINO IR, y el punto de entrada configurable maneja imágenes, vectores de sensores tabulares, características de audio e entradas multimodales emparejadas. El código se validó en una GPU Intel, y la inferencia a través de la pipeline también se confirmó en una NPU Intel, incluyendo la generación de los archivos de salida JSONL y SQLite.
Pruebas que van más allá de la precisión
La validación trascendió la precisión del modelo. Cada flujo de trabajo se probó desde la carga del modelo y la generación de resultados estructurados, pasando por los agentes, las interfaces, las pruebas, los tickets y la ejecución en hardware Intel. Las verificaciones abarcaron tanto los límites entre los componentes como las salidas de los modelos individuales.
Lo que muestran las demostraciones
Dos vistas muestran cómo funciona el sistema. La primera es la orquestación del backend. Comienza con los resultados de inferencia en la capa de datos compartidos. El agente de políticas los filtra según la política configurada, y el agente de análisis resume su significado desde un punto de vista operativo. Luego, el agente de evidencias agrupa cada resultado junto con sus datos de origen y metadatos en un registro trazable. Juntos, convierten la salida del modelo almacenada en análisis estructurado y evidencias listas para su revisión.
La segunda es la conversación unificada. Los usuarios revisan los resúmenes del análisis, examinan las evidencias y filtran los resultados, además de consultar datos estructurados de mantenimiento. Después de investigar, pueden crear un ticket de mantenimiento para seguimiento. Esto demuestra todo el proceso, desde explorar los resultados hasta presentar un ticket.
Lecciones del diseño
El problema central de diseño fue equilibrar la reutilización con el comportamiento específico de cada modalidad. Los cinco casos comparten componentes de configuración, ejecución, almacenamiento y agente, mientras que pequeños procesadores se encargan del preprocesamiento y posprocesamiento necesarios para cada tipo de dato. Se evita la duplicación sin forzar que entradas muy diferentes pasen por una lógica idéntica.
Los resultados también sugieren que no sea adecuado almacenar únicamente una etiqueta. Cuando los valores brutos de los sensores, las cajas delimitadoras, las confianzas por ramas, los metadatos y las vistas previas de la fuente se envían junto con la predicción, cada resultado permanece vinculado a pruebas que tanto las personas como los agentes pueden examinar.
En los casos multimodales, la fusión tardía permite rastrear de forma independiente las ramas de audio, texto y raster. El ponderamiento igual actual es sencillo y reproducible, aunque pesos aprendidos o calibrados dinámicamente podrían reflejar mejor el grado de fiabilidad de cada modalidad.
La capa de agentes no reemplaza a los modelos predictivos. Organiza los resultados almacenados, obtiene pruebas de apoyo y dirige una pregunta a el análisis o operación en la base de datos adecuados. La validación abarca los conjuntos de datos evaluados y el hardware Intel, y las implementaciones reales seguirían necesitando pruebas, monitoreo y calibración específicos para cada sitio.
De prototipo a plano
Lo que comenzó como un pipeline diseñado para un único caso de uso se volvió más modular, multimodal y orientado al usuario. OpenVINO proporciona la capa de inferencia común, mientras que el almacenamiento estructurado junto con agentes coordinados convierten la salida del modelo en información que una persona puede examinar y actuar sobre ella. La misma secuencia, desde los datos industriales pasando por la inferencia y las pruebas hasta la exploración en lenguaje natural y los tickets, ahora se repite en varios dominios de mantenimiento.
Lecturas relacionadas
- Flujos de trabajo multiagente de LangGraph: Comparación entre enjambre y supervisor — Divide un flujo de trabajo de LangGraph en subagentes con puntos de verificación, luego crea un asistente financiero tanto como enjambre como supervisor, y observa dónde falla cada patrón.
- Un agente financiero de QuickBooks que funciona con un LLM local mediante Ollama y LangChain — Un agente ReAct basado en Qwen 3.5 9B y una RTX 4070 lee datos en tiempo real de QuickBooks sin ningún costo relacionado con la nube. Consulta el código, los resultados y las limitaciones conocidas.