Pourquoi l’IA ne peut toujours pas résoudre votre véritable problème d’optimisation mathématique

Pour utiliser l’IA pour créer un modèle d’optimisation mathématique pour un problème commercial réel, vous vous êtes probablement heurté au même mur : l’IA fonctionne à merveille sur des exemples de manuels et s’effondre dès que vous lui transmettez vos données réelles et votre problème réel.

Cet écart n’est pas une coïncidence. C’est voulu, et c’est la raison pour laquelle j’ai construit ORPilot.

La promesse d’une optimisation basée sur l’IA

La recherche opérationnelle (OR) alimente discrètement certaines des décisions les plus marquantes du monde des affaires depuis des décennies : acheminement des camions de livraison, planification de la production en usine, conception des chaînes d’approvisionnement, allocation des marchandises aux transporteurs. Les mathématiques sont matures et les solveurs sont excellents. Le goulot d’étranglement a toujours été l’expertise humaine requise pour traduire un problème commercial en modèle mathématique.

Les grands modèles linguistiques (LLM) semblaient être la solution parfaite. Un nombre croissant de recherches, notamment la série OptiMUS, OR-LLM et d’autres, ont montré que les LLM de pointe peuvent générer un code de solveur correct pour des problèmes de programmation linéaire (LP) et de programmation en nombres entiers mixtes (MIP) bien spécifiés. Les résultats semblaient impressionnants. Les démos étaient convaincantes.

Ensuite, vous essayez d’utiliser l’un de ces outils sur un problème réel, et les fissures apparaissent immédiatement.

Là où les outils existants tombent en panne

Presque tous les outils LLM-for-OR construits à ce jour partagent une hypothèse cachée : la description du problème est complète, sans ambiguïté et transmise à l’IA dans une seule invite bien formatée avec toutes les données soigneusement intégrées en ligne.

Ce n’est pas ainsi que fonctionnent les vrais problèmes de salle d’opération. Même pas proche.

Considérez ce qui se passe réellement lorsqu’une équipe de chaîne d’approvisionnement souhaite créer un modèle d’optimisation :

1. La description du problème est incomplète et ambiguë. Un analyste commercial dira « nous voulons minimiser les coûts de transport » et oubliera de mentionner que chaque centre de distribution a une limite de débit, que certains itinéraires n’existent pas ou que l’ouverture d’une installation entraîne un coût fixe unique. Ces omissions ne sont pas
   négligence. Ce sont des hypothèses que l’analyste considère comme évidentes, et c’est exactement pourquoi elles sont dangereuses. Un système d’IA qui commence la modélisation avant que ces détails ne soient définis produit un modèle techniquement correct mais pratiquement erroné.
2. Les données sont trop volumineuses pour tenir dans une invite. Un véritable problème de chaîne d’approvisionnement peut impliquer des centaines de sites de production, des centres de distribution, des clients et des milliers de produits sur plusieurs périodes. Le tableau de la demande à lui seul peut contenir des millions d’entrées. Vous ne pouvez pas intégrer cela dans une invite. Même si vous le pouviez, inonder la fenêtre contextuelle de données brutes augmente considérablement le risque d’hallucinations.
3. Les données dont vous disposez ne sont pas celles dont le modèle a besoin. Le modèle peut nécessiter une matrice de distance entre toutes les paires d’emplacements. Ce que vous avez est un tableau de coordonnées GPS. Le modèle pourrait nécessiter une demande globale par produit et par période. Ce que vous avez est un grand livre de transactions avec une ligne par commande. Combler cette lacune, à savoir calculer des paramètres dérivés à partir de données brutes, constitue une étape d’ingénierie importante qu’aucun outil LLM-for-OR existant ne gère automatiquement.
4. Une fois que vous disposez d’un modèle fonctionnel, la portabilité et la reproductibilité sont importantes. Si vous souhaitez réexécuter le modèle sur des données mises à jour, passer de Gurobi à un solveur open source ou confier le modèle à un collègue sur une autre machine, vous revenez à la case départ à moins que l’outil ne produise un artefact durable et indépendant du solveur. La plupart des outils produisent du code spécifique au solveur et rien d’autre.

Ce ne sont pas des cas extrêmes. Ce sont les conditions standard pour tout déploiement en salle d’opération dans le monde réel. Les outils LLM-for-OR existants ont été conçus pour un monde différent, un monde de manuels scolaires, et ils montrent leurs coutures dès qu’ils le quittent.

Présentation d’ORPilot

ORPilot est un agent d’IA open source conçu dès le départ pour les conditions de production. Il s’agit, à ma connaissance, du premier outil OR basé sur 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’optimisation d’IA 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 donne la priorité à la compréhension plutôt qu’à la vitesse, reflète un seul principe directeur : un agent d’IA doit travailler de la même manière qu’un consultant humain qualifié en salle d’opération.

Un bon consultant ne se rend pas à une réunion client et ne commence pas à écrire un modèle mathématique sur un tableau blanc. Ils posent des questions. Ils écoutent attentivement. Ils repoussent quand quelque chose
est ambigu. Ils s’assurent que les données sont dans le bon état avant le début de la modélisation. Ce n’est qu’après tout cela qu’ils prennent la plume.

Le pipeline d’ORPilot reflète cette discipline à travers cinq étapes connectées séquentiellement.

Étape 1 : Entretien avec l’agent

L’agent d’entretien est le point d’entrée. Il reçoit votre première description du problème commercial, qui peut être vague, incomplète, voire contradictoire, et vous engage dans une
dialogue structuré pour combler les lacunes. Le principe clé de la conception est qu’aucune modélisation ne commence tant que l’entretien n’est pas terminé.

L’agent est invité à identifier les lacunes d’information dans la description actuelle, à poser au plus une question de clarification ciblée par tour (pour éviter de vous submerger) et à terminer une fois que la fonction objectif, 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 telles que :

ORPilot : « Une fois qu’un établissement est ouvert, reste-t-il ouvert pour toutes les périodes suivantes, ou peut-il être fermé 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 quelle que soit la quantité, ou autre chose ? »

Avant de terminer l’entretien, l’agent présente un résumé structuré complet avec la fonction objectif, les variables de décision, les contraintes, les paramètres, les indices, et vous donne la possibilité de corriger quoi que ce soit avant que ce résumé ne soit transmis en aval. C’est la protection contre le mode de défaillance le plus courant dans les outils LLM-for-OR : la modélisation du mauvais problème.

Étape 2 : Agent de collecte de données

Cette étape n’a pas d’équivalent dans la plupart des outils LLM-for-OR existants. Il s’agit de l’une des innovations structurelles les plus importantes d’ORPilot.

La plupart des outils LLM-for-OR existants supposent que les données sont intégrées dans le texte du problème, suffisamment petites pour tenir dans une invite. Pour les problèmes liés aux manuels scolaires, cela fonctionne. Pour les vrais problèmes, cela se décompose 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 de 500 clients, 500 produits et 12 périodes entraînerait 3 000 000 d’entrées de demande. Deuxièmement, l’intégration de données dans l’invite gonfle le risque d’hallucination et brûle inutilement la fenêtre contextuelle.

La réponse d’ORPilot est de traiter les données comme étant entièrement distinctes de l’invite. 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 consiste à déterminer exactement à quoi doivent ressembler ces fichiers CSV.

Sur la base de la spécification du problème fournie par l’agent d’entretien, l’agent de collecte de données détermine :

• Quelles entités (ensembles) existent dans le modèle
• De quels attributs (paramètres) chaque entité a besoin
• Le schéma précis pour chaque table requise : noms de colonnes, types, sémantique

Il vous présente cette spécification et attend que vous ayez fourni tous les fichiers au bon format. Il valide l’exhaustivité avant de continuer.

Surtout, l’agent est flexible : si vous ne disposez pas d’un élément de données particulier prêt pour le modèle (par exemple, le modèle a besoin d’une matrice de distance mais vous n’avez que des coordonnées GPS), vous indiquez à l’agent ce que vous avez réellement et il met à jour le schéma en conséquence, en passant l’écart à l’étape suivante à gérer.

Étape 3 : Agent de calcul des paramètres

Presque tous les outils LLM-for-OR 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, cela n’est presque jamais vrai. Deux exemples qui reviennent constamment dans les problèmes réels de salle d’opération :

• Un modèle de tournées de véhicules nécessite une matrice de distance par paire. L’utilisateur dispose de coordonnées GPS. Le calcul des distances euclidiennes ou géographiques est une transformation qui sort totalement du cadre de la formulation LP/MIP.
• Un modèle de production multipériode nécessite une demande globale par période. L’utilisateur dispose d’un grand livre de transactions avec une ligne par commande. Le paramètre du modèle est une agrégation de somme qui doit être calculée à partir des données brutes.

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

1. Identifie les paramètres du modèle qui ne peuvent pas être lus directement à partir des tables brutes
2. Génère un script Python pour calculer ces paramètres dérivés
3. Exécute le script dans un environnement sandbox
4. É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, celles-ci sont propres, correctement saisies, 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 nouvelles tentatives.

Une autre situation courante dans laquelle l’agent de calcul de 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 aux contraintes liant les variables d’expédition continue aux décisions binaires d’ouverture d’installations. Il s’agit d’un paramètre dérivé qu’il serait peu pratique de demander à l’utilisateur de fournir directement.

É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 résolution Python complet pour le backend de votre choix. 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 sandbox. Si quelque chose ne va pas : erreur de syntaxe, exception d’exécution ou résultat du solveur infaisable/illimité, le message d’erreur complet et le traçage sont renvoyés au LLM avec le code généré précédemment. L’agent essaie à nouveau, jusqu’à un nombre maximum de tentatives configurable par l’utilisateur.

En pratique, la majorité des échecs sont résolus en une ou deux tentatives. La principale raison pour laquelle la boucle de nouvelle tentative d’ORPilot est efficace est que les étapes en amont ont déjà fait le plus dur : le problème est correctement spécifié, les données sont prêtes pour le modèle et l’agent seul
doit corriger une erreur au niveau du code plutôt que de repenser l’ensemble de la structure du modèle.

Étape 5 : Agent journaliste

Après une résolution réussie, un agent rapporteur traduit les résultats numériques en anglais simple, expliquant quelles installations ouvrir, quels itinéraires utiliser, quelles quantités produire, dans le langage du domaine du problème commercial d’origine, pour une consommation par un utilisateur professionnel plutôt que par un expert de la salle d’opération.

Pourquoi cette commande est importante

Le pipeline est délibérément séquentiel. Chaque étape est déclenchée par la réussite de la précédente. L’entretien doit être terminé avant le début de la collecte des données. Les données doivent être validées avant l’exécution du calcul des paramètres. Les paramètres doivent être prêts avant que le code soit généré.

Ce séquençage évite le mode de défaillance le plus courant dans les outils OR basés sur LLM : des erreurs en cascade où une description ambiguë du problème se propage à travers le pipeline et produit un code syntaxiquement valide mais modélise un objectif incorrect.

À quoi cela ressemble à grande échelle

J’ai testé ORPilot sur quelques problèmes OR, dont un problème de conception de réseau de chaîne d’approvisionnement avec 50 sites de production, 50 centres de distribution, 500 clients, 500 produits, 12 périodes. Le modèle résultant comportait plus de 9,7 millions de variables de décision et 963 000 contraintes. ORPilot a géré avec succès l’intégralité du pipeline de bout en bout, depuis la conversation initiale jusqu’à la collecte de données, le calcul des paramètres, la génération de code et le reporting de la solution, produisant ainsi une solution optimale avec Gurobi. Consultez mon article ici https://arxiv.org/abs/2605.02728 pour voir les résultats de plus de problèmes de test.

Commencer

ORPilot est open source et disponible dès maintenant :

GitHub : https://github.com/GuangruiXieVT/ORPilot
Article : https://arxiv.org/abs/2605.02728

L’installation prend quelques minutes. ORPilot prend en charge OpenAI, Anthropic, Google et DeepSeek en tant que fournisseurs LLM, ainsi que Gurobi, CPLEX, PuLP, Pyomo et OR-Tools en tant que backends de solveur.

Dans le prochain article de cette série, nous examinerons en profondeur la représentation intermédiaire (IR) – l’artefact JSON indépendant du solveur qui rend les résultats d’ORPilot reproductibles et portables sur tous les backends sans jamais appeler à nouveau le LLM. Restez à l’écoute!