PaperlayerView exact revision on arXiv

Source-linked AI summary

Right Answers, Costly Models: The Efficiency Gap in LLM-based Optimization Modeling

Zhong Li, Xin Huang, Jinhui Wan, Xiangyi Wang, Shenkai Zhang, Ruiqi Chen, Wenyu Liu, Zaiwen Wen, Ziyan Luo

arXiv:2609.38884v1cs.LGcs.AI

TL;DR

Correct optimization models can still be costly to construct and solve, and it is unclear whether LLMs can recognize problem structure and choose efficient modeling techniques. The paper builds a benchmark with paired ordinary and expert references to evaluate that ability. Across the 11 evaluated LLMs, most programs with correct objective values take longer to solve than their expert counterparts on comparable tasks.

  • Problem

    LLM optimization modeling needs evaluation beyond executability and numerical correctness because construction and solving time and memory can limit practical problem sizes.

    Source: §1 · p. 2

  • Method

    The authors curate 50 expert techniques in OptTips and use the six-agent OptDachshund framework to build EfficientOpt, a 561-task benchmark with paired references.

    Source: §1 · p. 3, §3.2 · p. 5, §5 · p. 9

  • Results

    Across the 11 evaluated LLMs, most programs returning correct objective values take longer to solve than expert implementations on comparable task subsets.

    Source: §1 · p. 3, §5 · p. 10

  • Takeaways & Limitations

    Optimization modeling should be assessed for both solution correctness and computational cost, since smaller formulations can still solve more slowly and preparation can offset faster solving.

    Source: §5 · p. 10

Abstract

from arXiv · show

Optimization modeling formulates real-world decision problems as mathematical programs that solvers can use to find optimal decisions. Large language models (LLMs) can automate this process, but the resulting correct formulations can require substantial time and memory to construct and solve, limiting practical scalability. Therefore, we systematically investigate whether LLMs can identify problem structure from natural-language descriptions and apply suitable optimization modeling techniques to generate mathematical models and solver code that solve the problems correctly and efficiently. To this end, we first curate OptTips, a knowledge base of 50 expert modeling techniques in eight families. Using this knowledge, we develop OptDachshund, a multi-agent framework that transforms problems from existing optimization benchmarks into new tasks for evaluating LLMs' use of modeling techniques. It constructs conventional and expert mathematical models with solver code for the same task and data, providing baselines for correctness and computational cost. The resulting EfficientOpt benchmark contains 561 expert-reviewed tasks with paired reference implementations. Evaluation of 11 representative LLMs reveals an efficiency gap on correctly solved tasks with comparable measurements: for every LLM, most generated programs take longer to solve than their expert counterparts. Within the comparable reference-size subset, 57\% of programs with correct objective values and fewer variables and linear constraints have longer recorded solver times. Case studies show that different modeling techniques can achieve the same optimal value at similar recorded cost. Faster solving may not reduce execution time if the code takes longer to prepare data and build the model. LLM optimization modeling should therefore be evaluated for both correctness and computational efficiency.

1 INTRODUCTION

LLMs can produce numerically correct optimization models whose computational costs remain high, motivating a benchmark that tests whether they exploit problem structure.

1 INTRODUCTION

  • Executability and numerical correctness alone do not establish efficiency because alternative formulations of the same problem can have sharply different computational costs.Loose Big-M constants, unnecessary integrality, and unexploited symmetry can increase solver effort.Source: §1 · p. 2
  • The study asks whether LLMs can recognize problem structure and use suitable modeling techniques to obtain correct solutions at lower computational cost.The introduction notes that efficiency-focused prompting alone does not guarantee an effective reformulation.Source: §1 · p. 2
  • Paired ordinary and expert references on identical data let the authors assess modeling choices beyond answer correctness.The references provide conventional and technique-informed formulations with solver code for the same task and data.Source: §1 · p. 3
  • OptTips, OptDachshund, and EfficientOpt provide expert techniques, a task-construction framework, and 561 tasks with paired references.The paired references support comparisons of correctness, technique use, and computational cost.Source: §1 · p. 3
  • For every evaluated LLM, most programs with correct objective values take longer to solve than expert implementations.Figure 1 also illustrates matching optimal values with about 236× and 178× the expert solver time in two GPT-5.5 case studies.Source: Figure 1 · p. 2, §1 · p. 3

2 RELATED WORK

Related work uses expert knowledge to guide optimization modeling and evaluates modeling quality or efficiency; this paper adds technique-specific paired references for task evaluation.

2 RELATED WORK

  • OptiMind and OptSkills use expert knowledge to guide training, inference, or reusable workflows, while this paper turns individual techniques into evaluation-task specifications.OptTips specifies applicability conditions and modeling actions, which OptDachshund uses to build test problems and paired references.Source: §2 · p. 3
  • SAGE uses correctness and solver-efficiency feedback, whereas FrontierOR compares algorithm quality and runtime against one Gurobi reference per task.The cited evaluations do not provide a conventional/expert pair tied to a designated modeling technique.Source: §2 · p. 4
  • EfficientOpt pairs conventional and expert references on identical data to distinguish technique adoption from implementation efficiency and assess construction and solving costs separately.It also recognizes that efficient solutions may use techniques other than the designated one.Source: §2 · p. 4

3 BENCHMARK CONSTRUCTION

The benchmark construction combines expert modeling knowledge, multi-agent task redesign, and validation to produce tasks with paired conventional and expert references.

3 BENCHMARK CONSTRUCTION

  • The benchmark defines a task by its natural-language problem, fixed numerical input, and required outputs; a valid procedure must respect semantics and satisfy those outputs.Efficiency concerns the time and memory to produce and execute a valid procedure, with resource scope and execution conditions stated.Source: §3 · p. 4

3.1 OPTTIPS: EXPERT MODELING KNOWLEDGE

  • OptTips curates 50 modeling techniques across eight methodological families, with structured cards linking problem patterns and inefficiency symptoms to modeling actions.The tight Big-M example derives M = 4 from bounds, replacing M = 8 while preserving binary feasible solutions.Source: §3.1 · p. 5

3.2 OPTDACHSHUND: MULTI-AGENT BENCHMARK CONSTRUCTION

  • OptDachshund’s six agents work in three stages: match and reformulate, audit and repair, then build and validate paired references.The workflow uses solver verification and independent expert review; failed checks trigger revision, while unresolved candidates are rejected.Source: §3 · pp. 4–5, Figure 2 · p. 4, §3.2 · p. 5
  • The audit checks task clarity, formulation correctness, technique applicability, duplicates, and hints; reference audits and expert reviews check code, formulations, and solver results.At least two experts independently review each candidate, with a third resolving substantive disagreements.Source: §3.2 · p. 6

3.3 EFFICIENTOPT: BENCHMARK COMPOSITION AND INTERFACE

  • EfficientOpt contains 561 tasks spanning problem classes and application fields, with ordinary and expert references of varied formulation types and sizes.Expert references have fewer variables in 43.1% of pairs and fewer constraints in 51.0%.Source: §3.3 · pp. 6–7
  • Each task gives an LLM a problem statement and input-data schema for executable solver code, while hiding technique labels, references, and validation records.Ordinary and expert references use the same task and data, enabling separate checks of numerical answers, technique use, and construction and solver costs.Source: §3.3 · p. 7

4 EXPERIMENTS

Across the experiments, the authors evaluate numerical correctness and computational costs alongside modeling choices. Correct answers can still be costly, and formulation size, model preparation, generation latency, and memory provide distinct views of that cost.

4.1 EXPERIMENTAL SETUP

  • The evaluation covered 11 general-purpose LLMs on all 561 tasks, with each task run three times under the same machine and settings.A run counted as numerically correct when Gurobi returned OPTIMAL and its finite objective matched the verified reference within 10^-6 absolute and relative tolerances.Source: §4.1 · p. 7, §4 · p. 7

4.2 NUMERICAL OUTCOMES VARY ACROSS TASKS (RQ1)

  • Among the five column-generation tasks, accuracy across evaluated models was 27.3%, compared with 93.9% on tasks that split into independent subproblems.An OPTIMAL status alone did not guarantee a correct objective: 338 of 4,602 such programs returned incorrect values.Source: §4.2 · p. 8

4.3 CORRECT ANSWERS CAN STILL BE COSTLY (RQ2)

  • For every LLM, the slowest ∼10% of correctly solved runs consumed 68.4–76.2% of total Runtime.Median runtimes were 23.1–36.0 seconds, while summed Runtime per model was 12.0–27.7 hours.Source: §4.3 · p. 8, Figure 6 · p. 8

4.4 MODELING CHOICES AND SOLVER EFFICIENCY (RQ3)

  • Of 735 numerically correct outputs with smaller formulations than their expert references, 449 (61.1%) took longer to solve.Model size does not fully capture solver difficulty; Figure 7(a) presents the smaller-formulation comparison.Source: §4.4 · p. 9, Figure 7 · p. 9
  • In department relocation, the expert used continuous interaction variables to reduce the binary count from 5,472 to 288; LLMs identified the designated or an equivalent technique in 46.3% of programs.Another technique was identified in 24.6%; these labels do not establish correctness or speed.Source: §4.4 · p. 9

4.5 SOLVING IS ONLY PART OF THE COST (RQ4)

  • Adding Build time reversed the LLM–expert speed comparison in 8.6% of 4,148 pairs, and 17.3% of 4,202 correct runs spent longer on Build than optimization.Such reversals occurred for all 11 LLMs.Source: §4.5 · p. 9
  • Generation took longer than Build+opt in 55.6% of 4,202 correct runs with both measurements.The share was 76.2% for Qwen 3.6 27B and 74.1% for Qwen 3 32B.Source: §4.5 · p. 9
  • Across 4,202 correct runs, median Gurobi peak memory was 0.135 GB, while the 90th percentile was 2.314 GB and 224 runs (5.3%) reached at least 4 GB.Typical memory use can therefore mask demanding cases.Source: §4.5 · p. 9

5 DISCUSSION AND CONCLUSION

The discussion presents OptTips, OptDachshund, and EfficientOpt as contributions to optimization-modeling evaluation. It situates them alongside work on model generation, reusable expertise, and benchmarks, while distinguishing technique-guided task construction from knowledge used to assist generation.

5 DISCUSSION AND CONCLUSION

  • EfficientOpt pairs ordinary and expert implementations on the same instances, enabling separate assessment of numerical correctness, technique use, and computational cost.Across 11 evaluated LLMs, correctly answered programs used less aggregate Gurobi solver time than ordinary references but more than expert references on comparable task subsets.Source: §5 · pp. 9–10

A EXTENDED RELATED WORK

  • The related-work discussion frames the paper’s contributions across model generation, reusable modeling knowledge, benchmarks and verification, and computational efficiency.It notes that trained models may also use search, retrieval, and solver feedback during inference.Source: A EXTENDED RELATED WORK · p. 14

A.1 GENERATING AND REFINING OPTIMIZATION MODELS

  • Prior model-generation work includes specialized-agent workflows, modular formulation and code workflows, and tree search over modeling decisions.Learning-based approaches use specialized training data, instruction tuning, synthesized examples, or solver feedback.Source: §A.1 · pp. 14–15

A.2 EXPERT KNOWLEDGE AND REUSABLE MODELING SKILLS

  • OptTips organizes individual techniques into cards linking applicability conditions and inefficiency symptoms to modeling actions and examples.OptDachshund uses these specifications to redesign tasks and build ordinary and expert references on the same numerical instance; evaluated LLMs receive neither target-technique cards nor reference implementations.Source: §A.2 · p. 15

A.3 BENCHMARK COVERAGE AND SEMANTIC VERIFICATION

The related-work discussion reviews benchmarks and verification approaches, then positions EfficientOpt as a technique-guided evaluation with paired references and distinct cost assessments. It also gives the benchmark’s evaluated and supplementary technique coverage.

A.3 BENCHMARK COVERAGE AND SEMANTIC VERIFICATION

  • Prior benchmarks span linear-program translation, more complex modeling, broader application coverage, nonlinear problems, industrial instances, and text-plus-visual inputs.Verification work also examines formulation equivalence, components, and consistency across descriptions, formulations, and code; matching objectives alone does not establish that required outputs are preserved.Source: §A.3 · p. 15

A.4 EVALUATING COMPUTATIONAL EFFICIENCY

  • EfficientOpt pairs ordinary and expert references for tasks built around designated techniques, assessing technique adoption separately from correctness and generation, construction, solving, and memory costs.This supports distinguishing non-adoption, costly implementations that adopt a technique, and effective alternatives.Source: §A.4 · p. 16

B BENCHMARK COMPOSITION AND EVALUATION COVERAGE

  • EfficientOpt contains 561 tasks covering 29 OptTips techniques; 63 supplementary tasks cover the remaining 21 techniques and are excluded from reported evaluation.The supplementary tasks are documented in Appendix J.Source: B BENCHMARK COMPOSITION AND EVALUATION… · p. 16

B.1 TASK COMPOSITION AND CLASSIFICATION

The appendix describes the benchmark and evaluation coverage, then reports accuracy and comparisons of solver time, model size, and preparation costs. Across the comparisons, correct answers do not ensure faster solving, and preparation or long-tail runs can materially affect measured costs.

B.1 TASK COMPOSITION AND CLASSIFICATION

  • The 561 tasks span seven algebraic formulation classes; evaluation uses verified reference objectives, and generated-code prompts request a Gurobi model-construction function.The evaluation runner supplies the numerical instance and invokes the solver at execution time.Source: §B.1 · p. 16, §B.2 · p. 17, §B.3 · p. 17

C.1 NUMERICAL OUTCOMES (RQ1)

  • Across 6,171 evaluations, 4,264 (69.1%) return correct objective values; 338 of 4,602 programs reporting OPTIMAL return incorrect values, and most unsuccessful evaluations end without OPTIMAL.The 1,569 Other outcomes account for 82.3% of 1,907 unsuccessful evaluations.Source: §C.1 · p. 17, Table 3 · p. 18

C.2 ACCURACY ACROSS TASK GROUPS (RQ1)

  • Accuracy ranges from 27.3% (15/55) on T17 to 93.9% (248/264) on T15.T08 and T17 contain 9.1% of tasks but account for 32.2% of programs with OPTIMAL status and incorrect objective values.Source: §C.2 · pp. 18–19, Table 4 · p. 18

C.3 SOLVER COSTS ACROSS TASKS AND MODELS (RQ2)

  • The slowest approximately 10% of correctly solved runs account for 68.4–76.2% of total solver time, while median Runtime is 23.1–36.0 seconds and mean Runtime is 150.8–247.3 seconds.Figure 10(b) summarizes Runtime distributions and the slowest tenth’s share of measured Runtime.Source: §C.3 · p. 20, Figure 10 · p. 21
  • On 47 tasks solved by all models, expert mean Runtime is 43.05 seconds versus 77.04–197.44 seconds for LLMs; on other eligible tasks, 63.7% of valid LLM–expert pairs are slower.The 47-task comparison covers 8.4% of the benchmark; the broader comparison covers tasks solved correctly by at least one LLM.Source: Table 5 · p. 20, §C.3 · p. 21, Table 6 · p. 21

C.4 MODEL SIZE AND SOLVER TIME (RQ3)

  • Among smaller LLM models, 61.1% (449/735) under one size criterion and 57.1% (181/317) under another have longer Runtime than the expert.Of the 449 slower cases under the first criterion, 346 take at least twice as long, with at least one additional second of solver time.Source: §C.4 · p. 22, Table 7 · p. 22

C.5 COSTS BEYOND SOLVER TIME (RQ4)

  • Adding Build reverses the faster/slower comparison in 357 of 4,148 pairs (8.6%), with reversals in all 11 models; 160 reversals differ by at least 10 seconds.A sensitivity comparison with a larger tie tolerance still finds 317 reversals (7.6%).Source: §C.5 · p. 22, Table 8 · p. 23
  • Generation takes longer than recorded Build+opt in 55.6% of 4,202 correct runs; solver-memory P90 is 2,206.7 MiB across all runs, versus a median of 128.5 MiB.The generation comparison uses runs with both measurements; the memory summaries pool runs across models.Source: §C.5 · pp. 22–23, Table 10 · p. 24

C.6 RESULTS FOR FINE-TUNED MODELS

On selected slow runs, a small share of LLM solves accounts for most recorded solver time, and expert implementations are often faster on those same tasks. Fine-tuned models have limited correctness, and optimal solver status does not ensure the task’s verified answer.

C.6 RESULTS FOR FINE-TUNED MODELS

  • OptMATH (32B) and SIRL (32B) achieve the highest fine-tuned-model accuracies, at 24.42% and 21.03%, while smaller models range from 0 to 6.42%.Efficiency comparisons are limited by these small sets of correct solutions.Source: §C.6 · pp. 24–25
  • Of 458 programs ending with OPTIMAL status, 166 (36.2%) return an objective different from the verified answer.A solver can optimize a generated model successfully even when that model answers the task incorrectly.Source: §C.6 · p. 25
  • Failure patterns vary: OptMATH (7B) and SIRL (7B) have 401 and 504 static failures, LLMOPT has 377 code errors, and resource limits affect both 32B models.Time and memory limits account for 108 OptMATH and 149 SIRL runs.Source: §C.6 · p. 25

C.7 SLOW RUNS AND TOTAL SOLVER TIME (RQ2)

  • 68.4–76.2% of total solver time comes from the slowest ∼10% of runs, despite median runtimes of 23.1–36.0 seconds.Totals reach 12.0–27.7 hours, and T10 accounts for 24.6–50.5% of selected-run time for every model.Source: §C.7 · p. 25, Table 12 · p. 25
  • On selected slow tasks, 407 of 427 LLM runs are slower than expert references, and each LLM’s summed Runtime is 3.45–7.71 times the expert total.These tasks were selected for high LLM runtime, so the comparison does not estimate the overall gap or isolate a technique’s effect.Source: §C.7 · p. 25, Table 13 · p. 26
  • Halving the slowest 10% of runs’ runtimes would cut total solver time by 34.2–38.1%, while halving all other runs would cut it by 11.9–15.8%.The median would remain unchanged when the slowest tenth is halved.Source: §C.7 · p. 26

D EVALUATION METRICS AND COMPARISON PROTOCOL

  • The evaluation protocol defines metrics, eligible comparisons, aggregation rules, and limits on interpreting cost differences.The appendix describes the rules used in Section 4 and Appendix C.Source: D EVALUATION METRICS AND COMPARISON… · p. 26

D.1 METRICS AND MEASUREMENT SCOPE

The paper measures accuracy, technique use, and computational cost separately, with distinct boundaries for preparation, solver work, generation, model size, and memory. Cost comparisons use eligible paired tasks and aggregation rules that constrain how differences can be interpreted.

D.1 METRICS AND MEASUREMENT SCOPE

  • Build measures preparation work, while Build+opt adds elapsed time around separately timed solver calls without counting Gurobi Runtime again.The subtotal can omit input loading, imports, result extraction, and work outside timed intervals.Source: §D.1 · pp. 26–27
  • Runtime and Work describe the most recent optimization call, with tracked calls summed for multi-solve procedures; Work is an arbitrary effort unit, not seconds or Python operations.Work depends on the model, hardware, and solver settings, and untracked solves inside model-building code may be absent from these totals.Source: §D.1 · p. 27
  • API latency covers only the final recorded client call, while token counts describe the returned response under each provider’s conventions.Earlier generation or repair calls are excluded, and unavailable counts remain missing.Source: §D.1 · p. 27
  • Figure 5 reports separate maxima for reference variable and total-constraint counts, whereas size–runtime analysis uses variables, linear constraints, and matrix nonzeros from the timed solve.Counts are before presolve, and the reported maxima need not come from the same model.Source: Table 14 · p. 26, §D.1 · p. 27
  • Matched memory analysis uses the maximum of three process RSS snapshots, while Gurobi peak measures allocation within the solver environment and may miss intervening process peaks.Gurobi peak is neither whole-process memory nor a sum of per-model peaks.Source: §D.1 · p. 27

D.2 TASK SELECTION AND RESULT AGGREGATION

  • Numerical accuracy covers all 561 tasks, while paired cost comparisons use 543 tasks with agreeing optimal objectives; invalid or missing measurements are excluded, not replaced with zero.Cost-ratio comparisons require complete measurements for all four ratios, and task sets can differ between LLMs.Source: §D.2 · p. 27
  • Shifted geometric ratios give eligible tasks equal weight in log space; a ratio below one indicates lower LLM cost or size, not a summed-cost speedup.The shift is one second for time, one solver work unit for Work, and one for counts; size ratios do not establish faster solving.Source: §D.2 · p. 27
  • Equal model-size counts do not establish formulation identity, since input order, starting solutions, or solver parameters can affect performance.Paired timing measurements use the same machine, task, and numerical instance.Source: §D.2 · p. 28

E DATASET QUALITY CONTROL AND EXPERT VERIFICATION

Independent experts review candidate tasks and paired references against validity, verification, and technique-use criteria; repairs trigger renewed checks. The protocol’s acceptance requirements do not include observed speedup.

E DATASET QUALITY CONTROL AND EXPERT VERIFICATION

E.1 INDEPENDENT REVIEW AND INFORMATION ACCESS

  • Five experts review candidates independently, with at least two assigned to each; one initially sees only the public statement and schema, while another sees references and validation evidence.Evaluated LLMs receive the public statement and schema, while reference solutions, objectives, technique labels, and expert hints remain hidden.Source: §E.1 · p. 28

E.2 ACCEPTANCE CRITERIA

  • Task specifications must define decisions, objective, domains, constraints, and outputs without hidden-reference dependence, and reviewers check schema–instance consistency and structural difficulty.The task may expose structure but must not prescribe the target technique.Source: §E.2 · p. 28
  • Ordinary and expert references must solve the same task on identical data, meet output requirements, and have mathematically justified answers; valid transformations may use different feasible sets.The ordinary reference must be a plausible conventional formulation rather than an artificially weakened comparison.Source: §E.2 · p. 28
  • The expert reference must apply an applicable OptTips mechanism faithfully, and reviewers verify both references’ status, feasibility, objectives, and requested decisions on the same instance.Exact-task optimality may also be established through analytic or exact solutions, certificates, or a checked feasible solution with a matching bound.Source: §E.2 · p. 28

E.3 DECISIONS, REPAIR, AND CORPUS REVIEW

  • A third expert adjudicates substantive disagreements; repairs trigger renewed affected checks, while semantic or primary-technique changes restart the full protocol.Corpus review also checks duplicates and distributions of techniques, source problems, structures, and difficulty.Source: §E.3 · pp. 29–30

F ASSESSING MODELING TECHNIQUE USE

  • Technique recognition is assessed separately from numerical correctness and computational cost, using automated labels, execution and timing checks, and selected manual inspections.A different approach can also produce a correct, efficient solution.Source: F ASSESSING MODELING TECHNIQUE USE · p. 30

F.1 AUTOMATED ASSESSMENT OF TECHNIQUE USE

The assessment reports how often LLMs use designated or alternative techniques, then combines technique labels with execution and objective-check outcomes. Manual examples show why model structure must be inspected to identify modeling choices and what compared formulations preserve.

F.1 AUTOMATED ASSESSMENT OF TECHNIQUE USE

  • 46.3% of records received a target label, 24.6% an alternative, 21.3% none, and 7.8% N/A; target-label rates ranged from 33.9% to 55.4% across models.The assessment covered all 6,171 model–task pairs, with 561 tasks per LLM.Source: §F.1 · p. 30, Table 15 · p. 30

F.2 COMBINING TECHNIQUE LABELS WITH EXECUTION OUTCOMES

  • C1–C4 require an optimal or solved status and a passing archived objective check; errors and timeouts fall into C5.C2 uses an alternative label and a solver-time threshold, but meeting that threshold does not guarantee a speedup over either reference or account for generation or construction cost.Source: §F.2 · p. 31
  • The combined diagnostics contain 4,249 C1–C4 records, distinct from the 4,264 numerically correct records used in the main evaluation.These diagnostics do not replace the main accuracy results or cost comparisons.Source: §F.2 · p. 31

F.3 MANUAL INSPECTION OF SELECTED MODELING CHOICES

  • Inspecting formulations and code is necessary to identify modeling choices, because solver status, model size, and runtime alone cannot identify a technique.The selected cases are illustrative, not a random sample.Source: §F.3 · p. 32, Table 17 · p. 32

G CASE STUDIES ON MODELING CHOICES AND EFFICIENCY

  • The case studies examine which formulation properties alternatives preserve and how model construction affects recorded costs.Timing scope and required outputs are defined elsewhere in the paper.Source: G CASE STUDIES ON MODELING CHOICES AND… · p. 32

G.1 WHAT THE COMPARED FORMULATIONS PRESERVE

  • In technology mixing, primal technology shares and the expert dual have equal optimal values on the evaluated instance, with a direct recovery map from shares to dual multipliers.Feasibility is established by choosing each block’s least-resource technology under the resource cap; strong duality then gives equal optimal values.Source: §G.1 · p. 32
  • In department relocation, both formulations preserve the common objective and enforce interaction products at integer assignments, but their LP relaxations differ.For fractional assignments, product inequalities can allow y = 0 while marginal equalities do not; because the expert also changes linking constraints, the comparison does not isolate removing binary declarations.Source: §G.1 · p. 32

G.2 HOW CONSTRUCTION CHANGES THE COST COMPARISON

Case studies compare solver time with construction-inclusive costs, while the accompanying framework description details how OptDachshund designs, implements, and audits paired references. The examples show that construction can either offset or widen a solver-time advantage.

G.2 HOW CONSTRUCTION CHANGES THE COST COMPARISON

  • The Kimi/Qwen solver-time ratio is 273.512×, but their Build+opt ratio is 1.043×, as Qwen’s much longer build time offsets most of its solver-time advantage.The two shift-scheduling formulations preserve feasible integer shift-start decisions and the objective.Source: §G.2 · p. 32
  • Transit duty scheduling has the same feasible start decisions and objective in both formulations, while the ordinary/expert Runtime ratio of 1.813 grows to 5.021 for Build+opt.The expert model uses 180,000 variables and constraints versus 1,620,420 each in the ordinary model; it is faster to build as well as solve.Source: §G.2 · pp. 32–33

H OPTDACHSHUND: AGENT ROLES AND INFORMATION FLOW

  • OptDachshund’s Technique Matcher selects applicable OptTips techniques, and the Reformulation Designer creates a task requiring a substantive modeling choice.The Quality Auditor checks validity, consistency, applicability, traceability, leakage, duplication, and diversity; the Repair Agent returns findings for re-audit.Source: H OPTDACHSHUND: AGENT ROLES AND… · p. 33
  • Reference agents build ordinary and expert implementations for the same task, instance, and required outputs, then audit them against the task and selected technique.Final acceptance requires independent expert review and solver-grounded verification; agent approval alone is insufficient, and observed speedup is not required.Source: H OPTDACHSHUND: AGENT ROLES AND… · p. 33

I TASK VALIDITY AND COMPUTATIONAL COST

The appendix defines validity against the original task, fixed input, and required outputs, and frames efficiency comparisons around explicit resources and accounting scope. It also describes OptTips’ breadth and the boundary of the reported evaluation.

I.1 VALID SOLUTION PROCEDURES

  • A valid procedure must answer the original specification for the fixed input and required outputs; reporting only an optimal value is insufficient when decisions or certificates are requested.The procedure may use a different representation if its transformation is justified and the code recovers the required answer.Source: §I.1 · p. 34
  • Alternative representations are valid only when their solution procedures justify the required answer, such as recovering original decisions from an extended or dual formulation.Decomposition requires coordinated subproblem solves and a stopping rule establishing the required solution quality.Source: §I.1 · p. 34

I.2 RESOURCE ACCOUNTING AND COMPARISON SCOPE

  • Efficiency comparisons require the same task, input, and answer quality, with resource and accounting scope stated; time and memory are assessed separately.Costs also depend on implementation and execution conditions, not just formulation.Source: §I.2 · p. 34
  • Complete request time includes API, orchestration, execution, and checking; execution itself includes setup/data, build, optimization, and between-call or recovery work.Solver time already included in a recorded Build interval must not be counted again.Source: §I.2 · p. 34
  • A technique may reduce solver time while increasing construction time or memory, and model-size counts do not measure efficiency.An expert reference need not be the least costly valid implementation; memory comparisons also require a stated scope and sampling method.Source: §I.2 · p. 35

J.1 RATIONALE AND COVERAGE

  • The reported Gurobi evaluation covers 561 tasks and 29 OptTips cards; the remaining 21 cards have supplementary tasks outside performance analysis.OptTips spans foundational formulation choices, diverse modeling mechanisms, and broader methodological areas, and is described as a starting point rather than an exhaustive catalog.Source: §J.1 · p. 35, Table 18 · p. 35

J.2 CARD STRUCTURE AND EXTENSION

OptTips cards share a seven-component schema for describing techniques and their use. The appendix also identifies possible extensions to technique coverage and lists the full inventory.

J.2 CARD STRUCTURE AND EXTENSION

  • Each OptTips card has seven components: identifier, core idea, applicable patterns, inefficiency symptoms, expert actions, mathematical example, and benchmark guidance.The patterns state structural conditions, symptoms identify the issue, actions specify the transformation, and benchmark guidance addresses paired implementation, validation, and measurement.Source: §J.2 · p. 35
  • Figures 12 and 13 show one worked example from each family, including applicability conditions, shared model terms, mathematical justification, and benchmark guidance.The cards support extensions that follow the schema and state mathematical justification; the text proposes broader solver and algorithm coverage.Source: §J.2 · p. 35, Figure 12 · p. 36, Figure 13 · p. 37

J.3 COMPLETE TECHNIQUE INVENTORY

  • The complete inventory lists all 50 OptTips techniques, spanning formulation, algorithmic, and solver-aware choices.The appendix notes that full cards are available in the public repository.Source: Table 19 · p. 38
Loading 2609.38884v1…