Gemeinsam bessere Lastprognosen – ein Federated-Learning-Experiment auf öffentlichen Energie-Zeitreihen

Lastprognose ist für die meisten Versorger Alltagsgeschäft – und zugleich ein Bereich, in dem sich kleine Verbesserungen unmittelbar in Beschaffungskosten, Bilanzkreistreue und Regelenergiebedarf niederschlagen. Die unbequeme Wahrheit dabei: Ein einzelnes Stadtwerk sieht immer nur sein eigenes Netzgebiet. Das Modell lernt aus dem Verbrauchsmuster einer Region, einer Kundenstruktur, eines Wetterregimes.

Die naheliegende Idee, mehr Daten heranzuziehen, scheitert in der Praxis fast immer am gleichen Punkt: Verbrauchsdaten sind sensibel, wettbewerbsrelevant und rechtlich heikel. Niemand exportiert seine Lastgänge an einen Wettbewerber oder einen zentralen Pool. Genau hier setzt Federated Learning (FL) an: gemeinsam ein Modell trainieren, ohne dass die Rohdaten je den jeweiligen Standort verlassen.

Dieser Beitrag dokumentiert ein kleines, bewusst nachvollziehbares Experiment auf frei verfügbaren Energie-Zeitreihen. Es ist kein Produktnachweis, sondern eine ehrliche Standortbestimmung: Was bringt FL hier konkret – und wo sind die Grenzen?

Die Ausgangsfrage

Wenn mehrere „virtuelle Versorger” jeweils nur ihr eigenes Lastprofil sehen – kann ein gemeinsam trainiertes Modell bessere Prognosen liefern als das, was jeder für sich allein hinbekommt, ohne dass jemand seine Rohdaten teilt?

Aufbau

Um die Situation mehrerer Versorger nachzustellen, ohne echte vertrauliche Daten zu verwenden, haben wir ein öffentliches Datenset stündlicher Lastzeitreihen in mehrere disjunkte „Clients” aufgeteilt – jeder Client steht für eine Organisation mit eigenem, nicht geteiltem Datenbestand.

Verglichen wurden drei Szenarien:

1. Lokal (Baseline): Jeder Client trainiert ausschließlich auf seinen eigenen Daten. Das entspricht dem heutigen Normalfall.
2. Zentral (Obergrenze): Alle Daten werden zusammengeworfen und ein einziges Modell trainiert. Datenschutzrechtlich in der Realität meist ausgeschlossen – hier nur als theoretische Vergleichsmarke.
3. Föderiert (FL): Die Clients trainieren lokal; ausgetauscht werden nur Modell-Updates (Gewichte), die ein Koordinator mittels Federated Averaging zu einem gemeinsamen Modell verrechnet. Rohdaten bleiben überall lokal.

Als Modell diente bewusst eine schlanke, gut verstandene Architektur für Tageslast-Prognosen; die Wahl ist für die Kernaussage zweitrangig. Bewertet wurde über den mittleren absoluten prozentualen Fehler (MAPE) auf einem je Client zurückgehaltenen Testzeitraum.

Ergebnisse

Das erwartbare, aber dennoch instruktive Muster:

Szenario	Mittlerer MAPE	Einordnung
Lokal (Baseline)	am höchsten	Status quo je Organisation
Föderiert (FL)	dazwischen, nah an zentral	ohne Rohdatenaustausch
Zentral (Obergrenze)	am niedrigsten	rechtlich meist unrealistisch

Drei Beobachtungen sind über den konkreten Zahlenwert hinaus belastbar:

• FL holt den Großteil des Abstands zwischen „lokal” und „zentral” auf – ohne dass Rohdaten geteilt werden. Der größte Hebel zeigte sich bei den Clients mit den wenigsten eigenen Daten: Wer allein zu wenig Historie hat, profitiert am stärksten vom geteilten Lernen.
• Heterogenität kostet. Unterscheiden sich die Lastprofile der Clients stark (andere Kundenstruktur, anderes Klima), wird FL schwieriger und der Vorsprung schrumpft. Das ist kein Detail, sondern der zentrale Praxisfaktor.
• Die Betriebskomplexität ist real. Schon dieses Spielzeug-Setup verlangt Abstimmung über Runden, Aggregation und Modellstand. In der Praxis kommen Governance, Onboarding und Betrieb hinzu.

Was das Experiment nicht zeigt

Ehrlichkeit gehört zur Methode:

• Es belegt keine harte Datenschutzgarantie. Reines Federated Averaging schützt Rohdaten, aber Modell-Updates können je nach Setting Informationen preisgeben. Verfahren wie Secure Aggregation oder Differential Privacy adressieren das – mit eigenen Kosten bei Genauigkeit und Komplexität. Ein eigener Beitrag dazu folgt.
• Die Daten waren öffentlich und sauber. Reale Lastgänge sind lückenhaft, fehlerbehaftet und uneinheitlich erfasst. Datenqualität und -harmonisierung sind in der Praxis oft der größere Brocken als das ML selbst.
• Ein einzelnes Datenset ist kein Beweis. Es ist ein Indiz – und eine Einladung, die Methode im eigenen Kontext zu prüfen.

Was es zeigt

Trotz aller Vorbehalte bleibt die Kernaussage robust: Es gibt einen messbaren Mehrwert darin, gemeinsam zu lernen – und er ist erreichbar, ohne sensible Rohdaten zu teilen. Genau diese Kombination macht datenschutzwahrende Kooperation für die Energiewirtschaft interessant, wo praktisch jeder Datensatz entweder personenbezogen, wettbewerbsrelevant oder kritisch ist.

Die spannende Frage ist deshalb nicht mehr ob es technisch geht, sondern mit wem – welche Organisationen passen so zusammen, dass gemeinsames Lernen sich lohnt und rechtlich tragfähig ist. Das ist eine Matching-Frage. Und genau darum soll es hier mittelfristig gehen.

---

Sie arbeiten an Lastprognose oder verwandten Themen und haben zu diesem Versuch eine Meinung – Widerspruch ausdrücklich willkommen? Schreiben Sie uns. Wer beim Thema dranbleiben möchte: Neue Beiträge gibt es per RSS-Feed, eine kompakte Einführung im Whitepaper.