Die Episode behandelt ein operatives Entscheidungsproblem aus dem Stromhandel: Wie leitet man aus Preisvorhersagen eine robuste Sequenz von Ein- und Verkaufsentscheidungen ab, wenn Ausführung (Trade kommt zustande oder nicht) und Prognosen unsicher sind? Als Beispiel dient ein Batteriespeicher, der in 15‑Minuten-Intervallen Strom kaufen (laden) oder verkaufen (entladen) kann. Der Fokus liegt weniger auf „einem guten Forecast“ als auf einem Entscheidungsalgorithmus, der unter realen Randbedingungen zuverlässig funktioniert.
1) Ausgangslage: Stromhandel als sequenzielles Entscheidungsproblem
Marktmechanismen
- Auktionen: Teilnehmende geben Gebote ab (oft mit Vorlauf, z. B. day-ahead). Am Ende wird ein „fairer“ Preis ermittelt, zu dem der Handel stattfindet. Wer höher geboten hat, zahlt trotzdem den fairen Marktpreis (analog für Verkäufer).
- Kontinuierlicher Handel: Laufender Handel wie an klassischen Börsen: Orders werden ausgeführt, sobald sie zusammenpassen.
Zeitstruktur
- Stromhandel ist in 15‑Minuten-Intervalle diskretisiert. Verpflichtungen (z. B. Einspeisung nach Verkauf) gelten jeweils für ein Intervall.
Typische Preisdynamik
- Nachts niedrige Preise, vormittags und nachmittags Peaks, mittags häufig ein Tief (z. B. Solar-Effekt). Es gibt Ausnahmen bis hin zu Preisen nahe Null (z. B. bei hoher Einspeisung erneuerbarer Energien bei geringer Nachfrage).
Wer profitiert grundsätzlich?
- Akteure mit Flexibilität:
- Speicher (Batterie, Pumpspeicher)
- Flexible Erzeugung (z. B. Biogas, Speicherwasser)
- Flexibler Verbrauch (Lastverschiebung, industrielle Prozesse)
Ziel
- Eine Sequenz von Kauf-/Verkauf-/Warteentscheidungen finden, die den Gewinn maximiert – unter Berücksichtigung technischer Grenzen und Unsicherheit.
2) Beispielsystem: Batteriespeicher als Entscheidungsobjekt
Das Beispiel ist bewusst vereinfacht, aber realitätsnah strukturiert:
- Kapazität: 10 MWh (im Modell: 10 „Einheiten“)
- Zustände: 0 bis 10 → 11 Ladezustände
- Leistung / Rampenbegrenzung: pro 15 Minuten ±1 Einheit (laden oder entladen)
- Horizont: 100 Zeitschritte (≈ 25 Stunden)
- Startzustand: t = 0 (Mitternacht), Ladezustand = 3
Damit entsteht ein klassisches sequenzielles Optimierungsproblem: Jede Entscheidung beeinflusst die später verfügbaren Optionen (z. B. wer morgens zu früh verkauft, hat nachmittags keinen Speicherinhalt mehr).
3) Naiver Ansatz: Schwellenwertstrategie – und warum sie scheitert
Als Baseline wird eine einfache Regel vorgestellt:
- Definiere einen Einkaufsschwellenwert (unterhalb kaufen)
- Definiere einen Verkaufsschwellenwert (oberhalb verkaufen)
- Dazwischen: nichts tun
- Schwellenwerte werden aus der Preisverteilung des Tages abgeleitet (z. B. unteres Drittel = kaufen, oberes Drittel = verkaufen)
Beobachtete Probleme im Beispiel:
- Der Speicher wird nachts schnell vollgeladen.
- Der Vormittagspeak ist in diesem konkreten Verlauf zu flach bzw. nur kurz über dem Verkaufsschwellenwert → es werden nur wenige Einheiten verkauft → das Vormittagsgeschäft wird „verpasst“.
- Das Mittagstief liegt knapp oberhalb des Einkaufsschwellenwerts → es wird nicht nachgeladen, obwohl es strategisch sinnvoll wäre.
- Am Nachmittag wird zu früh zu moderaten Preisen verkauft (z. B. 160), sodass später höhere Preisniveaus (180–200) nicht mehr bedient werden können, weil der Speicher leer ist.
- Zusätzlich werden kleinere Handelsgelegenheiten in oszillierenden Preisphasen nicht ausgenutzt.
Kernaussage: Schwellenwertregeln sind zu grob. Sie ignorieren die Abhängigkeit über die Zeit („Wenn ich jetzt verkaufe, fehlt mir Energie später“) und behandeln Entscheidungen nicht als zusammenhängende Sequenz.
4) Saubere Modellierung: Zustandsraum, Diskretisierung und Planungshorizont
Um algorithmisch belastbar zu werden, wird das Problem formalisiert.
Diskretisierung
- Zeit wird in 15‑Minuten-Schritte diskretisiert: ( t = 0 … 100 )
- Speicherfüllung wird diskretisiert: ( s = 0 … 10 )
Zustandsraum
- Ein Zustand ist ein Paar ((t, s)).
- Eine Entscheidung bewegt das System von ((t, s)) nach ((t+1, s‘)) mit Randbedingungen (z. B. ( s‘ = s ± 1) oder ( s‘ = s)).
Planungshorizont
- Zu kurz geplant → „greedy“, frühzeitige Verkäufe, später fehlen Ressourcen.
- Zu lang geplant → Forecastunsicherheit dominiert.
- Praktischer Sweet Spot liegt typischerweise bei 1–2 Tagen, muss aber systematisch validiert werden.
5) Warum Brute Force nicht geht – und was stattdessen funktioniert
Mit 100 Zeitschritten und 3 Aktionen pro Schritt (kaufen/verkaufen/nichts) gibt es:
- 3¹⁰⁰ ≈ 10⁵⁰ mögliche Entscheidungssequenzen.
Das ist nicht durchprobierbar.
Stattdessen: Dynamische Programmierung nach dem Optimalitätsprinzip von Bellman.
6) Optimaler Handelsalgorithmus (Deterministischer Forecast)
Zentrale Idee: Wir berechnen eine Funktion „maximaler zukünftiger Gewinn“:
- ( V(t, s) ): maximaler erwarteter Gewinn ab Zeitpunkt (t) bei Speicherstand (s)
Rückwärtsiteration
- Am Ende des Horizonts (z. B. (t=100)) wird ein Endwert für alle Ladezustände s gesetzt (eine Approximation reicht; Einfluss auf die Startentscheidung ist begrenzt).
- Dann iteriert man rückwärts von (t=99) bis (t=0) und bestimmt V(t, s) aus den Werten der nächsten zukünftigen Zeitscheibe V(t+1, s‘) + Cashflow.
- Für jeden Zustand ((t, s)) prüft man die möglichen Aktionen:
- Kaufen: sofortiger negativer Cashflow (Preis), Übergang nach ((t+1, s+1))
- Nichts tun: Übergang nach ((t+1, s))
- Verkaufen: sofortiger positiver Cashflow, Übergang nach ((t+1, s-1))
- Man wählt die Aktion mit dem höchsten resultierenden Wert und speichert sie (Policy/Entscheidungspfad).
Ergebnis
- Man erhält nicht nur den maximalen Gewinnwert, sondern auch die komplette optimale Entscheidungssequenz für den Startzustand ((0, 3)).
Hinweis zur Rechenlast
- Der Aufwand skaliert mit der Größe des Zustandsraums: mehr Ladezustände (feinere Diskretisierung) → mehr Rechenzeit. Diskretisierung ist daher ein praktischer „Hebel“ zwischen Qualität und Aufwand.
7) Diskontierung als Schutz gegen Forecastunsicherheit
Weil Vorhersagen in weiterer Zukunft unzuverlässiger sind, wird ein Diskontierungsfaktor ( β < 1 ) eingeführt:
- Erträge in der nahen Zukunft zählen stärker als Erträge in ferner Zukunft.
- Formal: Cashflows werden mit βᵗ gewichtet.
Das verhindert Strategien, die nur deshalb „optimal“ wirken, weil sie auf unsicheren, weit entfernten Forecastwerten aufbauen.
8) Erweiterung: Unsicherheit und Ausführungswahrscheinlichkeit
Die Episode wechselt dann von „Forecast ist perfekt“ zu „Forecast ist unsicher“ und ergänzt ein entscheidendes Realitätsdetail: Ein Gebot wird nicht garantiert ausgeführt.
8.1 Ausführung als probabilistisches Ereignis
Ein Forecast liefert nicht nur einen erwarteten Preis, sondern (idealisiert) auch eine Streuung/Verteilung. Daraus werden Preislevel für bestimmte Ausführungswahrscheinlichkeiten abgeleitet (Beispiel-Quantile):
- 2,3% / 15,9% / 50% / 84,1% / 97,7% (Sigma-verschobene Punkte einer Normalverteilung)
8.2 Mehr Handlungsoptionen
Statt nur „kaufen“ gibt es jetzt z. B. „Kaufangebot zu Preislevel X“ (mit bestimmter Ausführungswahrscheinlichkeit). Analog für Verkauf.
Aus 3 Aktionen werden dadurch 11:
- 5 Kaufpreisstufen
- 1x nichts tun
- 5 Verkaufpreisstufen
8.3 Erwartungswertbildung im Bellman-Update
Für ein Angebot gibt es zwei mögliche Folgezustände:
- Ausgeführt: Speicherstand ändert sich (z. B. (s+1) oder (s-1)), Cashflow realisiert
- Nicht ausgeführt: Speicherstand bleibt gleich, kein Cashflow (bzw. anderer Effekt)
Der Wert (V(t,s)) berücksichtigt daher den Erwartungswert aus beiden Fällen, gewichtet mit der jeweiligen Ausführungswahrscheinlichkeit.
9) Mehrere Auktionen und „bereits gesicherte“ Trades
In der Praxis existieren mehrere Auktionen/Handelsfenster. Wenn eine Order in einer frühen Auktion bereits getätigt wurde, verändert das die spätere Entscheidung:
- Der Algorithmus muss berücksichtigen, welche Mengen bereits „fest“ sind.
- Dadurch ändern sich die zulässigen Aktionen (z. B. zusätzliche Verkäufe sind nur möglich, wenn die physische Lieferfähigkeit über alle bereits gebuchten Mengen hinweg gewahrt bleibt).
10) Wie man Ausführungswahrscheinlichkeiten empirisch bestimmt
10.1 Auktion (relativ einfacher Fall)
- Man nutzt historische Daten: Forecastpreis vs. realer Auktionspreis.
- Betrachtet wird der relative Fehler (prozentual), nicht nur der absolute.
- Aus der Fehlerverteilung lässt sich für ein Gebotsniveau eine Ausführungswahrscheinlichkeit ableiten (über Integration/CDF).
Verfeinerungen sind begrenzt, da Auktionen „blind“ sind. Als zusätzliche erklärende Variablen werden u. a. genannt:
- Lastprognose
- Residuallast (Last minus erneuerbare Einspeisung)
10.2 Kontinuierlicher Handel (komplexer)
Hier kann auch bei „richtigem“ Preis die Ausführung scheitern, z. B. wegen Priorität/Queue und verfügbarem Volumen.
Zwei Ansätze:
- Empirisch über relative Preisabstände: Für Abstände statistisch erfassen, wie oft es geklappt hat.
- Execution-Modelle mit Marktmikrostruktur-Parametern, z. B.:
- Best Bid / Best Ask
- Volumen auf der Preisstufe „vor“ der eigenen Order
- Zeit bis zur Lieferung
- Preistrend / Dynamik
Wenn Tickdaten verfügbar sind, kann ein Hazard-Rate-Modell verwendet werden:
- Ereignisrate (Ausführungsrate) über Zeit integrieren → Ausführungswahrscheinlichkeit bis zum Lieferzeitpunkt.
11) Ensemble-Forecasts, Bewertung und sauberes Benchmarking
Weil einzelne Forecasts Fehler haben, wird Ensemble-Bildung diskutiert:
- Kombination der Forecastwerte:
- Mittelwert (einfach)
- Median (robuster gegen Ausreißer)
- Gewichtung nach Qualität:
- z. B. MSE gegen historische Daten
- oder Log-Likelihood (passt besser, wenn Verteilungen bewertet werden)
- Alternativ: Parameteroptimierung für Gewichte (aufwendiger, kann aber Spezialfälle besser abdecken)
Wichtig: Ausführungswahrscheinlichkeiten für Ensembles können
- neu empirisch bestimmt werden, oder
- aus den Einzelverteilungen kombiniert werden (oft weniger praktikabel als neu zu schätzen).
Datenaufteilung für belastbare Bewertung
- Trainingsdaten: Parameterlernen
- Testdaten: Qualitätsmessung ohne Overfitting
- Benchmarkdaten: letzter, „unberührter“ Realitätscheck vor Produktivsetzung
End-to-End-Bewertung
Am Ende zählt nicht die Forecast-Metrik allein, sondern der Ertrag im simulierten Handel (Backtest mit historischen Realpreisen und Ausführungslogik).
Als Orientierung dienen zwei Referenzen:
- „Minimum“: der naive Schwellenwert-Algorithmus
- „Maximum“: ein unrealistischer Upper Bound, bei dem der Algorithmus die historischen Preise „kennt“ (perfekte Information)
Diese Skala hilft zu entscheiden, wie viel Forecast-Verbesserung sich überhaupt lohnt.
12) Systemrealität: Monitoring, Brüche, Fallbacks und Wartbarkeit
Für den produktiven Betrieb werden pragmatische Punkte betont:
Monitoring und Datenvalidierung
- Ausfall eines Forecast-Services (keine Daten)
- Offensichtliche Format-/Einheitenänderungen (z. B. €/MWh vs. €/kWh)
- Subtile Verhaltensänderungen des Forecasts (Anbieter ändert Modell) – besonders kritisch, weil historisch kalibrierte Ausführungswahrscheinlichkeiten und Ensemble-Gewichte dann nicht mehr passen.
Fallback-Strategien
- Bei Ausfall zentraler Komponenten soll das System auf eine robuste, datenarme Strategie zurückfallen (z. B. die naive Threshold-Strategie oder eine andere konservative Regel).
- Bei Teil-Ausfällen (z. B. einzelne Ensemble-Komponenten) muss man fallweise entscheiden, ob weiter gehandelt wird oder ob man komplett in den Fallback geht.
- In jedem Fall: Alarmierung.
Randbedingungen als Hebel für Investitionsentscheidungen
- Der Algorithmus kann genutzt werden, um den Wert technischer Verbesserungen zu quantifizieren:
- höhere Lade-/Entladeleistung
- Wirkungsgrad
- Degradation/Alterungskosten
- So lassen sich Engineering- oder Investitionsentscheidungen datengetrieben begründen.
Hyperparameter-Tuning
- Diskontierungsfaktor β, Diskretisierung der Zustände, Anzahl Preis-/Wahrscheinlichkeitsstufen etc. beeinflussen Ergebnis und Laufzeit.
- Empfehlung: systematische Suche, z. B. mit Verfahren wie dem „Ellenbogenverfahren“, und pragmatisch lieber zunächst kleinere Parameter für schnelle Iteration.
13) Kernerkenntnisse der Episode
- Stromhandel mit Speicher ist ein sequenzielles Entscheidungsproblem mit harten Randbedingungen.
- Naive Schwellenwertstrategien scheitern an Interdependenzen über die Zeit und an Zielkonflikten (zu früh verkaufen vs. später bessere Preise).
- Brute Force ist unmöglich; dynamische Programmierung nach Bellman macht das Problem effizient lösbar.
- Realistische Modelle brauchen Diskontierung (Forecast wird schlechter mit Horizont) und vor allem Ausführungswahrscheinlichkeiten (Gebote sind nicht garantiert).
- Forecastqualität wird sinnvoll über End-to-End-Handelsertrag bewertet, mit klaren Baselines und sauberer Datenaufteilung.
- Produktivbetrieb erfordert Monitoring, Robustheit und Fallbacks – sonst kippt ein „gutes Modell“ bei Datenbrüchen in unkontrolliertes Verhalten.
Damit zeigt die Episode, wie aus Forecastdaten ein operativ belastbarer Handelsalgorithmus wird: nicht als theoretisches Modell, sondern als Entscheidungslogik, die unter Unsicherheit, Ausführungsrisiko und technischen Grenzen zuverlässig funktioniert.
Infos zum Podcast
Alle aktuellen Infos zum Podcast (Single Point of Truth):
https://www.algorithmus-schmiede.de/podcast-entscheidungen-automatisieren/