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](https://stromfee.ai/academy) 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](https://stromfee.ai) haben sich vier Prompt-Muster durchgesetzt.

### 1. Schema-First statt Frage-First

Schlechter Prompt:

> "Analysiere die Residuallast in Deutschland für März 2024."

Besserer Prompt:

> "Hier ist ein DataFrame mit Spalten `timestamp_utc` (ISO 8601), `load_mw` (A65), `wind_onshore_mw` (A75/B19), `solar_mw` (A75/B16) für DE-LU, stündlich, März 2024. Berechne die Residuallast als `load - wind_onshore - wind_offshore - solar` und identifiziere die 10 Stunden mit niedrigster Residuallast. Gib Timestamp, Wert und Wochentag zurück."

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:

> "Alle Zeitstempel sind UTC. CET = UTC+1, CESZ = UTC+2. Sommerzeit 2024: 31.03. 01:00 UTC → 03:00 CEST bis 27.10. 01:00 UTC → 02:00 CET."

### 3. Referenzwerte als Sanity-Check

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

> "Typische deutsche Systemlast: 35–75 GW. Day-Ahead-Preise 2024: -500 bis +500 €/MWh, Median ca. 75 €/MWh. Falls dein Ergebnis ausserhalb dieser Range liegt, markiere es als `CHECK_REQUIRED`."

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](https://stromfee.ai) arbeitet mit 15 vordefinierten Kausalketten nach LEAP-71-Pattern, die das LLM als Kontext bekommt:

> "Kausalkette K7: Hoher Preis ↔ {geringe Residuallast-Reserve, hohe Gaspreise TTF, geringe Nachbar-Exporte, CO2-Preis EUA}. Prüfe für den genannten Zeitraum jede Ursache einzeln."

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](https://transparency.entsoe.eu) 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](https://stromfee.ai) 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

> "User fragt: 'Warum war am 12. Januar 2024 abends so viel Redispatch nötig?' Verfügbare Tabellen: `redispatch_measures` (timestamp, tso, reason_code, mw, direction), `entsoe_dayahead` (timestamp, zone, price_eur_mwh), `entsoe_generation` (timestamp, psr_type, mw). Generiere SQL für einen Stunden-Breakdown 17:00–22:00 CET und interpretiere das Ergebnis mit Kausalkette K3 (Netzengpass Nord-Süd)."

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](https://stromfee.ai/academy) nach, inklusive Simulatoren für BESS-Arbitrage und Redispatch-Szenarien. Für konkrete Integrationen in Stadtwerke- oder Industrie-Umgebungen: [Kontakt](https://stromfee.ai/contact).

## 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]