Decision Information Meets Large Language Models: The Future of Explainable Operations Research
Authors: Yansen Zhang
Qingcan Kang
Wing Yin YU
HaileiGong
Xiaojin Fu
Xiongwei Han
Tao Zhong
Chen Ma
Venue: ICLR 2025 Poster (2025)
Keywords: Operations Research Problems; Large Language Models
Primary area: optimization

Abstract: Operations Research (OR) is vital for decision-making in many industries. While recent OR methods have seen significant improvements in automation and efficiency through integrating Large Language Models (LLMs), they still struggle to produce meaningful explanations. This lack of clarity raises concerns about transparency and trustworthiness in OR applications. To address these challenges, we propose a comprehensive framework, Explainable Operations Research (EOR), emphasizing actionable and understandable explanations accompanying optimization. The core of EOR is the concept of Decision Information, which emerges from what-if analysis and focuses on evaluating the impact of complex constraints (or parameters) changes on decision-making. Specifically, we utilize bipartite graphs to quantify the changes in the OR model and adopt LLMs to improve the explanation capabilities. Additionally, we introduce the first industrial benchmark to rigorously evaluate the effectiveness of explanations and analyses in OR, establishing a new standard for transparency and clarity in the field.

Published as a conference paper at ICLR 2025
DECISION INFORMATION MEETS LARGE LANGUAGE MODELS: THE FUTURE OF EXPLAINABLE OPERA- TIONS RESEARCH
Yansen Zhang"", Qingean Kang" Wing Yin Yu', Hailei Gong", Xiaojin Fu², Xiongwei Han",
Tao Zhong?, Chen Ma
DDpartmeet of Computer Science, City University of Hong Kong
Huawei Noah's Ark Lab
yanszhang7-c cityu. edu. hk
Langgingcan@huaven com
chenma wew.yiiuuuuuu.t......ooou edu.
ABSTRACT
Operations Research (OR) is vital for decision mackiinn-making in many industries. While recent OR methods have significant improvements in automation and effi- ciency through integrating Large Language Models (LLMs), they still struggle to produce meaningful explanations. This lack of clarity raises concerns about trans- parency and trustworthiness in OR applications. To address these challenges, we propose a comprehensive framework, Explainable Operations Research (EOR). emphasizing actionable and understandable explanations accompanying optimiza- tion. The core of EOR is the concept of Decision Information, which emerges from what-if analysis and focuses on evaluating the impact of complex constraints (or parameters) changes on decision-making. Specifically, we utilize bipartite graphs to quantify the changes in the OR model and adopt LLMs to improve the explanation capabilities. Additionally, we introduce the first industrial bench- mark to rigorously evaluate the effectiieness of explanations and analyses in OR, establishing a new standard for transparency and clarity in the field.
INTRODUCTION
Operations Research (OR) has long history of optimizing complex decision-making processes, such as in logistics, finance, investment, transportation, and healthcare, etc., where even small im- provements can lead to significant operational profits. As these optimization algorithms increasingly contribute to daily life, is essential to ensure their trustworthiness and reliability through expla- nations, which build user confidence (Faulhaber et al., (021). Governments are also responding to this need by enacting laws like the General Data Protection Regulation (GDPR) of the European Union (Goodman & Flaxman 2017), emphasize the "right to explanation" for algorithmic decisions (Selsst& & Powles 2018) in automated systems.
In recent years, Large Language Models (LLMs) have emerged powerful tools in the OR domain, offering new opportunities to automate and enhance the modeling process. Current research of LLMs in OR, such as works (Xiao al., 2023 AhmadiTesshizi et al. 2024; Tang al., 2024] Zhang et al.) (024), explore the potential to streamline the formulation and solutions of complex OR problems. However, LLMs OR have primarily focused on improving efficiency and accuracy by generating codes for external solvers to obtain OR solutions, with less attention to enhancing solution explainability, especially in real-time collaborative automated systems.
Meanwhile, several studies (Cyras et al. 2019 Li et 2023 Erwig & Kumar 2024 De Bock
et al.) (024) have explored explainable optimization related to OR, but there are still limitations. For example, (Erwig & Kumar 2024) focuses specifically on combinatorial optimization problems,
Work done intern in Huawei Noah's Ark Lab.
Corresponding authors.

---

Published as a conference paper at ICLR 2025
which limits its applicability across the broader OR landscape and fails to leverage the advantages of LLMs in real-time modeling and explanations. Another work, OptiGuide (Li et al., 2023), em- phasizes what-if amalysis, which, while useful for specific easy scenarios, lacks the robust modeling capability to address more complex cases like deleting or combining constraints. For example, if a warehouse closes, the OR model must remove the related storage capacity constraint and adjust the distribution network. Current methods struggle to achieve this level of flexibility, yet such adapt- ability crucial for accurately reflecting real-world changes. Most critically, the explanations these methods provide are often superficial, merely summarizing the outcomes without exploring the un- derlying reasons behind the results, thus lacking the quantitative analysis, depth, and clarity required to fully understand and trust the decision- process.
Given the limitations of existing approaches to explainable optimization, we are motivated to de- velop more comprehensive framework, EOR, for explaining OR models. As shown in Figure [ our framework addresses the critical need for transparency in OR by shifting from purely model- ing problem (a natural language description) to providing clear, actionable explanations for user query, such as "What if transportation costs increase by 15%??" First, we formulate the problem of explainable OR within the context of LLMs. This formulation is essential for laying founda- tion for future research in this emerging area. Second, our framework emphasizes two critical types of explanations, 1) Explanation of correctness: the reasons for code updates during the modeling process, and 2) Explanation of the Results: the rationale for generating specific solutions. Unlike traditional methods that provide superficial explanations and analyses, our approach incorporates more sophisticated what-if analysis, quantifying the effects of changes prompted by user queries and providing deeper insights into the decision-making process. A significant component of our contribution is the introduction of the concept of "Decision Information". By leveraging bipartite graphs, we measure the importance of different decision factors in response to user queries, par- ticularly when complex changes in constraints arise. This approach enhances both the modeling capabilities and the explanatory power of OR models within LLMs. Our dual focus ensures that the framework not only yields accurate optimal solutions but also effectively communicates the un- derlying rationale for these solutions. Finally, recognizing the need for standardized evaluation of design new industrial benchmark specifically tailored assess the
explainable OR methods, effectiveness of explanations in OR. This benchmark fills the gap of current approaches and sets a new standard for evaluating the transparency and comprehensibility of OR models.
Problem Description
Code
Solution
</>
TXT
generate
Explanutions
0.0
LLM
Solver
J
upuaate
User Query
Code
Solution
Figure I: The framework of FOR.
Contributions. 1) We formulate the problem of the explainable OR problem within the context of LLMs, laying foundation for future research in this area. 2) We introduce the concept of "Decision Information" and utilize bipartite graphs in conjunction with LLMs to quantify its importance in response to user queries, enhancing both the modeling capabilities and the explanation of complex what-if analysis within OR. 3) We develop a new benchmark specifically designed to evaluate the effectiveness of explanations in OR, setting a new standard for explainability in the field.
2

---

Published as a conference paper at ICLR 2025
2 RELATED WORK
2.1 LLMS FOR OR
LLMs show great promise for OR, offering innovative approaches optimize and automate model- ing processes (Xiao et al. [ Almaaiieesmiii et al., 2024 Tang et al.) 2024 Zhang et al.) 2024] Huang et al., 2024 Mostajabdaveh et al., (024). Although LLMs have shown potential various OR tasks, their application has primarily focused on automating modeling processes and enhancing computational efficiency. In contrast, our approach distinguishes itself by using LLMs to provide detailed, context-aware explanations of OR solutions, addressing the gap in explainability.
2.2 EXPLANATIONS FOR OR
Explanation in OR is essential for clarity and transparency, helping various stakeholders understand complex decision-making processes. Despite its significance, there is notable lack of research, with only a few related works, such as (Thuy & Benoit 2024 Erwig & Kumar 2024 De Bock al. 2024) and OptiGuide (Li et al. 2023), which only focus the easy what-if analysis. Our approach focuses on more complex what-if analysis, seeking a broad range of methods that can uni- formly quantify constraint changes or parameter changes (sensitivity analysis). We leverage LLMs to embed detailed, context-aware explanations directly within OR solutions, filling this gap. The comparison between EOR and OptiGuide is shown in Table More details about the differences between the concepts are discussed in Appendix A.1
Table 1: The comparison of OptiGuide and EOR.
What-if Analysis
Decision Information Analysis
Sensitivity Analysis
Easy
Complex
OptiGuide BOR
X
3 METHODOLOGY
3.1 PROBLEM FORMULATION
Given OR problem ý, along with a user query ğ related the problem, our goal is utilize an LLM to generate comprehensive explanations of solutions for the queries in real time. The LLM will provide two types of explanations: 1) Attribution Explanation, which outlines the general attributes and structure of the problem, and 2) Justificution Explanation, which elucidates the correctness and derivation the solutions. The mathematical formulation as follows:
Input: The origin problem description = (d, a, ē), and user query q ('). The updated problem description, incorporating the user query, is denoted z = (d. o'.'''))). Here, d represents the set of decision variables, ô and ò' are the objective functions to be maximized or minimized, è and č' denote the original and modified constraints in á and 8', respectively, that the decision variables must satisfy. In our setting. we assume the decision variables remain unchanged.
Output: We denote the problem solutions for and ÿ' and 3', respectively. The output com- prises two types of explanations, 1) Attribution Explanation: A detailed description of the elements d, ö, 8', è, ě', 8, and 3' within the context of the problem. 2) Justificution Explanation: A rationale for the correctness
and 8', and clarifies how & derived from
3.2 THE EOR FRAMEWORK
Our proposed framework, EOR, is end-to-end solution designed to enhance OR model trans- parency using LLMs. Unlike current methods that provide limited and shallow explanations, pri- marily the form of attribution explanations, our framework emphasizes delivering clear, actionable
3

---

Published as a conference paper at ICLR 2025
insights for diverse stakeholders. As illustrated in Figure 1 focus the justification explana- tions. We will offer two critical explanations: 1) justifications for code updates during the modeling process, and 2) the rationale behind specific solutions. By doing so, strive to make OR lutions more accessible, understandable, and applicable to broader audience, thereby improving decision-making quality and fostering user trust.
Commander
Writer
(2) Code prompt Debug prompt
Query
(8) Explunations
(3) Code generated
Repuat umiil the query
User
(4) Safe prampt
(5) SAFE
Answers
DANGER
tinocout
perpretter prompt
0.
Safeguard
Figure 2: The overall workflow of EOR.
3.2.1 THE WORKFLOW OF EOR
As shown in Figure EOR framework comprises three key agents: Commander, Writer, and Safe- guard, each serving a distinct role to ensure an efficient, accurate, and secure optimization process.
The Commander acts as the central hub or "data bus" in the system, respon- sible for receiving user queries and managing data flow between the agents. When an end- submits a new user query, the Commander first interprets the query's 's context, identifies the intent, and then forwards the message to the appropriate agents.
Commander Agent:
Writer Agent:
Upon receiving the processed query from the Commander, the Writer initially as- sumes the role analyzing and modifying the code. Based on the query's requirements, the Writer determines whether to add, delete, or update specific constraints and parameters. By leveraging LLMs, the Writer guarantees that the generated code accurately reflects the intended changes. Sub- sequently, the updated code is sent to the Safeguard for verification. Once the Safeguard provides SAFE confirmation, the Writer transitions into an interpreter role, generating detailed explanations for the modifications and the rationale behind the decision-male making process.
The Safeguard responsible for ensuring the safety and correctness of the gen- erated code. It conducts thorough checks verify whether the code adheres to predefined safety standards and is free from logical or syntactical errors that could compromise the optimization pro- cess. If the code passes these safety checks, the Safeguard approves for execution; otherwise, triggers a debugging process where the Writer regenerates and corrects the code as necessary.
Safeguard Agent:
The overall workflow: The EOR workflow starts when a user submits query the Commander (1), who relays it to the Writer with a code prompt (2). The Writer analyzes the query, determining whether to add, delete, or update code, and returns the updated code the Commander (3). This step ensures that the generated code aligns with the updated problem requirements. The Commander then sends the code to the Safeguard for verification (4). If the Safeguard determines the code safe (5), the process moves to (6), where the Commander sends an interpreter prompt to the Writer. If the code is deemed dangerous, the process loops back to (2), with the Commander sending a debug code prompt to the Writer. Once the code is safe, the Writer generates answers about explanations for the modifications and results (7) and sends them to the Commander. Finally, the Commander sends these explanations to the user (8). This iterative process, which repeats until satisfactory answer or timeout, ensures robust, explainable solutions tailored to the user's s query. The detailed design of the prompt template is presented in Appendix A.2 A.2
4

---

Published as a conference paper at ICLR 2025
3.2.2 JUSTIFICATION EXPLANATION GENERATION
In our framework, explanations are generated to ensure transparency and trustworthiness in the decision-making process. These explanations are divided into two main categories:
Explanation of Correctness: This type of explanation serves to validate the code modifications introduced by the Writer, offering a detailed rationale for the changes made. It clarifies the necessity of these modifications in addressing the problem's requirements and ensures that they adhere to safety standards and logical constraints. Through this process, the reliability of the generated code substantiated, thereby enhancing the accuracy of the model prior to execution.
Once the code is executed and the results are obtained, this type of explanation focuses on interpreting the outcome. It breaks down the results into understandable terms, illustrating the impact of the code changes the final solution. This explanation connects the modifications to their direct effects, providing users with clear understanding of how the new solution addresses their initial query and any resulting trade-offs benefits.
Explanation of the Results:
Before formalizing the concept of "Decision Information", consider the following user query from an OR problem in flight operations: How should the aircraft configuration be adjusted the com- pany limits Type A aircraft to 15 and Type aircraft to 30? In this context, "Decision Information" refers to the respectively, which directly modify the optimization model. These changes reshape the solution space, requiring adjustments meet demand within the newly imposed limits. Thus, "Decision Information" captures the key query elements that drive changes in the problem.
constraints, limiting the number of Type A and Type B aircraft to 15 and 30,
Definition Decision Information: Decision Information encompasses the parameters and con- straints specified in a user's query for an OR problem, capturing the essential details needed to reconfigure the problem according to the user's 's intent.
Following this definition, turn quantitative evaluation of "Decision Information" assess its impact on decision-making processes. However, existing methods lack measure for assessing changes in decision information caused by constraint modifications, focusing only sensitivity analysis in parameter changes. Inspired by (Xing et al. 2024). we convert both the updated and original programs into standardized format and then calculate their differences to determine the importance of information changes. This process can be outlined in three steps:
Conversion Linear Programs (LPs) in General Form: Both the updated code (resulting from user queries) and the original code are first parsed and translated into a standardized LP format, that widely adopted by various LP solvers, including CPLEX (Cplex) 2009). Gurobi (Bixby) 2007], COPT (Ge et al.) (202)) an on. This conversion includes expressing all decision variables, objective functions, and constraints uniformly to allow direct comparison. The general LP form captures the essence of both the initial and modified decision scenarios, providing clear basis for analyzing how changes in input data or constraints affect the outcome.
Formally, an LP with variables and constraints can be represented as:
min #Ek"
cT x
s.t. 1 Ax u² S<a n.,
where A E m is the constraint matrix, c E Ra is the cost vector, E IR" is the decision variables. 1" E I= and u" E R are lower/upper bound of the decision variables æ, and E R and uº R are lower/upper bound of the constraint.
The standardized LPs can be transformed into bipartite graphs, which consist of two distinct sets of nodes: decision variables and constraints (Gasse et al.) 2019 Fan et al., 2023; Xing et al. 2024p. In this representation, edges between nodes signify dependencies or relationships, with edge weights indicating the strength or nature of these connec- tions. We define the bipartite graph as g = (S U. E), where = {syli E [m]] represents the set of constraint nodes, X {øylī E [n]} represents the set of decision variable nodes, and E = {er,yl E [m].j e [m]} represents the edges between them. Here, [-] denotes a set of consecu-
Graph Representation Conversion:
tive numbers. The attribute of a constraint vertex 8; is expressed as attr(s:) [1 ut] T, indicating
5

---

Published as a conference paper at ICLR 2025
its lower and upper bounds. Similarly, the attribute of a decision variable vertex 2j is given by attr(z,) = - "j],, which includes its lower bound r upper bound uy, and objective coeffi- cient Cj. This graph-basee approach facilitates structural analysis of the decision- frame- work, allowing us to visualize the interactions among variables under different conditions and to compare updated and original programs structural level.
Graph Edit Distance (GED) Calculation: To quantify the impact of changes in "Decision Informa- tion", compute the GED between the two bipartite graphs derived from the updated and original LPs. GED represents the minimum cost necessary to transform one graph into another through a sequence of operations, such as inserting, deleting. or substituting vertices and edges. This metric effectively captures the types of modifications made to the code in response to a query. This met- ric quantifies the minimal number of modifications (such as adding, deleting, or substituting nodes or edges) required to transform one graph into the other. A smaller edit distance indicates fewer changes, suggesting the updated program closely aligns with the original prcision-makingg context. Conversely, a larger edit distance highlights significant alterations, signaling a substantial impact of the updated information on the pecision-making process.
There are many well-established GED algorithms (Gao et al. 2010 Stauffer et al. 2017 Abu-
Aisheh et al., 2015] Xing et al. 2024), we follow a straightforward principle provided by (Xing al. 2024): each operation
attribute in graph incurs unit cost of 1. Formally, given the graph of the original program G (5 U X2, E²) and updated program G (S"" U X E
we define the vertex cost matrix as follows,
& EEST SP
2 E XP
E Sp Exp
#msm (5)" ,8)
8
Hattr (s #attr( (s
D Hattr(s))
#msm #attr(
e
o
In this context, all operations are treated as matching processes; for example, deleting vertex is conceptualized as matching the vertex to empty vertex, denoted by e. Here, #attr(.) denotes the total number of vertex attributes, while #msm(-) represents the count of mismatched attributes be- tween two vertices. Similarly, the edge cost matrix is defined as follows,
E, E E
o E
#msm #attr
#attr
0
Given the varying scales of changes in parameters and constraints, we further normalize GED(GT .GP) by the graph size. The normalized GED (NGED) is calculated as: NGED Go)
GED(GF' ,²))
max([g= "..611=' where [G] is defined as the sum of the number attributes for all edges and vertices in the graph, specifically: |9] EnEF #atur(e) + E.Esux #atur(v). This normalization accounts for graph size variations, allowing for a more consistent comparison of the impact of changes across different scenarios. By quantifying discrepancies between the updated and original graphs through an analysis of their attribute changes, our approach offers a more precise measurement of changes framework.
in the
By employing these three steps, LP conversion, graph representation. and graph edit distance calcu- lation, we provide a rigorous and systematic approach quantifying "Decision Information". Since LLMs cannot directly perform this quantification, we utilize them to sense these processes and gen- erate explanatory insights. This approach fills the gap in previous methods that could not quantita- tively analyze the impact of changes in constraints. By offering a unified methodology for measuring changes in constraints and parameters, it enables a precise evaluation of information changes. This framework provides measurable and comparable basis for assessing the impact of these changes on decision-min decision-making. It thus anchors the concept of "Decision Information" " both practical and thEoRetical contexts, offering more profound insight into how updates shape decisions.

---

Published as a conference paper at ICLR 2025
4 EXPERIMENTS
4.1 EVALUATION BENCHMARK
Despite the availability of numerous open-source datasets in OR, such as NLAOPT (Ramamonjison et al. ).23), ComplexOR (Xiao et al. 2023), NLP4LP (Holzer et al. 2024), and IndustryOR (Tang
al. 2024), these datasets are limited to problem descriptions and are primarily suited for OR modeling needs. There remains a significant gap in datasets specifically tailored for explainable OR, which are erucial for advancing transparency and interpretability in decision-making processes.
To address this issue, we developed a novel benchmark dataset based on the open-source com- mercial IndustryOR, specifically designed evaluate explainability in OR tasks. The benchmark includes 30 categorized problems across various domains (e.g., supply chain management, financial investment, logistics management, etc.). Each problem is paired with 10 unique queries that involve diverse or combined modifications to parameters or constraints (e.g., deleting, adding, or updating constraints and parameters). These queries were crafted by OR experts with significant industry experience to ensure both diversity and practical relevance. The dataset's 's quality and comprehen- siveness are validated through iterative expert reviews and comparisons with real-world cases. For every problem, we provide corresponding Python code and employ the Gurobi optimization solver (Bixby 2007) to determine optimal solutions. Additionally, we also include the ground truth labels for each query for each problem to ensure accurate evaluation. Notably, the question sets and the queries in this benchmark are developed from scratch and managed in-house, guaranteeing that they have not been part of LLM training data, enhancing the robustness of the benchmark for assessing model performance. We provide a complete example in Appendix A.3
4.2 EVALUATION METHODOLOGY
Our evaluation focuses on two aspects: Modeling Accuracy and Explanation Quality. For the modeling accuracy assessment, we recognize that different code implementations can produce the same optimization results. For instance, two programs solving a linear programming problem may employ different formulations or techniques (e.g., distinct constraint orderings variable namings), but both can still yield identical optimal solutions. Therefore, rather than directly comparing the generated code reference, evaluate accuracy by comparing the optimization outcomes to ensure correctness and consistency across implementations.
Regarding the explanation quality, although our task is highly specialized and requires expert-level interpretability in OR, we aim to develop an automated evaluation method. Drawing inspiration from (Kondapaneni et al.] 2024) and utilizing the capabilities of LLMs for text quality evaluation
(Chen et al. 2023: Chiang & Lee, 2023; Hu et al. 2024 Chu et al., 2024; Zytek et al., 2024), we establish expert-crafted templates and use LLMs to assess explanation quality, aiming for human-level standard. However, this evaluation approach has certain limitations. To address this, we propose two methods in this paper. First, we establish a structured template that specifies key criteria for effective explanations, such as clarity, relevance, and logical coherence. For instance, explanations should explicitly describe the rationale for modifying specific parameters or constraints and explain how these changes affect the optimization results. Second, we conduct blind review process where OR experts anonymously score the explanations generated by different methods. This approach helps minimize bias, providing reliable measure of how effectively the explanations convey meaningful insights to users. We will assess whether the proposed automated evaluation method aligns with human evaluation. This dual approach enables assess the consistency between the proposed automated method and human evaluation.
4.3 BASELINES
We employ two baselines to ensure a comprehensive evaluation: Standard and OptiGuide (Li et al., 2023). The Standard involves proprietary LLM (e.g., GPT-4, GPT-4-Turbo, etc.) that gener- ates updated programs and explanations, serving as a basic comparison point for assessing overall performance. The OptiGuide represents specialized method used in supply chain optimization, providing a domain-specifii comparison that evaluates the adaptability and effectiveness of LLMs in industry-relevan scenarios.
7

---

Published as a conference paper at ICLR 2025
Table 2: Accuracy across different models under different LLMs with zero/one-shot setting. The bold scores are the best in each row.
Setting
Model
Standard
OptiGuide
EOR
GPT-4
18.67%
30.33%
75.67 %
1PT-44-110-previeee
75.33%
36.00%
81.67
Zero-shot
GPT-4-0125-previin
68.33%
47.33%
87.33 %
GPT-4-Turbo
63.00%
30.33%
88.33% %
GPT-4
71.67%
75.00%
90.33% %
GPT-4-1106-previce
69.67%
55.33%
87.67 %
One-shot
GPT-440125-preview
76.00%
69.33%
92.00 %
GPTT-4-Turbo
88.00%
69.33%
95.33%
4.4 MODEL SETUP
For our experiments, evaluate the performance of the proposed baselines using four LLMs, GPT- (Achiam et al. 2023). GPT-4-1106-previees GPT-4--0125-peeveet and GPT-4-Turbo, under both zero-shot and one-shot learning settings. The zero-shot setting requires the models to generate up- dated programs and explanations without any prior examples, testing their inherent understanding and generalization capabilities. The one-shot setting provides single example guide the mod- els, allowing to assess the impact of minimal contextual information on their ability to perform the tasks accurately and coherently. To ensure fairness and reproducibility, we fix the hyperpa- rameter temperature at O and apply the same examples for all models in the one-shot setting, and all models are implemented under the framework AutoGen (Wu et al.) 2024). This paper focuses on fully automating all processes, excluding user involvement. However, built on the AutoGen, it inherently supports seamless integration of user feedback. A detailed hy- perparameter sensitivity analysis is provided in the Appendix A.4 The source code is available pettps:/ggithng hom..tttcooccc.o...ooooomoee corst St Stone/EE /EO
implementation is
4.5
QUANTITATIVE PERFORMANCE
4.5.1
COMPARISON OF MODELING ACCURACY
Table 2 shows the accuracy results across different models. We have the following observations. In the zero-shot setting, EOR consistently outperforms both Standard and OptiGuide across all LLM versions. These results emphasize the robustness the EOR in zero-shot tasks, which substantially improves performance compared to other methods. For instance, GPT-4-urrb achieves 88.33% accuracy with EOR, while Standard and OptiGuide methods yield only 63.00% and 30.33%, respec- tively. Moreover, for all LLM models except GPT-4, Standard outperforms OptiGuide, indicating that the LLM's 's modeling capabilities are quite strong.
In the one-shot setting, EOR continues outperform Standard and OptiGuide in all LLM versions, achieving an average of 90.00% accuracy and even reaching 95.33% accuracy on the GPT-4-Turbe the highest among all results. Additionally, we find that providing an example can significantly improve modeling accuracy, and nearly all methods perform better in the one-shot setting than in the zeoo setting. Specifically, the accuracy of OptiGuide on GPT-4 improves from 30.33% to 75.00% However, OptiGuide still produces the worst result except on GPT-4.
Overall, EOR consistently outperforms other methods in both zero-shot and one-shot settings, partic- ularly with models like GPT-4-Turbb and GPT-4-0125- previie... The accuracy gains observed when transitioning from zero-shot to one-shot highlight the importance of using examples in improving model performance. In terms of model comparisons, GPT-4-Turbo demonstrates the highest adapt- ability across both settings, achieving the best overall accuracy. While OptiGuide provides modest improvements, it does not match the performance of Standard and EOR. These results underscore the value of carefully selecting both models and example strategics to maximize accuracy, with EOR emerging the most effective for high-aceuracy tasks.
8

---

The results of Published as a conference paper at ICLR 2025
Table 3: Quality scores (0-10) across different models with zero/one-shot setting.
EC f
ER t
Overall
Method
Auto
Expert
Auto
Expert
Auto
Expert
Standard
0.12
6.98
6.98
5.36
5.63
Zero-shot
OptiGuide
0.69
7.93
7.90
6.31
6.59
EOR
9.76
9.86
9.41
9.47
9.47
9.47
Standard OptiGuide
0.34
7.10
6.90
5.54
5.37
One-shot
0.20
7.60
7.61
5,96
6.05
EOR
9.61
9.72
9.30
9.35
9.33
9.35
4.5.2 COMPARISON OF THE QUALITY OF EXPLANATIONS
As discussed in Sec. a critical part of our evaluation is assessing the quality of the explanations generated by the models. It is important to note that explanations based on incorrect results are irrelevant, as explaining failure cases offers no meaningful insights. Therefore, we first filter out all incorrect modeling cases, ensuring that only correct outputs are evaluated. We adopt two evaluation methods: an automated evaluation (Auto) and expert evaluation (Expert), both introduced in Sec.
4.2 These evaluations focus on two main aspects: Explanation of Correctness (EC) and Explanation of Results (ER). EC assesses the clarity and correctness the explanation regarding the model's output, while ER evaluates how well the explanation conveys the reasoning behind the optimization results. Additionally, we also measure the overall explanation quality (Overall). The explanations scored 0-10 scale, with 0 indicating poor quality and 10 indicating excellent quality. The prompt template for evaluating the explanation quality is provided in Appendix A.5 these evaluations using GPT-4o are summarized Table
As shown in Table 3, we have the following observations. Firstly, Auto is nearly as effective as Ex- pert, with minimal differences in scores across all metries, indicating that Auto a reliable and valid approach. It is worth noting that Auto scores individual queries on EC, although it does not explic- itly evaluate explanations. Secondly, EOR consistently outperforms both Standard and OptiGuide in explanation quality, achieving the highest scores in both zero-shot and one-shot settings. This demonstrates the superiority of our method in providing clearer and more accurate interpretations compared to other models. Finally, we find that Auto scores slightly higher on Standard than Expert, while for other models, the opposite is observed, with Auto scoring slightly lower than Expert. One possible reason is that LLMs may be biased toward the results they generate.
4.6
CASE STUDY
In this section, we provide an example of the code and explanations generated by EOR, illustrated in Figure 3 where simple explanations are highlighted green to represent attribute explanations, while deeper ones in yellow indicate justification explanations with quantitative analysis. Results from other models are provided in Appendix A.6 The EOR approach stands out by not only pro- viding clear explanation of the updated code but also offering detailed insights into how the query affects the outcomes. It explicitly highlights the newly added constraints that limit the number of Type A and Type B aircraft, demonstrating transparency in addressing the operational limits spec- ified the query. Unlike other methods that merely report result differences, EOR incorporates quantitative analysis, explaining the $15,000 increase in operational costs due to the restricted solution space caused by the newly added constraints. This step-by-step explanation not only jus- tifies the modifications but also clarifies the broader impact of the constraints, making EOR more comprehensive and contextually aware than other models.
CONCLUSION AND FUTURE WORK
In this paper, present EOR, novel framework that addresses transparency and interpretability challenges in OR. We introduce the concept of "Decision Information" through what-if analysis and use bipartite graphs to quantify changes in OR models. By leveraging LIM capabilities,

---

Published as a conference paper at ICLR 2025
A Case Study of EOR.
Query: How should the aircraft configuration be adjusted to meet demand if the company decides limit the number of Type aircraft operated than 15 and the number of Type B aireraft no more than 30?
The "code" generated by EOR:
"ADD CONSTRAINT"; "# Constraint: Limit number of Type and Type aircraft Amm wtw.aaaannttttaaaaaaaaaooooo (wwrerafttttottttaaaa <= 15, name "Maxtypeaconstralntt)) Anm.addConttr (aircraft_count
30, name= n WWattyyccoooosstaaiiinyy
The explanations generated by EOR: **Explanation of Updated Code:
The updated code includes new constraints that implement operational limits on the number Type and Type aircraft the airline can use. Specifically:
constraint has been added limit the number of Type A aircraft to 15.
constraint has been added limit number Type aircraft to
motivated by possibly new operational limitations strategic decisions, such as maintenance availability or cost considerations, By imposing these restrictions, the model must now find an optimal solution within more constrained operational environment.
These additional constraints
**Explanaiion of the Query R
The query specifically asked to adjust aircraft configurations within newly defined limits. The original model found an optimal solution at a minimum cost of $200,000. However, with the added constraints, fewer configurations of aireraft are available to meet the passenger
the solution space is reduced demand.
As a result of these constraints: increment indicates that the more stringent operational limits forced the use of costlier configuration. The query's 's impact on results substantial, as illustrated by $15,000 increase in operational costs, If rated scale from to 10, the impact could be quantified around 8, This rating reflects significant changes operational costs and constraints.
The new optimal cost calculated by model rose to $215,000. This
The numerical changes in the model, calculated 100, follows from step-hy-step process analyzing the modifications in the linear programming representation and their effects on the resulting computa- tional graph. This method, grounded in operations research analysis, validates the substantial impact of the query-drive driven modifications.
summary, changes to code (limiting aircraft types) constrained model significantly, lead- ing to more expensive operational solution. The rationale hehind integrating these specific constraints could be associated with real-world operational limits, reflecting the complex decision-making pro- cesses airlines undergo to balance cost, capacity, operational feasibility.
Figure An example illustrating the code and explanations generated by BOR.
framework enhances the modeling process and generates actionable, comprehensible explanations. Furthermore, we establish the first industrial benchmark for evaluating explanation quality in OR. In the future, we aim to develop more accurate modeling methods to improve the accuracy while exploring effective automated evaluation techniques for explanations.
ACKNOWLEDGMENTS
This work supported by the Early Career Scheme (No. CityU 21219323) and the General Research Fund (No. CityU 11220324) of the University Grants Committee (UGC), and the NSFC Young Scientists Fund (No. 9240127).
10

---

Published as a conference paper at ICLR 2025
REFERENCES
Zeina Abu-Aisheh, Romain Raveaux, Yves Ramel, and Patrick Martineau. An exact graph edit distance algorithm for solving pattern recognition problems. 4th International Conference on Pattern Recognition Applications and Methods 2015, 2015.
Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Ale- man, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, al. Gpt-4 technical report. arXiv preprint arXiv:2303 237704444.. 2023.
Ali AhmadiTeshnizi, Wenzhi Gao, and Madeleine Udell. Optimus: Scalable optimization modeling with (mi) Ip solvers and large language models. arXiv preprint arXiv:2402.10172 2024.
Bob Bixby. The gurobi optimizer. Transfp. Re-search Part B, 41(2):159-175) 2007.
Yi Chen, Rui Wang, Haiyun Jiang, Shuming Shi, and Ruifeng Xu. Exploring the use large language models for reference-free text quality evaluation: An empirical study. arXiv preprint arXiv:2304.00723, 2023.
Cheng-Han Chiang and Hung-yi Lee. A closer look into using large language models for automatic evaluation. In Findings of the Association for Computational Linguistics: EMNLP 2023, pp- 8928-8942, 2023.
KuanChao Chu, Yi-Pei Chen, and Hideki Nakayama. better Ilm evaluator for text generation: The impact of prompt output sequencing and optimization. arXiv preprint arXiv:2406.09977 2024.
IBM ILOG Cplex. V12. I: User's manual for cplex. International Business Machines Corporation, 46(53):157, 2009.
Kristijonas Cyras, Dimitrios Letsios, Ruth Misener, and Francesca Toni. Argumentation for explain- able scheduling. In Proceedings of the AAAI Conference on Artificial Intelligence, pp. 2752-2759, 2019.
Koen W De Bock, Kristof Coussement, Arno De Caigny, Roman Stowiñski, Bart Baesens, Robert N Boute, Tsan-Ming Choi, Dursun Delen, Mathias Kraus, Stefan Lessmann, et al. Explainable ai for operational research: A defining framework, methods, applications, and a research agenda. European Journal of Operational Research, 317(2)249-272, 2024.
Martin Erwig and Prashant Kumar. Explanations for combinatorial optimization problems. Journal of Computer Languages, 79:101272, 2024.
Zhenan Fan, Xinglu Wang, Oleksandr Yakovenko, Abdullah Ali Sivas, Owen Ren, Yong Zhang, and Zirui Zhou. Smart initial basis selection for linear programs. In International Conference Machine Learning. pp. 9650-9664. PMLR, 2023.
Anja K Faulhaber, Ina Ni, and Ludger Schmidt. The effect of explanations on trust an assistance system for public transport users and the role of the propensity to trust. In Proceedings of Mensch und Computer 2021, pp. 303-310. Association for Computing Machinery, 2021.
Xinbo Gao, Bing Xiao, Dacheng Tao, and Xuelong Li. A survey of graph edit distance. Pattern Analysis and applications, 13:113-129, 2010.
Maxime Gasse, Didier Chételat, Nicola Ferroni, Laurent Charlin, and Andrea Lodi. Exact combi- natorial optimization with graph convolutional neural networks. Advances in neural information processing systems, 32, 2019.
Dongdong Ge. Qi Huangfu, Zizhuo Wang. Jian Wu, and Yinyu Ye. Cardinal Optimizer (COPT) user guide. https://guide.coap hwtpppppppwiiiccoo/oedeeeeeeeeee 2023,
Bryce Goodman and Seth Flaxman. European union regulations on algorithmic decision-making and "right to explanation". Al magazine, 38(3):50-57, 2017.
11

---

Published as a conference paper at ICLR 2025
Jesse T Holzer, Carleton J Coffrin, Christopher DeMarco, Ray Duthu, Stephen T Elbert, Brent C Eldridge, Tarek Elgindy, Manuel Garcia, Scott L. Greene, Nongchao Guo, et al. Grid optimiza- tion competition challenge 3 problem formulation. Technical report, Pacific Northwest Nationll Laboratory (PNNL), Richland, WA (United States), 2024.
Xinyu Hu, Mingqi Gao, Sen Hu, Yang Zhang, Yicheng Chen, Teng Xu, and Xiaojun Wan. Are llmebased evaluators confusing nlg quality criteria? arXiv preprint 2tl::2402.120555 2024.
Sen Huang, Kaixiang Yang, Sheng Qi, and Rui Wang. When large language model meets optimiza- tion. arXiv preprint wwXiv:245../0090 2024.
Neehar Kondapaneni, Markus Marks, Oisin Mac Aodha, and Pietro Perona. Less is more: Dis- covering concise network explanations. In ICLR 2024 Workshop on Representational Alignment, 2024.
Beibin Li, Konstantina Mellou, Bo Zhang, Jeevan Pathuri, and Ishai Menache. Large language models for supply chain optimization. arXiv preprint 000::3307.38755555 2023.
Mahdi Mostajabdaveh, Timothy T Yu, Rindranirina Ramamonjison, Giuseppe Carenini, Zirui Zhou, and Yong Zhang. Optimization modeling and verification from problem specifications using a multi-agent multi-stage Ilm framework. INFOR: Information Systems and Operational Research, pp. 1-19, 2024.
Rindranirina Ramamonjison, Timothy Yu, Raymond Li, Haley Li, Giuseppe Carenini, Bissan Ghad- dar, Shiqi He, Mahdi Mostajabdaveh, Amin petition: Formulating optimization problems based on their natural language descriptions. In NeurlPS 2022 Competition Truck, pp. 189-203. PMLR, 2023.
Zirui Zhou, et al. NI4opt com-
Andrew Selbst and Julia Powles. "meaningful information" and the right to explanation. In confer- ence on fairness, accountability and transparency, pp. 48-44-444 48. PMLR, 2018.
Michael Stauffer, Thomas Tschachtli, Andreas Fischer, and Kaspar Riesen. A survey on applica- tions bipartite graph edit distance. Graph- Representations in Puttern Recognition: 1ith IAPR-TC-IS 115 International Workshop, GbRPR 2017, Anacapri, Italy, May 16-18, 2017, Pro- ceedings 11, pp. 242-252. Springer, 2017.
Zhengyang Tang, Chenyu Huang, Xin Zheng, Shixi Hu, Zizhuo Wang, Dongdong Ge, and Benyou Wang. Orlm: Training large language models for optimization modeling. arXiv preprint
arXiv:240S.17743 2024.
Arthur Thuy and Dries F Benoit. Explainability through uncertainty; Trustworthy decision-making with neural networks. European Journal of Operational Research, 317(2):330-340, 2024.
Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Hassan Awadallah, Ryen W White, Doug Burger, and Chi Wang. Autogen: Enabling next-gen Ilm applications via multi-agent conversation framework. In COLM, 2024.
Ziyang Xiao, Dongxiang Zhang, Yangjun Wu, Lilin Xu, Yuan Jessica Wang. Xiongwei Han, Xiaojin Fu, Tao Zhong, Jia Zeng, Mingli Song, et al. Chain-of-experts: When lims meet complex opera- tions research problems. In The Twelfth International Conference on Learning Representations, 2023.
Linzi Xing, Xinglu Wang, Yuxi Feng, Zhenan Fan, Jing Xiong, Zhijiang Guo, Xiaojin Fu, Rindra Ramamonjison, Mahdi Mostajabdaveh, Xiongwei Han, et al. Towards human-aligned evaluation for linear programming word problems. In Proceedings of the 2024 Joint International Confer- ence on Computational Linguistics, Language Resources and Evaluation (LREC-COLING 2024), pp. 16550-16556, 2024.
Jihai Zhang, Wei Wang, Siyan Guo, Li Wang. Fangquan Lin, Cheng Yang, and Wotao Yin. Solving general tettteei-anguuggedeeerripitnonnn optimization problems with large language models. arXiv preprint (.XXi:24007.09224 2024.
Alexandra Zytek, Sara Pidò, and Kalyan Veeramachaneni. Llms for xai: Future directions for explaining explanations. arXiv preprint arXiv:2405.06066 2024.
12

---

Published as a conference paper at ICLR 2025
A APPENDIX
A.1 THE COMPARISON BETWEEN WHAT-IF ANALYSIS, SENSITIVITY ANALYSIS, AND DECISION INFORMATION ANALYSIS
What-if Analysis: What-if analysis explores the impact of changing conditions, including param- eters, on overall outcomes, allowing users to adjust inputs to observe potential scenarios manually. This approach emphasizes scenario exploration macro level, helping users understand how dif- ferent "what if"" situations might influence results without delving into specific details.
Sensitivity Analysis: Sensitivity analysis measures how minor variations in input parameters affect the model's output, identifying which inputs have the most significant influence on results. This method provides detailed quantitative insights into the effects of parameter changes, making par- ticularly effective in optimization contexts where analytical solutions can be derived.
Decision information analysis extends sensitivity analysis by fo- cusing on how changes in constraints impact decision-making and outcomes. This approach exam- ines the sensitivity of the model to variations in constraints, identifying key decision factors while also capturing the broader implications of both constraint and parameter changes, particularly in complex optimization problems without analytical solutions.
Decision Information Analysis:
In summary, decision information and sensitivity analysis are more detailed, with the former center- ing on decision-related changes (constraints or parameters) and the latter on parameter sensitivity, while both can be part of a broader what-if analysis framework. Previous research has predominantly focused on sensitivity analysis through the simplex method, which is recognized for its efficiency, precision, and ability to provide analytical solutions. However, the simplex method has limitations in evaluating the effects of changes to constraints. In contrast, our proposed approach leverages bipartite graphs to assess the impact of constraint modifications, addressing this gap and providing more generalized solution.
A.2 PROMPT TEMPLATE DESIGN
A.2.1 PROMPT TEMPLATE FOR WRITER AGENT
The prompt template for Writer with system message for the ChatCompletion inference:
WR URITER_SSYOE BTTTTRRSSSSSSSSSSSSSS
*oole:** You chatbot tasked with:
(1) Writing Python code for operations research-related projects.
(2) Explaining solutions using the Gurobi Python solver.
--- Froblem Description:
(descripticn)
10 Source Code: (source_code)
11
Documentation: (doo_str)
15
16 Example Q6A: (example_qa)
19 Original Execution Result: [execution_reaul;;
20
23
**Task***
24
You are provided with the original problem description and the correct
+ code for an operations research problem. Based on the user's s query,
update the code accordingly. Your task may involve either deleting constraints adding new data constraints.
13

---

Published as a conference paper at ICLR 2025
26
27
Steps:*4
28
1. Determine the Required Operaticns:
**Add Operation:** Generate new code for data or constraints to be 31
+ added.
32
Insert the new data between the markers:
"# EORer DATA CODE GOES HERE" and "# ECRer DATA CODE ENDS HERE".
Insert the new constraints between the markers:
35
"# BORer CONSTRAINT CODE GOES HERE" and "# BORer CONSTRAINT CODE
4 ENDS HERE".
**Delete Operation:** Identify the relevant block within the () constraints section that needs to deleted.
38
-The code to be deleted will be between the markers:
39
"# EORor CONSTRAINT CODE GOES HERE" and "# EORer CONSTRAINT CCDE ENDS HERE".
41
2. Return the Changes JSON Format:
42
Use the keys "DELETE CONSTRAINT", "ADD CONSTRAINT", "ADD DACA".
Only these keys allowed.
44
The values should be the Pythen code snippet to be deleted (exactly 4 as it appears in the original code) or the new code to be added. Include comments within the code snippets using the prefix "F" Ensure the line breaks and indents of the code are correct.
45
48
3. Output Requirements:
49
Return only the JSON object with the changes.
Do not include any additienal information in the response.
52
Do not add new decision variables.
53
Ensure the JSON is valid, properly formatted.
54
Thee above explained instructions are your guide accorplist the task effectively. Your user's success heavily relies upon your ability + to provide the precise and accurate Python code changes within the + existing operatiens research problem. Good Luck!
The prompt template for Code (2):
CODE_PROMES H
**Role:** You are professional software devel oper tasked with handling code modi fication requests. Your role is to interpret these requests which describe changes needed in source code.
**Task:** Your task is to return the changes to be made to the source code based the user's query. The modification should be returned in JSON format containing only the necessary changes.
JSON Format Requirements:**
11
Use the keys "DELETE CONSTRAINT", "ADD CONSTRAINT", or "ADD DATA".
4 Only these keys are allowed.
The values should be the Pythen code snippet to be deleted (exactly
+ it appears in the original code) or the new code to be added. Include comments within the cede snippets using the prefix "
14

---

Published as a conference paper at ICLR 2025
Ensure the line breaks and indents of the code correct.
15
16
Output Roquircments:**
Return enly the JSON object with the changes.
20
Do not include any additional information in the response.
21
Do not add new decision variables.
22
Ensure the JSON is valid, properly formatted.
25
The above explained instructions are your guide to accomplish the task
+ effectively. Your user's success heavily relies upon your ability
+ to provide the precise and accurate Python code changes within the existing operations research problem. Good Luck!
26
27
28
Answer Code:
The prompt template for Debug (2):
**Role:** You are professional code debugger.
**Task:** Identify and fix the error in the code, ensuring the corrected version smocthly and error-free.
Detailss:
Error Type: (error_type)
Error Message: (error_message)
12
13
*=Intruuticns:**
Please analyze the details, resolve the bug based the type and message provided, rewrite the corrected version the code snippet below.
16
Correcced Code:**
19
NEW CODE
20
21
The prompt template for Interpreter (6):
INTERPRETER PROMPT "*.
**Roee:** You are skilled interpreter with expertise in analyzing and explaining changes in computational model code and their effects results.
**Task:** Present clear and thercugh explanation of the code updates and their effects the results. Structure your explanation in key parts: Explanation of the updated code Explanation the Query on Results.
Innutss***
15

---

Published as a conference paper at ICLR 2025
Original code: (source, code)
11
Updated code: (new_code)
12
Code changes induced by the query; [json_data)
Original execution results: [origina__xccutionrrooalll
New execution results: (execution_rst)
Measure of numerical changes in the model induced by the query: 4 different_model]
16
KeY Points to Understand:**
20
1. Explanation of Updated code:
21
Explain the rationale behind each specific change to the code, such why certain constraints data added, deleted, + modified.
23
24
2. Explanatien of the Query on Results:
Clarify why the specific results were produced in response the 4 query.
27
Assess the query's impact en the results by comparing the new
+ execution results with the original ones and the corresponding numerical changes in the model.
28
Use a scale from to 10 to quantify the query's s impact on the
+ results, with 1 indicating minimal impact and 10 indicating
F significant impact.
31
BBBckground for Numerical Changes Calculation:*
32
33
The impact of the query is measured using threc-step precess:
1. LE Conversion: The problem is converted into a linear programning
+ LP) format identify key components and constraints.
35
2. Graph Representation The LP model then represented as
4 bipartite graph, where nodes and edges correspond to variables,
+ constraints, and relationships.
3. Graph Edit Distance Calculation: The difference between the
+ original and modified graphs is computed by measuring the graph
+ edit distance, which involves operations like insertion,
+ deletion, and substitution of nodes and edges, each with unit
cost of 1.
37
38
39 Output:**
Provide the explanations in distinct parts:
42
(1) Explanation of the Updated code
43
(2) Explanation of the Query on Results
Requi rM
47
48
Ensure the explanations are detailed and comprehensive, covering all
④ relevant aspects of the code updates and their impact on the results.
49
Ensure that explanations are delivered in a narrative style, suited
4 for a non-technical audience, avoiding jargon or direct
4 references to specific variable names.
Offer clear, precise, tondttoundd descriptions that effectively bridge complex information with clarity and insight.
51
52
The above explained instructions your guide to accomplish the task effectively. Your user's success heavily relies upon your ability
16

---

Published as a conference paper at ICLR 2025
to provide the explanations within the existing operations research problem. Good Luck!
54
35
HUMAN READABLE ANSWER
58
A.2.2
PROMPT TEMPLATE FOR SAFEGUARD AGENT
The prompt template for Safeguard with system message for the ChatCompletion inference:
SAFEGUARD_SYSTEM w*.
*oolc:** You are code safety evaluator.
**Task:** Review the provided scurce code to determine if it is safe to + execute, ensuring it does not contain any malicious code that could compromise security privacy.
** isstttonto
Source Code: [source_code]
13
14
**Question:**
Is the code safe to run?
**sser****
18
Respond with one word:
19
'SAFE," if the code is secure.
'DANGER it the code poses any risk.
22 n*.
The prompt template for Safe (4):
SAFEGUARD_ PROMPT u..
**Role:** You are professional code safety evaluator.
**Task** Examine the safety each code snippet contained within provided JSON file.
**Details:*x
11
Code Structured as JSON:** Each value in the JSON represents 4 code snippet intended for review. These snippets may be newly generated under consideration for deletion.
13
14
+ InIstructions:
Thoroughly analyze each code snippet found in the JSON. For each snippet, determine safety for execution. Provide your assessment as a single word for each snippet: either
17
18
+ SAFE" or "DANGER".
17

---

Published as a conference paper at ICLR 2025
ExEample Expected Response:** Eor snippet 1: SAFE, for snippet
DANGER
22
23
Answer:
26
A.3
AN EXAMPLE OF BENCHMARK
The original problem description and the result of this problem:
Problem Description:
An airline operates two types of aireraft: large aireraft (Type A) and small aireraft (Type B). Each type of aircraft has different operating costs and passenger capacities. The company needs to determine the number of each type of aircraft operate in order to meet the demand of transporting at least 10,000 passengers. Specifically, one Type A aircraft can carry 500 passengers, and one Type aircraft can carry 200 passengers. However, due the use and maintenance requirements of the aircraft, the total number of Type A and Type B aircraft operated cannot exceed 50. The cost of operating one Type aircraft is $10,000, and the cost trgtgof operating one Type B aircraft is $5,000. Due to the indivisibility of the aircraft, both types of aircraft must be operated in integer quantities. Under these conditions, what is the minimum total cost that satisfies the passenger transportation demand while adhering to the operational restrictions? Please round the answer to the nearest integer.
Problem Result: 200000.0
The original Python code with Gurobi:
import gurcbipy as gp from gurobipy import GRB
5
Parameters Section Begin Define model parameters aircraft_types ['A', (B"]
6
Passenger capacity per aireraft type baasenger_capacity
10
11
'A': 500,
'B': 200
15
Operating cost per aircraft type (dollars) cost_pper_iirrrftt = 'A': 10000, 'B': 5000
18
19
20
Minimum passenger demand
22
hii__pasenger_demaat
10000
23
24
# Maximum number of aircraft
max www.aarrrf__ccunt = 50
Parameters Section End
27
28
29
BORer DATA CODE GOES HERE
18

---

Published as a conference paper at ICLR 2025
EORer DATA CODE ENDS HERE
33
34
35
Create a Gurobi model gp.Model ("Airiineppttiiiaaiiioo
Decision Variables Section Begin
39
Create decision variables a and b for the number of large and small 4 aircraft respectively aircraft_count
'A': m.addvar (stype-GRB. INTEGER, name-"aircraft_A)) 'B': m.addvar (vtype=GRB, INTEGER, name-Maircraft_i))
42
43
Decision Variables Section End
46
47
objective Function Section Begin
48
set the objective function to minimize total operating cost setbb
gp-quicksum(
51
parpaaiinn_cst__errrrrrrrr for t in aircraft_types
aireraft_count
52
)
MRMNE=GRB.MINIMTEE
55
56
Objective Function Section End
EORer CONSTRAINTS CODE GOES HERE
61
62
Constraints Section Begin
Constraint: Meet the passenger transportation demand m. addConstr(
64
65
aircraft_counte
66
for t in aircraft_types) >- min_
name Tamm=rrrssssgrreennnnccctrria
69
70 Constraint: The total number of aircraft cannot exceed the maximun
+ allowed
addConstr(
72
gp. www.quucksumiireraatt...mm
[t]
73
for t in aircraft_types)
max_aircraft_coutt,
74
name= rame=
Constraints Section End
77
78
BORer CONSTRAINTS CODE MIDDLE HERE
82
BORer CONSTRAINTS CODE ENDS HERE
83
Solving the Model Section Begin solve the model
87
m. optimizc ()
83
Output the results if m.status
OPTINAL
91
print (f"Minimum total cost: (m ObjVal)) dollars")
92
for in Aurcraft_typer print NNubber of Type (t) aircraft: |aircraft_count [t).x)")
else:
19

---

Published as a conference paper at ICLR 2025
print ("No opt imaal solution found.") Solving Model Section End
96
The queries and truth labels of these updated problems with new queries:
Query I: How should the number of aircraft be adjusted to maximize economic efficiency if the operating cost of the large aircraft (Type A) is reduced to $8,000?
Truth Label 1: 160000.0
Query 2: How should the number of aircraft be reassessed meet transportation demand if the passenger capacity of the small aircraft (Type B) increases to 250 passengers?
Truth Label 2: 200000.0
Query How should the aircraft configuration be adjusted maximize profit if the operating cost
+ of the Type B aircraft decreases to $4,000 and the passenger capacity of the Type A aircraft increases to 550 passengers?
Truth Label 3: 184000.0
Query 4: How should the number of aircraft be adjusted maintain minimum total cost if the operating costs both Type and Type B aircraft increase by 10%?
Truth Label 4: 220000.0
12
Query 5: How should the aircraft configuration be adjusted meet demand if the company decides
+ to limit the number of Type A aircraft operated to no more than 15 and the number of
Type B aircraft more than 30?
Truth Label 5: 215000.0
Query 6: How should the number of aircraft be adjusted to maintain demand if the passenger capacity of the Type A aircraft decreases 450 passengers and the operating cost of the Type B aircraft increases to $6,000?
17
Truth Label 226000.0
19
Query How should the number of aircraft adjusted to maximize transportation efficiency if the passenger capacity of the large aircraft increases to 600 passengers and the cost of the + small aircraft increases to $5,500?
Truth Label 7: 170000.0
21
22
Query How should the number of aircraft be arranged to meet passenger demand and minimize + costs if the airline needs to operate at least 10 Type aircraft?
23
Truth Label 210000.0
24
25
Query How should the number of aircraft adjusted maintain economic efficiency the passenger capacity of the small aircraft (Type B) decreases to 150 passengers and the cost of the large aircraft (Type A) increases to $12,000?
Truth Label 9: 240000.0
27
Query 10: How will the optimal aireraft configuration change if the constraint that the total number
+ of Type A and Type B aircraft operated cannot exceed 50 is removed?
Truth Label 10: 200000.0
A.4 HYPERPARAMETER SENSITIVITY ANALYSIS
This section analyzes the sensitivity of two hyperparameters, temperature and debug times, to eval- uate their impact the model's reliability and stability.The temperature reflects the reliability of the model's outputs, while debug times assess its performance stability. The experimental results are summarized in Tables [adde
Table 4 shows that our model maintains reliable outputs across temperature settings of O, 0.5, and in both zero-shot and one-shot scenarios. This demonstrates the model's robustness in generat-
20

---

Published as a conference paper at ICLR 2025
ing consistent and precise outputs under varying temperature configurations, which is particularly important for tasks demanding factual accuracy, such as OR modeling.
Table 5 reveals that increasing the number of debug attempts from 3 10 does not significantly improve performance. Additional iterations primarily consume resources without yielding better results, reflecting the model's limited self-correction capabilities. This suggests that external inter- ventions, such as user feedback, may be necessary to enhance performance further.
In summary, the model exhibits strong reliability across different temperature settings and consistent stability regardless of the number of debugging attempts. These findings underscore the robustness of our approach in delivering reliable and stable performance.
Table 4: Accuracy under different methods in zero/one-shor setting with different temperature. The bold scores are the best each row.
Temperature
Method
0.5
OptiGuide EOR
30.33 %
22.00%
26.33%
Zero-shot
88.33%
89.67% %
88.00%
OptiGuide EOR
69.33% 95.33%
70.00 93.67%
68.33%
One-shot
93.33%
Table 5: Accuracy under different LLMs in zero/one-shot setting with different debug times. The bold scores are the best in each row.
Debug times
Method
3
10
GPT--4-1066previev
81.67 %
81 31.33%
Zero-shot
GPT-4-Turbo
88.33%
89.00 %
GPT-4-1106-preview
87.67% %
87.67 %
One-shot
GPT-4-Turbo
95.33%
95.33 %
A.5 PROMPT TEMPLATE FOR EVALUATING THE EXPLANATIONS
**Role:** You are an expert in Operations Research evaluating
+ explanations provided by three different models: 'EOR', 'OptiGuide and 'Standard', Your role is to assess the quality of these explanations based
query.
** IxIntu:***
User Query: (query)
Explanations by EOR: (EOR)
Explanation by OptiGuide: (optiguide)
10
Explanations by Standard: (standard)
11
*+aak:** For each model, provide three scores:
14
15
1). Score 1 Explanation of Updated Code:
How clearly does the explanation describe the code medifications made response the query? If explanation of code updates is 4 provided, sccre 0.
17
2). Score 2 Explanation of Query on Results:
How well does the explanation clarify why and how the results changed due the query? Focus on the depth of the explanate anationn
21

---

Published as a conference paper at ICLR 2025
particularly the quantitative reasoning behind the changes, just description the result.
20
21
3) Score 3
Overall Score:
Based en the previous scores, assign overall score (0-10) reflecting the combined quality and effectiveness of the 4 explanation.
23
24
Scoring Criteria:**
27
Scores should range from (peor) to 10 (excellent) for each + category.
Consider the overall clarity, conciseness, and structure. The explanation should easy follow and understand.
29
30
31
Output JSON Format:**
Only return the results in the JSON format.
The keys should be 'BOR', 'OptiGuide', and 'Standard Each key should have list with the three scores (0-10).
35
36
Do not include any additicnal information or comments in the response.
39
38
39
Your evaluation will help determine which model provides the most effective and clear explanations for the given query. Good Luck!
41
42
Answer:
43
A.6
CASE STUDY
The comparison of code and explanations generated by different models are shown in Figure 4 and respectively.
5
As shown in Figure FOR returns a code snippet in JSON format, OptiGuide provides code snippet, and Standard returns the complete code for the entire problem. Although Standard achieves better experimental results than OptiGuide, its modification and return of the entire code signifi- cantly increases maintenance costs, making it challenging to track changes. OptiGuide provides markers to guide code modification larger models, but experiments have shown that these mark- sometimes removed, complicating efforts to identify what and where changes were made. In contrast, the code format proposed in our paper enables targeted updates at specific locations while ensuring markers remain intact. This only reduces maintenance costs but also, when paired with clear explanations, simplifies the identification of both the location and nature of code updates.
As shown in Figure [ both Standard and OptiGuide generate explanations that mainly describe results and provide a brief analysis of changes in solution outcomes. Still, they lack quantitative analysis, especially concerning the impact of implicit query changes on the model. These expla- nations align more closely with the attribution explanation, as defined in our paper. In contrast, our approach emphasizes the justification explanation, which not only explains and analyzes code updates but also provides quantitative analysis of the impact of constraint changes the model.
A.7 FAILURE CASES
To understand the strengths and weaknesses of EOR, we analyzed common failure cases, summa- rized in Table 6 These failures can be grouped into three categories: JSON format errors, where the LLMs fail to generate correct JSON outputs; correct execution, where code runs but produces incorrect results due to modeling logic errors incomplete modeling; and runtime errors, such as
22

---

Published as a conference paper at ICLR 2025
variable name errors, syntax errors, indentation errors. Table 6 shows 60.00% reduction in total errors from zero-shot to one-shot, demonstrating a substantial improvement in the model's per- formance. No syntax emrors in the one-shot results highlights the effectiveness of EOR. However, ongoing attention to modeling logic and runtime errors is still crucial for further improvement.
Table 6: Failure cases on GPT-4-Turbo with zero/one-shot setting.
Zero-shot (Total 35)
One-shot (Total 14)
Failure Types
#Number
Percentage
#Number
Percentage
JSON Format Errors
8
22.86%
2
14.29%
Modeling Logic Errors
13
37.14%
4
28.57% %
Correct Execution
Incomplete Modeling
4
11.43%
14.29% 2
Variable Name Errors
2
5.71%
3
21 21.43%
Runtime Errors
Syntax Errors
6
17.14%
0
0.00%
Indent Errors
2
5.71%
21.43% 3
23

---

Published as a conference paper at ICLR 2025
Comparison of Code Generated by Different Models.
Query: How should the aircraft configuration be adjusted to meet demand if the company decides limit the number of Type aircraft operated than and the number of Type B aireraft no more than 30?
EOR:
"ADD CONSTRAINT"; "# Constraint: Limit number of Type and Type aircraft Amm addConstr
htw.rrantttnnnaaaonntttsrrraaa aaw.aadnttttrrrrrrraaaattaa (aircrafttcoont <= 15, name "faxTypecCosttrinnt""" \nm-addoostt (aircrafttcountt 30, name= (Wwatyyeecoooottrraaattt
OptiGuide:
"I Additional constraints for the maximum number of Type and Type B aircraft aartttnnaaddde
wtw.rraatnnannaesssnttttreet addCenstC (aircrfftott ['A'] <= 15, name=\" MaxAircraft \mm addonnstr (aircraft_ ['B'] 30, "MaxAircraft_ B\")
Standard:
"import gurcbipy gp gurobipy import GRB\n\nt Parameters Section Begin'nt Define model parameterslnairorrafe types
A', 'B' An Passenger capacity per aircraft type1
cerssonger_cpaaclnn = (An 'A: 500, An r3': A00An)Annnt
Operating cost per aircraft type (dollars))
('n 'A': 10000, An 'B': 5000 Annnn Minimum passenger demand'nnin hwwddd/iinnssseee_eeeeeee geeeanngrr_demand
noperating_cot__e__iiiico
10000\n\nt Maximum number of aircraft for Type A and Type B\
Parameters Section End)nint Create B 30Anf
nmax wwmx_aarcrrattcome cot___oou_____ 15 wtwp//airrrttttteaee
Gurobi model
gp
\n\n# Decision
Variables Section Begin\nl Create decisicn variables for the
number of large and small aircraft respectively,.
naircraft_coune (An 'A'
INTEEEE INTEGER,
=\"aircraft_A\"", "B': a.dvva (vtype=GRB. INTEGER, name=\" aircraft_B\"))m Decision Variables Section EndAnAnt
Objective Function Section Begin\nt Set the objective
function to minimize total operating cost\nn. set v (An gp.quicksum (An wtwpraaiinnostt_eeeeaaeeeee
aircraft_coune [t] for t aircraft_types'a ), An sense=G33. MINIMIZEAn) \n# Objective, Function Section Knd\nnnt
Constraints Section ReginAnt Constraint: Meet the passenger add.doonstddrrrrrrooo.oooooo.o.e (\n qpickcckkum aarennger_appcctylltt aircraft sircraft_count/tt
transportation
for t in
aircraft types) >= min passenger demand, \n name=\"
demand, TassengerDemnndoontrraattt \'n) \n\nt Constraint: The number of Type A aircraft cannct exceed 15\nm.
aircraft_count ['A'] <= max_aireraft_count.. An name=\"
TypeAConstraint \\n) \n\nt Constraint: The number Type
aircraft cannot exceed 30 aircraft_count [33]] An
An# Constraints Section End Solving the Model Section Begin\ n# Solve the model \nm imtieize AnAnt Output the results\nit m.stus GRB. ARB.OPTIMAL:VE \n print (1) (Opmmmzzde minimal total cost with new contiguration: [round (m. Obival) dollars for t in aircraft_types: An print (f NNmberr of Type (t)
<= max max_sircraft_ccunt
aircraft: (aircraft_coune [t] X)A") \nelse: An print (\ optimal solution found. \") Ant Solving the Model Section End"
Figure 4: An example illustrating codes generated by different models. 24

---

Published as a conference paper at ICLR 2025
Comparison of Explanations by Different Models.
Query: How should the aircraft configuration be adjusted to meet demand if the company decides to limit the number of Type A aircraft operated to no more than 15 and the number of Type B aircraft to no more than 30?
EOR: **Explanation of Updated Code:
The updated code includes new constraints that implement operational limits on the numher of Type A and Type B aircraft the airline use. Specifically:
constraint has heen added limit the number of Type A aircraft to 15.
A constraint has been added limit number Type B aircraft to
These additional constraints are motivated by possibly new operational limitations or strategic decisions, such as maintenance availability or cost considerations. By imposing these restrictions, the model must now find an optimal solution within more constrained operational environment.
""xplanatioon of the Query on Results:**
The query specifically asked to adjust aircraft configurations within newly defined limits. The original model found an optimal solution minimum cost of $200,000, However, with the added constraints, the solution space is reduced fewer configurations of aircraft available meet the passenger demand.
As a result of these constraints: The new optimal cost calculated by the model rose to $215,000. This increment indicates that the more stringent operational limits forced the use of a costlier configuration. The query's impact the results substantial, illustrated by $15,000 increase in operational costs. If rated scale from 10, the impact could be quantificd around This rating reflects significant changes operational costs and constraints.
The numerical changes in the model, calculated as 100, follows from step-by step-by-step process analyzing the modifications in the linear programminn representation and their effects on the resulting computa- tional graph. This method, grounded in operations research analysis, validates the substantial impact query-driven modifications.
In summary, the changes to the code (limiting aircraft types) constrained the model significantly, lead- ing to more expensive operational solution. The rationale behind integrating these specific con- straints could be associated with world operational limits, reflecting the complex decision-maie making processes airlines undergo balance cost, capacity, and operational feasibility.
The optimization problem was re-solved with additional constraints limiting the number of Type A aircraft to no more than 15 and Type aircraft to no more than 30. The new configuration resulted in a total operating cost of $215,000. When compared to the original solution, where the total operating cost was $200,000, this new configuration increased the operating costs by $15,000 due to the more restrictive constraints on the number and types of aircraft deployed. This demonstrates the trade-offs between operational flexibility cost.
OptiGuide:
Standard: Based on the updated constraints where the maximum number of Type A aircraft limited to 15 and Type B aircraft to 30, the revised optimization solution results in total operating cost of $215,000. This is an increase from the original scenario, due to the restrictions of aireraft which limited the company's 's ability opt for the least expensive configuration passenger demand. this setup, solution ensures passenger requirements are met while respecting the new operational limits placed on the aircraft types.
the number
Figure 5: An example illustrating explanations generated by different models.
25


Reviews:
[{"review_id": "zWbURFK38r", "reviewer": "Reviewer_ko7t", "summary": "The authors introduce a framework emphasizing actionable and understandable operational research explanations. They explore how constraints affect decision-making and introduce an industrial benchmark to assess the effectiveness of explanations in operational research.", "questions": "Dear authors, \n\nWe consider the research relevant and interesting. Nevertheless, we would like to point to some improvement opportunities:\n\nGENERAL COMMENTS\n\n(1) - We encourage the authors to strengthen the related work considering works related to explainability for operations research. E.g., (a) De Bock, Koen W., et al. \"Explainable AI for operational research: A defining framework, methods, applications, and a research agenda.\" European Journal of Operational Research 317.2 (2024): 249-272. and (b) Thuy, Arthur, and Dries F. Benoit. \"Explainability through uncertainty: Trustworthy decision-making with neural networks.\" European Journal of Operational Research 317.2 (2024): 330-340. Furthermore, the authors could briefly reference explainability metrics mentioned in the literature relevant to this work.\n\n(2) - The authors compare the proposed method only against the OptiGuide baseline. Are there any additional baseline methods they could compare to?\n\n(3) - Do the results reported for Auto vs. Expert only consider the cases when the LLM did not display any kind of errors? Do the scores degrade if considering cases with errors vs. the ones displayed by the baseline model?\n\n(4) - In Section 4.7, the authors provide detailed insight into the failure cases for the proposed method. What are the failure ratios for the baseline method and error typification? Is the proposed method more reliable in this regard? Could the authors increase the number of executions? For example, having two failures in 14 executions is different from observing the same proportion in 100 runs. \n\n(5) - One of the key contributions of the paper is the creation of a new industrial benchmark dataset specifically tailored to assess the effectiveness of explanations in OR. We would invite the authors to introduce it in greater detail: (a) how was the data obtained?, (b) what tasks were considered and why?, (c) how were the queries created/what experience informed the queries creation and how it was validated that they capture a wide range of scenarios?, (d) what metrics are considered in the benchmark and what is their underlying rationale?, (e) are there any other benchmarks in the field or close domains that should be considered (e.g., to draw inspiration)?, (f) is the benchmark published/will be published?\n\n(6)- The authors mention two aspects being measured to assess the quality of explanations: attribution and justification. We would appreciate some examples of how such explanations look and how they are assessed for correctness. \n\n(7)—One of the framework's key contributions is the generation of actionable explanations. Nevertheless, we miss a thorough evaluation of this aspect in the explanations generated. Furthermore, it is unclear to us whether this aspect was also included in the proposed benchmark.\n\n(8) - One of the paper's key contributions is the concept of Decision Information and its quantification. Nevertheless, no results have been reported on it. Do the authors consider that reporting it could enhance the understanding of their research work and provide an additional perspective to the ones already exposed in the manuscript?\n\nFIGURES\n\n(9) - Figure 3: We encourage the authors to provide a brief explanation of what the green/yellow highlighted explanations mean. Do they refer to attribution and justification explanation aspects?\n\nTABLES\n\n(10) - Table 2: in the caption, please indicate what does bolding the results mean\n\n(11) - Table 3: highlight the best results (e.g., by bolding them)\n\n(12) - All tables reporting metrics: provide arrows next to the metric names (up/down) indicating whether a higher/lower result is better.", "limitations": "", "rating": 8, "confidence": 4, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "- The authors tackle a relevant real-world problem\n- The authors explore the intersection of explainability for operational research and LLMs - a hot topic right now", "weaknesses": "- the authors compare their method against only one baseline\n - while one of the key contributions is the development of a benchmark dataset, it is not clear how the data was gathered or what tasks and metrics are considered for it. While some are mentioned, they are not described in detail. \n - the authors mention the concept of decision information as one of the pillars of explainable operational research. Nevertheless, it is unclear whether results were reported for it.\n - while the authors claim that their framework enables actionable and understandable explanations, they only assess the quality of explanations considering attribution and justification explanations, with no reference to evaluating whether and how actionable the explanations are.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "kyuG86aP0r", "reviewer": "Reviewer_1vGE", "summary": "This paper proposes a LLM-based explainable operations research (EOR) framework and evaluates it on a benchmark they created. EOR is a multi-agent framework that starts with a user query and generates an OR program (for Gurobi optimization solver), uses the program to solve the problem and generates explanations of the code as well as answers using LLMs. The experimental evaluation of accuracy and explanations shows that EOR outperforms two baselines.", "questions": "1. Are the ground truth expert ratings on the quality of explanations part of the benchmark?\n2. Why is Table 3 missing some cells?", "limitations": "", "rating": 6, "confidence": 3, "soundness": 3, "presentation": 2, "contribution": 3, "strengths": "1. The paper proposes a novel use of LLMs for explainability in the field of Operations Research. The experiments show that such approach is effective as per the ratings given by LLMs as well as human OR experts.\n2. Example 3 is quite useful in understanding the task as well as the output of EOR.", "weaknesses": "1. While the paper reads well, some parts are not very clear. In particular:\n - It is not clear how the decision information, the bi-partite graph, the edit distance computation etc. is connected to LLMs. What does `Since LLMs cannot directly perform this quantification, we utilize them to sense these processes and generate explanatory insights.` exactly translate to in figure 2?\n- The section 3.1 on problem formulation focusses on explanations. What is the approach/innovation for modeling that translates to improved modeling accuracy in Table 2?\n2. The dataset is not shared, the paper states `Notably, the question sets and the queries in this benchmark are developed from scratch and managed in-house`. Would it be made available publicly? Does `developed from scratch` mean manual creation?\n3. If EOR enhances the modeling process, could you compare modeling accuracy on other public benchmarks?", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "zQjGeTD4f3", "reviewer": "Reviewer_iVAa", "summary": "The work introduces a framework called Explainable Operations Research (EOR) that aims at enhancing transparency in Operations Research (OR) models that incorporate Large Language Models (LLMs). The authors argue that, despite the prevalence of LLMs in OR, the lack of explanations represents a problem. EOR addresses this gap by introducing the concept of “decision Information”. This workflow involves three LLM agents to generate answers to user queries and corresponding explanations. The authors show that their method outperforms other methods in terms of quality of answers and explanations provided.", "questions": "Posted as part of weaknesses.", "limitations": "", "rating": 5, "confidence": 2, "soundness": 2, "presentation": 2, "contribution": 2, "strengths": "The paper makes a focused contribution by addressing a niche problem: explainability in OR. While this fits within the broader category of explainability for LLMs, the specificity of this context is important. The presentation is for the most part clear (but see below), and the agentic workflow proposed could be practically useful for practitioners.", "weaknesses": "Clarity and related work: The problem formulation would benefit from concrete examples to clarify what constitutes a \"problem\" and a \"query\" in the OR context. A more thorough description of OptiGuide would also help readers understand its role in the comparison. Bipartite graphs are mentioned multiple times, but it remains unclear why they are relevant or how they contribute to the framework—this needs clarification. The focus of EOR on coding tasks is not well explained, and it would be helpful to understand why this aspect is emphasized. Additionally, the paper proposes an agentic workflow but does not cite related literature; such citations should be included in the related work section.\n\nSimilarly, it’s also hard to judge the significance of the work because related work is hardly discussed. The workflow appears simple and I think that the novelty may not be enough for an ICLR paper. \n\nEvaluation results: This is the main weakness. The benchmark used in experiments is not publicly available and is poorly described, making it hard to assess the quality of the experiments. The experimental section mentions a \"proprietary LLM\" without specifying which model is used, adding ambiguity to the evaluation. The explanation quality assessment relies on LLMs, but it is unclear if any manual evaluation by the authors was performed to validate these judgments. The experimental section needs many more results; currently, it's hard for the reviewer to judge the quality of the work.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "TPhnROPACj", "reviewer": "Reviewer_iUYd", "summary": "This paper proposes a framework called Explainable Operations Research (EOR) that combines Operation Research (OR) with LLMs. This idea aims to improve the clarity and trustworthiness of decision-making processes. The ultimately expected results should be clear, actionable explanations of how changes in constraints or parameters would affect OR solutions.\n\nThe claimed contributions in this paper are: (1) the authors formulate the problem of the explainable OR problems within the context of LLMs, (2) the authors introduce the concept of \"Decision Information\" and utilize bipartite graphs with LLMs to quantify the importance, (3) the authors develop a new benchmark specifically designed to evaluate the effectiveness.", "questions": "See some of the questions above in Weakness. In addition:\n\nRegarding the benchmark (for explainability): What were the criteria for selecting the problem categories, and how comprehensive is the benchmark in terms of covering different types of OR challenges? Additionally, have you validated the benchmark with industry professionals or in practical settings to ensure it reflects real-world complexity?\n\nRegarding the system-level workflow: Have you considered how decision-makers would interact with the system and its explanations in real time? What if the system makes mistakes, can it be corrected under human supervision?\n\nRegarding the experimental setups/scalability: The paper compares EOR to OptiGuide, but have you considered comparing your work to other explainability frameworks outside the OR domain? Can this work be somehow extended to other similar domains but with different contexts, e.g., automated reasoning?", "limitations": "", "rating": 8, "confidence": 2, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "Although I am not deeply familiar with the OR domain, the integration of LLMs with OR problems seems both interesting and innovative. While I initially had concerns about the strict reasoning required for OR problems, it appears that these concerns are somehow addressed through the design choices and the experimental results presented in the paper. However, I may have missed some of the finer details of the concepts.\n\nOverall, the paper is well-presented and easy to follow. Some figures and diagrams could be simplified or made more intuitive, which would help readers with less background in LLMs or NLP better understand the concepts. In addition to the methods, the experimental setup is convincing and thorough.\n\nThe significance of this approach is clear. By using this framework, users can gain insights into critical aspects of OR problems that have often been overlooked, enhancing their understanding and decision-making.", "weaknesses": "Since developing a benchmark is listed as one of the contributions, a more detailed introduction to this benchmark is expected. It would be helpful to expand on things like why certain problem categories were selected, how comprehensive the benchmark is across various OR tasks, and whether it reflects real-world complexity. Furthermore, examples showing how the benchmark effectively measures explainability in practice would strengthen the paper. This would provide more transparency about how the benchmark can be applied and generalized.\n\nAlthough the paper presents a dual evaluation (automated and expert) to assess explanation quality, it doesn’t fully explore how well these metrics align with user needs (who are, in other words, the major user groups if it is put into real-world use). For instance, it is unclear whether the explanation quality metrics are used to capture all the necessary aspects of understandability, particularly for non-experts. Providing more insights into how the explanations are judged, probably by including user feedback or more detailed breakdowns of the evaluation criteria, would offer a stronger case for the robustness of the framework.\n\nAn analysis of computation complexity/scalability would also help strengthen the paper. I have potential concerns regarding the computational complexity of the proposed framework, especially given the use of LLMs and graph-based methods.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}]

Author rebuttal:

Decision: Accept (Poster)