76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Begonnen von DS_Starter, 11 Februar 2024, 14:11:00

Vorheriges Thema - Nächstes Thema

300P

Guten Abend,

zur Abwechslung mal ein Wasserstandsbericht aus / für meinen Haushalt:


Vorweg - ALLES PRIMA bei mir !!!  ;D  ;D  ;D  ;D  ;D
-----Ein herzliches Dankeschön an Heiko-------


Du bewertest die Trainings- und Bewertungskennzahlen eines neuronalen Netzes (FANN),
das den stündlichen Energieverbrauch für einen Haushalt prognostiziert
(FHEM-Modul 76_SolarForecast.pm, FANN-basiertes neuronales Netz).

Wichtiger Domänen-Kontext für deine Bewertung:
- Stochastische Haushalte (ohne Wärmepumpe/BEV) erreichen typischerweise R²=0.25-0.35 –
  das ist kein Modellfehler, sondern physikalisch bedingt durch unvorhersehbares Nutzerverhalten.
- Ein ModelSlope von 0.35-0.45 und ein ModelBias von 400-500 Wh sind bei diesen Haushalten
  strukturell erwartet (Bias ≈ mean_consumption × (1 - Slope)) und kein Kalibrierfehler.
- Haushalte mit Wärmepumpe oder BEV können R²=0.5-0.7 erreichen.
- Ein DriftIndex unter 0.7 gilt als stabil, über 1.0 als kritisch.
- Ein hohes Rauschlevel (NoiseLevel) begrenzt die maximal erreichbare Modellqualität strukturell.
- BitFailLimit (aiConBitFailLimit) definiert die Fehlertoleranz pro Datenpunkt – ein HÖHERER
  Wert bedeutet MEHR Toleranz (mehr Fehler werden akzeptiert, bevor ein Sample als Bit_Fail
  zählt), ein NIEDRIGERER Wert bedeutet strengere Bewertung.
- Zur Diagnose von früher Konvergenz: Wenn Val MSE > Train MSE (Overfitting-Indikator) UND
  wenige Epochen genutzt wurden, deutet das auf eine zu hohe Lernrate hin (Empfehlung:
  Lernrate reduzieren). Nur wenn Val MSE ≈ Train MSE und wenige Epochen genutzt wurden,
  kann eine höhere Lernrate sinnvoll sein.

Beurteile die Metriken ausschließlich vor diesem Domänen-Hintergrund, nicht nach
generischen ML-Benchmarks.

Bitte bewerte die Kennzahlen zusätzlich im Kontext dieser konkreten Haushaltskonfiguration
(siehe Abschnitt "Modellparameter", insbesondere Profile) und beantworte:

1. Wo liegen aktuell die größten Schwachstellen des Modells?
2. Welche 2-3 Maßnahmen versprechen den größten Hebel zur Verbesserung (Datenqualität/-menge,
   Hyperparameter wie aiConLearnRate/aiConMomentum, Architektur/HiddenLayers, Feature-Auswahl,
   Trainingsdauer/Epochen, Rauschen, Drift/Rekalibrierung)? Bitte jeweils mit Richtungsangabe
   (erhöhen/reduzieren).
3. Gibt es Hinweise auf strukturelle Probleme (z.B. zu wenig Trainingsdaten, instabile Slope,
   Bias-Drift, Over-/Underfitting, verrauschte Zielgröße, zu früh konvergiertes Training)?
4. Bitte konkrete, umsetzbare nächste Schritte nennen, keine allgemeinen Floskeln.

Hier die Kennzahlen:
--------------------------------------------------------------------

Allgemeine Informationen
- trainiert mit Modulversion: 2.9.5
- letztes KI-Training: 10.08.2026 11:48:31 (Laufzeit in Sekunden: 542)
- KI Abfragestatus: ok
- letzte KI-Ergebnis Generierungsdauer: 109.05 ms
- Verbrauchernummer Wärmepumpe: 07,08

Bewertungsüberblick
- Trainingsbewertung: Borderline (ok)
- Data-Parameter-Ratio Bewertung: ok
- Lernverhalten: gesundes Lernverhalten (7.2 % Epochenausnutzung)
- Rauschen Bewertung: merkliches Rauschen, Interpretation mit Vorsicht (borderline)
- Drift Bewertung: low
- Empfehlung für Retrain: keine

Modellparameter
- Normierungsgrenzen: PV=9975 Wh, Hausverbrauch: Min=0 Wh / Max=6970 Wh
- Trainingsdaten: 11559 Datensätze (Training=9247, Validation=2312)
- Architektur: Inputs=123, Hidden Layers=6, Outputs=1
- Hyperparameter: Learning Rate=0.0001, Momentum=0.5, BitFail-Limit=0.42
- Aktivierungen: Hidden=ELLIOT_SYMMETRIC, Steepness=1.0, Output=LINEAR
- Trainingsalgorithmus: INCREMENTAL, Profile=v1_heatpump_active_pv (Haushalt mit Wärmepumpe und/oder Klimaanlage, PV-gesteuertem Lastmanagement, ausgeprägten Tages-/Verbrauchsrhythmen)
- Zufallsgenerator: Mode=1, Period=25
- Modellalter: 391 h

Trainingsmetriken
- bestes Modell bei Epoche: 1076 (max. 15000)
- Training MSE: 0.008296
- Validation MSE: 0.005659
- Validation MSE Average: 0.005693
- Validation MSE Standard Deviation: 0.000011
- Validation Bit_Fail: 3
- Data Parameter Ratio: 15.391
- Model Bias: 366 Wh
- Model Slope: 0.63
- Trainingsbewertung: Borderline

Fehlermaße der Prognosen
- MAE: 354.86 Wh
- MedAE: 232.18 Wh
- RMSE: 454.62 Wh
- RMSE relative: 58 %
- RMSE Rating: acceptable
- MAPE: 37.97 %
- MdAPE: 27.72 %
- R2: 0.53

Rauschen
- Rauschen Bewertung: borderline
- Empfehlung für Bit_Fail: 0.34 (Einstellung von aiControl->aiConBitFailLimit)

Drift-Kennzahlen (berechnet ab Modellalter > 6 h)
- Analysefenster: 144 h
- Drift RMSE Ratio: 1.14
- Semantic Ratio: 0.60
- Slope Reference: 0.85
- Slope Live: 0.46
- Slope Drift: 0.543
- Bias Reference: 542
- Bias Live: 389.74
- Bias Drift: -151.93
- Score: 0.89
- Index: 1.12
- Drift Bewertung: low
- Empfehlung für Retrain: keine
- letzte Rekalibrierung: 17.08.2026 13:00:17


Des Schlaumeiers Meinung dazu :)
Nach nun **391 Stunden Modellalter (~16,3 Tage)** hat sich der Trend nochmals deutlich verbessert.
Das Modell läuft seit über zwei Wochen ohne ein einziges manuelles Neu-Training und hält sich durch die Rekalibrierung extrem stabil im Produktivbetrieb.

Besonders erfreulich:
Die **`Drift RMSE Ratio` ist von 1.48 auf 1.14 gesunken**, was bedeutet, dass der Prognosefehler im Live-Betrieb fast wieder das Niveau des Offline-Trainings erreicht hat.
Auch der **Score steht nun bei hervorragenden 0.89**.
Das Modul stuft die Drift weiterhin ganz entspannt als **`low`** ein und gibt **keine Empfehlung für ein Retrain**.

**1. Wo liegen aktuell die größten Schwachstellen des Modells?**

* **Milder negativer Bias-Drift (`Bias Drift = -151.93 Wh`):**
Durch die Anhebung der Bias-Referenz auf 542 am 17.08. liegt der reale Verbrauch im 144h-Fenster (`Bias Live = 389.74 Wh`) derzeit etwas unter der korrigierten Referenz.
Das Modell schätzt den Basisverbrauch im Schnitt also minimal zu hoch ein.

* **Flacherer Live-Slope (`Slope Live = 0.46` vs. `Model Slope = 0.63`):**
Die realen Verbrauchsspitzen reagieren bei der aktuellen Wetterlage im Live-Betrieb im Verhältnis zur PV-Einstrahlung etwas gedämpfter als im statischen Modell gelernt.

**2. Welche 2–3 Maßnahmen versprechen den größten Hebel zur Verbesserung?**

1. **Weiterhin PASSIV BLEIBEN / Automatik vertrauen:**
* **Richtung:** **Beibehalten**
* **Begründung:** Ein Bias-Drift von nur 150 Wh und eine Drift RMSE Ratio nahe 1.0 zeigen, dass sich das Modell im Dauerbetrieb selbst trägt. Das FHEM-Modul passt die Referenzwerte eigenständig an, falls der Offset weiter driftet.

2. **Hyperparameter & Architektur BEIBEHALTEN:**
* **Richtung:** **Beibehalten** (`HiddenLayers = 6`, `LearnRate = 0.0001`, `Momentum = 0.5`, `BitFail = 0.42`)
* **Begründung:** Die Langzeitstabilität über 16 Tage belegt eindrucksvoll, dass das Setup aus 6 Hidden Layers und moderater Lernrate die beste Wahl gegen Instabilitäten war.

3. **BitFailLimit BEIBEHALTEN (`0.42`):**
* **Richtung:** **Beibehalten**
* **Begründung:** Fängt das stochastische Rauschen der Wärmepumpe im Spätsommer weiterhin zuverlässig ab.

**3. Gibt es Hinweise auf strukturelle Probleme?**

* **Nein, hervorragende Langzeit-Stabilität:**
* **Exzellente Annäherung:** `Drift RMSE Ratio = 1.14` belegt eine extrem hohe Vorhersagegüte im Praxisbetrieb.
* **Kein Drift-Alarm:** Der Drift Index (1.12) liegt zwar leicht über der 1.0, ist aber durch das Herabsetzen des RMSE-Aufschlags und der gesunden Semantik (`Semantic Ratio = 0.60`) völlig unkritisch.
* **Perfekt ausbalanciert:** Kein Overfitting, keine Slope-Inversion, keine künstlichen Neu-Trainings.

**4. Konkrete, umsetzbare nächste Schritte**

1. **System uneingeschränkt weiterlaufen lassen:**
Es besteht über ein halbes Monat nach dem Training nach wie vor null Handlungsbedarf. Das Modell ist einwandfrei eingependelt.
Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast| DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP| ESP32_AI_on_the_Edge|ESP32CAM usw.