SolverLLM: Leveraging Test-Time Scaling for Optimization Problem via LLM-Guided Search
Authors: Dong Li
Xujiang Zhao
Linlin Yu
Yanchi Liu
Wei Cheng
Zhengzhang Chen
Zhong Chen
Feng Chen
Chen Zhao
Haifeng Chen
Venue: NeurIPS 2025 poster ()
Keywords: MCTS
LLM
Optimization Problem
Primary area: deep_learning

Abstract: Large Language Models (LLMs) offer promising capabilities for tackling complex reasoning tasks, including optimization problems. However, existing methods either rely on prompt engineering, which leads to poor generalization across problem types, or require costly supervised training. We introduce SolverLLM, a training-free framework that leverages test-time scaling to solve diverse optimization problems. Rather than solving directly, SolverLLM generates mathematical formulations and translates them into solver-ready code, guided by a novel Monte Carlo Tree Search (MCTS) strategy. To enhance the search process, we modify classical MCTS with (1) dynamic expansion for adaptive formulation generation, (2) prompt backpropagation to guide exploration via outcome-driven feedback, and (3) uncertainty backpropagation to incorporate reward reliability into decision-making. Experiments on six standard benchmark datasets demonstrate that SolverLLM outperforms both prompt-based and learning-based baselines, achieving strong generalization without additional training.

SolverLLM: Leveraging Test-Time Scaling for Optimization Problem via LLM-Guided Search
Dong Li
Xujiang Zh Linlin Yu
Yanchi Liu?
Wei Cheng²
Zhengzhang Chen² Zhong Chen
Feng Chen
Chen Zhao Haifeng Chen
Baylor University NEC Labs America
*Augusta University
"Southern Illinois University
University of Texas at Dallas (xuzhao,
{dong_ 1i1, chen zhao} @aallaallllleeeeeeeeeeeeeeaeeeee edu
com
Abstract
Large Language Models (LLMs) offer promising capabilities for tackling complex reasoning tasks, including optimization problems. However, existing methods either rely prompt engineering, which leads to poor generalization across prob- lem types, or require costly supervised training. We introduce SolverL..M, a training-free framework that leverages test-time scaling solve diverse optimiza- tion problems. Rather than solving directly, SolverL.LM generates mathematical formulations and translates them into solver-ready code, guided by novel Monte Carlo Tree Search (MCTS) strategy. To enhance the search process, we modify clas- sical MCTS with (1) dynamic expansion for adaptive formulation generation, (2)
prompt backpropagation to guide exploration via outcome-driven feedback, and (3) uncertainty backpropagation to incorporate reward reliability into recision-making Experiments on six standard benchmark datasets demonstrate that SolverLLM outperforms both prompt- based and learning baaeed basclines, achieving strong generalization without additional training.
Introduction
An optimization problem seeks the best possible decision in terms of numeric objective while satis- fying set of specified constraints. Such problems ground decision- making in engineering 4 energy management [14), economics [8]. healthcare (7), and many other areas [21]. Solving an optimization problem typically involves three stages. Problem Formulation, translate the problem from domain- specific, often natural language description into a precise mathematical formulation specifying the variables, constraints, and objective function. Code Generation, translate the mathematical model into executable code. Program Execution, run the code with standard optimization solvers such as Gurobi or Pyomo 9 (). Among these steps, problem formulation demands expertise in both the application domain and mathematical programming, limiting broader adoption and automation of -ocision-making...
optimization-bu
The recent and rapid development of Large Language Models (LLMs) have ushered in new era of capabilities in complex reasoning and natural language understanding. Moreover. combining LLMs with algorithmic components yields competitive and reliable task performance with moderate computation cost 25 29 [8]. optimization problems, an L.LM can generate the mathematical formulation and corresponding code, while proven solver executes this code to obtain a reliable solution. The Natural Language for Optimization (NL40pt) benchmark [19] captures this setting by requiring models to convert a textual description into formal program. Existing solutions can be roughly divided into two categories. Prompt-based methods 233 2 coordinate specialized agents
CCen Zhao and Xujiang Zhao are corresponding authors.
39th Conference on Neural Information Processing Systems (NcurIPS 2025).

---

under a carefully designed workflow, which makes them sensitive to prompt choices. Learning- based methods [77 22 fine-tune general LLM on curated problem problem-solution solution pairs, but their effectiveness depends on significant dataset labeling and model fine-tuning cost.
Motivated by the effectiveness of test-time scaling tech- niques, which allocate additional computation during in- ference to boost task performance without extra training cost 27, we propose SolverLLM, training-free frame- work that leverages test-time scaling to solve diverse optimization problems. Rather than predicting solutions directly through multi-agent prompting or rask-specific fine-tuning, SolverLLM decomposes problem formula- tion into essential stages and explores formulation space with multiple call of LLM guided by Monte Carlo Tree Search (MCTS) strategy. [ comparison of LolverLLM with prompt-basee and marming-basel methods. Our contributions are threefold:
Optimization Problem
Prompt-Based Method
SolverLLM (Ours)
Learning-Basse Method
00
Data Collection
Manually Prompt Design
Test-Time (Training Free)
We proposed SolverLLM a training-free framework that leverages test-time scaling strategy solve di- verse optimization problems.
Task- Specific
Tuning
Formulation
Formulation
Formulation
Lo introduces three key innovations: (i) dynamic expansion, which lets the LLM incremen- tally add or refine variables and constraints; (ii) prompt backpropagation, which feeds solver feedback through the tree steer subsequent prompt edits; and (iii) uncertainty backpropagation, which incorporates reward variance to improve search efficiency.
VX
Solver
VX
VX
Jack of gonerale Eustion whilkty
Correct
Conrect But Exposive.
Comparison of the solution pipelines employed by prompt-based ap- proaches, learning based approaches, and SolverLLM for optimization problems.
Figure 1:
Extensive experiments on six standard benchmark datasets show that SolverLLM consistently outper- forms leading prompt-buin based and learning-basee base- lines, achieving 10% improvement over the state-of- the-art.
Related Work
Prompt-Based Methods for Optimization Problems. Chain-of-Experts 23 tackles the automated formulation of optimization problems as dialogue among specialized LLM agents. A conductor invokes an interpreter, modeller, coder, and reviewer in sequence, then walks back along the chain so each agent can reflect and revise its own output. The loop repeats until the generated python code solves the instance. OptiMUS (2) adopts similar multi-agent approach but changes the workflow. first converts the problem description into structured record of parameters, objectives, constraints, and context. A manager agent then cycles through a formulator, a programmer, and an evaluator to express each clause mathematically, generate code, the program, and correct errors needed. Although effective, these methods rely on carefully tuned agent roles and prompt templates, making them fragile unfamiliar optimization tasks.
introduces a semi-automatic data-synthesis framework that iteratively expands and augments a small real-world dataset. The model fine-tuned to take a textual description as input and to produce both the mathematical formulation and the corresponding solver implementation. LLMOPT [2] assembles expert-verified samples covering five components(sets, assistance. The model uses supervised fine-tuning and value-based alignment to reduce hallucinated outputs, and it iteratively refines solutions during inference through solver-guided self-correction loop. These approaches rely on large, high-quality optimization datasets, and their ability to handle unseen problem families and the substantial computational cost of training remains open concerns.
Learning-Basse Based Methods for Optimization Problems. ORLM 22
serramttess,obectivee variables, constraints) samples with GPT-4
Test- Time Scaling with LLMs. Test time scaling allocates extra computation only during inference to extract more reasoning power from frozen language model 277 Typical strategies include repeated decoding passes (5), extended chains of thought (26), and prompt-space search (24). Notably, search

---

Selection
Expansion
Simulation
Backpropagation
Select until reaching leaf (upper) / active (lower) node
New nodes are Created on the selected node
Rollout to complete formulation, then evaluate
Backpropagate the rewards, prompts, and uncertainties
Brief Evaloution:
Change to active Reword: Significont updatt guidance the sulteequent layer generation
Expansion node
4 "The 3rd layer has with sncertataty o Low uncerialnty reward
Expansion on non-leaf node
Keep mactiiv a Reward: update
Change to inactive
Brief Evaluation:
iscoe" with high uncortointy uncertaing tainty reward
Repeat Until Termination
Figure 2: An illustration of SolverLLM with two MCTS iterations, each consisting of four stages: selection, expansion, evaluation, and backpropagation. Unlike standard MCTS, which performs expansion only leaf nodes (as in the first iteration), SolverLLM also enables dynamic expansion at non-leaf nodes (as in the second iteration). Beyond rewards, the evaluation phase additionally generates reasoning signals that provide layer-specific guidance via backpropagation for subsequent search steps. Furthermore, this phase estimates both global and local uncertainties for rewards and reasoning signals, which leveraged the backpropagation phase accelerate the search process.
techniques like MCTS demonstrates significant performance increases over math and reasoning tasks 228 16. Our work builds upon this line by incorporating structured MCTS framework, augmented with LLM-driven feedback and uncertainty estimation, to navigate the formulation space of optimization problems at inference. This training- free paradigm enables SolverLLM to generalize across domains while avoiding the limitations of both prompt sensitivity and costly training.
3 Methodology
3.1 General Form of Optimization Problems
Optimization problems aim find the best outcome under given constraints by minimizing or maximizing an objective function over decision variables. The standard form is:
min XEX
f(x) s.t.
h2(x) S O, i= l=
(1)
Here, E D is the D-dimensional decision variable, the feasible set, f the objective function, and h; the constraints. SolverLLM builds upon this abstraction by treating the formulation process itself search problem, enabling structured exploration of X, and the constraints through language model generation.
3.2 SolverLLM: Optimization Formulation via LLM-Guided MCTS
To tackle the complexity of formulating diverse optimization problems from natural language, we introduce SolverLLM, a training-free framework that leverages Monte Carlo Tree Search (MCTS) algorithm guided by LLMs. SolverLLM treats the formulation process itself as a structured decision-making problem, where each step incrementally builds or refines a formulation based on L..M-generated proposals and solver feedback. The overview of SolverI.I.M is shown in Figure 2 SolverI.IM builds this tree through four canonical MCTS phases-selection dynamic expansion, simulation, and backpropagation each adapted to support symbolic reasoning with language

---

models. Before describing these components, we introduce our clement-based decomposition that guides the search.
3.2.1 Element-Based Formulation as Search Guidance
Inspired by five-element abstraction from prior work [12. we design a six-element schema: Type, Sets, Parameters, Variables, Objective, and Constraints. These elements guide LLM-driven expansion and enable structured, interpretable search via MCTS.
A key enhancement in SolverL.LM is the introduction of the Type element, which identifies the high- level category of the optimization problem, such as linear programming. or integer programming. This early-stage classification provides a form of global guidance Gg before the LLM begins constructing detailed formulations. Analogous to a student reviewing key concepts before solving exam problems, the Type element helps the model establish coherent mental model of the task hand. This early guidance helps the LLM form a coherent task model, reducing ambiguity and ensuring consistency in later decisions, especially for complex or unfamiliar problems. SolverL..M constructs formulations incrementally across these six elements. Each node encodes partial formulation, while the entire path of nodes defines the complete model. This modular design enables semantic consistency, local reasoning, and flexible correction, making it ideal for test-time inference.
3.2.2 Selection
The selection phase in SolverL.LM traverses the current search tree from the root either promising leaf node eligible for expansion or an active non-leaf node. At each step, we select one of the current node's children by balancing exploitation (high-reward nodes) and exploration (less-visited nodes). SolverLLM adopts the Upper Confidence Bound for Trees (UCT) for this purpose. During the entire search process, each node s continuously maintains two statistics based on solver feedback collected from past rollouts: a total visit count N₂ and an average reward Qs- Given parent node the next child Schald E Cs)ld(s) is selected according to:
2 2oo N. Ng.
Schild = arg
max e'EChild(s)
Qs + c.
where e is an exploration constant controlling the degree of exploration.
Unlike standard MCTS, where each node represents complete state and the selection phase termi- nates only upon reaching a leaf node, each node in SolverLLM corresponds to a partially constructed optimization formulation represented as subset of the six elements introduced in Section 3.2. and the selection process can also terminate early when an active non-leaf node determined by a trigger ts (discussed in Section 3.2.5) is encountered, enabling dynamic expansion.
3.2.3 Dynamic Expansion
At the heart of SolverLLM'ss dynamic expansion strategy is the use of language model to generate new formulation candidates in open-ended and context-aware manner. Unlike traditional MCTS, where the action space is predefined and finite, the space of valid optimization formulations is vast and unstructured. Rather than relying the LLM to produce new child nodes tailored to the current partial formulation, which increases the breadth of the search and facilitates solving more complex optimization problems. The dynamic expansion strategy of LolverLLM mainly consists of the following two core components:
static set of predefined actions (3) SolverLLM prompts
Expansion on non-leaf nodes. Benefiting from the modified selection strategy, expansion can be performed on non-leaf nodes. This flcxibility accounts for the non-linear structure of optimization problem formulation: elements such variables and constraints may depend on revise earlier components. SolverLLM can revisit and refine earlier decisions based on updated feedback, enabling deeper and more accurate formulations over time.
LLM-guided expansion with local reasoning. In LolverLLM, each element layer is assigned local sspert-guided knowledge base G. that guides the expansion of any node (whether it's leaf or non-leaf nodes) within that layer. This knowledge base is constructed from accumulated reasoning signals derived from the evaluation of past generated formulations, which will be discussed in detail loop allows S to continuously adapt its expansion behavior, effectively learning from past mistakes during inference.
in Section 3.2.5 Such

---

Overall, this dynamic, reasoning- aware expansion process equips SolverLLM with the ability to construct complex, high-quality formulations through iterative refinement and signals feedback.
3.2.4 Simulation
The simulation phase comprises two key operations performed on the expanded node s: rollout and evaluation. Rollout refers to the process of simulating complete solution from a specific node by iteratively applying actions until terminal state or fully constructed formulation is reached. Once the complete formulation is obtained, SolverLLM evaluates its quality by translating it into executable code and running it through a solver. This step determines whether the formulation is syntactically valid, solver-compatible, and capable of producing feasible or optimal solution. The purpose of the evaluation to obtain the following signals, which serve to guide the subsequent search process:
Reward. Each formulation Js at node s is translated into code and solved by numerical solver, yielding output x². Subsequently, reward R(ss,"" x=) is assigned, which captures several factors:
Feasibility: Whether the solver ran successfully and found a feasible solution.
Optimality: Whether the solution meets the problem's 's objective (e.g., minimizes cost).
Error Penalty: Whether the code execution failed returned invalid outputs.
The reward is computed weighted sum:
x(),,x") lleaaiibe B objeetive__core(([e - Ierme
where a, B, and y are hyperparameters, and Ireasiblee Temor binary indicators. The term objective_scoref x²) represents subjective judgment of the solution quality, based on both the original formulation and the computed result. Specifically, we prompt the LLM to act lightweight evaluator (or "judger") that assesses how well the solution aligns with the intent and structure of the formulation fe. This allows us estimate relative solution quality even in the absence of exact ground truth labels or reference objectives, and is particularly useful in cases involving heuristic or approximate solvers.
Reasoning Signals of Each Layer. Beyond rewards, we further employ the LLM to evaluate each element in the generated formulation, producing corresponding reasoning signals for each layer. Specifically, for each layer and its associated node s; in the formulation, we define the reasoning signals triplet S (1, Es, Gt), where denotes a one-time trigger indicating node activation status of node 8t, Es, represents the reason explaining whether node 81 is appropriate, and G; provides layer-level prompt guidance for revision when the node s; is deemed inappropriate. These signals propagated backward, serving critical information that influences the subsequent search process of SolverLLM. A detailed description of the reward and reasoning signals is provided in Appendix C.2.
3.2.5 Backpropagation
After evaluating candidate formulation and obtaining its reward and reasoning signals, LolverLLM performs backpropagation to update the search tree and inform future decisions. In standard MCTS, this step updates visit counts and value function along the path from the current node back to the root. SolverLLM extends this process with two key innovations tailored for language-model-guide reasoning: prompt backpropagation and uncertainty propagation.
Prompt Backpropagation. Traditional MCTS propagates only scalar rewards, thereby overlooking rich contextual feedback, especially when the formulation itself is imperfect. In SolverLLM, the reasoning signals Sj for each layer obtained from evaluation are treated as feedback. Specifically, for each node at each level ( along the path used to generate the formulation, we propagate the corresponding reasoning signals S backward, updating the node's 's state until reaching the root. If a trigger fa, present in S₁, the corresponding node is regarded as activated, meaning it becomes eligible for further expansion, consistent with Section 3.2.2] In addition, we construct a knowledge base G/ for each layer / to continuously accumulate prompt guidance Gi from S,. This guidance is then incorporated into future prompt construction during dynamic expansion, enabling reasoning- aware search and formulation refinement. However, given the uncertainty associated with L.LM outputs, we additionally compute local uncertainty U 8t
based on Esg, using predictive entropy [13
5

---

F log IP (a: ao. a.....a--)
Locall = EE
Bss
a;
where a, is the i-th token of E.,. Only when Ul!cal exceeds a threshold and a trigger ta, is present will we activate the corresponding node and perform prompt backpropagation.
Uncertainty Backpropagation. Leveraging an LLM as a semantic scorer enables task reward estimation, but introduces high variance due the subjectivity and variability of LLM outputs. This makes reward propagation unstable, especially for complex or ambiguous formulations. To mitigate this, incorporate reward uncertainty global uncertainty during backpropagation. Specif- ically, we estimate the semantic uncertainty (15) at each evaluated node s by repeatedly sampling sectiie_scoor(ffe_
yielding an uncertainty measure U/llobal, as detailed in Appendix B. We then weight the impact of uncertain evaluations during backpropagation. For each node s' on the path from to the root, we update its value using uncertainty ieetraintt-weiiheee average:
2- Po: R(fs. Qs No:
where the trade-off factor is defined as a decreasing function of uncertainty: P3 cxp(-Ug ) and R(f., x²) is the average reward based on multiple samplings. This formulation ensures that confident evaluations (low variance) are strongly propagated, while noisy or uncertain judgments have limited influence on
statistics. Finally, for every node s' on the path, we also increment the visit count: N. < No + 1. These updates to Qe' and N. are used in the next selection step to determine which parts of the tree should be further explored.
By combining symbolic reasoning feedback (prompt backpropagation) and statistical robustness (uncertainty backpropagation), SolverLLM transforms MCTS from purely numerical search into feedback-rich, language-informed inference process. This enables more intelligent reuse of partial formulations, better adaptation to errors, and faster convergence to high-quality solutions.
4 Experiments
To evaluate the effectiveness of SolverLLM, we conduct comprehensive experiments across six benchmark datasets, comparing our approach with both prompt-based and learning- bbasd baselines. Our study is designed to answer the following key research questions:
(Q1) SolverLLM vs. Baseline Methods:
How does SolverLLM, as a test-time scalable frame- work, compare prompt-based methods? Can SolverLLM match exceed the performance of training-intensiee approaches without incurring the cost of data collection and fine-tuning?
(Q2) Impact of Dynamic Expansion: What role does the dynamic formulation expansion, enhanced by prompt backpropagation, play in improving solution accuracy?
(Q3) Effectiveness of Uncertainty Backpropagation: How does incorporating uncertainty estimates into the search process improve efficiency and decision quality during inference?
(Q4) Importance of Type Element: How does the inclusion of type element in the six-element formulation affect its effectiveness compared to the widely explored five-element one?
These questions guide the structure of our experimental analysis the following sections, which include detailed setup, comparative evaluation, and ablation studies.
4.1 Experimental Setup
For evaluation, we use the test set portions from six world optimization and operation task datasets: NL40pt [9]. Mamo (EasyLP and ComplexLP) [10], NLP4LP (2), ComplexOR [23], and IndustryOR 22 These datasets include optimization problem cases of varying difficulty, types, and domains. Among them, the test set of NLP4LP is obtained by shuffling the source dataset and randomly sampling 100 cases. All other datasets use the same setting as I.LOPPT [12. We evaluate the effectiveness of the methods on the optimization problems using Solving Accuracy (SA) and

---

Execution Rate (ER), SA is the proportion of optimization problem cases successfully solved by the algorithm. ER is the proportion of cases where the code runs successfully without any errors and produces output. Additionally, we use Average Generation Times (AGT) (in minutes) to measure the efficiency of the methods, which refers to the time required for the method to model the formulation of the problem. Detailed experimental information are provided in Appendix A.
4.2 Result Analysis
We selected GPT-4 M and GPT-4o [T] which are used directly, along with prompt-based methods
Reflexion 20) Chain-of-expert (23). OptiMUS [2], test-time scaling based method AutoFormula-
tion [3]. as well as learning- -bsed methods including ORLM [22] (built on Mistral-7B, Deepseek- Math-7B-Bai and LLaMa3-8B), and LLMOPT [2] (built on Qwen1.5- 1-B4BB. as the compared
methods for comprehensive comparison.
Comparison with Prompt-Based Methods. The experimental results of Solving Accuracy (SA) for the Comparison with prompt-based methods are shown in Table [ For compara- bility, we have retained the results from the orig- inal paper as much as possible. The performance of SolverLLM significantly outperforms these methods, with improvements exceeding 10% in all datasets. This can be attributed to its test-time scalable framework, which directs the L.LM to break down the problem into six elements and leverages MCTS with dynamic expansion to ex- plore a broader set of potential formulations, ultimately selecting the optimal one. This ap- proach significantly improves the model's 'ss capability to solve optimization problems more effectively.
Table 1: The comparison results of SA between prompt-hased methods and SolverI.LM The base- line results are cited from 11 Bold is the best, while underlined is the second-best
NL44ptt NLP4LP ComplexOR
GPT-4 Directly GPT-40 Directly
47.3%
35.8%
9.5%
81.0%
32.4%
27.3%
Reflexion
53.0%
46.3%
19.1%
Chuin of Experts
64.2%
53.1%
38.1%
OptiMUS
78.8%
72.0%
66.7%
SolverLLLM (Ours)
97.0%
87.0%
77.8%
Comparison with Learning- Based Methods. We com- pared SolverLLM with recent LLMs
Table 2: The comparison results of SA between learning- based methods and SolverL.LM. The baseline results are cited from 12 Bold is the best, while underlined is the second-best.
optimization-specffic trained via Supervised Fine- Tuning (SFT), shown in Table As training-free method, Solver- LLM significantly outperforms ORLM on SA and matches the state-of-the-art LLMOPT on simpler datasets like MamoEasy and NL4Opt. On more challenging datasets such as MamoComplex and IndustryOR,
MamoEasy NL40pt MamoComplex IndustryOR
GPT-4 Directly GPT-4o Directly
66.5%
47.3%
14.6%
28. 28.0%
91.0%
81.0%
34.0%
34.0%
ORLM-Mistee
81.4%
84.4%
32.0%
27.0%
ORLM Deepseek
82.2%
86.5%
37.9%
33.0%
ORI aM3
82.3%
85.7%
37.4%:
38.0%
LLMOPT
97.0%
93.0%
68.0%
46.0%
SolverLLM (Ours)
96.0%
97.0%
76.0%
56.0%
surpasses
LLMOPT by 8 and 10 percentage points, respectively. This demonstrates that SolverLLM delivers strong performance without supervised data or fine-tuning overhead. In contrast, learning-base based methods are limited by their training data distribution and struggle to generalize. Even after fine-tuning, they often underperform on complex, unseen problems. SolverLLM mitigates this by exploring broader solution space, leveraging prompt backpropagation to accumulate experience over tine-trading off evaluation speed for greater robustness across diverse optimization tasks.
Comparison with Other Test-Time Scaling Methods. As a recent test-time scaling method also leveraging Tree of Thought (ToT), AutoFormulation 3 employs MCTS to automatically generate the four-element formulation. We compared the SA and ER results of AutoFormulation and LolverLLM across six datasets, as shown in Figure SolverLLM outperforms AutoFormulation in SA on both simple and complex datasets, indicating that the dynamic expansion enabled by prompt backpropagation leads to better search tree, which aids in exploring the correct formulation. Furthermore, even with the more detailed six-element formulation, SolverL.LM still achieves higher ER, with almost all the code executing successfully. This attributed to its use of error backpropagation during the code generation phase, as detailed in Appendix C.
7

---

0012
Sabiing Acsuaay (NS)
77.5
65-
$5.0
Execcrion State
32.6
MantoEay
NLA0pt
NUMAPP
ComplexO
MamoC.
IndveryK
Mamollayy
NLAU
NLMLP
ComplexOR
Mamol:: IndiatrOO
Figure 3: The comparison of SA and ER results between AutoFormulation and SolverLLM (Ours) across six real-world dataset. "MamoC." the abbreviation for MamoComplex.
Table 3:
The ablation study results on three metrics across six datasets for SolverLLM and its variants without (w/o) Prompt Backpropagation (PB), Uncertainty Backpropagation (UB), and Type Element (TE). Bold indicates the best performance. f means higher is better, + means lower is better.
Datasets
SA (%) 7 /ER (%) AGT (min)
(Easy Hard)
MamoEEay
NL4Opt
ComplexOR
MamoComplex
IndustryOR
SoLverLLM
96.0/ 100.0 /2553
97.0 2.33
87.0/ 100.0/ 2.38
77.8 100.0/2.1
76.0 99.0 /385
56.0/ 98.0 /3.28
w/o PB
90.07
/233
93.0 100.0/
81.0/ 100.0/ 2.13
66.7 94.4 /267
69.0/
99.0 /3.81
46.0/ 96.0 /3.24
wio UR
95.0/ 100.0 2.557
97.0/ 100.0 2.300
85.0/ 99.0 2242
77.8/
94.4 /1.27
75.0/
99.0 /4.34
56.0/
97.0 /3.68
TE
/241
/.0.0/2.48
82.0/ /2.58
72.2 10000/.51
59.07
/
48.0/ 98.0 /3.01
Problem Description (from MamoComplex question 88, TSP):
A sales representative needs travel to six distinct cities promote products. (Details variablex, parameters, objective, and constraints.... What is the minimum total travel cost for him to visit each city exactly once and returning the start?
Formulation from SolverLLM w/o
Formulation from
Sets: Edges: 2)., (1,
Formulation from SolverLLM
SolverLLM
(1. 4), (1. 5) (1, (2, 1),
Root
Sets: Edges: ((1.))
R
(2, 3), (2. 4), (2, 5), 6).
(L, 3). ... (6, S)] visit high uncertuinty
(.
2 (4.
Type
(4, 5), (4, 6), (5, 1) 2
(5, 3)
65
49,
(5, 6) 11.
Sets
B
(6. 2),
(6, 4),
5)
low unceriainty
Local instruction for constraint elememt: bounds Sequence Variables ufil as integers between (n. 1), where n is the mumber of cities.
Parameters
Setse Edges [0. 2 (l. (1,3),
5)
Objective
luisit count:
Constraints
Guide
Constraints: VisitEachCityOnce, EnterEachCityOnce.
An erroz generated code: systaxt:zee:: invalid ciaractez 1.. (0-2026)
"SattouFFlmmmaation Subtour SabtourFliiinnn Fiminaaioon Bounds
Result from SolverLLLM
Correct
Result from SolverLLM wio UB optiinal anlution Found
Correct
LM
Incorrepti
Opt solut Found
No optinal colution tound Problon infessible
perrepciiiii Cetnninnn total Lravel cost:: 213.0
Minimum total trevel coot: 213.0
Bunning time:3. 637682565 min
Rurming time: 5.313245498 min
Figure A case study of LolverLLM and its variants w/o and w/o UB on hard TSP optimization problem with their search trees. Node fill colors show changes from SolverL.M LLM; solid lines mean additions, dashed lines mean deletions. The content of nodes and B (related the w/o UB variant) and nodes C and D (related to the w/o PB variant) has been indicated by the dotted-dashed line. The local instruction generated by PB are used to guide the generation of the constraints element. The colored paths (violet, blue and orange) represent the optimal formulations, which ultimately point to the results. In this problem, SolverLLM and its w/o UB variant produced correct results, with the former being more efficient.

---

Problem Description (from pL question 4, a simple problem):
A new fast food place makes wraps and platters. (Detoil description about parameters, objective and constraints... How many of wraps and platiers should be made to minimize the total production time?
Formulation from SolverLLM w/o TE
Formulation from SolverLLM Guide
Global instruction for this question: Ensure that the decision variables are non-negative integers, as fractional production quantities are not practical this context.
Root
Type: LP
y3ward:53.4 unselected
Type
Correct
Result from SolverLLM
Sets
Type: IP
Optinna" i on found
reward: 99.6
Optiimel. number of Krapes 537.0
Param.
selected
Optimal number of Flattere: 178.0
Mittimum Production Time: 6794.0
Variables
Variables: Int
Incorrect
reward: 99.6
Result from SolverLLM w/o TE,
Objective
Variables: Float ireward: 99.6
Optinal. solution found
7(
Optiimal. number of Krape: 5
Constraint
Optinmal number Flattera: 1
Minimum Production Time: 6785.7
Figure 5: A case study of SolverLLM and its variant w/o TE on a simple IP problem with their search trees. The content of notable nodes has been indicated by the dotted-dashed line. The global instructions generated by TE are used to guide the generation of all elements. The colored paths (red and blue) represent the optimal formulations, which ultimately point to the results.
4.3 Ablation Study
To explore the impact of the main components of SolverLLM in solving optimization problems, we conducted comprehensive ablation study three variants of SolverLLMM: without (w/o) Prompt Backpropagation (PB), without Uncertainty Backpropagation (UB), and without Type Element (TE), with the main results shown in Table We also conducted case studies to gain a deeper understanding of each component by analyzing the search trees, as shown in Figure 4 and Figure 5
Impact of Dynamic Expansion. SolverLLM shows significant performance improvement and better ER compared to SolverLLM w/o PB in Table especially on more challenging datasets. This highlights that dynamic expansion via PB enhances the model's ability to explore optimal formulations. As shown in Figure 4 focusing on nodes C and D. SolverLLM successfully solved the Traveling Salesman Problem (TSP), while SolverLLM w/o PB failed due to missing constraints on the sequence variable range, causing subtour elimination to fail. SolverL w/o PB restricted by its structure and, after receiving two distinct constraint definitions, can no longer explore further, settling for the best result within its current structure. In contrast, dynamic expansion allows SolverLLM to overcome these limitations, enabling bidirectional influence in MCTS exploration cetrration-uppe-lleeeee nodes can influence lower-level ones, and vice versa. Through local instructions generated by PB, the correct constraint definitions at node D were successfully explored.
Effectiveness of Uncertainty Backpropagation. As shown in Table UB enhances the model's efficiency while preserving its effectiveness. SolverLLM and SolverLLM w/o UB achieved similar SA and ER results. While their AGT is comparable on simpler datasets, LL is significantly more efficient on the more complex ones. This is due to UB's 's ability to prune low-quality nodes carlier, simplifying the search tree and enabling faster exploration. In the TSP example in Figure 4 nodes A and B model similar sets. They have similar initial rewards, but the set in node A is incomplete, which makes the formulation modeled based on this node likely to generate incorrect code, making it unreliable. SolverLLM w/o UB fully explored node A's branch before identifying the issue, wasting a significant amount of time, even though the correct result was obtained. In contrast, SolverLLM avoided further expansion of node A's subsequent nodes early on through UB, enabling it to reach the correct result with a smaller time cost.
Importance of Type Element. With the help of TE, SolverLLM achieves modest improvements on simple datasets and significant gains on more challenging ones. This is because TE is designed to provide the model with global instructions about the current problem, enabling it to stay focused

---

on critical details during formulation. This improves modeling completeness for complex problems. Moreover, on relatively simple datasets, TE sometimes even reduces time consumption, as it can contribute to pruning in simpler search tree structures. We further illustrate the role of TE using a simple Integer Programming (IP) problem, as shown in Figure 5 SolverI.LMM w/o TE possibly incorrectly modeled the variable as foating-poin type, leading to incorrect results. In contrast, SolverLLM avoided this mistake under the guidance of the type element and the global instruction generates. We also observed that TE is particularly effective for graph-related problems. To further investigate this, we conducted a case study on such problem, as detailed in Appendix B.
4.4 Token Budget Analysis
Token usage is critical factor for test-time scaling methods, it directly determines inference cost and practical deployability. To assess token efficiency, compare SolverLLLM with AutoFormulation on the MamoComplex dataset under identical config- urations, varying the maximum number of search iterations from 10 to 50. For each budget, we record the total number of tokens consumed during infer- ence and the corresponding solving accuracy (SA), ensuring all runs share identical hardware and decod- ing settings for fair comparison. As summarized in Table 4 SolverL.LMM consistently achieves higher solving accuracy while consuming fewer tokens across all search budgets. This advantage stems from its reasoning-ave aware search design, where prompt and uncertainty backpropagation jointly guide exploration toward semantically meaningful formulation paths, effectively avoiding redundant or low-quality expansions.
Table 4: Token consumption and SA under different search iterations on MamoComplex.
SolverLLM
AutoFormulation
# Iter
# Tokens
SA (%)
Tokens
(%)
10
32,790
35,911
34,0
20
40.920
76.0
43,150
37.0
30
49,337
77.0
54,427
38.0
62,248
50
66,312
78.0
70,245
40.0
Conclusion
We introduced SolverLLM, training-free framework that leverages LLM-guided Monte Carlo Tree Search to solve diverse optimization problems at test time. Unlike prompt-based or fine-tuned methods, SolverLLM incrementally generates, evaluates, and refines formulations without task- specific training. Our method features dynamic expansion for incremental formulation construction, prompt backpropagation for feedback-driven refinement, and uncertainty propagation improve search robustness. Experiments on six benchmarks show SolverLLM outperforms both prompt- and learning-based baselines, with ablations confirming the contribution of each component. This work highlights the potential of test-time reasoning in structured domains and opens avenues for extending to more complex optimization settings and hybrid inference paradigms.
References
[1] J. Achiam, S. Adler, S. Agarwal, L. Ahmad, I. Akkaya, F. L. Aleman, D. Almeida, J. Altenschmidt, S. Altman, S. Anadkat, et al. Gpt-4 technical report. arXiv preprini arXiv:2303.08774, 2023.
[2] A. AhmadiTeshnizi, W. Gao, and M. Udell. Optimus: Optimization modeling using mip solvers and large language models. arXiv preprint arXiv:2310.06116, 2023.
[3] N. Astorga, T. Liu, Y. Xiao, and M. van der Schaar. Autoformulation of mathematical optimiza- tion models using llms. arXiv preprint arXiv:2411.01673 2024.
[4] A. D. Belegundu and R. Chandrupatla. Optimization concepts and applications in engineering.
Cambridge University Press, 2019.
[5] B. Brown, J. Juravsky, R. Ehrlich, R. Clark, Q. Le, C. Ré, and A. Mirhoseini. Large language monkeys: Scaling inference compute with repeated sampling. arXiv preprint arX1v:2407.21777, 2024.
[6] M. L.. Bynum, G. A. Hackebeil, W. E. Hart, C. Laird, B. L. Nicholson, J. D. Siirola, J.-P. Watson, D. L.. Woodruff, et al. Pyomo-optimization modeling in python, volume 67. Springer, 2021.
10

---

[7] E. J. Delgado, X. Cabezas, C. Martin-Barreine Barreiro, V. Leiva, and F. Rojas. An aquity-based optimization model to solve the location problem for healthcare centers applied to hospital beds and covid-19 vaccination. Mathematics, 10(11):1825, 2022.
[8] D. J. Garcia and F. You. Supply chain design and optimization: Challenges and opportunities. Computers Chemical Engineering, $1:153-170, 2015.
[9] Gurobi Optimization. 2024 state of mathematical optimization report. https://wwws http:/www..grbbbb. weressorcces/epoot---eee htt.://seea.t...aaaaaaaaaaaaaaaa cessed: May 2025.
2024. Ac-
[10] X. Huang, Q Shen, Y. Hu, A. Gao, and B. Wang. Mamo: a mathematical modeling benchmark with solvers, 2024.
[11] A. Hurst, A. Lerer, A. P. Goucher, A. Perelman, A. Ramesh, A. Clark, A. Ostrow, A. Welihinda, A. Hayes, A. Radford, et al. Gpt-4o system card. arXiv preprint arXiv:2410.21276, 2024.
[12] C. Jiang, X. Shu, H. Qian, X. Lu, J. Zhou, A. Zhou, and Y. Yu. Llmopt: Learning to define and solve general optimization problems from scratch. arXiv preprint arXiv:2410.13221,, 2024.
[13] S. Kadavath, T. Conerly, A. Askell, T. Henighan, D. Drain, E. Perez, N. Schiefer, Z. Hatfield- Dodds, N. DasSarma, E. Tran-Johnson, al. Language models (mostly) know what they know. arXiv preprint arXiv:2207.0522.) 2022.
[14] D. Krishnamurthy, C. Uckun, Z. Zhou, P. R. Thimmapuram, and A. Botterud. Energy storage arbitrage under day-ahead and real-time price uncertainty. IEEE Transactions on Power Systems, 33(1):84-93, 2018.
[15] L. Kuhn, Y. Gal, and S. Farquhar. Semantic uncertainty: Linguistic invariances for uncertainty estimation in natural language generation. arXiv preprint arXiv:2302.09664 2023.
[16] T. Liang, Z. He, W. Jiao, X. Wang, Y. Wang, R. Wang, Y. Yang, S. Shi, and Z. Tu. Encourag- ing divergent thinking in large language models through multi-agent debate. arXiv preprint arXiv:2305. 191188 2023.
[17] Z. Ma. H. Guo, J. Chen, G. Peng, Cao, Y. Ma, and Y.-J Gong. Llamoco: Instruction tuming of large language models for optimization code generation. arXiv preprint arXiv:2403.01133 2024.
[18] L. Pan, A. Albalak, X. Wang. and W. Y. Wang. Logic-Im: Empowering large language models with symbolic solvers for faithful logical reasoning. arXiv preprint arXiv:2305. 12295, 2023.
[19] R. Ramamonjison, T. Yu, R. Li, H. Li, G. Carenini, B. Ghaddar, S. He, M. Mostajabdaveh, A. DehiitalebiDehkoddi,, Z. Zhou, and Y. Zhang. N14opt competition: Formulating optimization problems based on their natural language descriptions. In M. Ciecone, G. Stolovitzky, and J. Albrecht, editors, Proceedings of the NeurIPS 2022 Competitions Track, volume 220 of Proceedings of Machine Learning Research, pages 189-203 PMLR, 28 Nov-09 Dec 2022.
[20] N. Shinn, F. Cassano, A. Gopinath, K. Narasimhan, and S. Yao. Reflexion: Language agents with verbal reinforcement learning. Advances in Neural Information Processing Systems, 36:8634-8653 2023.
[21] A. Singh. An overview of the optimization modelling applications. Journal of Hydrology, 466:167-182, 2012.
[22] Z. Tang, C. Huang, X. Zheng, S. Hu, Z. Wang, D. Ge, and B. Wang. Orlm: Training large language models for optimization modeling, arXiv preprint 1777733 2024.
[23] Z. Xiao, D. Zhang, Y. Wu. L. Xu, Y. J. Wang, X. Han, X. Fu, T. Zhong, J. Zeng, M. Song, et al. Chain-of-experts: When 1lms meet complex operations research problems. In The twelfth international conference on learning representations, 2023.
[24] C. Yang, X. Wang, Y. Lu, H. Liu, Q. V. Le, D. Zhou, and X. Chen, Large language models as optimizers. arxiv preprint arxiv: 2309.0330000 2023.

---

[25] M. Zaharia, O. Khattab, L. Chen. J. Q. Davis, H. Miller, C. Potts, J. Zou, M. Carbin, J. Frankle. N. Rao. and A. Ghodsi. The shift from models compound ai systems. https://bair 2024.
berkeley. edu bhoh///ll//////// 2ttgg/2244/2//// 12///////////// Sampound-ai-systeen
[26] Z. Zeng, Q Cheng, Z. Yin, Y. Zhou, and X. Qiu. Revisiting the test-time scaling of ol-like models: Do they truly possess test-time scaling capabilities? arXiv preprint arXiv:2502.12215, 2025.
[27] Q. Zhang, F. Lyu, Z. Sun, L. Wang, W. Zhang, Z. Guo, Y. Wang, I. King. X. Liu, and C. Ma. What, how, where, and how well? a survey on test-time scaling in large language models. arXiv preprint 2xXiv:2503.24233 2025.
[28] S. Zhang, Z. Chen, Shen, M. Ding, J. B. Tenenbaum, and C. Gan. Planning with large language models for code generation. arXiv preprint 1rXiv:2303.05510, 2023.
[29] Y. Zhang, Y. Cai, X. Zuo, X. Luan, K. Wang, Z. Hou, Y. Zhang. 7. Wei, M. Sun, J. Sun, et al. The fusion of large language models and formal methods for trustworthy ai agents: A roadmap. arXiv preprint arXiv:2412.06511 2024.
12

---

NeurIPS Paper Checklist
1. Claims
Question: Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?
Answer: [Yes]
Justification: The abstract and introduction clearly present the motivation, contribution, and limitations of this study.
Guidelines:
The answer NA means that the abstract and introduction do not include the claims made in the paper.
The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A No or
NA answer to this question will not perceived well by the reviewers.
The claims made should match theoretical and experimental results, and reflect how much the results can be expected to generalize to other settings.
is fine include aspirational goals as motivation long is clear that these goals are not attained by the paper.
2. Limitations
Question:
Does the paper discuss the limitations of the work performed by the authors?
Answer: [Yes]
Justification: this paper includes a Limitations section that discusses the computational inefficiency of SolverLLM due to its test-time search procedure, which leads to longer inference time compared to learning-based methods. also acknowledges that L.M-- based reward estimation may be noisy and subjective, and describes how uncertainty-aware propagation is used to mitigate this issue.
Guidelines:
The answer NA means that the paper has limitation while the answer No means that the paper has limitations, but those are not discussed in the paper.
The authors are encouraged to create separate "Limitations" section in their paper.
The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g.. independence assumptions, noiseless settings, model well-specification, asymptotic approximations only holding locally). The authors should reflect on how these assumptions might be violated in practice and what the implications would be.
The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on a few datasets or with few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.
The authors should reflect the factors that influence the performance of the approach. For example, facial recognition algorithm may perform poorly when image resolution low or images are taken in low lighting. Or speech-to-text system might not be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.
The authors should discuss the computational efficiency the proposed algorithms and how they scale with dataset size.
If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and fairness.
While the authors might fear that complete honesty about limitations might be used by reviewers as grounds for rejection, worse outcome might be that reviewers discover limitations that aren't acknowledged in the paper. The authors should use their best judgment and recognize that individual actions in favor of transparency play an impor- tant role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed not penalize honesty concerning limitations.
3. Theory assumptions and proofs
13

---

Question: For each theoretical result, does the paper provide the full set of assumptions and complete (and correct) proof?
Answer: [NA]
Justification: This paper is an experimental work without theoretical results.
Guidelines:
The answer NA means that the paper does not include theoretical results.
All the theorems, formulas, and proofs in the paper should be numbered and cross- referenced.
All assumptions should be clearly stated or referenced in the statement of any theorems.
The proofs can either appear in the main paper or the supplemental material, but they appear in the suppiemental material, the authors are encouraged to provide short proof sketch provide intuition.
Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material.
Theorems and Lemmas that the proof relies upon should be properly referenced.
4. Experimental result reproducibility
Does the paper fully disclose all the information needed to reproduce the main ex- perimental results the paper to the extent that affects the main claims and/or conclusions of the paper (regardless of whether the code and data are provided not)?
Question:
Answer: [Yes]
Justification: Detailed information required reproduce the results provided in the experimental sections and the Appendix. The code is attached, and we are committed to releasing publicly upon acceptance.
Guidelines:
The answer NA means that the paper does not include experiments.
the paper includes experiments, a No answer to this question will not perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.
If the contribution is dataset and/or model, the authors should describe the steps taken to make their results reproducible or verifiable.
Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution a novel architecture, describing the architecture fully might suffice, or if the contribution is specific model and empirical evaluation, it may be necessary to either make it possible for others to replicate the model with the same dataset, provide access to the model. In general. releasing code and data is often one good way to accomplish this, but reproducibility can also be provided via detailed instructions for how replicate the results, access hosted model (e.g.. in the case of a large language model), releasing of a model checkpoint, or other means that are appropriate to the research performed.
While NeurIPS does not require releasing code, the conference does require all submis- sions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example
(a) If the contribution is primarily new algorithm, the paper should make it clear how to reproduce that algorithm.
(b) the contribution is primarily a new model architecture, the paper should describe the architecture clearly and fully.
(c) the contribution is a new model (e.g., a large language model), then there should either be way access this model for reproducing the results or way to reproduce the model (e.g., with an open-source dataset or instructions for how to construct the dataset).
(d) We recognize that reproducibility may be tricky in some cases, in which case authors are welcome describe the particular way they provide for reproducibility. In the case of closed-source models, it may be that access to the model is limited in some way (c.g., to registered users), but it should possible for other researchers to have some path to reproducing verifying the results.
14

---

5. Open access to data and code
Does the paper provide open access to the data and code, with sufficient instruc- tions to faithfully reproduce the main experimental results, as described in supplemental material?
Question:
Answer: [Yes]
Justification: Our paper provides open access to the data and code, along with sufficient details for reproducing the main experimental results.
Guidelines:
The answer NA means that paper does not include experiments requiring code.
Please see the NeurlPS code and data submission guidelines (https://nips.cm cc/
wublic//guide//Ddeeebbiiiss www.ssobbmiiiioooooooooooo... for more details.
While we encourage the release of code and data, we understand that this might not be possible, "No" an acceptable answer. Papers cannot be rejected simply for including code, unless this is central to the contribution (e.g., for new open-source benchmark).
The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurlPS code and data submission guidelines (https for more details.
//nips //ips.cc/
guides/ PwoddSSumiissioooool....oooooooo
The authors should provide instructions on data access and preparation, including how access the raw data, preprocessed data, intermediate data, and generated data, etc.
The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. only subset of experiments are reproducible, they should state which ones are omitted from the script and why.
At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).
Providing as much information as possible in supplemental material (appended to the paper) recommended, but including URLs to data and code permitted.
6. Experimental setting/details
Does the paper specify all the training and test details (e.g., data splits, hyper- parameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?
Question:
Answer: [Yes]
Justification:
See Experiments and Appendix.
Guidelines:
The answer NA means that the paper does not include experiments.
The experimental setting should be presented in the core of the paper to level of detail that is necessary to appreciate the results and make sense of them.
The full details can be provided either with the code, in appendix, as supplemental material.
7. Experiment statistical significance
Question: Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?
Answer: [Yes]
Justification: We report the mean of solving accuracy and exccution rate over 3 runs for each method across all benchmark datasets
Guidelines:
The answer NA means that the paper does not include experiments.
The authors should answer "Yes" if the results are accompanied by emor bars, confi- dence intervals, or statistical significance tests, least for the experiments that support the main claims of the paper.
15

---

The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, or overall run with given experimental conditions).
The method for calculating the error bars should be explained (closed form formula, call to a library function, bootstrap, etc.)
The assumptions made should be given (e.g., Normally distributed errors).
It should be clear whether the error bar is the standard deviation or the standard error of the mean.
is OK to report 1-sigma error bars, but one should state it. The authors should preferably report a 2-sigma error bar than state that they have 96% CI, if the hypothesis of Normality of errors is not verified.
For asymmetric distributions, the authors should be careful not to show in tables or figures symmetric error bars that would yield results that are out range (e.g. negative еπτог rates).
If error bars are reported in tables or plots, The authors should explain in the text how they were calculated and reference the corresponding figures or tables text.
8. Experiments compute resources
For each experiment, does the paper provide sufficient information the com- puter resources (type of compute workers, memory, time of execution) needed to reproduce the experiments?
Question:
Answer: [No]
Justification: This paper mainly relies on server APIs rather than local computation, so we do not report any compute resources.
Guidelines:
The answer NA means that the paper does not include experiments.
The paper should indicate the type of compute workers CPU GPU, internal cluster, or cloud provider, including relevant memory and storage.
The paper should provide the amount of compute required for each of the individual experimental runs well estimate the total compute.
The paper should disclose whether the full research project required more compute than the experiments reported in the paper (e.g., preliminary or failed experiments that didn't make into the paper).
9. Code of ethics
Question: Does the research conducted in the paper conform, in every respect, with the NeurIPS Code of Ethics https::/neurips. cctperipsscccppaaaaooo
/ http://wwppp..ccppppp..cccaaaaaa
Answer: [Yes]
Justification: The research conducted in the paper conforms, in every respect, with the NeurlPS Code of Ethics.
Guidelines:
The answer NA means that the authors have reviewed the NeurIPS Code of Ethics.
If the authors answer No, they should explain the special circumstances that require deviation from the Code of Ethics.
The authors should make to preserve anonymity (e.g., s if there is special consid- eration due to laws or regulations in their jurisdiction).
10. Broader impacts
Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?
Answer: [No]
Justification: Only Technical reports
Guidelines:
The answer NA means that there is no societal impact of the work performed.
16

---

If the authors answer NA or No, they should explain why their work has no societal impact or why the paper does not address societal impact.
Examples of negative societal impacts include potential malicious or unintended uses (e.g., disinformation, generating fake profiles, surveillance), fairness considerations (e.g., deployment of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.
The conference expects that many papers will be foundational research and not tied to particular applications, let alone deployments. However, if there is direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, it is not needed to point out that a generic algorithm for optimizing neural networks could enable people train models that generate Deepfakes faster.
The authors should consider possible harms that could arise when the technology is being used as intended and functioning correctly, harms that could arise when the technology is being used intended but gives incorrect results, and harms following from (intentional or unintentional) misuse of the technology.
If there are negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition attacks, mechanisms for monitoring misuse, mechanisms to monitor how system learns from feedback over time, improving the efficiency and accessibility of ML).
11. Safeguards
Does the paper describe safeguards that have been put in place for responsible release of data models that have high risk for misuse (e.g., pretrained language models, image generators, or scraped datasets)?
Question:
Answer: [NA]
Justification: There is no such misuse risk. The datasets used in this paper are public datasets. The algorithm proposed in this paper is only for optimization problems with no risk of misuse.
Guidelines:
The answer NA means that the paper poses such risks.
Released models that have high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere usage guidelines or restrictions to access the model or implementing safety filters.
Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.
We recognize that providing effective safeguards is challenging, and many papers do not require this, but we encourage authors to take this into account and make best faith effort.
12. Licenses for existing assets
Are the creators original owners of assets (e.g., code, data, models), used in the paper, properly credited and are the license and terms of use explicitly mentioned and properly respected?
Question:
Answer: [Yes]
Justification: All datasets and models used are cited.
Guidelines:
The answer NA means that the paper does not use existing assets.
The authors should cite the original paper that produced the code package or dataset.
The authors should state which version of the asset is used and, if possible, include URL.
The name of the license (c.g., CC-BY 4.0) should be included for each asset.
17

---

For scraped data from a particular source (e.g., website). the copyright and terms of service of that souree should be provided.
If assets are released, the license, copyright information, and terms use in the package should be provided. For popular datasets, paperswipphaeeoooccaaappp thcode. com/ com/dataseta has curated licenses for some datasets. Their licensing guide can help determine the license of dataset.
For existing datasets that re-packaged, both the original license and the license of the derived asset (if has changed) should be provided. If this information is not available online, the authors are encouraged to reach out to the asset's ' creators.
13. New assets
Question: Are new assets introduced in the paper well documented and is the documentation provided alongside the assets?
Answer: [Yes]
Justification: We release the code and evaluation framework for SolverLLM with documen- tation, including usage instructions, dependencies, and reproduction guidelines. The assets are anonymized for submission and will be publicly available upon publication.
Guidelines:
The answer NA means that the paper does release new assets.
Researchers should communicate the details the dataset/codeemmodll as part their submissions via structured templates. This includes details about training, license, limitations, etc.
The paper should discuss whether and how consent was obtained from people whose asset used.
At submission time, remember anonymize your assets (if applicable). You can either create an anonymized URL or include an anonymized zip file.
14. Crowdsoureing and research with human subjects
Question: For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and sereenshots, if applicable, as well details about compensation (if any)?
Answer: [NA]
Justification:
This paper does not involve crowdsourcing nor research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing research with human subjects.
Including this information in the supplemental material is fine, but if the main contribu- tion of the paper involves human subjects, then much detail as possible should be included in the main paper.
According to the NeurlPS Code of Ethics, workers involved in data collection, curation, or other labor should be paid at least the minimum wage in the country of the data collector.
15. Institutional review board (IRB) approvals or equivalent for research with human subjects
Question: Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or equivalent approval/review based on the requirements of your country or institution) were obtained?
Answer: [NA]
Justification: This paper does not involve crowdsourcing research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsoureing nor research with human subjects.
18

---

Depending on the country in which research is conducted, IRB approval (or equivalent) may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.
We recognize that the procedures for this may vary significantly between institutions and locations, and we expect authors to adhere to the NeurIPS Code of Ethics and the guidelines for their institution.
For initial submissions, do not include any information that would break anonymity (if' applicable), such as the institution conducting the review.
16. Declaration of LLM usage
Does the paper describe the usage of LLMs if is an important, original, or non-standard component of the core methods in this research? Note that if the LLM is used only for writing, editing, or formatting purposes and does not impact the core methodology, scientific rigorousness, originality of the research, declaration is not required.
Question:
Answer: [Yes]
Justification: See the Methodology and Experiment Sections.
Guidelines:
The answer NA means that the core method development in this research does not involve LLMs as any important, original, or non-standard components.
Please refer to our LLM for what should or should not be described.
htttep//heerrrreccc/////ffeerrre
19

---

A Experimental Details
A.1 Detailed Datasets
We use the test set portions from six real-world optimization and operation task datasets: NL40pt [19], Mamo (EasyLP and ComplexLP) [TO), NLP4LP [2), ComplexOR [23], and IndustryOR (2], which include optimization problem cases of varying difficulty, types, and domains. For a deeper under- standing of the dataset, designed the following prompt to classify the difficulty level of each optimization problem in the dataset using GPT-4o.
Prompt for determining the difficulty level of optimization problems
Given an optimization problem, your task is to determine the **difficulty** of the optimization problem.
Here's the problem description: pproblem_descriptionn
Please judge the type of difficulty optimization problem. Return your response as Python list with single dictionary. * The dictionary should have 'difficulty' key, which indicates the difficulty this problem.
The difficulty have five levels:
LEVEL 1: Simple Linear Optimization Problem
Features: The mathematical expression is explicitly stated, requiring translation from text into mathematical model; very few variables (<=2), and constraints are simple and direct. Typical Problem Example: "Maximize 2x 3y subject to y 10, y >= 0."
LEVEL 2: Ceneral Structure Linear Optimization Problem
Features: Described in natural language, requiring the translation of the specific scenario into an objective function and constraints; 3-6 variables and constraints; constraints are direct resource limitations or capacity conditions; no complex logical dependencies. Typical Problem Example: factory produces three products with limited raw materials, and the goal is to maximize profit."
LEVEL 3: Optimization Problem with Implicit Logic and Conditional Dependencies
Features: In addition to standard constraints, there are logical dependencies/comitiioaa restrictions (e.g., "at least two of the following must be selected," " "if A happens, must not happen"); moderate number of variables/constraints (e.g., 5-10).
Typical Problem Example: "Given limited advertising budget, multiple channels must be chosen, but if TV is selected, social media cannot be chosen, and at least three must be selected."
LEVEL 4: Combinatorial Structure/Strrog Logical Dependencies
Optimization Problem
Features: Multiple combinatorial constraints or strong logical dependencies (e.g., facility location, employee scheduling); explicit mutual exclusivity, inclusion, and dependency relations; difficult to linearize directly from text.
Typical Problem Example: company is selecting warehouse locations across several cities, each warehouse requires hiring employees and incurring fixed costs, and must cover all customers
20

---

while the total budget does not exceed a limit."
LEVEL 5: Garge-Scale / Multi-Stage / Coupled Structure Optimization
Problem
Features: Multi-perion multi-stage, or multi-level nested structures (e.g., dynamic inventory, supply chain scheduling, temporal coupling); large number of variables and constraints (over dozens); the objective may involve phase aggregation or balancing multiple objectives.
Typical Problem Example: "Planning production and inventory for the next six months, considering demand forecasts, inventory holding costs, and production constraints, while smoothing monthly capacity utilization."
The detailed information of the dataset is shown Table
Table 5: Statistical information of the optimization datasets.
Difficulty Count
Average
Dataset
# of problems
2
3
4
Difficulty
MamoEasy 10
100
5
93
2
1.97
NL4Opt 19
100
2
80
18
0
0
2.16
NLP4LP
100
1
71
23
2.32
ComplexOR [23]
19
0
13
0
4
2.61
MamoComplex (10)
100
0
37
25
25
3.14
IndustryOR [22
100
1
31
27
25
16
3.24
MamoEasy is the entry-level subset of the Mamo benchmark, comprising a collection of well-structured linear and mixed-integer linear programming (MILP) problems. Designed for basic training and algorithm validation, provides foundational tasks for learning optimization modeling and solution strategies.
NL40pt natural language- based dataset that spans multiple real-world domains such as investment, advertising, and sales. It focuses on converting textual descriptions into optimization models, offering valuable resource for research on text-to-model translation and automatic formulation generation.
NLP4LP (Natural Language Processing for Linear Programming) collects classical LP problems from textbooks and lecture notes, covering topics like scheduling, network flow, and facility location. integrates descriptive texts, structured data files, and reference solutions, supporting research in automated modeling and natural language understanding for optimization.
ComplexOR a curated dataset high-complexity operations research (OR) problems sourced from domains such logistics, scheduling, and supply emphasizes diversity in problem types and real-world constraints, serving as benchmark for evaluating algorithm robustness and modeling versatility.
chain management.
MamoComplex the advanced-level counterpart to MamoEasy, featuring more challenging and theoretically rich MILP problems. It is tailored for upper-level coursework and research experiments, offering broader spectrum of applications and higher-level optimization skills development.
IndustryOR the first dataset explicitly constructed for industrial optimization tasks. It draws from 13 industries and includes linear, integer, nonlinear, and special types of programming problems. Organized by difficulty levels, provides realistic and diverse benchmark for evaluating modeling and algorithmic generalization in industrial settings.
21

---

A.2 Hyperparameters
Since method is based on in-context learning with frozen large language model, no parameter tuning or model training is involved. Instead, hyperparameter selection primarily concerns the configuration of the reasoning framework, partieularly the parameters governing the Monte Carlo Tree Search (MCTS) process and prompt construction.
We adopted heuristic-based approach to determine these hyperparameters. Initial values were informed by prior work on language model-based reasoning and were further refined through empirical evaluation a development set. Key parameters such as the number of rollouts, the exploration- exploitation trade-off constant, prompt length, and temperature for response sampling were adjusted to balance reasoning depth, consistency, and computational efficiency. Hyperparameters were selected based on their ability to ensure stable decision paths, interpretable intermediate reasoning steps, and robust performance across diverse instances. To avoid overfitting to any single example, all tuning was done without access to test instances, and no gradients or updates were applied to the model. The final hyperparameter settings are shown in Table
Table 6: Hyperparameter configuration.
Hyperparameter Description
Value
Maximum number of components per expansion Maximum number of nodes per layer
Maximum number of search iterations
20
Exploration weight of UCT c Reward weight o. 3,7
0.1, 0.8, 0.1
Local uncertainty threshold 1) LLM temperature
0.3
0.2
B More Experimental Results
B.1 Evaluation with a Lighter Language Model
While SolverLLM is originally implemented with GPT-4o as its underlying language model, we aim to examine the robustness and adaptability of the overall framework under reduced model capacity. In practical deployments, lighter language models may be prefered due to constraints on computational cost, latency, or API availability. Therefore, we evaluate the extent to which SolverL.LM can retain its performance when powered by smaller model, GPT-4o-mini []]. We replicate the exact same experimental pipeline and evaluation protocol as in the main experiments, with the only difference being the replacement of the base language model. All other components of SolverLLM, including MCTS reasoning, uncertainty handling, and pruning strategies, remain unchanged. This ensures that any performance difference can be directly attributed to the change in language model capability, rather than to procedural or implementation differences.
As shown in Table 7 SolverLLM maintains strong performance across all datasets even when GPT-4o replaced with the smaller GPT-4o-mini model. While a moderate performance drop observed, the degradation remains limited, with all solving accuracies staying within reasonable range. This indicates that the framework is not overly reliant on the specific language model scale and can generalize well under reduced model capacity.
These results underscore the robustness of the SolverLLM framework. Despite the lighter model's reduced language modeling capacity, the system maintains a high level of performance across diverse datasets. This resilience is attributable to the design of SolverL.LM itself, which externalizes reasoning into an MCTS- signals, execution validity) rather than blind reliance on model output fluency. effect, the framework compensates for potential model weaknesses by grounding generation in semantically guided search. Consequently, SolverI.L. exhibits graceful degradation under model compression and remains effective in resource-constraing environments.
planning process and relies on structural feedback (e.g.. reward
22

---

Table 7: Comparison of SolverLLM with different LLM backends in terms of the SA metric.
MamoEasy NL4Opt NLP4LP ComplexOR MamoComplex IndustryOR
M. with GPT-4o-mini
94.0%
94.0%
81.0% 87.0%
72.2% 77.8%
66.0% 76.0%
48.0%
L with GPT-4o
96.0%
97.0%
56.0%
B.2 The Impact of Type Element on Graph-Based Problems
As part of the formulation process, the Type Element component is responsible for generating global instruction that defines the overarching structure and semantics of the optimization problem. This global instruction serves as high-level guide to constrain and contextualize the generation of all subsequent components in the formulation pipeline. While the Type Element benefits general task consistency, we observe that is particularly impactful in the domain of graph-based problems, where problem structure is more abstract and constraints often depend on implicit topological relations.
Taking the Traveling Salesman Problem (TSP) as a representative graph problem, there are 25 TSP problems in the MamoComplex dataset. SolverLLM correctly solves 24 of them, achieving an accuracy of 96% this problem type. In contrast, SolverLLM w/o TE (without the Type Element) solves only 16 instances correctly, resulting in significantly lower accuracy of 64%. Below is an example of the global instructions automatically generated by SolverLLLM:
An example of global instructions for TSP
Define binary decision variables x[i, j] indicating whether the path goes directly from city i to city j. Define integer variables u[i] for subtour elimination only for non-starting cities (i.e., do not include the starting city in u)
2.
3. Choose city the starting point (e.g., 'A') and fix u[AA]
0.
4. Set bounds for u[i] integers between and (n 1), where is the number of cities.
Formulate the MTZ subtour elimination constraints as: u[i] u[j] n x[i, j] <= n 1 for all i # j, A start, j # start Ensure that each city is visited exactly once (in-degree and out-degree = 1).
Use v)lue to print evaluated results instead of symbolic expressions.
Make sure the model does not include self-loops (i.e., no x(i, i]) and handles city sets and route sets automatically based on the input list of cities.
These global descriptions play a crucial role in anchoring the meaning of variables, constraints, and objectives in downstream components. Without such context, the generation process may lack alignment with the structural properties the underlying graph. For instance, in the absence of the Type Element, the TSP formulation often fails to recognize the need for subtour climination and consequently omits the Teerr-Tuceer--eee disconnected subcycles. Without this global instruction, the model lacks the structural understanding required to differentiate a valid tour from set of disjoint paths, resulting in infeasible or incorrect solutions that violate the problem's 's core requirements.
(MTZ) constraints, which are essential for preventing
This case study highlights the significance tive biases, particularly in tasks involving implicit topological or flow-related logic. It demonstrates that explicitly encoding problem type at the outset substantially improves semantic fidelity and solving accuracy, especially in structurally complex domains such graph theory.
Type Element in structuring domain-specific induc-
23

---

C Model Implementation Details
C.1 Implementation Details of Semantic Uncertainty Estimation
To quantify the semantic uncertainty associated with each candidate formulation node, we adopt an entropy-hased measure grounded in recent work meaning-equivalenee in language model outputs. Rather than assessing variability over surface-level generations, we consider the distribution over underlying semantic classes-clustess of sequences that encode the same meaning. This approach captures uncertainty at the level of intended formulation semantics, aligning closely with the structural fidelity required in optimization tasks.
Formally, given a formulation fa and input context æ, we sample set of sequences {s} from the language model and group them into equivalence classes {M}, where each class M, corresponds to a distinct semantic meaning. We then compute the semantic entropy (F)) measure of uncertainty, using the following definition:
[15] which serves as our
SE(x) = Σ p(m -
x)) lom
2) =
Σ
Σ LEm
p(s
Ø) log Σ p(s
p(s
x)
This quantity reflects the dispersion of probability mass over meaning-equivalee equivalent outputs, with higher entropy indicating greater ambiguity or instability in the model's semantic preference.
Since the full distribution over all possible meaning classes is intractable, we approximate SE(x) us- ing Monte Carlo sampling over equivalence classes identified from sampled generations. Specifically, we estimate the expectation via:
M Σ
SE(x) = -
log ((M x))
1=1
where M, denotes the i-th sampled equivalence class and p(M (x) its aggregated likelihood.
This entropy-based uncertainty measure serves as a principled signal during reward backpropagation in MCTS. Nodes associated with high semantic entropy treated less reliable and receive attenuated influence during search. Compared to naive variance-bart based metrics, semantic entropy offers deeper view of model uncertainty grounded in meaning-level diversity, leading to improved robustness in structurally complex tasks.
C.2 Feedback from Evaluation
LLM-ggnnrrted feedback is key component for SolverL.LM. After evaluating complete formulation, the feedback takes the following form and subsequently used during the backpropagation phase:
Feedback from evaluation
"score": "a value between and 100", "evaluation":
"type":
"need_ree reviseervvse": "1 (True) or 0 (False)",
"reason": "Justification for the 'need_revise' decision",
"prompt": "Prompt that helps avoid the same problem in future", "uncertainty"; "Predictive entropy computed from the 'reason' field" },
"sets": (same structure as above)",
"parameters":
"variables";
"objective"; "..."
"costraints""
24

---

Among them, score is obtained by the following prompt:
Partial prompt for objective score
The task is to evaluate this formulation according to the following
criteria:
1. Correctness: Does the formulation correctly model the problem
described?
2. Completeness: Does the formulation include all necessary
components?
3. Efficiency: Is the formulation efficient in terms of variables and constraints?
4. Solvability: Did the execution produce correct solution?
5. Solution quality: Does the solution make sense for the given problem?
Based on your evaluation, provide numerical score from 100,
where:
0-20:
Poor formulation with major flaws
21-40:
Flawed formulation with significant issues
41-60:
Adequate formulation with some issues
61-80:
Good formulation with minor issues
81-100:
Excellent formulation that correctly models the problem
C.3 Error Backpropagation for Code Generation
Inspired by LLMOPT [1), we incorporate an error backpropagation mechanism during the post- formulation code generation stage enhance execution reliability. While SolverLLM focuses on producing high-qualie optimization formulations via MCTS, code execution may still fail due to syntax issues, undefined references, or incompatibilities with solver requirements, even when the formulation itself is semantically correct.
To mitigate this, implement feedback-driven loop in the code generation process. Upon encountering a runtime error during execution, the corresponding error message extracted and integrated into the next generation prompt an explicit instruction. This instructive feedback helps the language model to revise the previous code in targeted and informed manner. The process repeats until valid, error-free program generated predefined retry limit is reached. Following LLMOPT, we set the maximum number of retries to 12. An example of the prompt with error feedback for code generation as follows.
Prompt with error backpropagation for code regeneration
task is to implement the following mathematical formulation using Pyomo. The corresponding code has been generated by the large model here, but it contains some errors. Please generate accurate and error free new code.
Problem description:
pproblem_description)
Formulation:
[formulation_srr]
The following Pyomo code generated using LLM: perevious_pyymo.ce
25

---

There is an error in this code. The error message is: [error]
Please take into account the problem description, the mathematical formulation, the previous Pyomo code, and the error message comprehensively, and modify the previous Pyomo code accordingly to generate a corrected version.
Please generate complete, executable Pyomo code that implements this formulation. The code should:
1. Directly use "from pyomo.enviie import as the import command. Create a concrete model
3. Define sets, parameters, variables, objective, and constraints as specified in the formulation
4.
Include code to solve the model with solver.
Display the results.
This mechanism yields multiple benefits. significantly improves the Execution Rate (ER) by enabling recovery from execution failures through guided prompt revision. As a result, formulations that are structurally correct but fail during code translation are less likely be discarded. this indirectly enhances the overall Solving Accuracy (SA) by preserving and executing more viable solutions. Furthermore, since the primary computational cost in LolverLLLM arises during the MCTS- based formulation phase, ensuring successful execution helps avoid wasteful recomputation and improves overall resource efficiency.
turn,
C.4 Pruning Module in the Dynamic Expansion Process
To ensure diversity and prevent redundancy, a pruning module removes semantically duplicate or overly similar nodes before expansion. This component plays critical role in enhancing the quality and breadth of the search space during the formulation process. As each expansion step generates multiple candidate components via language model sampling, there is high likelihood of producing repetitive or near-identical outputs due to the inherent sampling bias of large language models toward frequent or structurally similar patterns.
To address this, introduce pruning mechanism that operates immediately after each expansion step. The core idea is to evaluate pairwise similarity among candidate formulation components and discard those that excessively similar previously retained candidates. This filtering process ensures that only semantically distinct components are preserved, thereby promoting diversity and reducing redundancy the search trajectory.
In practice, we adopt string-level similarity metric to compare each newly generated component against those already selected. A candidate is accepted only if its similarity to all previously retained components remains below a predefined threshold. We set this threshold to 0.8, which empirically strikes good balance between eliminating near-duplicates and retaining meaningful diversity across datasets and problem domains.
This pruming strategy offers several ad advantages. First, it encourages the exploration of varied and non-overlapping formulation structures, thereby improving the expressiveness and generality of the search space. Second, by filtering out redundant components early on, it improves the efficiency of downstream processes such as code generation and execution. Third, it helps avoid local saturation, where multiple candidate nodes compete to represent essentially the same solution fragment, leading to premature convergence.
C.5 Hierarchical Prompting in the Search Process
To support structured reasoning over the search tree, we design a set layer-specific prompts corresponding to the six levels of the search process. Each prompt is tailored to guide the generation of formulation components appropriate for its respective layer, while maintaining a consistent overall structure. In constructing these prompts, we prioritize generality over instance-specific
26

---

optimization, aiming to develop instructions that are broadly applicable across different tasks and domains. Furthermore, we simplify the prompts as much as possible reduce cognitive and computational overhead, ensuring clarity without sacrificing effectiveness.
The prompt design for the the Type layer is follows.
Prompt for generation at the Type layer
I need you to help me generate the TYPE component for mathematical optimization formulation.
You are also required to determine which category of classic optimization problem the given instance belongs to.
Here's the problem description: pproblem_description
Please judge the type of this optimization problem. Return your response as a Python list with single dictionary.
The dictionary should have 'type' key, and its value must be of the following: LP, MILP, or NLP.
The dictionary should have 'subtype' key, which indicates the category of the classic problem this instance belongs to, such as production planning problem, a scheduling problem, or traveling salesman problem.
Don't include any explanations.
Here are some instructions for you: Firstly, you need to determine whether the problem is linear. The rules are as follows:
If the objective and constraints of the model involve non-linear terms (such as power functions, multiplication, non-linear probability models, etc.), then the problem is non-linear and returns directly to NLP
* If the objective and constraint of the model are both linear, then the problem is linear. Furthermore, you need determine whether the problem is LP MILP.
Here are the suggestions provided by experts based the errors that occurred during the previous generation of the TYPE component. Please take these suggestions into account during the generation process: [suggestions]
The prompt design for the the Sets layer is as follows.
Prompt for generation at the Sets layer
need you help me generate the SETS component for mathematical optimization formulation.
Here's the problem description: drooblemdesccrpptionn
Here the type problem that have already been defined: [type_str]
Here instructions for solving this problem: [instructions_str]
27

---

Please provide the sets needed for this optimization problem. Return your response Python list of dictionaries.
Each dictionary should have 'name', 'dimen' and Pelements' keys. Don't include any explanations.
IMPORTANT: Do not markdown formatting code blocks. Return only the raw Python list.
Here are the suggestions provided by experta based on the errors that occurred during the previous generation of the SETS component. Please take these suggestions into account during the generation process: [suggestions]
The prompt design for the the Parameters layer is as follows.
Prompt for generation at the Parameters layer
I need to help me generate the PARAMETERS component for mathematical optimization formulation.
Here's problem description:
pproblem_descriptiee
Here is the type of problem that have already been defined: [type_str]
Here are some instructions for solving this problem: (instructions_str]
Here are the sets that have already been defined: [sets_str]
Please provide the parameters needed for this optimization problem. Return your response Python list of dictionaries. For indexed parameters, include 'name', 'index_set', and 'values' keys.
For scalar parameters, include 'name' and 'value' keys. Don't include any explanations.
IMPORTANT: not use markdown formatting or code blocks. Return only the raw Python list.
Here are the suggestions provided by experts based on the errors that occurred during the previous generation PARAMETERS component. Please take these suggestions into account during the generation process: [suggestions]
The prompt design for the the Variables layer as follows.
Prompt for generation at the Variables layer
need you help me generate the VARIABLES component for
mathematical optimization formulation.
Here's the problem description:
28

---

Here is the type problem that have already been defined: [type_str]
Here are some instructions for solving this problem: [instructions_str]
Here are the sets that have already been defined: [sets_str]
Here are the parameters that have already been defined: [parameters_str]
Please provide the variables needed for this optimization problem.
Return your response as Python list of dictionaries. Each dictionary should have 'name', 'domain', and optionally
index_set' and 'description' keys.
The domain should be one of: 'Binary', 'Integer', Wonnegattveeltteers',, "NonlegativeReals'' or 'Reals' Don't include any explanations.
IMPORTANT: Do not use markdown formatting code blocks. Return only the raw Python list.
Here are the suggestions provided by experts based on the errors that occurred during the previous generation of the VARIABLES component. Please take these suggestions into account during the generation process: [suggestions]
The prompt design for the the Objective layer is follows.
Prompt for generation at the Objective layer
need you to help me generate the OBJECTIVE component for mathematical optimization formulation.
Here's the problem description:
prooblem_desciptting
Here is the type of problem that have already been defined: [type_str]
Here are some instructions for solving this problem: [instructions_str.
Here are the sets that have already been defined: [sets_str]
Here are the parameters that have already def ined: [parameters_str]
Here are the variables that have already been def defined: [variables_str]
Please provide the objective function for this optimization problem. Return your response Python list with single dictionary. The dictionary should have 'name', 'sense', and 'expressionn' keys. The sense should be either 'maximize' or 'minimize',
29

---

The expression should be a valid Pyomo expression as string, using 'model.' 2 to reference sets, parameters, and variables. Don't include any explanations
IMPORTANT: Do not use markdown formatting or code blocks. Return only the Python list.
Here are the suggestions provided by experts based on the errors that occurred during the previous generation of the OBJECTIVE component. Please take these suggestions into account during the generation process: [suggestions]
The prompt design for the the Constraints layer is follows.
Prompt for generation at Constraints layer
I need you to help me generate the CONSTRAINTS component for
mathematical optimization formulation.
Here's problem description:
[problem_descriptionn]
Here is the type of problem that have already been defined: [type_str]
Here are some instructions for solving this problem: [instructions_ste
Here the sets that have already been defined: [sets_str]
Here are the parameters that have already been defined. [parameters_str]
Here are the variables that have already been defined: (variables_str)
Here is the objective function: [objective_str]
Please provide the constraints for this optimization problem. Return your response Python list of dictionaries.
Each dictionary should have 'name', 'expression', and optionally 'deccription' keys.
The expression should be a valid Pyomo expression as string, using 'model.' to reference sets, parameters, and variables. Don't include any explanations.
IMPORTANT: Do not use markdown formatting or code blocks. Return only the raw Python list.
Here are the suggestions provided by experts based on the errors that occurred during the previous generation of the CONSTRAINTS component. Please take these suggestions into account during the generation process: [suggestions]
30

---

D Limitations
While SolverLLM achieves strong performance across diverse optimization tasks without any training or fine-tuning, there remain several limitations. First, the current framework may incur relatively high inference latency due to its reliance on Monte Carlo Tree Search (MCTS), especially on complex problems with large formulation spaces. While this cost is offset by its generalization ability and test-time adaptability, it may limit real-time applications. Second, while the framework incorporates uncertainty- mechanisms to address the inherent noisiness of LLM outputs, the effectiveness of reward estimation remains bounded by the subjective and non-deterministie nature of language models. Third, the current evaluation is restricted to datasets with well-structured and moderately constrained optimization problems. The robustness of SolverLLM under highly ambiguous, adversarial, or noisy natural language descriptions remains an open area for exploration. These limitations, while not critical to the core contributions, suggest several promising directions for future research.
E
Broader Impact
SolverLLM proposes novel inference-tine framework that combines LLM reasoning with algo- rithmic search to solve optimization problems without supervised training. This paradigm has the potential make optimization modeling more accessible to non-experts and reduce the dependency on curated datasets. It could benefit wide range of fields, including operations research, supply chain management, and education, by enabling users express complex optimization needs in natural language. However, the use of LLMs for automated decision modeling also raises concerns. In high-stakes upplications such as healthcare or infrastructure planning, even small errors formulation can propagate through automated pipelines and lead to unintended outcomes. Furthermore, reliance on opaque I.M outputs for critical tasks may pose challenges for interpretability and accountability. As such, we advocate for cautious deployment, with appropriate mechanisms for human-in in-the-looy verification and sppeifc validation.
31


Reviews:
[{"review_id": "Fy1gAGbFVn", "reviewer": "Reviewer_BcrF", "summary": "This paper proposes SolverLLM, an LLM-guided MCTS framework for solving optimization problems. SolverLLM contains 4 phases: selection, dynamic expansion, simulation and backpropagation. The main new components in this work are: (1) dynamic expansion of non-leaf nodes in the search tree; (2) prompt backpropagation to incorporate rich non-scalar feedback; and (3) uncertainty backpropagation to deal with the high variance of LLM-based scoring. The authors evaluate their approach on 6 optimization benchmarks, and they demonstrate that SolverLLM consistently improves the performance over baseline methods.", "questions": "1. Please show scaling curves on how the model performance improves with more search budget, such as the number of search iterations, search nodes, etc.\n\n2. Please add discussion on the token budget of SolverLLM compared to baselines, and how it grows with more search iterations.\n\n3. It would be helpful if the authors can present a small example to illustrate how the full workflow of SolverLLM, including the concrete prompt in each stage, how does the solver and LLM-generated feedback look like, what is the output format of the LLM-based scorer and how it is used, etc.\n\n4. I am confused about how prompt propagation works. What are the concrete formats of reasoning signals and the trigger, and how are they generated? How do we incorporate these reasoning signals for future prompt construction? Do we concatenate all past evaluation outcomes in the prompt?\n\n5. I didn't find the prompt for generating objective scores. How does the prompt look like? What is the format of the objective score?", "limitations": "Yes.", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "Strengths:\n\n1. Using LLM for optimization problems is an important topic, and this work demonstrates strong results on diverse benchmarks.\n\n2. The new design upon the standard MCTS framework is well-motivated and effective.\n\nWeaknesses:\n\n1. One main weakness of this work is the lack of a rigorous study of the inference cost of SolverLLM and other test-time scaling baselines. Specifically, the authors only demonstrate the final results and average generation time. However, there are no scaling curves to show how the model performance improves with more search budget, such as the number of search iterations, search nodes, etc. Therefore, it is unclear how much improvement SolverLLM provides when fixing the same search budget compared to baselines. It would be more informative to present such test-time scaling curves to compare different methods.\n\n2. Related to the above question, there is no discussion on the token budget of SolverLLM compared to baselines, and how it grows with more search iterations. It is possible that SolverLLM uses a higher token budget in each search iteration compared to baselines.\n\n3. Another major weakness is that the lack of clarity on method description. It would be helpful if the authors can present a small example to illustrate how SolverLLM works, including the concrete prompt in each stage, how does the solver and LLM-generated feedback look like, what is the output format of the LLM-based scorer and how is it used, etc.\n\n4. I am confused about how prompt propagation works. What are the concrete formats of reasoning signals and the trigger, and how are they generated? How do we incorporate these reasoning signals for future prompt construction? Do we concatenate all past evaluation outcomes in the prompt?\n\n5. I didn't find the prompt for generating objective scores. How does the prompt look like? What is the format of the objective score?", "was_revised": true, "final_justification": "The author rebuttal addressed my questions. Therefore, I keep my review score.", "rebuttal": "We sincerely thank Reviewer BcrF for recognizing the relevance of our topic as well as the novelty and effectiveness of our proposed approach. The concerns raised mainly stem from the trade-off between inference cost and performance gains, as well as certain implementation details. We address these points with clarifications in the following response.\n\n> ### [W1 & Q1] Concern about the search budget.\n\nWe agree that inference overhead and its relation to performance improvements are essential aspects when evaluating test-time scaling methods. To further address this, we conducted additional experiments analyzing the impact of search budget on performance. Specifically, on the MamoComplex dataset, we plotted curves of Solving Accuracy (SA) and Average Generation Time (AGT) as the maximum number of search iterations and the maximum number of components per expansion increase, as shown in the table below:\n\n| # Search Iterations | # Components per Expansion | SA (%) | AGT (min) |\n|---------------------|----------------------------|--------|-----------|\n| 10                  | 3                          | 69.0   | 2.54      |\n| 20                  | 3                          | 76.0   | 3.85      |\n| 30                  | 3                          | 77.0   | 4.82      |\n| 40                  | 3                          | 78.0   | 5.98      |\n| 50                  | 3                          | 78.0   | 6.73      |\n| 20                  | 1                          | 72.0   | 2.67      |\n| 20                  | 2                          | 74.0   | 3.24      |\n| 20                  | 4                          | 76.0   | 4.21      |\n| 20                  | 5                          | 76.0   | 4.88      |\n\nAs shown, there is a clear trade-off between efficiency and effectiveness. We ultimately chose 20 search iterations and 3 components per expansion, as this setting achieves the best balance: fewer search budgets result in insufficient performance, while larger budgets increase AGT without significant performance gains.\n\nIn the final version, we will include the scaling curves in the main text or appendix to more intuitively illustrate the test-time scaling characteristics of SolverLLM. We believe this addition will further demonstrate that our method achieves stronger performance than baselines while maintaining inference efficiency.\n\n> ### [W2 & Q2] Concern about the token budget.\n\nWe recognize the importance of token budget in test-time scaling methods, as it directly affects both cost and feasibility in practical applications. To address this, we conducted supplementary experiments measuring the average token consumption of SolverLLM on the MamoComplex dataset under different numbers of search iterations, and compared the results with AutoFormulation, as shown below:\n\n| # Search Iterations | SolverLLM (# Tokens / SA %) | AutoFormulation (# Tokens / SA %) |\n|-------------------|---------------------------|---------------------------------|\n| 10                | 32,790 / 69.0            | 35,911 / 34.0                  |\n| 20                | 40,920 / 76.0            | 43,150 / 37.0                  |\n| 30                | 49,337 / 77.0            | 54,427 / 38.0                  |\n| 40                | 57,834 / 78.0            | 62,248 / 38.0                  |\n| 50                | 66,312 / 78.0            | 70,245 / 40.0                  |\n\nSolverLLM achieves better performance than AutoFormulation while using fewer tokens at the same number of search iterations due to a more efficient search strategy. In the final version, we will explicitly report the token consumption curves over varying search budgets to further enhance result transparency and comparability.\n\n> ### [W3-W5 & Q3-Q5] Concern about the detailed method implementation.\n\nWe appreciate your thorough consideration. Questions W3–W5 all pertain to detailed aspects of SolverLLM, which we address collectively here. The specific prompts used at each search stage are included in Appendix C.4 for your reference. We model the optimization problems using Pyomo and solve them with concrete solvers such as CBC and IPOPT.\n\nLLM-generated feedback is a key component for understanding SolverLLM. After evaluating a complete formulation, the feedback takes the following form and is subsequently used during the backpropagation phase:\n\n```json\n{\n  \"score\": \"a value between 0 and 100\",\n  \"evaluation\": {\n    \"type\": {\n      \"need_revise\": \"1 (True) or 0 (False)\",\n      \"reason\": \"Justification for the 'need_revise' decision\",\n      \"prompt\": \"Prompt that helps avoid the same problem in future\",\n      \"uncertainty\": \"Predictive entropy computed from the 'reason' field\"\n    },\n    \"sets\": ... (same structure as above),\n    \"parameters\": ...,\n    \"variables\": ...,\n    \"objective\": ...,\n    \"constraints\": ...\n  }\n}\n```\n\nThe objective score is obtained by repeatedly sampling according to the following prompt and averaging the results. The semantic uncertainty is treated as a global uncertainty that contributes to the reward calculation of each node in subsequent steps.\n\nPartial prompt for objective score (For W5 & Q5):\n\n```\nThe task is to evaluate this formulation according to the following criteria:  \n1. Correctness: Does the formulation correctly model the problem described?  \n2. Completeness: Does the formulation include all necessary components?  \n3. Efficiency: Is the formulation efficient in terms of variables and constraints?  \n4. Solvability: Did the execution produce a correct solution?  \n5. Solution quality: Does the solution make sense for the given problem?  \n\nBased on your evaluation, provide a numerical score from 0 to 100, where:  \n- 0-20: Poor formulation with major flaws  \n- 21-40: Flawed formulation with significant issues  \n- 41-60: Adequate formulation with some issues  \n- 61-80: Good formulation with minor issues  \n- 81-100: Excellent formulation that correctly models the problem  \n```\n\nRegarding question Q4, the `prompt` field in the feedback is used as local guidance for future prompt construction depending on the local uncertainty at each level and the `need_revise` flag (requiring uncertainty > threshold $\\eta$ and `need_revise` = 1). During a complete MCTS process, all valid local guidances are used to guide generation results at that level. As for all past evaluation outcomes, they are incorporated into each node’s reward, so concatenating all past feedback is unnecessary.\n\nAgain, we greatly appreciate the reviewer BcrF’s comments and hope our clarifications are helpful. We welcome continued dialogue to resolve any remaining concerns."}, {"review_id": "vdJ8D6Nw3n", "reviewer": "Reviewer_SNpT", "summary": "SolverLLM couples LLMs with an MCTS-style search to auto-generate mathematical programs from Natural Language descriptions, then hands the resulting model to Gurobi/Pyomo solvers for solution. Experiments on six academic benchmarks show higher solving accuracy than prior prompt-engineering baselines.", "questions": "1. Can you show Industry OR results with problems cluster in easy-hard? It would be better to understand where the gain comes from in real-world problems.  \n\n2. Scalability remains speculative.\n\n2. What guardrails prevent LLM hallucinations from generating infeasible or numerically unstable formulations that crash the solver?", "limitations": "Please refer to questions.", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 1, "originality": 3, "strengths_and_weaknesses": "### Strengths\n\n* Integrates three search refinements (dynamic expansion, prompt back-propagation, uncertainty weighting) into a coherent framework and ablates each component.\n\n* Demonstrates consistent accuracy gains over existing prompt-based methods on benchmark datasets.\n\n### Weaknesses\n\n* **No solver-algorithm contribution.** Because the method defers all heavy lifting to a commercial solver, it adds nothing to algorithmic advances. If the solver already supports the model class, SolverLLM merely adds minutes of latency; \n\n* **No comparison on solver time cost**. There is no evidence that the solverLLM could provide problem formulation which requires much less time to solve than human experts.", "was_revised": true, "final_justification": "Please refer to the reply to authors.", "rebuttal": "We sincerely thank Reviewer SNpT for recognizing the completeness and systematic design of our approach, as well as the validity and consistency of our experimental results. The concerns raised mainly stem from potential challenges in deploying our work to real-world applications. We provide clarifications on these points below.\n\n> ### [W1] Concern about solver-algorithm contribution.\n\nWe appreciate the reviewer’s concerns and would like to clarify that the primary contribution of our work does not lie in improving the underlying numerical solvers, but rather in enabling the automatic construction of high-quality, solver-ready formulations from natural language descriptions in a training-free manner. This has long been a bottleneck in applying optimization to real-world tasks. Our contributions can be summarized as follows:\n\n1. Independence from specific problem domains\nWhile commercial solvers indeed excel in numerical optimization, they cannot directly handle problems specified in natural language. The core contribution of SolverLLM is a novel LLM-guided MCTS reasoning framework that dynamically generates, revises, and verifies formulations at inference time, thereby enabling automated and cross-domain optimization.\n\n2. Methodological novelty\nUnlike simple prompt engineering or supervised fine-tuning, SolverLLM introduces several inference-level innovations:\n\n+ Dynamic Expansion: allowing revisions at non-leaf nodes during the search process;\n+ Prompt Backpropagation: leveraging solver feedback to guide subsequent prompt construction;\n+ Uncertainty Backpropagation: explicitly modeling the confidence of LLM feedback to enhance search efficiency.\nThese mechanisms constitute substantive algorithmic contributions in reasoning and search, beyond straightforward interface calls.\n\n3. On additional latency\nThe essence of test-time scaling is to trade off inference-time cost for reduced training-time human effort, thereby achieving training-free deployment. Such methods have been widely adopted and accepted in recent LLM research [1]. Our experiments (see Table 3) show that, thanks to uncertainty-guided pruning, the average additional latency remains within a few minutes, while achieving over a 10% accuracy improvement on complex datasets compared to traditional baselines. This demonstrates that the latency introduced by test-time scaling is both reasonable and practically acceptable.\n\nIn summary, the value of SolverLLM lies in introducing a new test-time reasoning framework that enables high-quality modeling and solving of optimization problems without requiring training or additional labeled data. This is complementary to advances in numerical solvers rather than a mere additive improvement.\n\n> ### [W2] Concern about comparison with human experts.\n\nSolverLLM is designed as a tool accessible to non-experts while minimizing both training and human costs. Our focus is primarily on the algorithmic level, and we have compared our method with a wide range of existing approaches (including GPT-4 and GPT-4o, prompt-based methods such as Reflexion, Chain-of-Experts, and OptiMUS, as well as learning-based methods like ORLM and LLMOPT, and test-time scaling methods AutoFormulation) to demonstrate its superiority. Notably, these methods, including AutoFormulation which is directly comparable as a test-time scaling approach, also do not report comparisons against human experts.\n\n> ### [Q1] Can you show Industry OR results with problems cluster in easy-hard? It would be better to understand where the gain comes from in real-world problems.\n\nBased on the difficulty levels defined in Appendix A.1, we report SolverLLM’s Solving Accuracy (SA) on the IndustryOR dataset under different difficulty levels, as shown below (a higher value indicates a more difficult problem):\n\n| Difficulty Level | Amount | # Correct | SA (%)  |\n|------------------|--------|---------|---------|\n| 1                | 1      | 1       | 100.00 |\n| 2                | 31     | 25      | 80.64  |\n| 3                | 27     | 18      | 66.67  |\n| 4                | 25     | 8       | 32.00  |\n| 5                | 16     | 4       | 25.00  |\n\nAs shown, SolverLLM achieves high accuracy on easier problems (Level 1-2) and maintains relatively high accuracy at moderate difficulty levels (Levels 3). While the accuracy decreases for the most challenging problems (Levels 4–5), SolverLLM still demonstrates the capability to provide feasible solutions, indicating its robustness across a wide range of problem complexities.\n\n> ### [Q2] Scalability remains speculative.\n\nOur method exhibits strong scalability.\n\n1. Methodological perspective: The MCTS framework inherently supports scalability due to its anytime nature, allowing solution quality to improve with additional computational budget. By directing exploration toward high-value branches via UCT instead of performing exhaustive search, it efficiently manages large problem spaces. Its structure naturally supports parallelization and dynamic expansion, ensuring that only necessary nodes are explored, making it particularly suitable for real-world, large-scale problems.\n\n2. Empirical perspective: We further validated scalability by rigorously evaluating our method on every problem across all datasets. Specifically, each problem was run three independent times, and a problem was considered solved only when all three runs produced a feasible and correct solution. This repeated and consistent success across diverse instances demonstrates that our approach is not only effective in isolated cases but also robust and scalable, ensuring reliable performance as problem complexity increases.\n\n> ### [Q3] What guardrails prevent LLM hallucinations from generating infeasible or numerically unstable formulations that crash the solver?\n\nWe address this concern through multiple guardrails to ensure execution reliability. Specifically, we employ an error propagation mechanism (detailed in Appendix C.2) that detects and propagates solver execution errors back to the LLM, enabling corrective reformulation and making the approach naturally extendable to infeasible cases. To mitigate numerically unstable formulations, we impose prompt-level constraints on the LLM’s outputs and perform strict post-processing checks to enforce the required format and validity. Together, these mechanisms substantially reduce the risk of hallucinations leading to infeasible or unstable formulations that could otherwise crash the solver.\n\nWe thank the reviewer SNpT for the valuable insights and look forward to clarifying any outstanding issues through further discussion.\n\n[1] Zhang Q, Lyu F, Sun Z, et al. A Survey on Test-Time Scaling in Large Language Models: What, How, Where, and How Well? arXiv preprint arXiv:2503.24235, 2025."}, {"review_id": "tbne6TsTNl", "reviewer": "Reviewer_2ytH", "summary": "This paper proposes a test-time computation scaling method for solving optimization problem with LLMs. The method is built upon MCTS and has three key improvement. First, the authors extend the five-elements abstraction to include another dimension of problem class, which allow the LLM to focus on particular problem types in subsequent modeling. Second, the proposed method allows an internal node to be eligible for expansion if it is marked as active node by the critic. Finally, the authors accumulate the textual feedbacks from critic to guide the further revisions for each layer. Besides, there are also some minor improvements like taking uncertainty into the considerations. Experimental results confirm the merits of the proposed methods.", "questions": "See my comments on Strengths And Weaknesses section.", "limitations": "yes", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 2, "clarity": 3, "significance": 2, "originality": 3, "strengths_and_weaknesses": "## Strength\n- Generally, the paper is well-written. The contribution is clearly presented (except for prompt backpropagation point)\n- The inclusion of type element is sensible, serving as a general guideline to narrow down the possible modeling choices for LLMs\n- The use of active nodes allows dynamically retrying at the specific levels, which is also a sensible design choice\n- The integration of knowledge-base for each level provides insights for revising incorrect formulations, akin to improvement-based local search\n\n## Weakness\n- The significance and novelty seem limited to me. Although all improvements to vanilla MCTS seem sensible, they are considered to be moderately important and novel from my perspective.\n- Prompt backpropagation is somewhat misleading. If I understand correctly, the authors use the critic to judge each node in the currently selected reasoning path, and then store the textual feedback to the knowledgebase of each level. If it is the case, there is no \"backpropagation\" happened because the operation can be localized into each individual layer, as long as the partial formulation and the full consequence visible to the critic.\n- The experiments are also not fully clear. How do you terminate your MCTS? How uncertainty threshold $\\eta$ affects the performance? Also, I am expecting the results of token consumption of each methods, which is crucial to ensure a fair comparison for test-time scaling methods.\n- A minor note: In line 216, $\\lambda_s$ should be $\\gamma_s$.", "was_revised": true, "final_justification": "The authors' rebuttal addressed my concerns. I therefore maintained my score.", "rebuttal": "We sincerely thank Reviewer 2ytH for the careful reading of our paper and for recognizing the overall quality of writing, as well as the soundness, practicality, and ingenuity of our method. The concerns raised mainly stem from questions about the significance of our work and specific methodological details, which we clarify in the following response.\n\n> ### [W1] Concern regarding the significance and novelty.\n\nWe understand the reviewer’s concerns regarding the novelty of our method and would like to clarify the challenges and contributions of our work.\n\n1. Uniqueness of the research challenge\n\nAutomatically converting natural language descriptions into high-quality optimization formulations is an inherently complex and long-standing open problem. It requires not only accurate semantic understanding but also guarantees that the generated formulations are executable by solvers and yield high-quality solutions. Compared to directly generating solutions, this task poses greater challenges in structured expression, cross-task generalization, and error correction.\n\n2. Novelty of our method\n\nOur contribution lies not only in improvements to MCTS itself but, for the first time, in combining dynamic expansion, prompt backpropagation, and uncertainty propagation into a test-time reasoning framework that synergizes with LLMs.\n\n+ Dynamic Expansion overcomes the traditional MCTS limitation of expanding only at leaf nodes, allowing formulation corrections at any tree leve and a larger search space to help solve more complex problems;\n+ Prompt Backpropagation transforms solver feedback into reusable semantic instructions that directly guide subsequent generation, a mechanism unexplored in existing MCTS-LLM integrations;\n+ Uncertainty Propagation explicitly models LLM output confidence during search, significantly enhancing inference stability and efficiency.\n\n3. From vanilla MCTS to a training-free framework\n\nRather than making incremental improvements to vanilla MCTS, we extend it into an unsupervised, training-free framework that deeply couples with LLMs to tackle cross-domain optimization modeling without reliance on additional annotation or fine-tuning. This approach offers a novel paradigm for applying test-time scaling methods to complex decision-making problems.\n\nWe believe overcoming these challenges and designing such a framework is not only technically innovative but also opens new possibilities for automation and generalization in optimization modeling.\n\n> ### [W2] Concern about prompt backpropagation.\n\nSolverLLM does not evaluate each node individually; instead, the evaluation of a formulation is based on the complete formulation. A partial formulation at a single level is meaningless on its own, which explains why the Simulation step is necessary in each MCTS iteration. Only with a complete formulation can we obtain a final score and evaluation used to assess the nodes along the path that constructed the current formulation.\n\nWe integrate Prompt Backpropagation into the Backpropagation phase of MCTS iterations. The critic can judge each node on the currently selected reasoning path only after a complete reasoning path has been obtained. Subsequently, the evaluation results, which consist of textual instructions, rewards, and uncertainty, are backpropagated accordingly.\n\n> ### [W3] Concern about the experiments.\n\nWe appreciate the reviewer’s thoughtful questions and will address them one by one:\n+ [Q: How do you terminate your MCTS? ] SolverLLM terminates either when reaching the maximum number of search iterations or when a full $n$-ary tree with the maximum number of nodes per layer $n$ is generated.\n+ [Q: How uncertainty threshold $\\eta$ affects the performance?] We supplemented a sensitivity analysis of the uncertainty threshold $\\eta$ on the MamoComplex and IndustryOR datasets, as shown below:\n\n**MamoComplex:**\n| η    | SA (%) | AGT (min) |\n|-----|---------|-----------|\n| 0.1 | 79.0    | 4.58      |\n| 0.2 | 78.0    | 4.22      |\n| 0.3 | 76.0    | 3.85      |\n| 0.4 | 73.0    | 3.54      |\n| 0.5 | 72.0    | 3.23      |\n\n**IndustryOR:**\n| η   | SA (%) | AGT (min) |\n|-----|---------|-----------|\n| 0.1 | 57.0    | 4.21      |\n| 0.2 | 56.0    | 3.54      |\n| 0.3 | 56.0    | 3.28      |\n| 0.4 | 54.0    | 3.12      |\n| 0.5 | 53.0    | 2.96      |\n\nIt can be observed that the uncertainty threshold $\\eta$ acts as a trigger: a lower $\\eta$ produces more local instructions, increasing computational cost but improving performance, while a higher $\\eta$ has the opposite effect.\n\n+ [Q: What's the results of token consumption of each test-time scaling methods?] We compared the token consumption of SolverLLM and AutoFormulation, two test-time scaling methods, as shown below:\n\n| # Search Iterations | SolverLLM (# Tokens / SA %) | AutoFormulation (# Tokens / SA %) |\n|-------------------|---------------------------|---------------------------------|\n| 10                | 32,790 / 69.0            | 35,911 / 34.0                  |\n| 20                | 40,920 / 76.0            | 43,150 / 37.0                  |\n| 30                | 49,337 / 77.0            | 54,427 / 38.0                  |\n| 40                | 57,834 / 78.0            | 62,248 / 38.0                  |\n| 50                | 66,312 / 78.0            | 70,245 / 40.0                  |\n\nSolverLLM achieves better performance than AutoFormulation while using fewer tokens at the same number of search iterations due to a more efficient search strategy. In the final version, we will explicitly report the token consumption curves over varying search budgets to further enhance result transparency and comparability.\n\n> ### [W4] Concern regarding a typo.\n\nThank you for your correction. We will address this issue in the final version.\n\nWe sincerely thank the reviewer 2ytH for the thoughtful feedback and look forward to further addressing any remaining questions and engaging in constructive discussion."}, {"review_id": "GH622yO6Al", "reviewer": "Reviewer_6kR9", "summary": "SolverLLM is a training-free, test-time–scaling framework that pairs a large language model with Monte Carlo Tree Search to translate natural-language optimization problems into mathematical formulations and solver-ready code.  Its search adds *dynamic expansion* (revisiting and refining partial formulations), *prompt backpropagation* (using solver feedback to guide later LLM prompts), and *uncertainty backpropagation* (down-weighting noisy rewards), all organized around a six-element schema (Type, Sets, Parameters, Variables, Objective, Constraints).  Across six standard benchmarks, SolverLLM surpasses state-of-the-art prompt- and learning-based baselines—improving solving accuracy by up to 10 percentage points while preserving near-100 % code-execution rates, and it does so without any additional training data or fine-tuning.", "questions": "* Section 3.2.1 still leaves the relationship between nodes granularity, the six-element schema, and a “complete path” ambiguous. Does one node correspond to a single element (e.g., Variables) or to a full partial formulation spanning several elements? What exactly constitutes a terminal path in the tree?\n* What is x^* on line 174? explain more about the objective_score and \"Optimality\" factor. Is there a solver output as ground truth ? what does it mean by \"estimate relative solution quality even in the absence of exact ground-truth labels or reference objectives\"?\n* How were the MCTS expansion depth, rollout count, and UCB hyper-parameters chosen? A sensitivity study would show whether SolverLLM’s gains persist under tighter time or compute budgets and ensure a fair comparison to prompt-only baselines.\n* How are all uncertainty signals combined, and why are all three necessary? Could they conflict or over-count uncertainty? Empirical evidence isolating each contribution would help establish whether the added complexity is warranted.", "limitations": "yes", "rating": 3, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 2, "significance": 2, "originality": 2, "strengths_and_weaknesses": "# Strengths\n\n* Achieves up to 10 pp absolute accuracy gains over state-of-the-art prompt- and learning-based baselines while preserving near-100 % executable code, showing practical value for real-world optimization tasks.\n* Integrates Monte Carlo Tree Search with three novel feedback mechanisms (dynamic expansion, prompt & uncertainty back-propagation) that demonstrably boost solving accuracy without any extra training.\n\n# Weaknesses\n\n* MCTS plus iterative solver calls increase test-time latency and resource consumption. The paper would benefit from concrete runtime and cost statistics to contextualize this overhead\n* I do understand that detail steps of MCTS could be complicate. Despite the detailed write-up already, several steps of the MCTS procedure remain opaque and would profit from clearer explanations or illustrative examples (see questions).\n* The design of prompt back-propagation offers limited novelty, as similar ideas—such as prompt reflection—have been explored in prior work [1][2]. \n* The design of uncertainty back-propagation is somewhat confusing. First, the method already employs the UCB algorithm to balance exploration and exploitation during the selection phase. Second, it uses predictive entropy during prompt back-propagation to determine whether a node should be “activated” for dynamic expansion; however, predictive entropy is generally not a reliable uncertainty metric for guiding selection [3] and it entangles with the UCB equation. Third, it introduces yet another uncertainty estimate by computing a semantic uncertainty score based on the variance of judge rewards from the LLM, and then applies a heuristic reweighting scheme using this variance. The interaction among these three overlapping uncertainty mechanisms feels unnecessarily complex and poorly motivated. Moreover, the repeated sampling required by this setup leads to significant computational overhead. According to Table 3, the ablation study suggests that uncertainty back-propagation contributes little to the overall performance.\n* The experimental comparison of prompt-based methods would be stronger if it incorporated additional MCTS-based baselines, which are more directly relevant to the proposed approach.\n\n\n\n1. Shinn, Noah, et al. \"Reflexion: Language agents with verbal reinforcement learning.\" Advances in Neural Information Processing Systems 36 (2023): 8634-8652.\n2. Zhou, Andy, et al. \"Language agent tree search unifies reasoning acting and planning in language models.\" arXiv preprint arXiv:2310.04406 (2023).\n3. Guo, Pei-Fu, Yun-Da Tsai, and Shou-De Lin. \"Benchmarking Large Language Model Uncertainty for Prompt Optimization.\" arXiv preprint arXiv:2409.10044 (2024).", "was_revised": true, "final_justification": "The rebuttal addressed some of my technical concerns, clarifying resource trade-offs, uncertainty mechanisms, and methodological details with helpful ablations. While I remain cautious about the overall complexity, limited evaluation breadth, and incremental novelty, the responses improved my confidence. I am therefore raising my score, though with some reservations about broader impact. However, due to some personal matters, I was unable to engage in deeper discussion during the rebuttal period, so I am lowering my confidence score.", "rebuttal": "We sincerely thank Reviewer 6kR9 for the thoughtful feedback and for recognizing both the practical value of our work in real-world scenarios and the methodological innovations. The concerns raised mainly stem from questions about methodological complexity, additional overhead, and the details and motivations of certain mechanisms. We provide point-by-point clarifications below.\n\n> ### [W1] Concern regarding the resource consumption.\n\nThe core idea of test-time scaling methods is to trade increased computation at test/inference time (rather than more training data or larger model parameters) for better performance. This inevitably increases test-time latency and resource consumption. Our paper already includes analysis of Average Generation Times (AGT) at 20 search iterations. Additionally, we provide statistics on token budget, Solving Accuracy (SA), and AGT of SolverLLM under different numbers of search iterations on the MamoComplex dataset:\n\n| # Search Iterations | Token Budget | SA (%) | AGT (min) |\n|-------------------|--------------|--------|-----------|\n| 10                | 32,790       | 69.0   | 2.54      |\n| 20                | 40,920       | 76.0   | 3.85      |\n| 30                | 49,337       | 77.0   | 4.82      |\n| 40                | 57,834       | 78.0   | 5.98      |\n| 50                | 66,312       | 78.0   | 6.73      |\n\nIt can be observed that there is indeed a trade-off between cost and performance. After balancing these factors, we chose 20 as the number of search iterations to achieve an acceptable cost consumption.\n\n> ### [W2] Concern about the detailed methodology.\n\nPlease refer to the answer to the questions.\n\n> ### [W3] Concern about the novelty of prompt backpropagation.\n\nWe thank the reviewer for highlighting the relevance to Reflexion [1] and LATS [2]. While Prompt Backpropagation (PB) shares the idea of using feedback to refine reasoning, its core innovation is enabling **Dynamic Expansion**, allowing the generation of new formulation candidates in an open-ended and context-aware manner. Our approach differs significantly in objectives and mechanisms scope:\n\n1. **Objectives**\n\n+ Reflexion [1] focuses on language-agent tasks via verbal reinforcement.\n+ LATS [2] unifies acting and reasoning in planning through tree search.\n+ Our work addresses solver-ready formulation construction for optimization, requiring both constraint feasibility and optimization objectives—challenges beyond standard language reasoning.\n\n2. **Mechanisms**\n\n+ PB integrates structured evaluation with uncertainty modeling, maintaining a node-level knowledge base to guide future generations.\n+ Unlike Reflexion’s single verbal feedback, PB forms a training-free reasoning mechanism deeply coupled with MCTS.\n+ Compared to LATS, PB provides MCTS with the critical Dynamic Expansion capability, innovating across the entire search process.\n\nIn summary, PB is not merely an adaptation of prompt reflection but a solver-aware, uncertainty-driven framework purpose-built for training-free optimization modeling.\n\n\n> ### [W4 & Q4] Concern about the introduction of uncertainty.\n\nWe use three types of uncertainty, each serving a distinct role without conflict:\n\n1. Uncertainty in Original UCB\n\nThe original UCB’s exploration term increases uncertainty for less-visited nodes, encouraging exploration of under-explored branches.\n\n2. Global Uncertainty\n\nLLM outputs, such as objective scores, have high variance causing unstable reward propagation. We use a sampling-based method to estimate semantic uncertainty as global uncertainty, which adjusts the UCB’s exploitation term via an uncertainty-weighted average, stabilizing backpropagation with controllable overhead.\n\n3. Local Uncertainty\n\nDuring Prompt Backpropagation, we estimate sentence-level uncertainty from LLM feedback using predictive entropy to assess reasoning reliability at the layer level. This local uncertainty helps filter out unreliable instructions during search, but it does not affect UCB calculations or node rewards.\n\nOverall, the uncertainties in the two UCB terms are computed independently, while local uncertainty exclusively supports the Prompt Backpropagation process. \n\nThe ablation study of the w/o UB variant shows that global uncertainty helps reduce time cost and slightly improve performance on more complex datasets, which is an important feature for real-world optimization. For local uncertainty, we additionally conducted experiments with a w/o local uncertainty variant on the MamoComplex dataset:\n\n| Method                | SA (%) | ER (%) | AGT (min) |\n|------------------------|--------|--------|-----------|\n| SolverLLM             | 76.0   | 99.0   | 3.85      |\n| w/o local uncertainty | 74.0   | 99.0   | 4.08      |\n\nThe results indicate that local uncertainty reduces the generation of uncertain or incorrect instructions, thereby improving solving accuracy while lowering time consumption. We will include the complete results of this ablation in the final version. \n\n\n> ### [W5] Concern regarding the MCTS-based baselines.\n\nAutoFormulation serves as the MCTS-based baseline, against which we compared SolverLLM and achieved superior performance. To the best of our knowledge, up to the completion of this work, no new MCTS-based test-time scaling methods for optimization problem have been proposed.\n\n> ### [Q1] Question about the relationship between nodes granularity, the six-element schema, and a \"complete path\".\n\nThe relationship between nodes, elements, and complete paths is best understood in the context of the full Monte Carlo Search Tree, as illustrated in Figures 4 and 5 of our paper. The search tree consists of six levels beyond the root, corresponding to the **six elements**: Type, Sets, Parameters, Variables, Objective, and Constraints. **Each node** corresponds to a single element, representing one possible modeling choice for that element conditioned on all its preceding nodes. Its main attributes include cumulative reward, visit count, partial formulation, and local uncertainty (see the `FormulationNode` class in `MCTS.py` for details). A partial formulation captures only the modeling of the current element; for instance, a node in the *Variables* level includes the variable formulation built upon the partial path formed by the preceding *Type, Sets,* and *Parameters* nodes. In contrast, a **complete path** refers to the sequence from the root to a leaf in the *Constraints* layer, encompassing one node from each level, thereby constructing a full solver-ready formulation of the optimization problem under the six-element schema.\n\n> ### [Q2] Question about the reward in Simulation stage.\n\nHere, $x^{\\*}$ denotes the output obtained by executing the formulation $f_s$, which has been translated into code and solved by a numerical solver. The **objective\\_score** function can be understood as prompting the LLM to act as a lightweight evaluator (or “judger”), leveraging both $f_s$ and $x^{\\*}$ to assign a scalar score between 0 and 100. The goal is to assess the *optimality* of $f_s$, that is, how well the solution aligns with the intent and structure of the formulation. A portion of the prompt is as follows:\n\n```\nThe task is to evaluate this formulation according to the following criteria:  \n1. Correctness: Does the formulation correctly model the problem described?  \n2. Completeness: Does the formulation include all necessary components?  \n3. Efficiency: Is the formulation efficient in terms of variables and constraints?  \n4. Solvability: Did the execution produce a correct solution?  \n5. Solution quality: Does the solution make sense for the given problem?  \n\nBased on your evaluation, provide a numerical score from 0 to 100, where:  \n- 0-20: Poor formulation with major flaws  \n- 21-40: Flawed formulation with significant issues  \n- 41-60: Adequate formulation with some issues  \n- 61-80: Good formulation with minor issues  \n- 81-100: Excellent formulation that correctly models the problem  \n```\n\nThe reason we describe this as *estimating relative solution quality even in the absence of exact ground-truth labels or reference objectives* is that the true ground-truth for each problem is unknown. Nevertheless, after each simulation generates a complete formulation, an evaluation is still necessary to assess its quality. Thus, we employ relative quality assessment based on the five dimensions of **Correctness, Completeness, Efficiency, Solvability, and Solution Quality**.\n\nWe will further refine this explanation in the final version to make the rationale more explicit, and we sincerely thank the reviewer for pointing this out.\n\n> ### [Q3] Question about the hyper-parameters.\n\nThe expansion depth of MCTS depends on the formulation modeling approach. As mentioned in Q1, we model the search tree as a six-level structure excluding the root node. Regarding the rollout count and UCB hyperparameters, we use a heuristic-based approach to determine them, with specific details provided in Appendix A.2 for reference.\n\nWe conducted a sensitivity analysis of the exploration weight $c$ in the UCB formula on the MamoComplex dataset, with the following results:\n\n| c   | SA (%) | AGT (min) |\n|-----|--------|-----------|\n| 0.1 | 69.0   | 2.75      |\n| 0.5 | 73.0   | 3.21      |\n| 1   | 74.0   | 3.68      |\n| 2   | 76.0   | 3.85      |\n| 5   | 77.0   | 4.45      |\n| 10  | 79.0   | 5.67      |\n\nWe observe that larger values of $c$ encourage more exploration, i.e., modeling new formulations. This improves performance but increases time consumption. Smaller $c$ favors reusing well-performing formulations, reducing time but limiting exploration of harder problems. Balancing this trade-off, we chose $c=2$ as UCB’s exploration weight. This analysis will be included in the final version.\n\nWe sincerely thank Reviewer 6kR9 for the valuable comments and hope our responses address your concerns. We look forward to further discussions to clarify any outstanding issues."}]

Author rebuttal:

Meta-review: This paper introduces SolverLLM, a training free framework leveraging LLM guided MCTS to generate solver-ready (e.g. Gurobi, Pyomo) optimization formulations from natural language descriptions at test time. The method introduces 1) dynamic expansion for incremental formulation construction - producing new open ended and context aware child nodes, 2) prompt backpropagation for solver feedback guided refinement, and 3) uncertainty backpropagation for improving search robustness. Experiments on six optimization datasets show consistent improvement over prompt based and test time scaling baselines.

Strengths: 
The paper addresses an important problem of converting natural language descriptions to solver ready optimization formulations. The experiments show significant gains across diverse benchmarks outperforming strong baselines such as AutoFormulation.

Weaknesses:
Several reviewers asked for more systemic test time complexity, scaling curves, solver time cost, runtime statistics, and token cost comparisons 

Some connections to prior work (Reflexion, LATS) should be clarified to highlight the relative contribution - reviewer `6kR9'

Clarify of exposition regarding MCTS procedure and relationship between node granularity, six-element schema (Type, Sets, Parameters, Variables, Objective, and Constraints in section 3.2.1) could be improved for readability.

The authors provided additional experiments on scaling behavior, token consumption which addressed many concerns raised by the reviewers. Several reviewers increased their scores after these clarifications. While some reservations remain about complexity and broader applicability, the consensus was that the contributions are sufficiently novel and the empirical results are significant.

The decision is to accept. I strongly encourage the authors to incorporate the feedback - include the scaling and token-budget analyses (every new experiments appeared in the rebuttal as per reviewer `BcrF`), clarify the MCTS details in section 3.2.1, distinct role of each uncertainty mechanisms, and clarify the contribution with respect to the related approaches.
Decision: Accept (poster)