Vom Schema zur Entscheidung: Wie LLM-Agents die Pipeline von Digital Twin bis Optimierung beschleunigen.

Wer heute Daten in Entscheidungen verwandelt, durchläuft — bewusst oder nicht — vier Spuren: Digital Twin (Schemata, Simulationen, Rohdaten), Analytics Engineering (Semantic Layer, aggregierte Daten), Analytics & ML (Use Cases identifizieren, Modelle bauen, trainieren, betreiben) und Optimierung (klassische OR-Modelle, Simulations-Gyms, Metaheuristiken). Quer darunter liegen zwei Bänder, die jede Spur berühren: QA und Visualize.

Abb. 1 — Vier Spuren, zwei Querschnittsbänder. Jeder Pfeil ist heute ein manueller Übersetzungsschritt zwischen Disziplinen — und damit ein Kandidat für Agent-Unterstützung.

Die These dieses Beitrags: Jeder Pfeil in diesem Diagramm ist heute ein teurer, manueller Übersetzungsschritt — vom OT-Schema zum Datenmodell, vom Datenmodell zum Use Case, vom Use Case zur formalen Optimierung. Diese Übersetzungen sind keine Rechenarbeit, sondern Verständnis- und Formulierungsarbeit. Und genau dafür sind Large Language Models gebaut. Der entscheidende Faktor ist dabei nicht das Modell selbst, sondern der Harness: das spezialisierte Gerüst aus Tools, Verifikationsschleifen, Solver-Anbindung und Domänenwissen, das aus einem Sprachmodell einen verlässlichen Mitarbeiter in der Pipeline macht.

Am Anfang der Pipeline steht das, was in Werken, Netzen und Flotten ohnehin vorhanden ist: heterogene Rohschemata. OPC-UA-Adressräume, SCADA-Tags mit kryptischen Namenskonventionen, Asset-Modelle aus dem Instandhaltungssystem, ERP-Strukturen, Zählpunktlisten. Wer daraus einen Digital Twin oder auch nur eine belastbare Simulation bauen will, verbringt Wochen damit, diese Schemata zu lesen — zu verstehen, welcher Tag welche Anlage misst, welche Einheit gilt, welche Hierarchie gemeint ist.

Genau dieses Lesen ist eine Agent-Aufgabe. Ein LLM-Agent mit Schema-Introspektions-Tools durchläuft Adressräume und Tabellen, erkennt Namenskonventionen, schlägt Mappings auf ein Zielmodell vor und markiert Unsicherheiten explizit zur Prüfung. Darauf aufbauend generiert er Simulationskonfigurationen und Szenarien für synthetische Daten — etwa Lastprofile für Anlagen, die noch keine Historie haben.

Abb. 2 — Sieben Schema-Welten, sieben Namenskonventionen. Der Agent liest sie alle — und schlägt das gemeinsame Zielmodell vor.

Der Harness dazu: MCP-Anbindungen an die Quellsysteme (lesend), Werkzeuge zur Schema-Introspektion, und — entscheidend — die Validierung jedes vorgeschlagenen Mappings gegen echte Datenproben. Ein Mapping, das an realen Stichproben scheitert, kommt nicht durch. So bleibt der Mensch Reviewer der Struktur, nicht Abtipper der Tags.

Die zweite Spur ist das Herzstück der Pipeline — und der Ort, an dem die meisten Projekte stecken bleiben. Ein Unified Namespace oder Semantic Layer ist im Kern eine Ontologie-Aufgabe: Aus Rohschemata und Geschäftskontext entsteht eine gemeinsame Sprache — Namensräume, Kennzahlen- Definitionen, Aggregationslogik, Lineage. Diese Arbeit ist konzeptionell, iterativ und dokumentationsintensiv. Drei Eigenschaften, die sie für LLM-Agents prädestinieren.

Konkret heißt das: Der Agent liest die Rohschemata aus Spur eins, gleicht sie mit dem Geschäftskontext ab — Prozessbeschreibungen, Kennzahlen-Kataloge, sogar Wiki-Seiten — und schlägt einen Namensraum vor: Standort / Anlage / Aggregat / Messgröße. Daraus generiert er dbt-Modelle und Aggregationslogik, inklusive Tests und Dokumentation. Jede Iteration mit dem Fachbereich verfeinert die Ontologie; der Agent hält Modell, Tests und Doku synchron.

• Vorschlagen statt raten: Der Agent legt Mapping-Kandidaten mit Konfidenz und Begründung vor — der Fachbereich entscheidet.
• Code als Ergebnis: dbt-Modelle, Views und Prüfregeln entstehen als versionierter, getesteter Code — kein Klick-Konfigurat.
• QA als Gate: Automatische Tests, Lineage-Checks und Human-in-the-loop-Review sind Teil des Harness, nicht Nachgedanke.

Die dritte Spur beginnt mit einer Box, die man wörtlich nehmen darf: „propose analytics use cases based on schemata & business context". Das ist — Buchstabe für Buchstabe — ein LLM-Prompt. Bisher war diese Aufgabe Workshop-Arbeit: Fachbereiche, Data Scientists und Berater sammeln Ideen, priorisieren nach Bauchgefühl, und oft gewinnt der lauteste Use Case statt des wertvollsten.

Ein Agent geht systematischer vor: Er durchsucht den Semantic Layer, gleicht verfügbare Daten mit Geschäftszielen ab und erzeugt eine priorisierte Kandidatenliste — je Use Case mit Datenverfügbarkeit, geschätztem Wertbeitrag und Umsetzungsaufwand. Nicht als Ersatz für den Workshop, sondern als dessen vorbereitete Grundlage: Die Diskussion startet bei einer quantifizierten Longlist statt bei einem leeren Whiteboard.

Danach wird der Agent zum ML-Engineering-Copiloten für model → train → run: Er schreibt Feature-Pipelines gegen den Semantic Layer, orchestriert Experimente, interpretiert Metriken und dokumentiert Entscheidungen. Der Harness dafür: Sandboxed Code Execution, Anbindung an Experiment-Tracking, automatische Evaluation gegen Holdout-Daten — und die aggregierten Daten aus Spur zwei als einzige erlaubte Datenquelle, damit Training und Semantik nie auseinanderlaufen.

Der vielleicht stärkste Hebel liegt in der vierten Spur. Operations Research hat ein bekanntes Nadelöhr: Zwischen dem Fachanwender, der sein Problem in Prosa beschreibt, und dem formalen Modell mit Zielfunktion und Constraints steht traditionell ein rarer Spezialist. LLM-Agents verkürzen genau diese Strecke — sie übersetzen natürlichsprachliche Problembeschreibungen in Solver-Code für Gurobi, OR-Tools oder HiGHS, erklären Infeasibilities in Klartext und iterieren direkt mit dem Fachbereich.

# Batterie-Fahrplan: Spotpreis-Arbitrage unter Netzbezugsgrenze
m.t = RangeSet(0, 95)                      # 96 Viertelstunden
m.charge    = Var(m.t, bounds=(0, 0.5))    # MW Laden
m.discharge = Var(m.t, bounds=(0, 0.5))    # MW Entladen
m.soc       = Var(m.t, bounds=(0, 2.0))    # MWh Speicherstand

def grid_cap(m, t):                       # Netzbezug ≤ 3,3 MW — hart
    return load[t] + m.charge[t] - m.discharge[t] <= 3.3
m.cap = Constraint(m.t, rule=grid_cap)

def soc_balance(m, t):                    # Speicherbilanz je 15 min
    prev = 1.0 if t == 0 else m.soc[t-1]
    return m.soc[t] == prev + 0.25*(eta*m.charge[t] - m.discharge[t]/eta)
m.bal = Constraint(m.t, rule=soc_balance)

m.end_soc = Constraint(expr=m.soc[95] >= 1.0)  # Schichtende ≥ 50 %

m.obj = Objective(                          # Kosten minimieren
    expr=sum(0.25*price[t]*(m.charge[t] - m.discharge[t]) for t in m.t),
    sense=minimize)

Abb. 3 — Jede Prosa-Anforderung findet sich als benannter Constraint wieder. Der Solver prüft die Rechnung — der Fachbereich prüft die Bedeutung.

Das Beispiel zeigt den entscheidenden Punkt: Der Solver ist eine harte Verifikationsinstanz. Das Modell rechnet — oder es rechnet nicht. Eine vergessene Einheit, ein widersprüchlicher Constraint, eine unbeschränkte Variable fallen sofort auf. Damit hat die vierte Spur etwas, das reinen Text-Anwendungen fehlt: ein eingebautes Korrektiv gegen Halluzination. Der Harness ergänzt Constraint-Bibliotheken für wiederkehrende Muster (Speicherbilanzen, Rüstzeiten, Lenkzeiten) und Benchmark-Suites für Regressionstests.

Für den zweiten Ast der Spur — Gym/Simulationen und MC-Metaheuristiken — gilt dasselbe Prinzip: Agents konfigurieren Simulationsumgebungen aus dem Digital Twin, tunen Metaheuristik-Parameter, interpretieren Konvergenzverhalten und dokumentieren, warum eine Lösung gewählt wurde. Die Simulation übernimmt die Rolle des Solvers: Sie ist das Ground-Truth- Feedback, an dem sich jeder Vorschlag messen lassen muss.

Die beiden Bänder unter der Pipeline sind keine Fußnote — sie sind der Grund, warum das Ganze im Dauerbetrieb funktioniert. QA heißt hier: Agents als Reviewer der Agents. Ein Prüf-Agent generiert Tests für Datenmodelle, überwacht Datenqualität und Drift, und — besonders wirksam — prüft Optimierungsergebnisse gegen die Simulation: Der gestrichelte Pfeil von run zurück zum Gym im Diagramm ist ein geschlossener Feedback-Loop. Ein Fahrplan, der in der Simulation die Netzgrenze reißt, geht nicht in den Betrieb.

Visualize wiederum profitiert direkt vom Semantic Layer: Weil Kennzahlen dort definiert und dokumentiert sind, kann ein Agent Dashboards und Berichte generieren, die garantiert dieselben Definitionen nutzen wie Training und Optimierung. Schluss mit drei Versionen derselben Kennzahl in drei Abteilungen — der Bericht ist ein Abnehmer des Layers, kein Parallelsystem.

• Testgenerierung: Prüfregeln und Unit-Tests für jedes Datenmodell, automatisch vorgeschlagen, menschlich freigegeben.
• Plausibilitäts-Backtesting: Jede Optimierungsempfehlung läuft gegen die Simulation, bevor sie den Betrieb erreicht.
• Berichtswesen als Nebenprodukt: Dashboards und Management-Reports direkt aus den Definitionen des Semantic Layer.

Wie sieht das konkret aus? Drei kompakte Beispiele — je eines pro Branche, jeweils entlang derselben Pipeline.

Der Unterschied zwischen einem Chatbot, der über Daten redet, und einem Agent-System, das in der Pipeline arbeitet, liegt vollständig im Harness. Vier Bausteine machen ihn aus:

Wichtig ist die Reihenfolge der Verantwortung: Der Agent schlägt vor, der Harness prüft, der Mensch gibt frei. Kritische Aktionen — ein Prozess wird verschoben, eine Batterie vorgeladen, ein Plan veröffentlicht — durchlaufen definierte Freigaben. Das ist keine Bremse, sondern die Voraussetzung dafür, dass Agents überhaupt in produktionsnahe Systeme dürfen.

Kein Beitrag über LLM-Agents ist vollständig ohne die Gegenrechnung. Vier Risiken verdienen besondere Aufmerksamkeit:

• Halluzinierte Constraints: Ein Modell, das rechnet, ist nicht automatisch das richtige Modell. Ein plausibel klingender, aber falsch übersetzter Constraint fällt dem Solver nicht auf — nur dem Fachbereich. Deshalb: Jeder Constraint trägt seine Prosa-Herkunft als Kommentar und wird einzeln abgenommen.
• Verantwortung & Nachvollziehbarkeit: Wer haftet für einen automatisch generierten Plan? Die Antwort muss organisatorisch geklärt sein, bevor der erste Agent produktiv geht — mit klaren Freigabestufen und dokumentierten Entscheidungswegen.
• Datenschutz & OT-Security: Agents mit Zugriff auf Leittechnik-nahe Daten brauchen dieselbe Sicherheitsarchitektur wie jedes andere System in dieser Zone — lesende Anbindung, Netzsegmentierung, Berechtigungsmodell des Kunden.
• Plausibler Unsinn: Ohne harte Verifikation produzieren LLMs überzeugende Fehler. Die Antwort ist architektonisch, nicht appellativ: Kein Agent-Output erreicht den Betrieb ohne Test, Solver oder Simulation dazwischen.

Und die vielleicht wichtigste Einordnung: Die Rolle des Menschen verschiebt sich — vom Modellbauer zum Modell-Reviewer, vom Pipeline-Handwerker zum Architekten der Verifikation. Das ist ein Kompetenzthema, kein Personalabbau-Thema. Die raren OR- und Data-Spezialisten werden nicht ersetzt; sie werden von Übersetzungs-Fleißarbeit entlastet und auf die Fälle konzentriert, in denen ihr Urteil wirklich zählt.

Die vier Spuren des Diagramms verschwinden nicht — Schemata müssen weiterhin verstanden, Semantik weiterhin hergestellt, Modelle weiterhin verifiziert werden. Was sich ändert, ist die Durchlaufzeit: Der Weg vom Rohschema zur produktiven Optimierung schrumpft von Monaten auf Wochen, weil die Übersetzungsschritte dazwischen nicht mehr auf rare Spezialisten warten.

Für den Einstieg empfehlen sich zwei Prinzipien: Erstens, mit einem eng umrissenen Übergang starten — etwa der Use-Case-Discovery auf dem bestehenden Datenbestand oder der Modellformulierung für einen bekannten Optimierungsfall. Zweitens, Verifikation von Anfang an mitdenken: Tests, Solver-Feasibility und Simulations-Backtesting sind keine späteren Ausbaustufen, sondern die Grundlage, auf der Agents Vertrauen verdienen.

• Gibt es ein Optimierungsproblem, das seit Jahren „auf der Liste" steht, weil die Modellierung fehlt?
• Liegen Schemata und Geschäftskontext vor, aus denen ein Agent Use Cases ableiten könnte?
• Existiert ein Semantic Layer — oder wäre sein Aufbau der erste Agent-Use-Case?
• Ist eine Simulation oder ein Solver vorhanden, der als Verifikationsinstanz dienen kann?

Wenn zwei oder mehr dieser Fragen mit Ja beantwortet werden, ist der Boden bereitet. Der nächste Schritt ist bewusst klein: ein Übergang, ein Agent, ein Verifikationsgate — und ein KPI, an dem sich das Ergebnis messen lässt.