Laisser le LLM traduire, pas résoudre : transformer les notes de quart en contraintes de planification sûres

Un planning de production reste optimal à peu près le temps qu'il faut à quelqu'un pour écrire une note de quart. « Fuite hydraulique sur la presse 3, la maintenance dit environ 40 minutes. » Le solveur qui a construit le planning ne sait pas lire cela. Il faut donc un humain : un planificateur ouvre la note, identifie la machine, estime l'arrêt, met à jour le modèle et relance le calcul. Dans le modèle de coûts que nous utilisons, cette boucle manuelle prend environ 15 minutes par événement, et la ligne attend pendant tout ce temps.

Les grands modèles de langage excellent précisément sur ce qui bloque le solveur : transformer un langage opérationnel approximatif en données structurées. La tentation est d'aller plus loin et de leur confier aussi le planning. C'est l'étape que nous jugeons erronée, et la recherche derrière GenOR-Twin a été construite pour l'éviter.

La plupart des perturbations d'un planning arrivent sous forme de phrase, pas de champ de données. Un grand modèle de langage sait lire cette phrase. Il ne faut pas lui confier la planification qui suit — et il n'en a pas besoin.

§ 02Pourquoi ne pas laisser le modèle planifier ?

L'ordonnancement d'atelier, les tournées de véhicules ou la planification de projets sous contraintes de ressources sont des problèmes NP-difficiles. Les solveurs exacts et les métaheuristiques bien réglées les traitent avec des garanties connues : un plan qu'ils renvoient respecte toutes les contraintes de capacité et de précédence du modèle. Un modèle de langage n'offre aucune garantie de ce type. Il peut produire un plan convaincant qui affecte deux opérations à la même machine en même temps.

Il existe un second échec, plus discret. Quand on demande à un modèle d'interpréter une note et d'agir en une seule étape, personne ne vérifie l'interprétation. S'il comprend « presse 3 » comme une machine qui n'existe pas, ou transforme « ça devrait être réparé bientôt » en une durée que personne n'a donnée, l'erreur passe directement dans le plan.

§ 03Le modèle traducteur

GenOR-Twin sépare le travail en deux. Le modèle de langage ne fait que traduire : il lit la note et propose une contrainte, par exemple unavailable(M3, [100, 140]), avec un score de confiance. Le solveur existant fait toute la planification. Entre les deux, un validateur symbolique applique trois contrôles. La ressource existe-t-elle dans le graphe de connaissances du site ? L'heure de début est-elle dans le futur et non dans le passé ? La durée est-elle physiquement plausible ? Une contrainte qui échoue à l'un de ces contrôles n'atteint jamais le solveur.

Sur 300 journaux opérationnels historiques, 50 pour chacun des six domaines étudiés, annotés indépendamment par deux experts (κ de Cohen = 0,91), le pipeline modèle de langage plus validateur a retrouvé la lecture des experts dans 299 cas, soit 99,7 %. Le même modèle sans validateur atteignait 97,2 %. Sur les journaux très ambigus, où la correspondance brute tombe à 76,5 %, le validateur a intercepté 88,2 % des extractions hallucinées avant qu'elles n'affectent un planning.

§ 04Toutes les perturbations ne justifient pas une replanification complète

Une fois la contrainte validée, il reste à décider de l'intensité de la réaction. Le SmartScheduler de GenOR-Twin compare la durée de la perturbation à la marge moyenne du planning et vérifie si la machine touchée est un goulot. Un arrêt court sur une machine non critique déclenche une réparation locale par décalage, en bien moins d'une milliseconde. Un arrêt long, ou sur un goulot, déclenche une ré-optimisation complète. Et si la confiance du modèle est inférieure ou égale à 0,85, le système fait appel à un humain, qui vérifie une seule interprétation au lieu de reconstruire le planning.

Dans une étude contrôlée, les planificateurs assistés par cette politique ont choisi la bonne réponse dans 98,0 % des cas, contre 79,5 % pour les planificateurs seuls. Le gain tient moins à l'optimisation qu'à la suppression des hésitations sur le type de réponse qu'appelle une perturbation.

§ 05Ce que disent les chiffres, et ce qu'ils ne disent pas

Sur des jeux de référence classiques (instances d'atelier de Taillard, de tournées de Solomon et de projets PSPLIB), le pipeline a obtenu des objectifs meilleurs de 3,7 % à 4,9 % qu'un pipeline d'extraction à base de règles, sur 100 exécutions par jeu avec p < 0,01. Ces gains sont modestes, et l'article le dit. La vraie faiblesse de la référence à base de règles n'était pas le solveur : elle échouait à analyser 82 % des formulations variées présentes dans les journaux réels.

La vitesse n'est pas en cause non plus. L'inférence sémantique prenait environ 2 millisecondes, que le planning compte 25 ou 50 000 opérations ; le modèle de langage n'est donc jamais le goulot. La valeur se trouve dans le délai de la décision complète : le modèle de coûts de l'article l'estime à environ 2 minutes, revue comprise, contre 15 minutes pour la boucle manuelle.

L'intérêt économique n'est pas universel. Le même modèle de coûts est négatif sous environ 100 perturbations par an, ou quand l'arrêt coûte environ 20 $ la minute. À 500 événements par an et 60 $ la minute d'arrêt, il indique environ 375 000 $ de bénéfice net annuel. Autrement dit, cette approche est rentable là où les perturbations sont fréquentes et coûteuses, comme dans l'automobile ou les semi-conducteurs, et pas partout.

§ 06Par où commencer

Aucune intégration en production n'est nécessaire pour savoir si cela fonctionne sur vos opérations. Prenez quelques mois de journaux de quart ou de maintenance exportés et les plannings qu'ils ont perturbés, et rejouez-les hors ligne. Pour chaque journal, vous voyez ce qui aurait été extrait, ce que le validateur aurait rejeté, la réponse que le planificateur aurait choisie et le coût du plan obtenu. C'est par ce rejeu que nous commençons les pilotes GenOR-Twin, et il alimente le modèle de coûts avec votre propre fréquence de perturbations et votre coût d'arrêt, plutôt qu'avec les nôtres.