Large Language Models and Operations Research: A Structured Survey

TL;DR

Operations research (OR) is the math of making good decisions under constraints: routing trucks, scheduling factories, allocating supply. The classic workflow is brutal — a human expert hand-translates a messy business problem into a formal model (variables, an objective, constraints), then hands it to a solver. That translation is slow, expensive, and brittle. This survey catalogs ~135 recent papers showing LLMs attacking three distinct points in that pipeline: (1) automatic modeling — natural language to a runnable optimization model; (2) auxiliary optimization — LLMs generating and evolving the heuristics that solver algorithms use; and (3) direct solving — the LLM itself producing solutions with no formal model at all. The headline takeaway for a builder: the modeling-and-repair loop (generate → run solver → read errors → fix) is mature enough to productize today, the heuristic-evolution loop is where the research frontier and the real performance gains live, and direct solving is still a parlor trick outside small instances.

Problem & Motivation

Here is the concrete pain. A logistics client says: “I have 40 trucks, 600 deliveries, drivers can’t exceed 9 hours, refrigerated goods must arrive before noon, and I want to minimize fuel cost.” To actually optimize this, someone has to convert that paragraph into a mixed-integer linear program (MILP): decision variables (which truck does which route), an objective function (total fuel), and dozens of constraints (the 9-hour rule, the noon rule, every truck-route pairing). That person is a trained OR analyst, they cost a fortune, and they take days to weeks. Change one business rule and they re-model from scratch.

Two structural problems compound this:

• The modeling bottleneck. The hard part isn’t solving — solvers like Gurobi, CPLEX, and OR-Tools are excellent. The hard part is the semantic-to-structure mapping: getting from human language to a correct formal model. This is exactly where LLMs are strong (language) and traditional OR is weak (it assumes the model already exists).
• The heuristic-design bottleneck. For NP-hard problems (where exact solving is computationally hopeless at scale), you need heuristics — clever rules of thumb that find good-enough solutions fast. Designing a good heuristic has historically been a PhD-level craft, tuned by hand per problem. There’s no scalable way to invent new ones.

LLMs offer a wedge into both: they can write the model and write (and rewrite, and evolve) the heuristics. That’s the bet this whole literature is making.

What’s New (Core Contribution)

This is a survey, so its contribution is organizational clarity, not a new algorithm. Prior surveys were fragmented — one covered only combinatorial optimization, another only “LLM as algorithm generator,” another only the modeling stack, another only evolutionary methods. None gave a builder a single coherent map.

The genuine contributions:

1. A unified three-pillar taxonomy. Before: scattered task-specific papers. Now: every LLM-for-OR method slots into automatic modeling, auxiliary optimization (LLM helps a solver), or direct solving (LLM is the solver). This is the spine of the whole field and it’s genuinely useful for deciding where to invest.

2. A five-step closed-loop schema for automatic modeling. Before: “the LLM writes a model.” Now: an explicit pipeline — comprehension → element identification → structure generation → code generation → verification & feedback — with the feedback loop (run it, read the solver error, repair) called out as the load-bearing part. This is the part you can ship.

3. A maturity narrative for heuristic evolution. The survey traces LLMs moving from a single generator (“write me one heuristic”) to a full-process collaborator (multi-agent systems that generate, evaluate, select, and evolve heuristics across generations, fused with reinforcement learning and Monte Carlo Tree Search). This is where the real, measured wins are (e.g., FunSearch finding genuinely novel algorithms).

4. An honest open-issues list. Unstable semantic-to-structure mapping, fragmented progress, weak generalization, and immature benchmarks. They name the gaps instead of cheerleading.

How It Works (Technically)

Since this is a survey, the “mechanism” is the taxonomy itself plus the two loops that recur across nearly every paper. I’ll demystify both loops, then the RL/evolution machinery the reader likely doesn’t know cold.

Pillar 1 — Automatic Modeling: the generate-validate-repair loop

This is the most production-ready idea in the survey. The five steps:

1. Problem comprehension — parse the natural-language description: what are we optimizing, what are the limits?
2. Element identification — extract the formal pieces: decision variables, constraint types, objective function. (The LLMOPT paper standardizes these into a “five-element” structure: sets, parameters, variables, objectives, constraints. Worth stealing — it’s a clean schema.)
3. Structure generation — assemble those pieces into a standard math model (e.g., a MILP).
4. Code generation — emit solver-executable code (Python calling Gurobi/OR-Tools/CPMpy).
5. Verification & feedback — run the code in the solver, catch errors or infeasibility, feed the error message back to the LLM, and repair. Loop until it solves.

Step 5 is the whole ballgame. An LLM writing a model one-shot is unreliable; an LLM that runs its own output and reads the traceback is dramatically more reliable. This is the same self-debugging pattern you already use in coding agents — applied to optimization. Frameworks like OptiMUS (and its connection-graph + structure-pool variants), Chain-of-Experts (role-specialized agents: terminology parser → model builder → coder → verifier, with forward construction and backward reflection), and OR-LLM-Agent (sandboxed repair) all instantiate this loop with different bells and whistles.

A key variation: prompt-only vs. prompt + fine-tuning. Prompt-only (OptiMUS) is lightweight and needs no training. Fine-tuning approaches (ORLM, LLMOPT, LLaMoCo) train on synthetic OR datasets to make the modeling more robust — ORLM reportedly beat GPT-4 on standard benchmarks under a Pass@8 setting (i.e., give it 8 tries, take the best). The tradeoff is the classic one: fine-tuning buys robustness and generalization at the cost of a training pipeline and data.

Pillar 2 — Auxiliary Optimization: LLM-driven heuristic evolution

This is the research frontier and where the interesting ML lives. The idea: instead of a human designing a heuristic, the LLM writes the heuristic as code, you score it by running it on problem instances, and you evolve a population of heuristics over generations — keeping the good ones, mutating and recombining them, discarding the bad.

If you’ve seen a genetic algorithm, this is that, but the “genetic operators” (mutation, crossover) are LLM calls instead of random bit-flips. Concretely:

• LMEA uses the LLM as a zero-shot evolutionary operator (it does the crossover and mutation by prompting).
• AEL / LLM4AD treat the algorithm itself as the thing being evolved — the LLM generates, rewrites, and refines algorithm code across rounds.
• FunSearch (the famous one, published in Nature) pairs an LLM generator with an automated evaluator and a distributed pool to maintain diversity; it discovered genuinely new mathematical constructions and bin-packing heuristics.
• ReEvo adds a reflection layer: after generating heuristic code, the LLM critiques its own output in language and uses that critique to steer the next generation (verbal self-feedback as a search signal).
• HeurAgenix turns this into a multi-agent system: separate generation, evolution, evaluation, and selection agents — exactly the MAS coordination pattern the reader has built before, applied to heuristic search.

The deeper fusions are where RL enters:

• Evo-Tune / CALM / Surina et al. close the loop back into the model weights: run the evolutionary search, collect which generated programs scored well, build a preference dataset (good program > bad program), and fine-tune the LLM with DPO (Direct Preference Optimization) or GRPO (Group Relative Policy Optimization) so the model itself gets better at generating high-quality heuristics over time. (DPO/GRPO explained in the glossary — short version: they nudge the model to assign higher probability to outputs a reward signal preferred, without the full machinery of classic PPO.)
• MCTS-AHD / PoH wrap Monte Carlo Tree Search around LLM heuristic generation — MCTS handles the strategic exploration of which heuristics to try next, the LLM handles generating candidates and evaluating nodes, forming a state-action-reward loop.

Pillar 3 — Direct Solving: the LLM as the solver

The most ambitious and least reliable. No formal model, no external solver — just prompt the LLM with the problem and ask for a solution. OPRO (“LLM as optimizer”) is the seminal example: it feeds the model the problem plus a history of past solutions and their scores, and asks for a better one — an iterative, gradient-free hill climb driven entirely by the model reading its own track record. Extensions add CoT reasoning, self-ensembling (sample many, pick best), and multimodal inputs (feed the LLM an image of a TSP instance and have it “eyeball” a route). Reality check: this works on small instances and degrades fast as problems scale. Useful for demos and as a baseline; not a production solver.

Architecture & data flow

flowchart TD
  NL["Natural-language problem<br/>(client's messy paragraph)"] --> P1

  subgraph P1["Pillar 1: Automatic Modeling"]
    C1[Comprehension] --> C2[Element ID:<br/>vars, constraints, objective]
    C2 --> C3[Structure: build MILP]
    C3 --> C4[Code: emit solver code]
    C4 --> C5{Run solver}
    C5 -->|error / infeasible| C6[LLM reads traceback,<br/>repairs] --> C4
    C5 -->|solves| SOL1[Solution]
  end

  NL --> P2
  subgraph P2["Pillar 2: Auxiliary Optimization"]
    H1[LLM generates<br/>heuristic code] --> H2[Run on instances,<br/>score]
    H2 --> H3{Good?}
    H3 -->|keep / mutate / crossover| H1
    H3 -->|build preference data| H4[Fine-tune LLM<br/>via DPO/GRPO] --> H1
    H2 --> SOLVER[Classic solver /<br/>metaheuristic] --> SOL2[Solution]
  end

  NL --> P3
  subgraph P3["Pillar 3: Direct Solving"]
    D1[Prompt LLM with problem<br/>+ past-solution history] --> D2[LLM emits candidate]
    D2 --> D3[Score it] --> D1
    D2 --> SOL3[Solution]
  end

Interactive: step through the five-stage automatic-modeling loop and watch a natural-language request become a runnable MILP — including the repair cycle when the solver throws an error. This is schematic, illustrating the loop structure the survey defines (Fig. 2), not real solver output.

Interactive: an LLM-driven heuristic evolution run. Each dot is a candidate heuristic; height is its score on the benchmark. Watch the population climb over generations as low scorers are culled and high scorers are mutated. Schematic illustration of the Pillar-2 evolutionary loop (e.g., FunSearch / AEL / ReEvo), not the papers' actual numbers.

The algorithm, simplified

The one idea that recurs everywhere and is worth being able to type from memory is the LLM-as-evolutionary-operator loop (Pillar 2). Here’s the core, stubbing the model and solver calls:

# Evolve a POPULATION of heuristics, using the LLM as mutation/crossover operator.
# This is the shared skeleton behind AEL, FunSearch, ReEvo, HeurAgenix, etc.

def evolve_heuristics(problem_spec, instances, generations=20, pop=10):
    # 1. Seed: ask the LLM for an initial population of heuristic CODE strings.
    population = [llm(f"Write a heuristic for:\n{problem_spec}") for _ in range(pop)]

    for g in range(generations):
        # 2. Score every heuristic by ACTUALLY RUNNING it on real instances.
        scored = [(h, mean(run_heuristic(h, inst) for inst in instances))
                  for h in population]
        scored.sort(key=lambda x: x[1], reverse=True)   # best first

        # 3. Keep the elite; this is the "selection" pressure.
        elite = [h for h, _ in scored[: pop // 2]]

        # 4. The LLM IS the genetic operator: it mutates/recombines elite code.
        children = []
        for parent in elite:
            critique = llm(f"This heuristic scored well but could improve. "
                           f"Why is it limited?\n{parent}")      # ReEvo's reflection step
            child = llm(f"Improve this heuristic. Critique: {critique}\n{parent}")
            children.append(child)

        population = elite + children                   # next generation

    return scored[0][0]   # best heuristic code found

The three load-bearing pieces: (a) run_heuristic gives a real, verifiable score — this grounds the whole search and is why it works where pure prompting fails; (b) the LLM-as-operator replaces hand-designed mutation; (c) the optional reflection step (critique) turns failure into a language signal that steers the next generation. Swap step 4 for a DPO/GRPO fine-tune on the scored pairs and you get the Evo-Tune/CALM family.

Built on Prior Work

Results & Evidence

This is a survey, so “results” means what the surveyed evidence collectively establishes — and, importantly, what it doesn’t.

What’s genuinely supported:

• Automatic modeling works and is improving fast. Multiple frameworks report near-expert modeling on standard benchmarks (NL4OPT, MAMO, IndustryOR), with ORLM models reportedly beating GPT-4 under Pass@8. OptiGuide hit >90% accuracy in a real Microsoft Azure supply-chain deployment — a rare production data point.
• Heuristic evolution produces real, sometimes superhuman, gains. FunSearch found novel constructions (published in Nature); several frameworks report beating traditional specialized optimizers on TSP/VRP/scheduling. This is the strongest evidence in the survey.
• Domain transfer is happening. Working applications in supply chain (OptiGuide), urban planning (City-LEO), food sustainability, job-shop scheduling (Starjob, beating heuristic + neural baselines), and telecom/edge computing.

What the evidence does NOT establish (the honest caveats the survey itself flags):

• Unstable semantic-to-structure mapping. The same model on the same problem class gives inconsistent formalizations. Reliability is the unsolved problem.
• Benchmarks are narrow and possibly leaky. Most benchmarks cover MILP and VRP, lean on accuracy/structural-equivalence metrics, and ignore efficiency, interpretability, and robustness. Many datasets are synthetic — a real gap from industrial messiness. Pass@8 numbers also flatter the methods (8 tries is generous).
• Direct solving doesn’t scale. Impressive on toy instances, falls apart at production scale.
• Fragmentation. No unified framework; results aren’t comparable across papers because everyone uses different benchmarks and metrics. Cherry-picking risk is high.

Bottom line for someone selling this: the modeling loop is real and deployable with guardrails; the evolution loop is real but research-grade; treat any single paper’s headline number with suspicion until you’ve run it on your data.

How You’d Use It

Three concrete service lines map directly onto the three pillars, in descending order of how ready they are to sell:

1. “Plain-English optimization” copilots (Pillar 1) — ship this now. For clients with recurring optimization needs (logistics, scheduling, inventory, staff rostering) who can’t afford a full-time OR team, build the five-step modeling loop on top of an existing solver (OR-Tools is free; Gurobi/CPLEX if they have licenses). The LLM turns a business analyst’s English into a runnable model; the verification-feedback loop catches the LLM’s mistakes. The moat isn’t the LLM — it’s the repair loop, the solver integration, and the domain-specific prompt library + few-shot examples you accumulate per vertical. This is a natural extension of the coding-agent pattern you already run.

2. Heuristic-as-a-service for hard scheduling/routing (Pillar 2) — pilot it. For clients with genuinely NP-hard problems at scale (large fleets, complex factories), the heuristic-evolution loop can discover problem-specific heuristics that beat off-the-shelf solvers. Higher effort, higher payoff, and a real moat because the evolved heuristics are tuned to their problem and data. This is where your MAS experience pays off — HeurAgenix is literally a multi-agent generate/evaluate/select system.

3. Direct solving (Pillar 3) — demos and prototypes only. Good for a flashy proof-of-concept (“look, it routes the trucks from a photo”) and for quickly scoping whether a problem is worth a real engagement. Don’t put it in production.

The clean framing for a sales conversation: “We don’t replace your solver — we replace the expensive analyst who feeds it, and for your hardest problems we evolve custom heuristics it could never design by hand.”

Build Your Own (Minimal Recipe)

Smallest version that captures ~80% of the value: a Pillar-1 modeling copilot with a repair loop.

Components and build order:

1. Solver backend. Start with ortools (free, Python-native, the survey notes Python frameworks suit LLMs best) or pulp for LP/MILP. This is the only deterministic, trustworthy part — lean on it.
2. The five-step prompt chain. One prompt to extract the five elements (sets, params, variables, objective, constraints — steal LLMOPT’s schema), one to emit solver code. Force structured output (JSON for the elements, then code) so you can validate each stage.
3. The repair loop — this is the hard part and the whole value. Execute the generated code in a sandbox, capture the traceback or infeasibility report, and feed it back: “Your model raised this error / was infeasible; here’s the code; fix it.” Cap at ~5 iterations. Getting good error→repair prompting is the engineering that separates a demo from a product.
4. A validation gate. Before trusting a solution, check it against the original constraints independently (don’t trust the LLM’s own “it’s solved”). This is the second genuinely hard part: catching silently wrong models that solve but model the wrong problem.

Libraries/models to reach for: ortools/pulp for solving, any strong code model (the survey’s results lean on GPT-4-class models), a sandbox (subprocess with limits or a container) for execution, and a structured-output layer (function calling / JSON mode). You can stand up a working v1 in days; the repair-loop and validation-gate quality is where the weeks go.

If you want Pillar 2 next: bolt the evolve_heuristics loop above onto the same solver harness — the scoring function (run_heuristic) reuses your execution sandbox.

How to Improve It

Limitations as leverage — concrete, testable ideas:

1. Attack the unreliability with a verifier ensemble. The core failure is unstable NL→model mapping. Generate k independent formalizations, solve all, and either take majority-agreement on the objective value or use an EquivaMap-style LLM equivalence check to flag disagreement for human review. Testable: does ensemble agreement correlate with correctness on a held-out set?

2. Close the loop into weights for modeling, not just heuristics. The Evo-Tune/DPO trick is mostly applied to Pillar 2. Apply it to Pillar 1: every successful (NL → correct model) repair becomes a preference pair; fine-tune so the model needs fewer repair iterations over time. Build a flywheel where each client engagement makes your modeler better.

3. Build a real benchmark from your own engagements. The survey’s loudest complaint is that benchmarks are synthetic and narrow. A proprietary benchmark of real client problems (anonymized) is both a research contribution and a defensible business moat — you’d know which methods actually work on messy industrial inputs.

4. Hybridize direct solving with a solver fallback. Use Pillar-3 direct solving for instant approximate answers (great UX), but always run the real solver in the background and reconcile. Test whether the LLM’s “warm start” actually speeds up the solver (a known classic technique — feeding a good initial solution).

5. Multimodal modeling, not just multimodal solving. The survey’s multimodal work is all Pillar 3 (eyeball the TSP). More useful: feed the LLM the client’s spreadsheets, network diagrams, and floor plans to extract constraints automatically — the modeling step is where real client data lives, and it’s rarely clean text.

Glossary

• Operations Research (OR) — the discipline of optimal decision-making under constraints using math models (routing, scheduling, allocation).
• MILP (Mixed-Integer Linear Program) — an optimization model with a linear objective/constraints where some variables must be whole numbers (e.g., “use 3 trucks, not 3.4”). The workhorse model type in this survey.
• Solver — software (Gurobi, CPLEX, OR-Tools) that takes a formal model and finds the optimal/near-optimal solution. Excellent and not the bottleneck.
• Heuristic — a fast rule-of-thumb that finds a good-enough solution when exact solving is too slow; classically hand-designed, here LLM-generated.
• NP-hard — a class of problems with no known fast exact algorithm; solution time blows up with size, which is why heuristics exist.
• Decision variable / objective / constraint — the three formal pieces of any optimization model: what you choose, what you’re optimizing, and the rules you can’t break.
• Automatic modeling — Pillar 1: turning natural language into a formal, runnable optimization model.
• Auxiliary / assisted optimization — Pillar 2: the LLM helps a solver, mainly by generating and evolving heuristics.
• Direct solving — Pillar 3: the LLM outputs solutions directly, with no formal model or external solver.
• Evolutionary algorithm — population-based search using selection, mutation, and crossover; here the LLM performs the mutation/crossover by writing code.
• FunSearch — LLM + automated evaluator that discovered genuinely novel algorithms (Nature 2024); the template for Pillar-2 work.
• Reflection (in evolution) — the LLM critiquing its own heuristic in natural language and using that critique to steer the next generation (ReEvo).
• DPO (Direct Preference Optimization) — a fine-tuning method that trains a model directly from “A is better than B” pairs, raising the probability of preferred outputs without a separate reward model or full RL loop.
• GRPO (Group Relative Policy Optimization) — an RL fine-tuning method that scores a group of sampled outputs and reinforces the ones above the group average; lighter-weight than PPO, used to bias generators toward high-quality heuristics.
• MCTS (Monte Carlo Tree Search) — a search algorithm that strategically explores a tree of possibilities by simulating rollouts; here it decides which heuristics to try next while the LLM generates and scores them.
• Pass@8 — an evaluation setting: give the model 8 attempts and count success if any succeeds; generous, so inflates reported accuracy.
• TSP / VRP / JSSP — Traveling Salesman / Vehicle Routing / Job-Shop Scheduling Problems; the canonical hard combinatorial benchmarks throughout the survey.
• Warm start — giving a solver a good initial solution to speed it up; a natural way to fuse LLM output with classic solvers.