Natural-language optimisation modelling & decision copilot

Many firms have decisions that mathematical optimisation could improve (product mix, staffing, allocation, capacity), but no operations-research (OR) team to formulate the model. An LLM-to-solver copilot lets a planner describe the problem in words. It drafts the formulation and solver code, runs it, explains the answer and handles follow-ups such as "what if demand rises 10%?". The LLM writes and explains the model, and a deterministic solver finds the optimum.

Problem & value

• Today: optimisation models are built by scarce OR specialists or consultants, or the decision is made in spreadsheets by intuition. Existing models are black boxes to planners: every "what if" becomes a ticket to the modeller.
• AI value: lowers the barrier to a first working model (days instead of weeks), speeds up prototyping for OR experts, and lets business users query existing models in plain language. Microsoft's OptiGuide pairs an LLM with a supply-chain optimisation model to explain results and answer what-if questions, while the solver stays the source of truth [1].
• Honest limits: formulation is the hard part. Benchmarks for LLM-generated models (NL4Opt and successors) show that accuracy depends strongly on problem complexity and on benchmark data quality [3]. Treat the output as a draft that needs validation, not as a verified model. This report gives no accuracy figure because results vary by benchmark version and model.

Variants

• Formulation assistant (modelling): problem text to model plus code, mainly for developers, analysts and OR consultants.
• What-if copilot over an existing model: the planner asks questions, the LLM translates them into parameter or constraint changes, re-solves and compares scenarios (OptiGuide pattern) [1].
• Spreadsheet-centred (SMB): data in Excel, the model in HiGHS or OR-Tools, answers in a chat or notebook.
• Domain-bound copilots: embedded in an application (APS, S&OP, workforce planning), with a fixed model template and an LLM only for parameter changes and explanations; see OPT-002, OPT-003, OPT-008.
• Teaching and prototyping: students and analysts learning modelling with an LLM tutor.

How it works

1. problem statement (text) + data schema
2. clarification dialogue (missing parameters, ambiguous constraints)
3. formulation: sets, parameters, variables, constraints, objective (LLM reasoning)
4. code generation (gurobipy / OR-Tools / HiGHS via highspy / Pyomo)
5. sandboxed execution + solver (deterministic)
6. validation: unit tests, feasibility checks, infeasibility diagnosis (IIS), comparison with a known baseline
7. explanation of the result + what-if loop (change parameter
8. re-solve
9. compare)
10. human review and sign-off before the plan is used

• LLM role: extract entities and constraints, choose a model class (LP, MILP, CP-SAT), write code, translate results and scenario questions. The LLM does not compute the optimum.
• Solver role: guarantees feasibility and optimality (or a proven gap), which an LLM alone cannot.
• Research agents: OptiMUS and similar multi-agent systems add automatic debugging and test loops to formulation [5]. Fine-tuned open models such as ORLM target model generation directly [6].
• Human-in-the-loop: a domain expert confirms the formulation (constraints in business language), checks the solution against a known case, and approves before any decision or system write-back. Execution of generated code must run in a sandbox.

Data preparation

The copilot needs less data than most use cases, but it needs clean problem inputs: capacities, costs, demands, time windows, rules and constraints. In an SMB these live in Excel sheets, the ERP (orders, routings, stock), planners' heads and sometimes e-mails or PDFs with customer requirements.

Typical gaps: implicit rules that nobody wrote down (the "we never do X on Fridays" knowledge), inconsistent units, outdated master data, multiple spreadsheet versions and missing cost figures. The biggest task is therefore not data cleaning but making constraints explicit.

Preparation steps: (1) run a short workshop to write down objective, decisions and constraints in plain language (PREP-016 for gold-standard examples), (2) restructure the source spreadsheets into tidy tables (PREP-011), (3) define terms and KPIs consistently (PREP-012), (4) collect two or three past planning cases with known good solutions as a test set (PREP-018). Tools: Excel/Power Query, pandas, a small SQLite or CSV store. Expect roughly 20 to 30 percent of the effort in preparation, mostly knowledge capture rather than technical cleaning.

Implementation paths

Which path for whom

• SMB: Path B. No off-the-shelf product fits a company's own planning problems; a small build on cloud APIs plus an open-source solver connects directly to the firm's own spreadsheets and ERP data.
• Enterprise: Path B. Cloud LLM APIs with a governed solver service integrate into existing planning landscapes; a shared internal AI platform can later take over.
• Developer: Path C. Open-weight code models and open-source solvers (OR-Tools, HiGHS) allow reproducible, self-hosted tooling without per-token costs.

Path A — Buy (off-the-shelf)

• Gurobi Modeler (agent on Gurobi Intelligence Hub: plain-language specification, formulation, gurobipy code and unit tests, with an MCP server for coding assistants). Gurobi's older AI Modeling GPTs and docs are being superseded by it [2].
• IBM Decision Optimization with watsonx and Decision Optimization in Cloud Pak for Data; FICO Xpress, Hexaly, nextmv and Timefold (Belgium, EU) are solver platforms, some with natural-language or API-driven scenario tooling. Check feature status per vendor.
• Embedded planning suites: o9, Kinaxis, Blue Yonder, SAP IBP, anyLogistix, AIMMS (Netherlands, EU), LLamasoft/Coupa. Their copilots usually query an existing planning model rather than invent new ones.
• Choose A when: you already license a solver or planning suite and want what-if access for planners without building anything.

Path B — Build on cloud APIs

• Models: a frontier reasoning/code model with structured outputs and tool use (Claude, GPT, Gemini, or Mistral as EU provider), hosted in an EU region (e.g. Azure OpenAI EU, Vertex AI EU, AWS Bedrock Frankfurt, Mistral La Plateforme).
• Solvers: OR-Tools (CP-SAT, routing) [7], HiGHS (open-source LP/MIP, MIT licence) [8], Pyomo or PuLP as modelling layers; Gurobi or CPLEX where performance or licensing is already in place.
• Orchestration: a small agent loop (generate, execute in sandbox, read solver log, repair) with a fixed prompt library of model templates; tool-calling to a registry of pre-validated models for what-if questions (safer than free generation).
• Choose B when: you need custom domain logic and your data may go to an EU-hosted API.

Path C — Self-host (open source)

• Models: open-weight reasoning/code models (e.g. Qwen3 / Qwen coder family, DeepSeek-R1 distillations, gpt-oss) served with vLLM or Ollama; research checkpoints such as ORLM [6].
• Stack: HiGHS, OR-Tools, Pyomo, optional Docker sandbox for generated code; notebooks as UI.
• Hardware: HW1 suffices for small models plus CPU solvers; HW2 to HW3 for strong reasoning models (30B+ class) locally.
• Effort: 1-3 months incl. sandboxing and evaluation. Choose C when: data or constraints are confidential and cannot leave the premises.

Path D — Custom training

Fine-tuning on pairs of problem text and verified models (as in ORLM [6]) is only worth it for a narrow domain with many recurring problem types and a large library of validated models. Synthetic data generation with solver-verified labels is the usual route. Rarely needed for SMBs.

State of the art (2026)

• Reasoning models have clearly improved text-to-model quality compared with 2023, and research moved from single-shot prompting to agentic loops with tests and solver feedback [5]. Benchmark scores should be read with care, since datasets and versions differ [3].
• Vendors converged on the "LLM as front end to a solver" pattern, with MCP servers exposing solvers and models to coding assistants [2].
• Typical failure modes: missing or wrongly linked constraints, wrong big-M or indexing, silently relaxed requirements, modelling a continuous variable as integer or vice versa, over-confident explanations, and non-reproducible output (the same prompt yields different models) [4].
• Mitigations: ask clarifying questions, generate tests (known feasible/infeasible cases), compare with a hand-solved toy instance, diff model versions, keep a library of reviewed templates, and show the formulation in business language.
• What-if on fixed models is more reliable than free-form formulation because the model structure is already validated [1].

Shared resources & combinations

• Same stack (llm-code + optimization-solver): OPT-001 vehicle routing, OPT-002 APS, OPT-003 workforce scheduling, OPT-005 inventory, OPT-008 S&OP and network design; the copilot can act as a conversational layer for all of them.
• Adjacent: CODE-001 (IDE assistants write the solver code), CODE-007 (app building for non-developers), DATA-009 (AutoML for analysts; no mathematical programming), and forecasting (PRED family) as input to optimisation ("predict then optimise").
• Shared infrastructure: one sandboxed code-execution service and one model gateway can serve code, analytics and optimisation copilots.

Effort, cost & KPIs

• Path A: days to weeks plus licences. Path B: 4-10 weeks for a validated pilot with 2-3 templates. Path C: 1-3 months plus hardware.
• Cost drivers: solver licences (open source avoids them), reasoning-model tokens (small per problem, since problems are short), and above all expert time for validation.
• KPIs: time from problem statement to validated model, share of generated models passing tests on first try, share of what-if questions answered correctly (checked against a reference), planner adoption, decision quality (objective value versus previous manual plan), and number of expert corrections per model.

People & change

Involve management (sponsor and scope), the department lead who owns the planning process, and the end-users, the planners, who know the real constraints and will verify every proposal. IT provides data access and a safe place to run solver code; data owners release the spreadsheets and ERP exports. Bring the planners in at the very start, because they supply the constraints and judge whether results are plausible.

Works council: usually no, since the tool optimises plans and resources, not behaviour or performance of people. It becomes relevant if the model schedules individual employees or logs who asked what; then §87(1) no. 6 applies. Even otherwise, inform the works council early under §90(1) no. 3 where AI is used in work processes.

Data protection: mostly business data; a DPO check is needed only if employee or customer data enters the model. Never send confidential cost data to a tool without an AVV (Art. 28 GDPR). AI literacy: show planners how the copilot formulates a model, how to read the assumptions and why generated code must be reviewed; this supports Art. 4 AI Act. Pilot with one planning problem and a power user as AI champion. Typical concern is trust in "black-box" results; answer with the visible model, constraints list and the option to override. See GUIDE-009, GUIDE-006 and GUIDE-008.

Risks, regulation & compliance

• EU AI Act: typically minimal risk, since the system produces planning models, not decisions about people. It becomes high risk (Annex III, e.g. employment, worker management or task allocation based on individual behaviour) if the optimised object is people, as in workforce scheduling with performance or behavioural data; then see OPT-003. AI literacy (Art. 4) applies to users [9].
• GDPR: model data is mostly operational. Staff rosters, driver data or customer data in prompts are personal data, so use EU-region processing, data processing agreements, minimisation and pseudonymised IDs where possible.
• Code execution risk: LLM-generated code can be wrong or unsafe; run it in a sandbox without network access and without production credentials.
• Decision risk and accountability: an infeasible or mis-specified model can give confident but wrong plans. Require expert sign-off, versioned models, and an audit log of prompt, formulation, code, data version and solver output. The optimiser's answer is only as good as the stated constraints.
• Vendor and IP: check licence terms for solver use with cloud LLMs, and whether prompts are used for training.

Getting started

1. Pick one recurring decision with a known best practice (e.g. a product-mix or shift-allocation problem) and a hand-built baseline.
2. Write the problem in plain language, with data columns and units, and let an LLM draft the formulation; review it with a domain expert.
3. Implement with HiGHS or OR-Tools, add unit tests (known solutions, infeasible cases) and sandbox execution.
4. Add a what-if layer for 5-10 typical planner questions on the validated model and compare answers with manual re-runs.
5. Measure the KPIs for 4-6 weeks, then decide on a template library or a purchased platform.

Sources

1. Li et al. (Microsoft) — Large Language Models for Supply Chain Optimization (OptiGuide) — https://arxiv.org/abs/2307.03875
2. Gurobi — Introducing Gurobi AI Modeling / Modeler on Intelligence Hub — https://docs.gurobi.com/projects/intelligence/en/current/mcp-server.html
3. Ramamonjison et al. — NL4Opt competition: formulating optimization problems based on their natural language descriptions — https://arxiv.org/abs/2303.08233
4. Gurobi AI Modeling documentation (prompting tips, pitfalls, example prompts) — https://docs.gurobi.com/projects/intelligence/en/current/
5. AhmadiTeshnizi et al. — OptiMUS: scalable optimization modeling with MILP solvers and LLMs — https://arxiv.org/abs/2402.10172
6. Huang et al. — ORLM: training large language models for optimization modeling — https://arxiv.org/abs/2405.17743
7. Google OR-Tools — https://developers.google.com/optimization
8. HiGHS open-source solver — https://highs.dev/
9. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj