Resumen Técnico: RACE-Sched

Enunciado del Problema

El Problema de Programación Dinámica de Taller Flexible (DFJSP) es un desafío crítico de toma de decisiones en línea en la manufactura moderna. Requiere asignar operaciones a máquinas heterogéneas bajo flexibilidad de ruteo y restricciones de precedencia, mientras se reacciona a perturbaciones estocásticas como fallos de máquinas, llegadas urgentes de trabajos y variaciones en los tiempos de procesamiento.

Los enfoques actuales enfrentan una compensación fundamental:

• Reglas de Despacho por Prioridad (PDRs) son interpretables y rápidas, pero carecen de la flexibilidad para adaptarse cuando los cuellos de botella cambian.
• Aprendizaje por Refuerzo Profundo (DRL) captura dinámicas complejas, pero a menudo carece de interpretabilidad y tiene dificultades para generalizar a través de diferentes escalas de problemas.
• Modelos de Lenguaje Grande (LLMs) ofrecen capacidades avanzadas de razonamiento y generación de código (Código-como-Política), pero su latencia de inferencia (segundos) es incompatible con los ciclos de decisión a nivel de milisegundos requeridos por los sistemas de control industrial.

Los marcos híbridos existentes a menudo separan el aprendizaje de la ejecución, dependiendo de un entrenamiento fuera de línea que no puede adaptarse a perturbaciones no vistas en tiempo real, o requieren interacciones síncronas que interrumpen la línea de producción.

Metodología: RACE-Sched

Para resolver el conflicto entre las restricciones de tiempo real y el razonamiento de largo horizonte, los autores proponen RACE-Sched, un marco basado en agentes asíncrono. Desacopla la ejecución de la política del razonamiento lógico utilizando una arquitectura de doble flujo:

1. Arquitectura Asíncrona de Doble Flujo

• Flujo Reactivo (Ejecución): Opera dentro del bucle de control crítico. Ejecuta una regla simbólica de prioridad compilada de baja latencia (función de Python) para tomar decisiones de despacho. Este flujo es determinista y opera en tiempos sub-milisegundo, asegurando que nunca espere al proceso de razonamiento.
• Flujo Deliberativo (Razonamiento): Opera fuera del camino crítico. Utiliza un LLM para analizar estadísticas resumidas de decisiones recientes, generar heurísticas candidatas en Python y validarlas en un entorno seguro (sandbox). Este flujo opera en una escala de tiempo más lenta (segundos a minutos) y no bloquea la línea de producción.

2. El Bucle Agente (Evolución con Restricciones de Seguridad)

El Flujo Deliberativo funciona a través de un ciclo de cuatro etapas:

• Planificador Estratégico: Resume el estado actual del sistema (por ejemplo, identificación de cuellos de botella) para formular una directiva de alto nivel.
• Ejecutor Sintáctico: Convierte la directiva en código Python ejecutable. Hace cumplir restricciones de seguridad, limita la complejidad del código y asegura que el código se compile dentro de un contexto de ejecución restringido.
• Validador de Simulación: Evalúa las reglas candidatas en un entorno de prueba (sandbox) utilizando un conjunto representativo de instancias. Compara la candidata contra la regla vigente utilizando pruebas estadísticas (por ejemplo, pruebas t) y umbrales de mejora predefinidos.
• Reflector Semántico: Sintetiza la retroalimentación diagnóstica de los resultados del sandbox para justificar la aceptación o el rechazo, registrando el razonamiento para iteraciones futuras.

3. Protocolo de Disparo y Despliegue

Las actualizaciones se activan periódicamente o cuando las métricas de rendimiento se degradan en relación con una ventana deslizante. Crucialmente, el despliegue ocurre mediante un intercambio atómico de punteros. Solo las reglas que pasan la validación en el sandbox se promueven al conjunto de reglas activo, asegurando que el bucle de control permanezca seguro y receptivo.

4. Repositorio de Conocimiento Semántico

Para mejorar la transferibilidad y reducir las ineficiencias del "arranque en frío", el sistema mantiene un repositorio indexado de heurísticas validadas. Cada entrada incluye el código de la política, las métricas de rendimiento y metadatos ligeros (por ejemplo, número de trabajos/máquinas). Cuando surge una nueva instancia de problema, el sistema recupera reglas similares para iniciar en caliente el proceso de generación de candidatos, reduciendo el consumo de tokens y mejorando la robustez a través de escalas.

Contribuciones Clave

1. Marco de Evolución Simbólica Asíncrona: Una arquitectura novedosa que desacopla el despacho en tiempo real de la síntesis de heurísticas impulsada por LLM, asegurando que el bucle de control permanezca receptivo mientras permite la evolución continua de la política.
2. Mecanismo de Despliegue Seguro: Un protocolo de validación basado en sandbox donde las heurísticas candidatas se prueban rigurosamente fuera de línea. Las actualizaciones se despliegan solo mediante intercambios atómicos de punteros si cumplen criterios de aceptación estrictos, evitando que reglas no verificadas interrumpan las operaciones.
3. Repositorio de Reglas Semánticas: Un mecanismo para el aprendizaje a lo largo de la vida que indexa heurísticas validadas con metadatos de instancias, permitiendo una inicialización basada en recuperación y mejorando la transferabilidad entre diferentes puntos de referencia y escalas de problemas.
4. Evaluación Exhaustiva: Pruebas extensas en GEN-Bench, MK-Bench y JMS-Bench, incluyendo pruebas de estrés para fallos de máquinas, demostrando un rendimiento superior sobre las líneas base de DRL y LLM directos.

Resultados Experimentales

• Rendimiento: En GEN-Bench (escala Normal), la variante de RACE-Sched que utiliza Qwen3-8B logró una Desviación Porcentual Relativa (RPD) de 5.33%, superando significativamente a la línea base líder de DRL (IDDQN con 9.82%) y otros métodos basados en LLM. Consistentemente logró una RPD más baja y mejores rangos promedio en todos los puntos de referencia.
• Eficiencia: El marco redujo el consumo de tokens de entrada en aproximadamente 60% en comparación con las líneas base de LLM directos al utilizar el repositorio para inicios en caliente y cambiar de la generación de acciones por paso a la síntesis compacta de políticas.
• Latencia: El Flujo Reactivo mantuvo una latencia sub-milisegundo (por ejemplo, ~0.05–0.09 ms), satisfaciendo las restricciones de tiempo real industriales. En contraste, el Flujo Deliberativo operó con latencias de 77–114 segundos por actualización, una brecha mitigada por el diseño asíncrono.
• Resiliencia: En las pruebas de estrés de fallos de máquinas (JMS-Bench), RACE-Sched demostró una adaptabilidad superior, restaurando el rendimiento a niveles previos al fallo y logrando el makespan final mínimo (29.6) en comparación con líneas base que sufrieron de heurísticas estáticas o alta varianza.
• Ablación: Eliminar el repositorio ("sin Repo") aumentó significativamente la RPD (por ejemplo, de 10.41% a 26.19% en GEN-Pequeño), confirmando el valor de la recuperación de conocimiento. Eliminar el bucle iterativo ("sin Bucle") también degradó el rendimiento en tareas complejas, validando la necesidad de refinamiento recursivo.

Significado y Afirmaciones

El artículo afirma que RACE-Sched logra harmonizar las restricciones de tiempo real con el razonamiento de largo horizonte. Al confinar la deliberación lenta del LLM, la validación en sandbox y la mejora de políticas al fondo, el marco permite que la lógica de control mejore continuamente sin obstaculizar la capacidad de respuesta en tiempo real de las máquinas físicas.

Los autores posicionan este enfoque como una solución al "desajuste de frecuencia" entre los ciclos cognitivos (LLMs) y los ciclos físicos (manufactura). Afirman que su método logra una calidad de solución superior y una adaptación robusta a eventos dinámicos en comparación con el DRL de vanguardia y el control directo por LLM, manteniendo al mismo tiempo la interpretabilidad y la seguridad requeridas para el despliegue industrial.

Limitaciones Reconocidas:
Los autores señalan que la calidad de la evolución de las reglas depende de la capacidad del LLM de fondo; los modelos más débiles pueden generar candidatos inválidos que son rechazados. Además, la construcción de escenarios de sandbox representativos requiere esfuerzo de ingeniería, y la reacción a tipos de perturbaciones completamente nuevos aún puede verse retrasada si se necesitan múltiples ciclos de deliberación.