Prompt Engineering für Energie-Analysen: Was LLMs über ENTSO-E-Daten lernen

TL;DR: LLMs wie GPT-4o oder Claude 3.5 kennen ENTSO-E-Strukturen aus ihren Trainingsdaten – Domain-Codes, XML-Schemas, typische Tages-Lastkurven. Für belastbare Energie-Analysen reicht das aber nicht. Gutes Prompt Engineering Energie kombiniert LLM-Kontextwissen mit aktuellen Transparency-Platform-Abfragen, expliziten Zeitzonen-Regeln (UTC vs. CET) und Validierung gegen Referenzwerte. Ohne Retrieval bleibt es Textgenerierung.

Warum LLMs bei ENTSO-E-Daten nicht einfach "funktionieren"

Wer GPT-4o fragt "Was war der Day-Ahead-Preis am 14. März 2024 in der Gebotszone DE-LU?", bekommt oft eine selbstbewusste Zahl. Die ist meist falsch. LLMs haben keinen Zugriff auf die ENTSO-E Transparency Platform, wenn sie nicht über ein Tool-Calling-Interface angebunden sind. Sie halluzinieren plausible Werte – 82,40 €/MWh klingt gut, war aber 71,15 €/MWh.

Das Problem ist strukturell: ENTSO-E-Daten sind stündlich (teilweise viertelstündlich ab Q4 2025), marktzonen-spezifisch, in UTC publiziert, und das XML-Format mit `A44` für Day-Ahead-Preise, `A65` für Systemlast oder `A75` für tatsächliche Erzeugung nach Typ ist nicht intuitiv. Ein LLM weiss, *dass* es diese Codes gibt – es kennt den tatsächlichen Wert aber nicht.

Gutes Prompt Engineering für Energie-Analysen setzt genau hier an: Man nutzt das Strukturwissen des Modells, liefert die Daten aber selbst.

Was LLMs über ENTSO-E tatsächlich wissen

Aus öffentlichem Trainingsmaterial (ENTSO-E-Dokumentation, GitHub-Repos wie `entsoe-py`, Stack-Overflow-Fragen) haben die Modelle Folgendes internalisiert:

• Domain-Codes: `10Y1001A1001A82H` = DE-LU, `10YAT-APG------L` = Österreich
• Document Types: A44 (Preise), A65 (Last), A69 (Windprognose), A75 (Erzeugung)
• PsrType-Codes: B16 = Solar, B19 = Onshore Wind, B18 = Offshore Wind, B01 = Biomasse
• Zeitzonen-Fallen: Transparency Platform liefert UTC, deutsche Marktteilnehmer rechnen in CET/CEST
• Typische Preisniveaus: 2023–2024 Day-Ahead DE-LU meist 60–120 €/MWh, negative Preise an sonnigen Sonntagen

Was die Modelle nicht zuverlässig wissen: konkrete Werte, aktuelle API-Änderungen (z. B. viertelstündliche Auflösung nach JAO-Umstellung), Sonderfälle wie den negativen Preis-Rekord vom 2. Juli 2023.

Prompt-Patterns, die bei Energiedaten funktionieren

Aus über zwei Jahren produktivem Einsatz in unseren Causal-Engine-Pipelines haben sich vier Prompt-Muster durchgesetzt.

1. Schema-First statt Frage-First

Schlechter Prompt:

Besserer Prompt:

Der zweite Prompt funktioniert, weil das LLM die Struktur kennt und nur rechnen muss – idealerweise in einem Code-Interpreter-Tool, nicht im Textmodus.

2. Explizite Zeitzonen-Deklaration

In unseren internen Tests produzieren GPT-4o und Claude 3.5 bei fehlender Zeitzonen-Angabe bei rund jeder fünften Abfrage einen Off-by-one-Fehler. Gerade bei Day-Ahead-Preisen (Gate-Closure 12:00 CET) und Sommerzeit-Umstellung ist das kritisch.

Standard-Prefix in unseren Prompts:

3. Referenzwerte als Sanity-Check

Wir hängen an fachliche Prompts einen "Plausibilitätskorridor" an:

Das reduziert stille Halluzinationen deutlich – präzise quantifiziert haben wir es nicht, aber es fällt im Review-Prozess auf.

4. Kausalketten statt Korrelationen

LLMs neigen dazu, Korrelation mit Kausalität zu verwechseln. Beispiel: "Der Preis war hoch, weil die Last hoch war." Oft stimmt das, manchmal aber auch nicht (hohe Importe aus Frankreich, niedrige Gaspreise etc.). Unsere Causal Engine arbeitet mit 15 vordefinierten Kausalketten nach LEAP-71-Pattern, die das LLM als Kontext bekommt:

Das Ergebnis ist keine Wahrheit, aber eine strukturierte Hypothese.

Was in der Praxis schiefgeht

Wir sehen drei wiederkehrende Fehlermuster, wenn Stadtwerke oder BGA-Betreiber versuchen, LLMs direkt auf ENTSO-E-Daten loszulassen.

Halluzinierte API-Endpunkte

GPT-4 generiert gelegentlich Endpunkte wie `transparency.entsoe.eu/api/v2/prices`, die so nicht existieren. Die reale API ist `web-api.tp.entsoe.eu/api` mit `securityToken`, `documentType`, `in_Domain`, `out_Domain`, `periodStart`, `periodEnd`. Ohne Validierung gegen die offizielle Transparency Platform API Guide landet man in Endlosschleifen.

Verwechslung von Forecast und Actual

A69 ist Wind-Forecast, A75 ist Actual Generation. LLMs verwechseln das regelmässig, besonders wenn im Prompt nur "Windproduktion" steht. Für eine Redispatch-Analyse ist der Unterschied entscheidend – der Prognosefehler ist ja genau der Auslöser.

Fehlende Marktzonen-Trennung

Seit der Trennung von DE-AT-LU (Oktober 2018) ist DE-LU eine eigene Gebotszone. Ältere Trainingsdaten enthalten noch die alte Zone. Ohne expliziten Domain-Code bekommt man Mischungen.

Retrieval-Augmented Prompting mit ClickHouse

Wir haben bei Stromfee rund 4,4 Millionen Redispatch-Massnahmen seit 2013 sowie ENTSO-E-Marktdaten in ClickHouse historisiert. Der Workflow für LLM-gestützte Analysen:

1. Natural-Language-Query → LLM generiert SQL gegen dokumentiertes Schema
2. SQL-Ausführung auf ClickHouse (Read-only-User, Query-Timeout 30s)
3. Ergebnis-Kontext zurück ans LLM für Interpretation
4. Validierung gegen Referenzwerte aus der `electricity_price_forecast`-Pipeline (Prophet-basiert, 96 Preissignale)

Der entscheidende Punkt: Das LLM generiert und interpretiert, aber rechnet nicht mit den Zahlen selbst. Jede Aggregation läuft in ClickHouse. Das reduziert Halluzinationsfehler auf nahezu Null für numerische Ergebnisse – die Interpretation bleibt aber fehleranfällig und muss fachlich gegengelesen werden.

Beispiel-Prompt aus unserem Redispatch-Portal

Das Ergebnis ist reproduzierbar, die SQL auditierbar, die Interpretation diskutierbar.

Grenzen: Wo Prompt Engineering endet

Ehrlich gesagt: LLMs ersetzen keinen Fahrplanmanager. Was sie gut können:

• Strukturierte Zusammenfassungen historischer Marktdaten
• Erste Hypothesen für Preis-Anomalien
• SQL-Generierung gegen dokumentierte Schemas

• Regulatorische Einordnung (EEG, §14a EnWG, BNetzA-Festlegungen) – mit Quellenangabe prüfen

Was sie nicht können:

• Echtzeit-Intraday-Entscheidungen unter 15 Minuten Reaktionszeit
• Prognosen, die klassischen ML-Modellen (Prophet, LightGBM, N-BEATS) überlegen sind
• Rechtsverbindliche Aussagen zu Messkonzepten oder §14a-Steuerbarkeit
• Umgang mit proprietären Daten, die nicht im Training waren (EPEX-Intraday-Continuous)

Für einen 1-MW-BGA-Betrieb in Norddeutschland, den wir seit 2023 monitoren, nutzen wir das LLM ausschliesslich für Post-hoc-Analysen – nie für Live-Vermarktungsentscheidungen. Die trifft die Causal Engine regelbasiert.

Fazit

Prompt Engineering Energie ist keine Magie, sondern saubere Informationsarchitektur. LLMs kennen ENTSO-E-Strukturen gut genug, um sie zu parsen und zu beschreiben – aber nicht gut genug, um Zahlen zu erfinden. Wer Schema-First prompted, Zeitzonen explizit macht, Retrieval aus einer eigenen Datenbank ergänzt und Ergebnisse gegen Referenzwerte validiert, bekommt belastbare Analysen. Wer GPT-4o ohne Tools nach Day-Ahead-Preisen fragt, bekommt Textgenerierung mit Zahlenillusion.

Wir bauen diese Workflows in der Stromfee Academy nach, inklusive Simulatoren für BESS-Arbitrage und Redispatch-Szenarien. Für konkrete Integrationen in Stadtwerke- oder Industrie-Umgebungen: Kontakt.

FAQ

Kann ich GPT-4o direkt an die ENTSO-E Transparency Platform anbinden?

Ja, über Function Calling oder Tool Use. Du definierst eine Funktion `query_entsoe(document_type, domain, period_start, period_end)` und das LLM ruft sie auf. Ohne diesen Schritt arbeitet das Modell nur mit Trainingswissen, nicht mit Live-Daten.

Welche LLMs eignen sich am besten für Energie-Analysen?

Claude 3.5 Sonnet und GPT-4o sind in unseren internen Tests auf Augenhöhe. Claude ist tendenziell vorsichtiger bei Zahlenangaben, GPT-4o stärker im SQL-Generieren. Gemini 2.0 ist bei langen Kontexten (ganze Jahresdatensätze) im Vorteil. Open-Source-Modelle wie Llama 3.3 70B reichen für Schema-Generierung, nicht für fachliche Interpretation.

Wie gehe ich mit der Umstellung auf 15-Minuten-Auflösung um?

Die ENTSO-E-Transparency-Platform hat die viertelstündliche Auflösung für Day-Ahead-Preise 2025 schrittweise eingeführt. Prompts sollten explizit die Auflösung abfragen (`resolution PT15M` vs. `PT60M`) und das LLM darauf hinweisen, dass historische Daten vor 2025 in Stundenauflösung vorliegen.

**Sind ENTSO-E-Daten für Prompt Engineering frei nutzba

[gekürzt]

Aktuelle Beiträge

Kommentare