Résumé Technique : OR-Space

Énoncé du Problème

Les benchmarks existants pour les agents de Modèles de Langage (LLM) en Recherche Opérationnelle (RO) abstraient largement les complexités des flux de travail industriels réels. Les évaluations actuelles réduisent généralement les tâches de RO à des problèmes « en un seul coup », où un agent traduit un prompt textuel autonome en une formulation mathématique ou un code de solveur. Cette approche échoue à capturer deux caractéristiques déterminantes de la RO industrielle :

1. Le Contexte de l'Espace de Travail : Les agents réels opèrent dans des environnements persistants et multi-artefacts contenant des exigences métier, des données structurées (CSV/JSON), des artefacts de code, des retours de solveurs et des interactions avec les parties prenantes, distribués sur plusieurs fichiers.
2. Le Contexte du Cycle de Vie : La RO industrielle est itérative. Les ingénieurs ne génèrent pas une solution une seule fois ; ils construisent des modèles initiaux, les révisent en réponse à l'évolution des règles métier ou des retours des solveurs, et expliquent les décisions résultantes à des parties prenantes non expertes.

Par conséquent, les benchmarks actuels ne peuvent pas déterminer si un agent est capable d'effectuer un travail d'optimisation fiable à travers un espace de travail multi-artefacts et à travers plusieurs étapes du cycle de vie de la modélisation.

Méthodologie

Les auteurs introduisent OR-Space, un benchmark d'espace de travail complet conçu pour évaluer les agents d'optimisation industriels. La méthodologie est structurée autour de deux axes principaux : un espace de travail exécutable persistant et un pipeline de tâches orienté cycle de vie.

1. Formalisation de l'Espace de Travail RO

Un espace de travail RO ($W$) est défini comme un environnement structuré, persistant et exécutable :
$$W = \langle D, P, S, E, M \rangle$$

• $D$ (Documents) : Artefacts en langage naturel (par exemple, business_requirement.md) décrivant les objectifs et les exigences.
• $P$ (Paramètres) : Fichiers de données structurées (CSV, JSON) contenant des entrées numériques, nécessitant souvent un nettoyage et un alignement de schéma.
• $S$ (Code) : Artefacts de code, incluant des scripts heuristiques, des modèles partiels ou des implémentations héritées.
• $E$ (Environnement) : Un bac à sable basé sur Docker supportant les E/S de fichiers, l'exécution de solveurs (Gurobi, COPT, PuLP, HiGHS) et les contraintes de ressources.
• $M$ (Métrique) : La métrique d'évaluation (cachée à l'agent) utilisée par le dispositif de benchmark.

Contrairement aux benchmarks antérieurs qui sérialisent tout le contexte dans un seul prompt, OR-Space exige que les agents localisent, connectent et ancrent l'information à travers ces artefacts distribués.

2. Modes de Tâches Orientés Cycle de Vie

OR-Space définit trois modes de tâches séquentiels dérivés de 100 problèmes de base (étendus à partir du benchmark IndustryOR) :

• Construire ($T_{Build}$) : L'agent construit un modèle d'optimisation prêt pour le solveur à partir de zéro en utilisant des documents métier et des fichiers de données, en partant d'une structure de code vide.
• Réviser ($T_{Revise}$) : L'agent modifie un flux de travail d'optimisation existant sous de nouvelles exigences. Cela inclut des variantes telles que Réviser-code (modification de code hérité), Réviser-modèle (modification de la formulation uniquement) et Réviser-tout. L'agent doit préserver la logique valide précédente tout en intégrant de nouvelles contraintes ou variables.
• Expliquer ($T_{Explain}$) : L'agent répond à des questions ancrées sur les solutions, les contraintes et les implications métier en utilisant des preuves distribuées à travers les documents, les données, le code et les sorties des solveurs (par exemple, variables duales, valeurs de slack).

3. Protocole d'Évaluation

• Construire & Réviser : Évalués via des métriques notées par le solveur. Une soumission est correcte si elle s'exécute sans erreur, renvoie un statut « Optimal » et atteint une erreur d'objectif relative $\le 1\%$ par rapport à une oracle de vérité terrain.
• Expliquer : Évalué à l'aide d'une grille de notation « LLM-comme-juge » ancrée. Les scores sont basés sur la Couverture Exacte (35 %), le Raisonnement (35 %), l'Ancrage (20 %), la Qualité de la Réponse (10 %) et une Pénalité d'Hallucination (jusqu'à -12).
• Analyse des Échecs : Le cadre enregistre des modes d'échec spécifiques, notamment les erreurs d'exécution, les formulations non réalisables, les objectifs incorrects et les explications infidèles.

Contributions Clés

1. Identification des Limites : L'article identifie que les benchmarks RO existants souffrent de contextes d'espace de travail autonomes et de contextes de tâches en un seul coup, qui sous-représentent la nature multi-artefacts et orientée cycle de vie des flux de travail industriels réels.
2. Benchmark OR-Space : Un nouveau benchmark construit autour d'espaces de travail exécutables persistants où les exigences, les données, le code et les sorties des solveurs sont distribués sur plusieurs fichiers.
3. Modes de Tâches : La définition de trois modes orientés cycle de vie (Construire, Réviser, Expliquer) qui capturent la construction, la maintenance et la communication des modèles.
4. Cadre d'Évaluation : Un protocole pour analyser les capacités des agents et les modes d'échec dans des tâches ancrées dans l'espace de travail, incluant l'ancrage des données, la cohérence de la révision et la fidélité de l'explication.

Résultats

Les auteurs ont évalué 20 modèles (frontière en source fermée, petits basés sur API et open-source) à travers le benchmark. Les principales conclusions incluent :

• L'Ancrage dans l'Espace de Travail est Difficile : Même les agents de pointe peinent avec la construction de modèles ancrée dans l'espace de travail. Le meilleur score de Construction était de 72,0 % (gemini-3.1-pro), la plupart des modèles de pointe se situant dans la fourchette 53–68 %. Cela met en évidence la difficulté de récupérer les schémas de données et les sémantiques métier à partir d'artefacts distribués par rapport à des prompts propres.
• Code Hérité comme Signal vs Bruit : Dans la tâche Réviser, les modèles performants (par exemple, gpt-5.4, claude-opus-4-6) ont souvent amélioré leurs performances en exploitant le code hérité comme signal (par exemple, gpt-5.4 est passé de 59 % à 79 %). À l'inverse, les modèles plus faibles ou « flash » ont souvent subi des baisses de performance (par exemple, gemini-3-flash a chuté de 23 points de pourcentage), suggérant qu'ils traitaient les détails d'implémentation comme du bruit ou copiaient des imports non liés au solveur.
• L'Explicabilité est Distincte : La performance dans Expliquer était faiblement corrélée aux scores de Construire et Réviser ($r \approx 0,16-0,28$). Certains modèles qui ont construit des modèles exécutables ont échoué à les expliquer fidèlement (par exemple, gemini-2.5-pro a résolu 69 % des instances de Révision mais n'a obtenu que 32,2 à Expliquer).
• Impact de l'Interface : L'utilisation d'une interface de système de fichiers (par rapport à une sérialisation de prompt plat) a généralement réduit les performances dans les tâches de génération de code (Construire et Réviser) d'une moyenne de 8,2 et 12,2 points de pourcentage, respectivement. Cela indique que la découverte de fichiers et l'inspection de schéma sont des difficultés substantielles, et non cosmétiques.
• Sensibilité au Contexte : L'ajout de formulations formelles au contexte de code a généralement aidé les modèles performants mais pouvait nuire aux modèles légers. Un contexte basé uniquement sur la formulation s'est avéré plus fragile qu'un contexte basé sur le code.

Signification et Revendications

L'article positionne OR-Space comme un changement nécessaire dans les paradigmes d'évaluation, passant de la génération de texte isolée à des flux de travail d'ingénierie robustes et ancrés dans les solveurs. Les auteurs affirment que :

• Fossé de Fiabilité : La navigation dans un espace de travail ouvert et multi-artefacts reste hautement difficile pour les agents LLM actuels, exposant des défaillances systémiques dans la cartographie des données et l'ancrage des contraintes que les benchmarks purement textuels masquent largement.
• Préparation Pratique : OR-Space fournit une base rigoureuse pour mesurer la préparation pratique des agents d'optimisation en simulant la nature itérative et multi-étapes de la RO industrielle.
• Modes d'Échec : Le benchmark permet une attribution fine des échecs, distinguant les erreurs de modélisation mathématique, les erreurs d'ancrage des données et les contraintes hallucinées, ce qui est crucial pour le déploiement d'agents dans des environnements réels.

L'étude conclut que, bien que les LLM montrent des promesses dans des tâches de formulation isolées, leur capacité à effectuer une ingénierie RO fiable à travers un espace de travail persistant et un cycle de vie complet est actuellement limitée, nécessitant davantage de recherches sur la fiabilité des agents, les modes d'échec et l'interaction avec l'espace de travail.