ORPilot : l'IA qui réinvente l'optimisation industrielle

La promesse de l'optimisation par l'IA

Depuis des décennies, la recherche opérationnelle (RO) joue un rôle discret mais essentiel dans les décisions commerciales, telles que le routage des camions de livraison, la planification de la production en usine, la conception des chaînes d'approvisionnement, et l'allocation de cargaisons aux transporteurs. Les mathématiques sous-jacentes sont matures et les solveurs disponibles sont d'une efficacité remarquable. Cependant, le véritable défi réside dans l'expertise humaine nécessaire pour traduire un problème commercial en un modèle mathématique exploitable.

Les grands modèles de langage (LLM) ont été perçus comme une solution potentielle à ce problème. Des recherches croissantes, incluant des séries comme OptiMUS et OR-LLM, ont démontré que ces modèles avancés peuvent générer du code de solveur correct pour des problèmes de programmation linéaire (LP) et de programmation mixte entière (MIP) bien spécifiés. Les résultats de ces études étaient impressionnants et les démonstrations convaincantes.

Cependant, lorsqu'on tente d'appliquer ces outils à des problèmes réels, des limitations apparaissent rapidement.

Les limites des outils actuels

Presque tous les outils LLM pour la RO développés jusqu'à présent partagent une hypothèse implicite : la description du problème est complète, sans ambiguïté, et fournie à l'IA dans un prompt bien formaté, intégrant toutes les données nécessaires. Cette hypothèse est loin de la réalité des problèmes de RO.

Prenons l'exemple d'une équipe de chaîne d'approvisionnement cherchant à construire un modèle d'optimisation. La description initiale du problème est souvent incomplète et ambiguë. Un analyste commercial pourrait dire "nous voulons minimiser les coûts de transport", sans mentionner que chaque centre de distribution a une limite de débit, que certaines routes n'existent pas, ou qu'ouvrir une installation entraîne un coût fixe unique. Ces omissions ne sont pas dues à la négligence, mais à des hypothèses que l'analyste considère comme évidentes, ce qui les rend particulièrement dangereuses. Un système d'IA qui commence à modéliser avant que ces détails ne soient fixés produit un modèle techniquement correct mais pratiquement erroné.

De plus, les données nécessaires pour résoudre ces problèmes sont souvent trop volumineuses pour être intégrées dans un prompt unique. Un problème de chaîne d'approvisionnement pourrait impliquer des centaines de sites de production, de centres de distribution, de clients, et des milliers de produits sur plusieurs périodes. La table de demande à elle seule pourrait comporter des millions d'entrées. Intégrer cela dans un prompt est impraticable. Même si cela était possible, inonder la fenêtre de contexte avec des données brutes augmente considérablement le risque d'hallucinations.

En outre, les données disponibles ne correspondent pas toujours à celles requises par le modèle. Par exemple, le modèle pourrait nécessiter une matrice de distances entre toutes les paires de lieux, alors que ce qui est disponible est un tableau de coordonnées GPS. Le modèle pourrait avoir besoin de la demande agrégée par produit et période, mais ce qui est disponible est un registre de transactions avec une ligne par commande. Combler cette lacune, c'est-à-dire calculer des paramètres dérivés à partir de données brutes, est une étape d'ingénierie significative que les outils LLM pour la RO existants ne gèrent pas automatiquement.

Une fois qu'un modèle fonctionnel est en place, la portabilité et la reproductibilité deviennent cruciales. Si vous souhaitez relancer le modèle sur des données mises à jour, passer de Gurobi à un solveur open-source, ou transmettre le modèle à un collègue sur une machine différente, vous devez repartir de zéro à moins que l'outil ne produise un artefact durable et indépendant du solveur. La plupart des outils produisent du code spécifique à un solveur et rien d'autre.

Ces défis ne sont pas des cas particuliers, mais les conditions standard pour tout déploiement de RO dans le monde réel. Les outils LLM pour la RO existants ont été construits pour un monde différent, un monde de manuel scolaire, et montrent leurs limites dès qu'ils en sortent.

Présentation d'ORPilot

ORPilot est un agent IA open-source conçu de zéro pour des conditions de production. C'est, à ma connaissance, le premier outil de RO basé sur un LLM conçu explicitement pour la réalité désordonnée, à grande échelle et riche en données de l'optimisation industrielle.

La plupart des outils d'IA pour l'optimisation passent directement à l'écriture de code dès que vous décrivez votre problème. ORPilot fait quelque chose de différent : il pose d'abord des questions.

Cette décision de conception, qui privilégie la compréhension à la rapidité, reflète un principe directeur unique : un agent IA devrait fonctionner de la même manière qu'un consultant RO humain qualifié.

Un bon consultant n'entre pas dans une réunion client et ne commence pas à écrire un modèle mathématique au tableau. Il pose des questions. Il écoute attentivement. Il réagit lorsque quelque chose est ambigu. Il s'assure que les données sont dans le bon format avant que la modélisation ne commence. Ce n'est qu'après tout cela qu'il prend le stylo.

Le pipeline d'ORPilot reflète cette discipline à travers cinq étapes connectées de manière séquentielle.

Étape 1 : Agent d'interview

L'agent d'interview est le point d'entrée. Il reçoit votre description initiale du problème commercial, qui peut être vague, incomplète ou même contradictoire, et engage un dialogue structuré pour combler les lacunes. Le principe de conception clé est qu'aucune modélisation ne commence tant que l'interview n'est pas terminée.

L'agent est invité à identifier les lacunes d'information dans la description actuelle, à poser au maximum une question de clarification ciblée par tour (pour éviter de vous submerger), et à terminer une fois que la fonction objective, les variables de décision, les contraintes et les exigences en matière de données sont toutes spécifiées sans ambiguïté.

En pratique, cela signifie des conversations comme :

• ORPilot : « Une fois qu'une installation est ouverte, reste-t-elle ouverte pour toutes les périodes suivantes, ou peut-elle être fermée plus tard ? »

• ORPilot : « Ce modèle gère-t-il un seul type de produit ou plusieurs produits ? »

• ORPilot : « Vous avez mentionné un coût de transport. Ce coût est-il par unité expédiée, par expédition indépendamment de la quantité, ou autre chose ? »

Avant de terminer l'interview, l'agent présente un résumé structuré complet avec la fonction objective, les variables de décision, les contraintes, les paramètres, les indices, et vous donne la chance de corriger quoi que ce soit avant que ce résumé ne soit transmis en aval. C'est la protection contre le mode d'échec le plus courant dans les outils LLM pour la RO : modéliser le mauvais problème.

Étape 2 : Agent de collecte de données

Cette étape n'a pas d'équivalent dans la plupart des outils LLM pour la RO existants. C'est l'une des innovations structurelles les plus importantes d'ORPilot.

La plupart des outils LLM pour la RO existants supposent que les données sont intégrées dans le texte du problème, suffisamment petites pour tenir dans un prompt. Pour les problèmes de manuel scolaire, cela fonctionne. Pour les problèmes réels, cela échoue de deux manières. Premièrement, les ensembles de données réels sont trop volumineux. Par exemple, un problème de chaîne d'approvisionnement avec 500 clients, 500 produits et 12 périodes aurait 3 000 000 d'entrées de demande. Deuxièmement, intégrer des données dans le prompt augmente le risque d'hallucination et consomme inutilement la fenêtre de contexte.

La réponse d'ORPilot est de traiter les données comme séparées du prompt. Les données résident dans des fichiers CSV. L'IA y accède uniquement en écrivant et en exécutant du code. Le travail de l'agent de collecte de données est de déterminer exactement à quoi doivent ressembler ces fichiers CSV.

En fonction de la spécification du problème de l'agent d'interview, l'agent de collecte de données détermine :

• Quelles entités (ensembles) existent dans le modèle

• Quels attributs (paramètres) chaque entité nécessite

• Le schéma précis pour chaque table requise : noms de colonnes, types, sémantique

Il présente cette spécification à vous et attend que vous ayez fourni tous les fichiers dans le format correct. Il valide la complétude avant de procéder.

De manière cruciale, l'agent est flexible : si vous n'avez pas un élément particulier de données prêtes pour le modèle (par exemple, le modèle a besoin d'une matrice de distances mais vous n'avez que des coordonnées GPS), vous dites à l'agent ce que vous avez réellement, et il met à jour le schéma en conséquence — transférant la lacune à l'étape suivante pour qu'elle soit gérée.

Étape 3 : Agent de calcul des paramètres

Presque tous les outils LLM pour la RO existants supposent que les quantités numériques nécessaires au modèle apparaissent directement dans les données fournies par l'utilisateur. En pratique, c'est presque jamais vrai. Deux exemples qui se présentent constamment dans les problèmes réels de RO :

• Un modèle de routage de véhicules a besoin d'une matrice de distances pair-à-pair. L'utilisateur a des coordonnées GPS. Le calcul des distances euclidiennes ou géographiques est une transformation entièrement en dehors du champ de la formulation LP/MIP.

• Un modèle de production multi-période a besoin de la demande agrégée par période. L'utilisateur a un registre de transactions avec une ligne par commande. Le paramètre du modèle est une agrégation-somme qui doit être calculée à partir des données brutes.

L'agent de calcul des paramètres comble cette lacune automatiquement. Il reçoit la spécification du problème et les fichiers CSV bruts, puis :

• Identifie quels paramètres du modèle ne peuvent pas être lus directement à partir des tables brutes

• Génère un script Python pour calculer ces paramètres dérivés

• Exécute le script dans un environnement isolé

• Écrit les résultats sous forme de fichiers CSV supplémentaires, transmis à l'étape de modélisation

Cela garantit qu'au moment où l'agent de modélisation voit les données, elles sont propres, correctement typées, correctement indexées et prêtes pour le modèle. Dans nos expériences, cette étape a considérablement réduit les échecs de génération de code et le nombre de tentatives.

Une autre situation courante où l'agent de calcul des paramètres pourrait être utile est le calcul des valeurs BigM. Dans certaines expériences que j'ai réalisées sur ORPilot, l'agent de calcul des paramètres a calculé une valeur BigM nécessaire pour les contraintes reliant les variables d'expédition continues aux décisions d'ouverture d'installations binaires. C'est un paramètre dérivé qu'il serait impratique de demander directement à l'utilisateur.

Étape 4 : Agent de génération de code

Avec une spécification complète du problème, des données brutes et des paramètres dérivés en main, l'agent de génération de code produit un script de solveur Python complet pour votre backend choisi. ORPilot prend actuellement en charge cinq backends : Gurobi, CPLEX, PuLP, Pyomo et OR-Tools.

Le code généré est immédiatement exécuté dans un environnement isolé. Si quelque chose ne va pas : erreur de syntaxe, exception d'exécution, ou un résultat de solveur infaisable/non borné, le message d'erreur complet et la trace de retour sont renvoyés au LLM avec le code précédemment généré. L'agent réessaie, jusqu'à un maximum de tentatives configurable par l'utilisateur.

En pratique, la majorité des échecs sont...