Resumen Técnico: De la Detección a la Acción – Uso de Agentes de LLM para el Control con Tolerancia a Fallos

Planteamiento del Problema

A pesar de los avances en la automatización, las operaciones de la industria de procesos dependen frecuentemente de la experiencia humana para la toma de decisiones ante condiciones imprevistas, particularmente cuando los datos son limitados o el comportamiento del sistema se desvía de los patrones esperados. Las plantas de proceso enfrentan desafíos como flujos de energía y materiales estrechamente acoplados, síntomas de fallos sutiles dependientes del estado y aludes de alarmas que abruman a los operadores. Los enfoques actuales de Inteligencia Artificial (IA), como el Aprendizaje por Refuerzo (RL), enfrentan barreras para su adopción, incluyendo una baja eficiencia de muestreo, generalizabilidad limitada y la necesidad de funciones de recompensa cuidadosamente diseñadas. Además, aunque los Modelos de Lenguaje de Gran Escala (LLM) ofrecen potencial para la orquestación de extremo a extremo, su despliegue en el Control con Tolerancia a Fallos (FTC) con fines de seguridad se ve obstaculizado por tres brechas específicas:

1. Fundamentación (Grounding): El conocimiento de la planta está fragmentado en artefactos heterogéneos (P&IDs, listas de enclavamientos, registros de mantenimiento), y la recuperación de solo texto suele fallar al capturar las relaciones complejas necesarias para las acciones correctivas.
2. Aseguramiento: Las acciones propuestas carecen de trazas auditables y de comprobaciones explícitas de viabilidad frente a enclavamientos, envolventes de operación y la física del proceso antes de su ejecución.
3. Oportunidad/Robustez: La recuperación debe operar bajo dinámicas híbridas y observabilidad parcial, donde las acciones retrasadas o incorrectas pueden ser inseguras.

Metodología

Los autores proponen un marco de trabajo de agentes de LLM para FTC activo que transforma las salidas de detección de fallos en acciones de recuperación conscientes de las restricciones. El marco opera a través de dos espacios: un Espacio Físico (la planta de proceso y los sistemas de seguridad) y un Espacio Virtual (que contiene una Capa de Agentes y una Capa de Herramientas).

1. Capa de Herramientas (Tool Layer)

La Capa de Herramientas proporciona la infraestructura necesaria para los agentes:

• Gemelo Digital de la Planta de Proceso (DPPT): Un conjunto de herramientas ejecutables que contiene datos de la planta, modelos basados en física/datos y servicios de simulación. Soporta el monitoreo de condiciones y la validación previa a la ejecución de las acciones correctivas.
• Generación Aumentada por Recuperación de Grafos (Graph RAG): Para abordar la brecha de fundamentación, los autores utilizan un grafo de conocimiento basado en ontologías construido sobre la ontología CPSMod. Esta integra artefactos de ingeniería heterogéneos en una representación interpretable por máquinas. La ontología combina cinco Patrones de Diseño de Ontologías (ODP) basados en estándares que cubren estructura (VDI 2206), función y flujos (VDI 3682), comportamiento discreto (Máquina de Estados UML), comportamiento continuo (OpenMath) y diagnóstico de fallos (DIN 17359). Los agentes utilizan consultas SPARQL para recuperar contexto con conciencia de relaciones que vincula equipos, lógica de control, modos de operación y semántica de fallos.

2. Capa de Agentes (Agent Layer)

El marco descompone las tareas del operador en un flujo de trabajo multi-agente que involucra a seis agentes especializados:

• Agente de Monitoreo: Un componente determinista/basado en datos que detecta fallos comparando valores de proceso contra líneas base estadísticas o modelos basados en datos.
• Agente de Planificación: Un agente basado en LLM que recupera funciones relevantes del sistema y comportamientos de la máquina de estados desde el grafo de conocimiento. Recorre el grafo de la máquina de estados para proponer rutas de recuperación de mínimo riesgo desde el estado actual con fallos hacia un estado operativo objetivo.
• Agente de Acción: Un agente basado en LLM que sintetiza acciones de control correctivas específicas (comandos discretos o adaptaciones de consigna continua) basándose en la ruta seleccionada y las capacidades de actuación de la planta. Asegura que las acciones respeten enclavamientos, límites y restricciones de tasa.
• Agente de Simulación: Invoca el servicio de simulación del DPPT para probar si las acciones propuestas pueden conducir el sistema a un estado válido sin violar la dinámica o las restricciones.
• Agente de Validación: Un agente determinista que evalúa las salidas de la simulación frente a criterios de seguridad (enclavamientos, envolventes, tiempo de recuperación, desempeño del lazo) para aprobar o rechazar la acción.
• Agente de Reprompting: Coordina un bucle de refinamiento iterativo. Si la validación falla, genera retroalimentación estructurada (por ejemplo, "violación de envolvente", "guarda no cumplida") y vuelve a solicitar (repromptear) al Agente de Planificación o de Acción para refinar el plan.
  Si no se encuentra un plan aceptable dentro de una ventana de tiempo delimitada, el control se transfiere a un sistema de respaldo de seguridad (fallback).

Contribuciones Clave

El artículo realiza tres contribuciones principales para abordar las brechas identificadas:

1. Fundamentación con Conciencia de Relaciones: El uso de una ontología y Graph RAG permite la recuperación de múltiples saltos de dependencias accionables, vinculando equipos, lógica de control y semántica de fallos, fundamentando así a los agentes de LLM en el conocimiento específico de la planta.
2. Aseguramiento de Seguridad mediante Validación: El marco impone la seguridad a través de planes de recuperación mínimos y explicables que se someten a una validación determinista previa a la ejecución (enclavamientos, envolventes, viabilidad dinámica) y mantienen una traza de decisión auditable mediante un flujo de trabajo multi-agente.
3. Operación de Latencia Acotada: El sistema soporta la operación bajo restricciones de tiempo mediante el monitoreo asistido por herramientas, la generación de acciones restringidas y un mecanismo de respaldo de seguridad si no se puede sintetizar un plan válido en el tiempo previsto.

Resultados Experimentales

El marco fue evaluado en dos bancos de pruebas: un Módulo de Mezclado discreto y un Reactor de Tanque Agitado Continuo (CSTR). Se probaron dos LLM ligeros: GPT-4.1-mini y GPT-4o-mini.

Módulo de Mezclado (Control Discreto)

• GPT-4.1-mini logró una tasa de éxito del 100% en 60 ejecuciones (10 por escenario de fallo), con 100% de corrección y precisión en las acciones. No requirió reprompts correctivos.
• GPT-4o-mini logró una tasa de éxito del 85% (51/60 ejecuciones). Los fallos se concentraron en pump_degradation (50% de éxito) y sensor_fault (60% de éxito). El análisis mostró que, aunque GPT-4o-mini identificó correctamente los actuadores necesarios (100% de recall), ocasionalmente activaba actuadores innecesarios (menor precisión) o seleccionaba rutas de derivación (bypass) incorrectas durante la planificación.
• Latencia: El tiempo medio de reloj (wall-clock time) fue de 32.7s para GPT-4.1-mini y 40.7s para GPT-4o-mini.

CSTR (Control Continuo)

• GPT-4.1-mini logró una tasa de éxito del 93.3% (28/30 ejecuciones). Manejó con éxito los escenarios de fouling, pump_degrade y cool_stuck_closed, requiriendo a menudo reprompting para converger en consignas seguras.
• GPT-4o-mini logró una tasa de éxito del 76.7% (23/30 ejecuciones). Tuvo dificultades significativas con el escenario cool_stuck_closed (4/10 de éxito), alcanzando frecuentemente el límite de reprompt debido a propuestas repetidas que no satisfacían los requisitos de recuperación.
• Desempeño: GPT-4.1-mini demostró una latencia de acción por llamada menor (2.1s vs 2.7s) y un consumo de tokens comparable.

Significado y Reivindicaciones

El artículo afirma demostrar una vía práctica desde la detección de fallos hasta la acción correctiva validada tanto para tareas de FTC discretas como continuas. Los autores sostienen que:

• Los agentes semánticamente fundamentados pueden derivar decisiones de recuperación válidas dentro de presupuestos de latencia compatibles con la dinámica del proceso (segundos a decenas de segundos), lo que los hace adecuados para el control supervisorio y por lotes (batch), pero no para sistemas de tiempo real estricto.
• Graph RAG es un mecanismo viable para contextualizar el conocimiento disperso de la planta, permitiendo a los agentes razonar sobre restricciones dependientes de fallos sin la enumeración explícita de todos los escenarios de fallo.
• La validación basada en simulación filtra eficazmente las acciones infactibles, y el reprompting puede corregir errores de decisión transitorios, aunque no puede compensar fallos de razonamiento sistemáticos o fallos no modelados.

Los autores mantienen una postura modesta, señalando que el marco es "primero de viabilidad" en lugar de "primero de optimidad". Reconocen limitaciones respecto al esfuerzo requerido para construir grafos de conocimiento, la incapacidad de simular fallos verdaderamente novedosos sin caracterización previa, y la dependencia actual de modelos alojados en la nube para la investigación, lo cual requeriría despliegue on-premise y segmentación IT/OT para uso industrial. El trabajo no pretende reemplazar totalmente a los operadores humanos, sino proporcionar una capa robusta de soporte de decisión autónoma para el FTC activo.