Résumé Technique : RACE-Sched

Énoncé du Problème

Le Problème de Planification Dynamique des Ateliers Flexibles (DFJSP) constitue un défi critique de prise de décision en ligne dans la fabrication moderne. Il nécessite l'affectation d'opérations à des machines hétérogènes, sous des contraintes de flexibilité de routage et de précédence, tout en réagissant à des perturbations stochastiques telles que des pannes de machines, des arrivées d'ordres urgents et des variations des temps de traitement.

Les approches actuelles font face à un compromis fondamental :

• Les Règles de Priorité de Dispatching (PDR) sont interprétables et rapides, mais manquent de flexibilité pour s'adapter lorsque les goulots d'étranglement se déplacent.
• L'Apprentissage par Renforcement Profond (DRL) capture des dynamiques complexes, mais manque souvent d'interprétabilité et éprouve des difficultés de généralisation à travers différentes échelles de problèmes.
• Les Grands Modèles de Langage (LLM) offrent des capacités avancées de raisonnement et de génération de code (Code-as-Policy), mais leur latence d'inférence (secondes) est incompatible avec les cycles de décision de l'ordre de la milliseconde requis par les systèmes de contrôle industriels.

Les cadres hybrides existants séparent souvent l'apprentissage de l'exécution, s'appuyant sur un entraînement hors ligne qui ne peut pas s'adapter aux perturbations inédites en temps réel, ou ils nécessitent des interactions synchrones qui perturbent la chaîne de production.

Méthodologie : RACE-Sched

Pour résoudre le conflit entre les contraintes temps réel et le raisonnement à long horizon, les auteurs proposent RACE-Sched, un cadre basé sur des agents asynchrones. Il découple l'exécution de la politique du raisonnement logique en utilisant une architecture à double flux :

1. Architecture Asynchrone à Double Flux

• Flux Réactif (Exécution) : Opère dans la boucle de contrôle critique. Il exécute une règle de priorité symbolique compilée à faible latence (fonction Python) pour prendre des décisions de dispatching. Ce flux est déterministe et opère en temps sub-milliseconde, garantissant qu'il n'attend jamais le processus de raisonnement.
• Flux Délibératif (Raisonnement) : Opère en dehors du chemin critique. Il exploite un LLM pour analyser les statistiques résumées des décisions récentes, générer des heuristiques Python candidates et les valider dans un bac à sable. Ce flux s'exécute à une échelle de temps plus lente (secondes à minutes) et ne bloque pas la chaîne de production.

2. La Boucle Agentique (Évolution Contrainte par la Sécurité)

Le Flux Délibératif fonctionne selon un cycle à quatre étapes :

• Planificateur Stratégique : Résume l'état actuel du système (par exemple, identification des goulots d'étranglement) pour formuler une directive de haut niveau.
• Exécuteur Syntaxique : Convertit la directive en code Python exécutable. Il fait respecter les contraintes de sécurité, limite la complexité du code et garantit que le code se compile dans un contexte d'exécution restreint.
• Validateur de Simulation : Évalue les règles candidates dans un environnement bac à sable en utilisant un pool représentatif d'instances. Il compare le candidat à la règle en place en utilisant des tests statistiques (par exemple, tests t) et des seuils d'amélioration prédéfinis.
• Réflecteur Sémantique : Synthétise les retours d'information diagnostiques issus des résultats du bac à sable pour justifier l'acceptation ou le rejet, en enregistrant le raisonnement pour les itérations futures.

3. Protocole de Déclenchement et de Déploiement

Les mises à jour sont déclenchées soit périodiquement, soit lorsque les métriques de performance se dégradent par rapport à une fenêtre glissante. Crucialement, le déploiement s'effectue via un échange atomique de pointeurs. Seules les règles qui passent la validation du bac à sable sont promues vers l'ensemble de règles actif, garantissant que la boucle de contrôle reste sûre et réactive.

4. Dépôt de Connaissances Sémantiques

Pour améliorer la transférabilité et réduire les inefficacités du « démarrage à froid », le système maintient un dépôt indexé d'heuristiques validées. Chaque entrée comprend le code de la politique, les métriques de performance et des métadonnées légères (par exemple, nombre d'ordres/machines). Lorsqu'une nouvelle instance de problème survient, le système récupère des règles similaires pour amorcer le processus de génération de candidats, réduisant la consommation de jetons et améliorant la robustesse à travers les échelles.

Contributions Clés

1. Cadre d'Évolution Symbolique Asynchrone : Une architecture novatrice qui découple le dispatching temps réel de la synthèse d'heuristiques pilotée par LLM, garantissant que la boucle de contrôle reste réactive tout en permettant une évolution continue de la politique.
2. Mécanisme de Déploiement Sûr : Un protocole de validation basé sur un bac à sable où les heuristiques candidates sont rigoureusement testées hors ligne. Les mises à jour ne sont déployées que via des échanges atomiques de pointeurs si elles répondent à des critères d'acceptation stricts, empêchant ainsi des règles non vérifiées de perturber les opérations.
3. Dépôt de Règles Sémantiques : Un mécanisme d'apprentissage tout au long de la vie qui indexe les heuristiques validées avec des métadonnées d'instances, permettant une initialisation par récupération et améliorant la transférabilité à travers différents benchmarks et échelles de problèmes.
4. Évaluation Complète : Tests étendus sur GEN-Bench, MK-Bench et JMS-Bench, incluant des tests de stress pour les pannes de machines, démontrant des performances supérieures aux bases de référence DRL et LLM directes.

Résultats Expérimentaux

• Performance : Sur GEN-Bench (échelle normale), la variante RACE-Sched utilisant Qwen3-8B a atteint une Déviation Pourcentage Relative (RPD) de 5,33 %, surpassant significativement la meilleure base de référence DRL (IDDQN à 9,82 %) et d'autres méthodes basées sur LLM. Elle a constamment obtenu une RPD plus faible et de meilleurs rangs moyens sur tous les benchmarks.
• Efficacité : Le cadre a réduit la consommation de jetons d'entrée d'environ 60 % par rapport aux bases de référence LLM directes en utilisant le dépôt pour les amorçages et en passant d'une génération d'actions par étape à une synthèse de politique compacte.
• Latence : Le Flux Réactif a maintenu une latence sub-milliseconde (par exemple, ~0,05–0,09 ms), satisfaisant les contraintes temps réel industrielles. En revanche, le Flux Délibératif a opéré avec des latences de 77 à 114 secondes par mise à jour, un écart atténué par la conception asynchrone.
• Résilience : Dans les tests de stress de pannes de machines (JMS-Bench), RACE-Sched a démontré une adaptabilité supérieure, restaurant le débit aux niveaux pré-panne et atteignant le makespan final minimum (29,6) par rapport aux bases de référence souffrant d'heuristiques statiques ou d'une forte variance.
• Ablation : La suppression du dépôt (« sans Dépôt ») a augmenté la RPD de manière significative (par exemple, de 10,41 % à 26,19 % sur GEN-Small), confirmant la valeur de la récupération de connaissances. La suppression de la boucle itérative (« sans Boucle ») a également dégradé les performances sur des tâches complexes, validant le besoin d'un raffinement récursif.

Importance et Revendications

L'article revendique que RACE-Sched harmonise avec succès les contraintes temps réel avec le raisonnement à long horizon. En confinant la délibération lente des LLM, la validation en bac à sable et l'amélioration des politiques à l'arrière-plan, le cadre permet à la logique de contrôle de s'améliorer continuellement sans entraver la réactivité temps réel des machines physiques.

Les auteurs positionnent cette approche comme une solution au « décalage de fréquence » entre les cycles cognitifs (LLM) et les cycles physiques (fabrication). Ils affirment que leur méthode atteint une qualité de solution supérieure et une adaptation robuste aux événements dynamiques par rapport aux DRL et au contrôle LLM direct les plus avancés, tout en maintenant l'interprétabilité et la sécurité requises pour le déploiement industriel.

Limites Reconnaues :
Les auteurs notent que la qualité de l'évolution des règles dépend des capacités du LLM en arrière-plan ; des modèles plus faibles peuvent générer des candidats invalides qui sont rejetés. De plus, la construction de scénarios de bac à sable représentatifs nécessite un effort d'ingénierie, et la réaction à des types de perturbations entièrement nouveaux peut toujours être retardée si plusieurs cycles de délibération sont nécessaires.