Source-linked AI summary

AlphaOPT: Formulating Optimization Programs with Self-Improving LLM Experience Library

Minwei Kong, Ao Qu, Xiaotong Guo, Wenbin Ouyang, Chonghe Jiang, Han Zheng, Yining Ma, Dingyi Zhuang, Yuhan Tang, Junyi Li, Shenhao Wang, Haris Koutsopoulos, Hai Wang, Cathy Wu, Jinhua Zhao

arXiv:2510.18428v4cs.AI

TL;DR

Optimization formulation remains difficult because ambiguous natural-language problems must be translated into precise models and executable solver code, while existing prompting and retraining approaches have limitations. AlphaOPT learns and refines solver-verified insights without parameter updates; it reports state-of-the-art results on LogiOR and OptiBench and strong out-of-distribution generalization. Its results are subject to an answer-value verification caveat: a small number of incorrect programs reached the correct objective value.

  • Problem

    Optimization modeling remains difficult to automate, and prior experience-reuse methods lack explicit applicability semantics, rigorous validation, and systematic cross-task refinement.

    Source: §1 · p. 2
  • Method

    AlphaOPT builds a hierarchical library of solver-verified insights from failed tasks and refines their applicability conditions using evidence aggregated across tasks, without updating model parameters.

    Source: §1 · p. 2, §3 · p. 4
  • Results

    AlphaOPT achieves state-of-the-art performance on LogiOR and OptiBench and demonstrates strong out-of-distribution generalization.

    Source: §1 · p. 2
  • Takeaways & Limitations

    The framework provides interpretable, auditable knowledge transfer that exposes LLM failure patterns across domain modeling, formulation, and solver syntax.

    Source: §6 · p. 9

    Auditing found three spurious passes (0.8%) where incorrect programs reached the correct optimal value; stronger safeguards are left to future work.

    Source: §4.2 · p. 7

Abstract

from arXiv · show

Optimization modeling underlies critical decision-making across industries, yet remains difficult to automate: natural-language problem descriptions must be translated into precise mathematical formulations and executable solver code. Existing LLM-based approaches typically rely on brittle prompting or costly retraining, both of which offer limited generalization. Recent work suggests that large models can improve via experience reuse, but how to systematically acquire, refine, and reuse such experience in structurally constrained settings remains unclear. We present \textbf{AlphaOPT}, a self-improving experience library that enables LLMs to learn optimization modeling knowledge from limited supervision, including answer-only feedback without gold-standard programs, annotated reasoning traces, or parameter updates. AlphaOPT operates in a continual two-phase cycle: a \emph{Library Learning} phase that extracts solver-verified, structured insights from failed attempts, and a \emph{Library Evolution} phase that refines the applicability of stored insights based on aggregate evidence across tasks. This design allows the model to accumulate reusable modeling principles, improve transfer across problem instances, and maintain bounded library growth over time. Evaluated on multiple optimization benchmarks, AlphaOPT steadily improves as more training data become available (65\% $\rightarrow$ 72\% from 100 to 300 training items) and outperforms the strongest baseline by 9.1\% and 8.2\% on two out-of-distribution datasets. These results demonstrate that structured experience learning, grounded in solver feedback, provides a practical alternative to retraining for complex reasoning tasks requiring precise formulation and execution. All code and data are available at: https://github.com/Minw913/AlphaOPT.

1 Introduction

Optimization modeling is difficult to automate because ambiguous natural-language specifications must become precise formulations, code, and solver-backed decisions. AlphaOPT learns structured, solver-verified modeling insights and refines their applicability; experiments report strong benchmark performance and out-of-distribution generalization.

1 Introduction

  • Automating optimization requires translating informal, often ambiguous specifications into precise, domain-specific formulations paired with suitable code and solvers.This translation remains a major bottleneck for end-to-end automation.Source: §1 · pp. 1–2
  • Experience-reuse methods often lack explicit applicability semantics, rigorous replay-based validation, and organization suited to diverse optimization insights.Applying mismatched experiences can be detrimental.Source: §1 · p. 2
  • AlphaOPT organizes solver-verified modeling insights in a self-updating hierarchical taxonomy and refines applicability using evidence aggregated across tasks.Its library-learning phase extracts insights from failed tasks, including when gold-standard programs are unavailable.Source: §1 · p. 2
  • AlphaOPT achieves state-of-the-art performance across multiple benchmarks, strong out-of-distribution generalization, and continual performance growth with converging library size.The experiments require no gold-standard formulation or program.Source: §1 · p. 2

2 Related Work

Prior optimization systems use prompting, training, or experience reuse, but challenges remain in sustained improvement, explicit applicability, verification, and cross-task generalization. AlphaOPT’s two-phase library cycle extracts insights and refines their applicability using evidence across tasks.

2.1 LLMs for Solving Optimization Problems

  • Prompt-based and training-based systems guide formulation or improve robustness, but prompting lacks sustained knowledge injection and training relies on data-intensive pipelines.The surveyed prompting examples include multi-role decomposition and retrieval-augmented agent workflows.Source: §2.1 · pp. 2–3
  • Prompt-based systems can plateau under distribution shift, while training-based approaches rely on high-quality, diverse data and can be difficult to interpret or audit.The section also notes that current methods remain insufficient for reliable deployment and sustained improvement in real-world operations research systems.Source: §2.1 · p. 3

2.2 Decision-making Tasks with Experience Learning

  • Experience learning reuses episodic traces or semantic insights across interactive decision-making, code tasks, and multi-step reasoning.Examples include Reflexion’s stored verbal reflections and ExpeL’s exemplars and insights.Source: §2.2 · p. 3
  • Existing experience-learning frameworks often lack explicit, verifiable applicability conditions, strict semantic verification, and systematic cross-task assessment of insight effects.These gaps increase negative-transfer risk and leave libraries without a mechanism to detect when locally useful insights degrade performance on broader task sets.Source: §2.2 · p. 3

3 Methodology

AlphaOPT addresses scarce gold-standard formulations and the challenge of learning when modeling rules apply. It acquires solver-verified insights from failed tasks, refines their conditions using cross-task evidence, and frames library construction as balancing task success with library complexity.

3 Methodology

  • AlphaOPT builds a library of reusable insights with explicit applicability conditions and iteratively refines those conditions at the population level.The two phases acquire insights from individual failed tasks and diagnose cross-task misalignments to reduce overgeneralization.Source: §3 · pp. 3–4

3.1 Library Learning

  • Failed-task exploration produces structured insights, which undergo retrieval and execution verification before storage in a dynamically expanding, hierarchical taxonomy.Insights are represented by taxonomy, condition, explanation, and example; online merging checks redundancy and validates correctness on associated tasks.Source: §3.1 · p. 4

3.2 Library Evolution

  • Library Evolution diagnoses positive, misleading, and beneficial-but-unretrieved task interactions, then tests refined conditions against the associated task set.Candidate conditions are selected when they improve the score combining kept positives, corrected negatives, and recovered unretrieved tasks.Source: §3.2 · p. 5

3.3 Optimization Perspective

  • The optimization perspective balances task success against library complexity, with convergence to a local optimum argued under boundedness, sufficient exploration, solver verification, and bounded merging.The authors present this as a principled justification rather than a strict theorem, given natural-language ambiguity and stochastic LLM outputs.Source: §3.3 · p. 6

4 Experiments

The experiments assess cross-domain generalization, component contributions, improvement with more training data, and library convergence. AlphaOPT performs strongly across benchmarks, and its structured retrieval and refinement support continued gains as the library stabilizes.

4.1 Experimental Setup

  • The experiments use 452 instances from four optimization datasets, with stratified 70/30 train-test splits and separate out-of-distribution evaluation on LogiOR and OptiBench.The library is built only from training tasks, and the experiments exclude instances labeled erroneous.Source: §4.1 · p. 6
  • GPT-4o at temperature 0 is the default backbone; success rate is primary, with micro- and macro-averaged accuracy also reported across prompt-design, fine-tuning, and experience-learning baselines.The baseline comparison includes OptiMUS, ORThought, ORLM, LLMOPT, Reflexion, and ExpeL.Source: §4.1 · p. 7

4.2 Overall Performance

  • AlphaOPT achieves the best performance on IndustryOR and LogiOR, exceeding the second-best method by an average of 6%.It also consistently outperforms most baselines on test splits, with ORLM higher only on NL4OPT.Source: §4.2 · p. 7
  • Transferring AlphaOPT’s library to fine-tuned LLMOPT yields a 6% average gain, while AlphaOPT achieves competitive results using answer labels rather than detailed formulation and code annotations.The paper characterizes fine-tuning and the external library as complementary mechanisms.Source: §4.2 · p. 7
  • On unseen LogiOR, AlphaOPT reaches 56.0% versus ORLM’s 19.6% and retrained LLMOPT’s 27.2%; it reaches 93.5% on OptiBench.Both datasets were not seen during training.Source: §4.2 · p. 7

4.3 Ablation Study

  • Removing applicability conditions costs 3.6 and 4.3 test micro- and macro-accuracy points; removing taxonomy costs 4.1 OOD macro points, while embedding retrieval costs 4.9 test micro and 5.4 OOD macro points.The paper attributes the embedding-retrieval drop to surface-text matches that can miss logical applicability.Source: §4.3 · p. 7
  • Without refinement, test micro- and macro-accuracy fall 6.8 and 9.2 points; removing insight examples costs 4.1 and 6.6 points, and 17.7 on MAMO (ComplexLP).The refinement-related declines also occur on out-of-distribution data; the largest reported refinement degradation is on structurally complex datasets.Source: §4.3 · p. 7

4.4 Continual Growth and Library Convergence

  • Out-of-distribution accuracy on LogiOR and OptiBench improves with training size without parameter updates, while accuracy converges and library growth stabilizes.Once the library stabilizes, additional tasks are largely absorbed by existing insights and token cost grows sub-linearly with dataset size.Source: §4.4 · p. 8, Figure 4 · p. 8

5 Library Analysis

The library organizes modeling and implementation knowledge in a three-track taxonomy, exposing recurring LLM error patterns. Refinement adjusts insight applicability using task associations and semantic conditions.

5.1 Library Taxonomy and Knowledge

  • Figure 5 shows that the experience library taxonomy consists of three main tracks, 14 level-1 labels, and 38 level-2 labels; percentages shown in red indicate their proportions.Source: Figure 5 · p. 8
  • Domain-modeling errors often involve structural coupling and global balance, especially in Resource Allocation (38.9%), Network Flow (31.9%), and Production Planning (12.5%).Production-planning formulations may fail to couple machine-level decisions with inter-temporal inventory balance.Source: §5.1 · p. 8
  • General-formulation errors concentrate in Variable Definition (66.7%), Constraint Formulation (16.7%), and Unit Scaling (11.9%), including unclear variable domains and inconsistent units.At-least/at-most constraints may be modeled as equalities or strict inequalities, producing overly restrictive formulations.Source: §5.1 · pp. 8–9
  • In the Code Implementation track, 76% of errors stem from Solver & API Syntax and 24% from Data I/O & Validation.Examples include confusion between quicksum and sum, key errors, index mismatches, and matrix-dimension errors.Source: §5.1 · p. 9

5.2 Examples of Library Refinement

  • Refinement generalizes across equivalent phrasings, adds positive lexical anchors, excludes misaligned tasks, and applies structural qualifiers; these changes reduce negative and unretrieved cases while preserving most positive cases.Examples include broadening single-scalar-capacity coverage while excluding multi-capacity settings, and tightening flow/conservation conditions.Source: §5.2 · p. 9, Figure 6 · p. 9

6 Conclusion and Discussion

AlphaOPT uses a self-updating taxonomy of solver-verified, condition-aware insights, refined with cross-task evidence. The paper identifies larger real-world problems and more efficient algorithms as priorities for practical deployment.

6 Conclusion and Discussion

  • AlphaOPT organizes optimization experience as a self-updating taxonomy of structured insights, generated and updated under solver verification and refined using cross-task evidence.The conclusion reports learning from answer labels alone and interpretable, auditable knowledge about recurring LLM failure patterns.Source: §6 · p. 9
  • Scaling to large real-world industrial problems and moving beyond correctness toward more efficient algorithms are identified as crucial for practical deployment.The paper also points to reasoning-oriented test-time scaling and composable agent skills as promising directions.Source: §6 · p. 9

A Proof of the Library Convergence

The refinement procedure reaches libraries that are locally optimal for the testing objective when training and testing distributions coincide, under either finite or compact-library assumptions.

A Proof of the Library Convergence

  • F balances expected task–library matching reward against a penalty for library complexity.The reward measures matching quality, and the complexity term is bounded.Source: A Proof of the Library Convergence · p. 11
  • Accepted merge and exploration steps strictly increase F; sufficient exploration eventually discovers improving neighbors, while bounded reward and complexity keep F bounded.A merge reduces library complexity without decreasing reward for relevant tasks; exploration improves reward for some tasks without increasing complexity.Source: A Proof of the Library Convergence · p. 11
  • With identical training and testing distributions, a finite library yields finite termination at a testing-objective local maximizer, never a saddle point.The proof also establishes that only finitely many strict improvements are possible.Source: A Proof of the Library Convergence · p. 11
  • For a compact library and continuous objective, the objective sequence converges and every subsequential limit is a testing-objective local maximizer, not a saddle point.The paper also gives this infinite-library case for completeness.Source: A Proof of the Library Convergence · p. 11

B.1 Datasets

The appendix describes the datasets, contrasts prior experience-learning insights with AlphaOPT’s broader transfer, and reports results on code-generation benchmarks beyond optimization formulation.

B.1 Datasets

  • Each dataset pairs a natural-language problem description with an optimal solution; NLP4LP and IndustryOR training gold programs come from Yang et al. [29], with cleaned releases from Astorga et al. [2].The dataset table’s Size column reports size after cleaning.Source: §B.1 · p. 11

B.2 Insights Learned Through Baseline Experience Learning Methods

  • ExpeL’s learned insights emphasize general modeling hygiene but omit explicit applicability conditions, domain-specific patterns, and solver-level details, limiting guidance for specific formulation or implementation errors.Examples include flow conservation, inventory balance, and fixed-charge activation patterns.Source: §B.2 · p. 12

B.3 Generalization Beyond Optimization Formulation

  • +7.0 on CO-Bench and +27.3 on HumanEval; AlphaOPT transfers beyond optimization formulation to algorithm/heuristic design and general-purpose code generation.The held-out evaluations use a lightweight GPT-4o-mini backbone; the learned libraries contain 28 and 46 insights, respectively.Source: §B.3 · p. 12, Table 4 · p. 12

B.4 Experimental Cost and Scalability

Library construction incurs an average cost around $0.1 per instance, while reuse and library convergence reduce the marginal cost of additional tasks.

B.4 Experimental Cost and Scalability

  • Around $0.1 per instance is incurred when building the library and amortized over later reuse; diagnosis–refinement typically converges within five rounds.Testing is substantially cheaper because it involves solution generation and insight reuse.Source: §B.4 · p. 12
  • As the library converges, most new tasks use existing insights rather than triggering another learning–diagnosis–refinement cycle, so marginal cost per task decreases.The cost does not grow linearly with dataset size.Source: §B.4 · p. 12
  • Representative-instance sampling and failure-threshold gating are proposed to improve large-scale efficiency.Sampling lowers training cost without meaningfully diminishing experiential-learning gains; gating focuses computation on still-failing tasks.Source: §B.4 · p. 12

B.5 Insight Distribution

The insight library’s distributions show that its tracks capture different recurring challenges, with contributions varying across the four training datasets. Capacity balancing dominates Domain Modeling, while variable-definition issues are most frequent in General Formulation and implementation insights are least numerous.

B.5 Insight Distribution

  • Domain Modeling insights most often concern Resource Allocation – Capacity/Resource Balance Equations, contributed by all four datasets, especially NLP4LP and Industry OR.These insights address constraints that keep resource usage within available capacity.Source: §B.5 · p. 12
  • Variable Definition labels—Explicit Bounds, Redundant Auxiliary Variable, and Continuous vs. Discrete Confusion—are most frequent in General Formulation, reflecting recurring issues across datasets.These issues concern variable types, value ranges, and modeling simplifications, which LLMs may mishandle when overlooking structural or physical consistency.Source: §B.5 · pp. 12–13
  • Code Implementation has the fewest insights, led by Solver & API Syntax – Nonlinear Constraint Handling and Data I/O & Validation – KeyError & Index Mismatch, mainly from MAMO (Complex LP) and NLP4LP.These categories point to solver-syntax compatibility and data accessibility challenges.Source: §B.5 · p. 13
  • Industry OR contributes most to Domain Modeling; MAMO (Complex LP) and Industry OR lead in General Formulation, while MAMO (Complex LP) and NLP4LP lead in Code Implementation.Although Industry OR and MAMO (Complex LP) are about half the size of the other library-learning datasets, they contribute many insights, which the authors associate with denser structural challenges and diverse error patterns.Source: §B.5 · p. 13

B.6 Success and Failure Case Study

Retrieved insights help solve new tasks in about half of evaluated cases, but some fail through misapplication or remain unusable when the LLM cannot operationalize them. The analysis also identifies a boundary: the current library does not adequately cover complex, interacting out-of-distribution structures.

B.6 Success and Failure Case Study

  • High-success insights cluster in Code Implementation – Solver & API Syntax and General Formulation – Variable Definition, targeting clear code or foundational modeling errors.Examples include replacing unsupported strict inequalities with non-strict forms and assigning explicit variable bounds.Source: §B.6 · p. 13
  • 70% of Fixed Charge (Big-M Linking) insights fail; applying Big-M without conditional activation can add redundant constraints, while overly rigid explicit bounds can restrict feasible solutions.The authors also report that some unnecessary upper bounds produce suboptimal solutions.Source: §B.6 · pp. 13–14
  • About half of retrieved insights help solve new tasks, while only a small portion introduce errors; outcomes vary across Level-1 taxonomy labels.The comparison excludes tasks that succeed both with and without retrieval; Figure 8 summarizes overall outcomes and proportions by taxonomy label.Source: §B.6 · p. 13, Figure 8 · p. 14
  • High-invalid-rate insights occur mainly in Resource Allocation and Production Planning: the LLM may retrieve a relevant insight but fail to translate it into executable formulas or solver implementations.For nonlinear constraints, it may omit auxiliary variables or misrewrite proportional constraints.Source: §B.6 · p. 14
  • Some LogiOR tasks remain beyond the library’s scope: interacting spatiotemporal constraints in routing, scheduling, and network flow exceed its mainly static, linear formulation knowledge.The authors identify insufficient taxonomy granularity and depth for such complex logic.Source: §B.6 · p. 14
  • The authors identify retrieval precision, insight clarity, execution effectiveness, and adaptation to unseen complex optimization scenarios as improvement targets.They also suggest expanding operations-research datasets around LLM error typologies.Source: §B.6 · p. 14

B.7 Specification of Library Taxonomy Labels

This section defines a taxonomy of optimization-modeling pitfalls and prompts for diagnosing failed programs, extracting and retrieving reusable insights, and refining their applicability. The prompts ground labels and applicability decisions in problem-specific evidence, including positive and negative task evidence, and emphasize precise, nonredundant issues and cases where insights could mislead.

B.7 Specification of Library Taxonomy Labels

  • Each level-2 label receives an LLM-generated condition when introduced, which later insights under that label inherit.The appendix lists conditions that define when each label applies and clarify its meaning.Source: §B.7 · p. 14, Table 6 · p. 15
  • The taxonomy covers variable-definition pitfalls, constraint translations and linearization, objective ambiguity, unit mismatches, and Big-M calibration.Examples include discrete-versus-continuous confusion, explicit bounds, relational operators, makespan versus total completion time, and deriving realistic bounds for M.Source: §B.7 · p. 16
  • It also labels solver-syntax and data-validation issues, including summation operators, strict inequalities, binary variables, constraint expressions, variable bounds, index mismatches, and missing-data defaults.Source: §B.7 · p. 16

C Prompts For LLM Modules

  • The self-exploration prompt asks the model to revise failed Gurobi programs using execution feedback and an optimal objective value, while prioritizing the problem description and rejecting unsupported assumptions or forced matches.If the supplied objective value appears inconsistent, the prompt says to retain the correct runnable formulation rather than force agreement.Source: C Prompts For LLM Modules · p. 17
  • The insight-generation prompt compares a failed model with a gold-standard program and requests concise lessons with taxonomy, condition, explanation, and wrong-versus-correct example fields.It prefers existing labels, allows new labels when needed, and distinguishes domain-specific modeling from domain-agnostic formulation practices.Source: C Prompts For LLM Modules · pp. 18–19
  • The retrieval prompt uses a diagnosed issue and failed model to select potentially applicable existing labels from Domain Modeling and General Formulation taxonomies.It permits multiple applicable labels and requires null when no label applies.Source: C Prompts For LLM Modules · pp. 20–21
  • Candidate insights are retained only when they directly address diagnosed issues, supported by concrete evidence and ranked by applicability.The task asks for an explanation of how each selected insight helps fix the specific modeling issue.Source: C Prompts For LLM Modules · p. 22
  • Insight conditions specify both applicability and inapplicability, so selection considers problem domains, modeling techniques, pitfalls, exclusion scenarios, and redundancy.The prompt says to exclude insights that would mislead in stated exclusion scenarios and keep only the most relevant overlapping insights.Source: C Prompts For LLM Modules · p. 23
  • Diagnosis compares failed and gold-standard formulations to identify independent root-cause issues at specific snippets, merging defects that share a correction.Variable names should be aligned using the problem specification, and reported issues should directly affect optimality.Source: C Prompts For LLM Modules · pp. 24–25
  • Insights are labeled positive, invalid, negative, or irrelevant according to correctness, adoption, and impact on formulation quality or risk.The prompt directs the model to judge correctness, check adoption, assess effects on correctness or identified issues, and map the result to one of four labels with supporting evidence.Source: C Prompts For LLM Modules · p. 26
  • The insight-selection prompt retains only insights that address diagnosed modeling issues, requires concrete evidence from the problem and diagnosis, and ranks selected insights by applicability.Its required output is a JSON array containing insight IDs, ranks, and evidence.Source: C Prompts For LLM Modules · pp. 22, 27
  • The condition-refinement prompt seeks to exclude negative-task cases, capture relevant unretrieved tasks, and preserve the original insight’s coverage through distinct refinement strategies.It consolidates applicability and inapplicability conditions, preserves the original condition verbatim, and proposes strategies such as broad rules, OR lists, must-have pairs, explicit-information requirements, keywords, and narrower scope.Source: C Prompts For LLM Modules · pp. 28–29
Loading 2510.18428v4…