Optimierungsmodellierung in natürlicher Sprache & Entscheidungs-Copilot

Viele Unternehmen haben Entscheidungen, die sich mit mathematischer Optimierung verbessern ließen (Produktmix, Personaleinsatz, Zuteilung, Kapazität), aber kein Operations-Research-Team (OR), das das Modell formuliert. Ein LLM-zu-Solver-Copilot lässt einen Planer das Problem in Worten beschreiben. Er entwirft die Formulierung und den Solver-Code, führt ihn aus, erklärt das Ergebnis und bearbeitet Folgefragen wie „Was wäre, wenn die Nachfrage um 10 % steigt?“. Das LLM schreibt und erklärt das Modell, ein deterministischer Solver findet das Optimum.

Problem & Nutzen

• Heute: Optimierungsmodelle werden von knappen OR-Fachleuten oder Beratern gebaut, oder die Entscheidung fällt in Tabellenkalkulationen nach Gefühl. Bestehende Modelle sind für Planer Black Boxes: Jede „Was wäre, wenn“-Frage wird zu einem Ticket an den Modellierer.
• KI-Nutzen: senkt die Hürde zu einem ersten funktionierenden Modell (Tage statt Wochen), beschleunigt das Prototyping für OR-Fachleute und lässt Fachanwender bestehende Modelle in Alltagssprache abfragen. Microsofts OptiGuide koppelt ein LLM mit einem Optimierungsmodell für die Lieferkette, um Ergebnisse zu erklären und Was-wäre-wenn-Fragen zu beantworten, während der Solver die maßgebliche Quelle bleibt [1].
• Ehrliche Grenzen: Die Formulierung ist der schwierige Teil. Benchmarks für von LLMs erzeugte Modelle (NL4Opt und Nachfolger) zeigen, dass die Genauigkeit stark von der Problemkomplexität und der Qualität der Benchmark-Daten abhängt [3]. Behandeln Sie das Ergebnis als Entwurf, der validiert werden muss, nicht als geprüftes Modell. Dieser Bericht nennt keine Genauigkeitszahl, weil die Ergebnisse je nach Benchmark-Version und Modell schwanken.

Varianten

• Formulierungsassistent (Modellierung): Problemtext wird zu Modell plus Code, vor allem für Entwickler, Analysten und OR-Berater.
• Was-wäre-wenn-Copilot über einem bestehenden Modell: Der Planer stellt Fragen, das LLM übersetzt sie in Änderungen von Parametern oder Nebenbedingungen, löst neu und vergleicht Szenarien (OptiGuide-Muster) [1].
• Tabellenzentriert (KMU): Daten in Excel, Modell in HiGHS oder OR-Tools, Antworten in einem Chat oder Notebook.
• Domänengebundene Copilots: in eine Anwendung eingebettet (APS, S&OP, Personaleinsatzplanung), mit festem Modell-Template und einem LLM nur für Parameteränderungen und Erklärungen; siehe OPT-002, OPT-003, OPT-008.
• Lehre und Prototyping: Studierende und Analysten lernen die Modellierung mit einem LLM-Tutor.

So funktioniert es

1. Problembeschreibung (Text) + Datenschema
2. Klärungsdialog (fehlende Parameter, mehrdeutige Nebenbedingungen)
3. Formulierung: Mengen, Parameter, Variablen, Nebenbedingungen, Zielfunktion (LLM-Reasoning)
4. Code-Erzeugung (gurobipy / OR-Tools / HiGHS über highspy / Pyomo)
5. Ausführung in der Sandbox + Solver (deterministisch)
6. Validierung: Unit-Tests, Zulässigkeitsprüfungen, Diagnose bei Unlösbarkeit (IIS), Vergleich mit einer bekannten Baseline
7. Erklärung des Ergebnisses + Was-wäre-wenn-Schleife (Parameter ändern
8. neu lösen
9. vergleichen)
10. Prüfung und Freigabe durch Menschen, bevor der Plan verwendet wird

• Rolle des LLM: Entitäten und Nebenbedingungen extrahieren, eine Modellklasse wählen (LP, MILP, CP-SAT), Code schreiben, Ergebnisse und Szenariofragen übersetzen. Das LLM berechnet nicht das Optimum.
• Rolle des Solvers: garantiert Zulässigkeit und Optimalität (oder eine bewiesene Lücke), was ein LLM allein nicht kann.
• Forschungs-Agenten: OptiMUS und ähnliche Multi-Agenten-Systeme ergänzen die Formulierung um automatische Debugging- und Testschleifen [5]. Feinabgestimmte offene Modelle wie ORLM zielen direkt auf die Modellerzeugung [6].
• Mensch-in-der-Schleife (Human-in-the-Loop): Ein Fachexperte bestätigt die Formulierung (Nebenbedingungen in Fachsprache), prüft die Lösung an einem bekannten Fall und gibt frei, bevor eine Entscheidung getroffen oder in ein System zurückgeschrieben wird. Die Ausführung des erzeugten Codes muss in einer Sandbox laufen.

Datenaufbereitung

Der Copilot braucht weniger Daten als die meisten Anwendungsfälle, aber saubere Problemeingaben: Kapazitäten, Kosten, Bedarfe, Zeitfenster, Regeln und Nebenbedingungen. In einem KMU liegen diese in Excel-Tabellen, im ERP (Aufträge, Arbeitspläne, Bestände), in den Köpfen der Planer und manchmal in E-Mails oder PDFs mit Kundenanforderungen.

Typische Lücken: implizite Regeln, die niemand aufgeschrieben hat (das Wissen „freitags machen wir nie X“), uneinheitliche Einheiten, veraltete Stammdaten, mehrere Versionen von Tabellen und fehlende Kostenangaben. Die größte Aufgabe ist daher nicht die Datenbereinigung, sondern die Nebenbedingungen explizit zu machen.

Aufbereitungsschritte: (1) in einem kurzen Workshop Ziel, Entscheidungen und Nebenbedingungen in Alltagssprache aufschreiben (PREP-016 für Gold-Standard-Beispiele), (2) die Quelltabellen in saubere Tabellen umstrukturieren (PREP-011), (3) Begriffe und Kennzahlen einheitlich definieren (PREP-012), (4) zwei oder drei frühere Planungsfälle mit bekannten guten Lösungen als Testsatz sammeln (PREP-018). Werkzeuge: Excel/Power Query, pandas, ein kleiner SQLite- oder CSV-Speicher. Rechnen Sie mit etwa 20 bis 30 Prozent des Aufwands für die Aufbereitung, überwiegend Wissenssicherung statt technischer Bereinigung.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg B. Kein Standardprodukt passt zu den eigenen Planungsproblemen eines Unternehmens; ein kleiner Eigenbau auf Cloud-Diensten plus einem Open-Source-Solver greift direkt auf die eigenen Tabellen und ERP-Daten zu.
• Großunternehmen: Weg B. Cloud-LLM-Schnittstellen mit einem gesteuerten Solver-Dienst lassen sich in bestehende Planungslandschaften integrieren; später kann eine gemeinsame interne KI-Plattform übernehmen.
• Entwickler: Weg C. Code-Modelle mit offenen Gewichten und Open-Source-Solver (OR-Tools, HiGHS) ermöglichen reproduzierbare, selbst betriebene Werkzeuge ohne Kosten pro Token.

Weg A — Kaufen (Standardsoftware)

• Gurobi Modeler (Agent im Gurobi Intelligence Hub: Spezifikation in Alltagssprache, Formulierung, gurobipy-Code und Unit-Tests, mit einem MCP-Server für Coding-Assistenten). Die älteren AI-Modeling-GPTs und die Dokumentation von Gurobi werden dadurch abgelöst [2].
• IBM Decision Optimization mit watsonx und Decision Optimization in Cloud Pak for Data; FICO Xpress, Hexaly, nextmv und Timefold (Belgien, EU) sind Solver-Plattformen, teils mit Werkzeugen für Szenarien in natürlicher Sprache oder über Schnittstellen. Prüfen Sie den Funktionsstand je Anbieter.
• Eingebettete Planungssuiten: o9, Kinaxis, Blue Yonder, SAP IBP, anyLogistix, AIMMS (Niederlande, EU), LLamasoft/Coupa. Ihre Copilots fragen in der Regel ein bestehendes Planungsmodell ab, statt neue zu erfinden.
• Wählen Sie A, wenn: Sie bereits einen Solver oder eine Planungssuite lizenziert haben und Planern Was-wäre-wenn-Zugriff geben wollen, ohne etwas zu bauen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Modelle: ein Frontier-Reasoning-/Code-Modell mit strukturierten Ausgaben und Tool-Nutzung (Claude, GPT, Gemini oder Mistral als EU-Anbieter), gehostet in einer EU-Region (z. B. Azure OpenAI EU, Vertex AI EU, AWS Bedrock Frankfurt, Mistral La Plateforme).
• Solver: OR-Tools (CP-SAT, Routing) [7], HiGHS (Open-Source-LP/MIP, MIT-Lizenz) [8], Pyomo oder PuLP als Modellierungsschichten; Gurobi oder CPLEX, wo Leistung oder Lizenzierung bereits gegeben sind.
• Orchestrierung: eine kleine Agentenschleife (erzeugen, in der Sandbox ausführen, Solver-Log lesen, korrigieren) mit einer festen Prompt-Bibliothek aus Modell-Templates; Tool-Aufrufe an ein Verzeichnis vorab validierter Modelle für Was-wäre-wenn-Fragen (sicherer als freie Erzeugung).
• Wählen Sie B, wenn: Sie eigene Fachlogik benötigen und Ihre Daten an eine in der EU gehostete Schnittstelle gehen dürfen.

Weg C — Selbst betreiben (Open Source)

• Modelle: Reasoning-/Code-Modelle mit offenen Gewichten (z. B. Qwen3 / Qwen-Coder-Familie, DeepSeek-R1-Destillate, gpt-oss), betrieben mit vLLM oder Ollama; Forschungs-Checkpoints wie ORLM [6].
• Stack: HiGHS, OR-Tools, Pyomo, optional eine Docker-Sandbox für den erzeugten Code; Notebooks als Oberfläche.
• Hardware: HW1 genügt für kleine Modelle plus CPU-Solver; HW2 bis HW3 für starke Reasoning-Modelle (Klasse 30B+) vor Ort.
• Aufwand: 1-3 Monate inkl. Sandboxing und Evaluierung. Wählen Sie C, wenn: Daten oder Nebenbedingungen vertraulich sind und das Haus nicht verlassen dürfen.

Weg D — Eigenes Training

Feintuning auf Paaren aus Problemtext und verifizierten Modellen (wie bei ORLM [6]) lohnt sich nur für eine enge Domäne mit vielen wiederkehrenden Problemtypen und einer großen Bibliothek validierter Modelle. Üblich ist die Erzeugung synthetischer Daten mit durch Solver verifizierten Labels. Für KMU selten nötig.

Stand der Technik (2026)

• Reasoning-Modelle haben die Qualität von Text-zu-Modell gegenüber 2023 deutlich verbessert, und die Forschung ist von einmaligem Prompting zu agentischen Schleifen mit Tests und Solver-Rückmeldung übergegangen [5]. Benchmark-Werte sollten mit Vorsicht gelesen werden, da Datensätze und Versionen abweichen [3].
• Die Anbieter sind auf das Muster „LLM als Frontend eines Solvers“ eingeschwenkt, wobei MCP-Server Solver und Modelle für Coding-Assistenten bereitstellen [2].
• Typische Fehlerbilder: fehlende oder falsch verknüpfte Nebenbedingungen, falsches Big-M oder falsche Indizierung, stillschweigend gelockerte Anforderungen, eine kontinuierliche Variable als ganzzahlig modelliert oder umgekehrt, übermäßig selbstsichere Erklärungen und nicht reproduzierbare Ergebnisse (derselbe Prompt liefert unterschiedliche Modelle) [4].
• Gegenmaßnahmen: Rückfragen stellen, Tests erzeugen (bekannte zulässige/unzulässige Fälle), mit einer von Hand gelösten Spielinstanz vergleichen, Modellversionen per Diff vergleichen, eine Bibliothek geprüfter Templates führen und die Formulierung in Fachsprache darstellen.
• Was-wäre-wenn auf festen Modellen ist verlässlicher als freie Formulierung, weil die Modellstruktur bereits validiert ist [1].

Gemeinsame Bausteine & Kombinationen

• Gleicher Technologie-Stack (llm-code + optimization-solver): OPT-001 Tourenplanung, OPT-002 APS, OPT-003 Personaleinsatzplanung, OPT-005 Bestand, OPT-008 S&OP und Netzwerkdesign; der Copilot kann für alle als Dialogschicht dienen.
• Angrenzend: CODE-001 (IDE-Assistenten schreiben den Solver-Code), CODE-007 (Anwendungsbau für Nicht-Entwickler), DATA-009 (AutoML für Analysten; keine mathematische Programmierung) und Prognosen (PRED-Familie) als Eingabe der Optimierung („erst vorhersagen, dann optimieren“).
• Gemeinsame Infrastruktur: ein Dienst für Code-Ausführung in der Sandbox und ein Modell-Gateway können Copilots für Code, Analytik und Optimierung bedienen.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen plus Lizenzen. Weg B: 4-10 Wochen für einen validierten Pilot mit 2-3 Templates. Weg C: 1-3 Monate plus Hardware.
• Kostentreiber: Solver-Lizenzen (Open Source vermeidet sie), Tokens des Reasoning-Modells (klein je Problem, da die Probleme kurz sind) und vor allem die Zeit der Experten für die Validierung.
• Kennzahlen: Zeit von der Problembeschreibung bis zum validierten Modell, Anteil der erzeugten Modelle, die Tests im ersten Anlauf bestehen, Anteil korrekt beantworteter Was-wäre-wenn-Fragen (gegen eine Referenz geprüft), Akzeptanz bei den Planern, Entscheidungsqualität (Zielfunktionswert gegenüber dem bisherigen manuellen Plan) und Zahl der Expertenkorrekturen je Modell.

Menschen & Veränderung

Binden Sie die Geschäftsleitung (Sponsor und Umfang), die Abteilungsleitung, die den Planungsprozess verantwortet, und die Anwender ein, also die Planer, die die tatsächlichen Nebenbedingungen kennen und jeden Vorschlag prüfen werden. Die IT stellt den Datenzugriff und einen sicheren Ort für die Ausführung von Solver-Code bereit; Datenverantwortliche geben die Tabellen und ERP-Exporte frei. Holen Sie die Planer ganz zu Beginn ins Boot, denn sie liefern die Nebenbedingungen und beurteilen, ob Ergebnisse plausibel sind.

Betriebsrat: in der Regel nein, da das Werkzeug Pläne und Ressourcen optimiert, nicht Verhalten oder Leistung von Menschen. Relevant wird es, wenn das Modell einzelne Beschäftigte einplant oder protokolliert, wer was gefragt hat; dann greift § 87 Abs. 1 Nr. 6. Auch sonst sollten Sie den Betriebsrat frühzeitig nach § 90 Abs. 1 Nr. 3 informieren, wenn KI in Arbeitsprozessen eingesetzt wird.

Datenschutz: überwiegend Geschäftsdaten; eine Prüfung durch die oder den Datenschutzbeauftragten ist nur nötig, wenn Beschäftigten- oder Kundendaten in das Modell gelangen. Senden Sie vertrauliche Kostendaten nie an ein Werkzeug ohne AVV (Art. 28 DSGVO). KI-Kompetenz: Zeigen Sie den Planern, wie der Copilot ein Modell formuliert, wie man die Annahmen liest und warum erzeugter Code geprüft werden muss; das unterstützt Art. 4 KI-Verordnung. Starten Sie mit einem Planungsproblem und einem Power-User als KI-Botschafter. Typische Sorge ist das Vertrauen in „Black-Box“-Ergebnisse; begegnen Sie ihr mit dem sichtbaren Modell, der Liste der Nebenbedingungen und der Möglichkeit zu überstimmen. Siehe GUIDE-009, GUIDE-006 und GUIDE-008.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): typischerweise minimales Risiko, da das System Planungsmodelle erzeugt, keine Entscheidungen über Personen. Es wird hochriskant (Anhang III, z. B. Beschäftigung, Verwaltung von Arbeitnehmern oder Aufgabenzuweisung auf Basis individuellen Verhaltens), wenn das optimierte Objekt Menschen sind, etwa bei der Personaleinsatzplanung mit Leistungs- oder Verhaltensdaten; siehe dann OPT-003. Die KI-Kompetenz (Art. 4) gilt für die Anwender [9].
• DSGVO: Modelldaten sind überwiegend operativ. Dienstpläne, Fahrerdaten oder Kundendaten in Prompts sind personenbezogene Daten; nutzen Sie daher Verarbeitung in der EU-Region, Auftragsverarbeitungsverträge, Datenminimierung und möglichst pseudonymisierte IDs.
• Risiko durch Code-Ausführung: Von LLMs erzeugter Code kann fehlerhaft oder unsicher sein; führen Sie ihn in einer Sandbox ohne Netzwerkzugang und ohne Zugangsdaten der Produktivsysteme aus.
• Entscheidungsrisiko und Verantwortlichkeit: Ein unlösbares oder falsch spezifiziertes Modell kann überzeugend wirkende, aber falsche Pläne liefern. Verlangen Sie die Freigabe durch Experten, versionierte Modelle und ein Audit-Protokoll von Prompt, Formulierung, Code, Datenversion und Solver-Ausgabe. Die Antwort des Optimierers ist nur so gut wie die formulierten Nebenbedingungen.
• Anbieter und geistiges Eigentum: Prüfen Sie die Lizenzbedingungen für die Nutzung von Solvern mit Cloud-LLMs und ob Prompts für das Training verwendet werden.

Erste Schritte

1. Wählen Sie eine wiederkehrende Entscheidung mit bekannter Best Practice (z. B. ein Produktmix- oder Schichtzuteilungsproblem) und einer von Hand erstellten Baseline.
2. Beschreiben Sie das Problem in Alltagssprache, mit Datenspalten und Einheiten, und lassen Sie ein LLM die Formulierung entwerfen; prüfen Sie sie mit einem Fachexperten.
3. Setzen Sie es mit HiGHS oder OR-Tools um, ergänzen Sie Unit-Tests (bekannte Lösungen, unzulässige Fälle) und die Ausführung in der Sandbox.
4. Ergänzen Sie eine Was-wäre-wenn-Schicht für 5-10 typische Planerfragen auf dem validierten Modell und vergleichen Sie die Antworten mit manuellen Neuberechnungen.
5. Messen Sie die Kennzahlen 4-6 Wochen lang und entscheiden Sie dann über eine Template-Bibliothek oder eine zugekaufte Plattform.

Quellen

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