Quelltext der Seite Driftmanagement und Bias-Korrektur im SolarForecast KI-Prognosesystem

= Driftmanagement und Bias-Korrektur im SolarForecast KI-Prognosesystem =

Diese Seite erläutert, wie SolarForecast die Qualität der neuronalen Verbrauchs- und Ertragsprognosen (AI::FANN) im laufenden Betrieb überwacht und automatisch nachjustiert. Zwei eng verzahnte Mechanismen sind dafür verantwortlich:

* Die '''Bias-Korrektur''' (<code>_aiFannApplyBiasCorrection</code>), die bei '''jeder einzelnen Prognoseabfrage''' (<code>aiFannConInfer</code>) angewendet wird und den rohen Netzwerk-Output in Echtzeit korrigiert.
* Das '''Driftmanagement''' (<code>aiFannDetectDrift</code>), das '''einmal pro volle Stunde''' die Prognosequalität der jüngsten Vergangenheit analysiert, die Korrekturparameter nachführt (Rekalibrierung) und bei Bedarf ein Retraining empfiehlt.

Beide Mechanismen arbeiten zusammen, ersetzen aber nicht das eigentliche Training – sie kompensieren die unvermeidliche Alterung eines einmal trainierten Modells zwischen zwei Trainingsläufen.


== Warum überhaupt Drift- und Bias-Management? ==

Ein neuronales Netz lernt beim Training einen statischen Zusammenhang zwischen Eingangsgrößen (PV-Ertrag, Temperatur, Uhrzeit, Anwesenheit, Lag-Features usw.) und dem Zielwert (Verbrauch). Dieser gelernte Zusammenhang ist jedoch nur eine Momentaufnahme:

* '''Saisonale Verschiebungen''' (Heizverhalten im Winter, Klimatisierung im Sommer)
* '''Verhaltensänderungen''' der Bewohner (neue Geräte, geänderte Homeoffice-Tage, Urlaub)
* '''Strukturelle Änderungen''' am Haushalt (neuer Verbraucher, BEV-Anschaffung, WP-Umbau)
* '''Sensor-/API-Störungen''' (fehlerhafte Wetterdaten, Zählerausfälle)

führen dazu, dass die Vorhersagequalität mit der Zeit sinkt – das reale Verhalten "driftet" vom gelernten Modellzustand weg. In der ML-Literatur unterscheidet man dabei:

* '''Concept Drift''': Der tatsächliche Zusammenhang zwischen Features und Zielgröße ändert sich (z. B. weil ein E-Auto angeschafft wurde und nun nachts geladen wird).
* '''Data Drift / Covariate Shift''': Die Verteilung der Eingangsgrößen ändert sich, der zugrunde liegende Zusammenhang bleibt aber gleich.

Ein vollständiges Neu-Training bei jeder kleinen Abweichung ist weder praktikabel (Rechenzeit, Datenmenge) noch für den Anwender komfortabel. SolarForecast verfolgt daher einen zweistufigen Ansatz:

# '''Kurzfristig''': Eine leichte additive/multiplikative Korrektur pro Prognosestunde (Bias-Korrektur), die auf zuletzt gemessenen Fehlerkennzahlen basiert.
# '''Mittelfristig''': Eine stündliche, statistisch abgesicherte Nachführung der Korrekturreferenzwerte (Drift-Rekalibrierung) sowie eine Retraining-Empfehlung, wenn die Drift strukturell und nicht mehr kompensierbar ist.


== Grundbegriffe ==

=== Bias und Slope ===

Für ein Modell, das reale Werte <math>y</math> aus Vorhersagen <math>\hat{y}</math> möglichst gut trifft, sind zwei Fehlerarten zu unterscheiden:

* '''Bias (additiver Fehler)''': systematischer Versatz, z. B. das Modell sagt im Mittel 430 Wh zu wenig voraus. Berechnet als <code>bias = mean(y - ŷ)</code>.
* '''Slope (multiplikativer Fehler)''': Steigung der linearen Regression <code>ŷ ~ y</code>. Ein Slope < 1 bedeutet, dass das Modell hohe Werte tendenziell unterschätzt und niedrige Werte tendenziell überschätzt (Regression-to-the-mean-Effekt bei stochastischen, schwer vorhersagbaren Haushalten).

Diese beiden Größen werden im Code an mehreren Stellen getrennt geführt:

* '''Statische Werte aus dem Training''': <code>ModelBias</code>, <code>ModelSlope</code>, <code>Mae</code>, <code>RmseRel</code> (einmalig beim Training bestimmt, siehe Trainingsmodul).
* '''Dynamische, laufend nachgeführte Referenzwerte''': <code>DriftRefBias</code>, <code>DriftRefSlope</code> (werden bei Rekalibrierung überschrieben und sind dann maßgeblich – <code>_aiFannApplyBiasCorrection</code> bevorzugt sie explizit, sofern definiert).
* '''Aktuelle Live-Abweichung zur Referenz''': <code>DriftBias</code>, <code>DriftSlope</code> (wie weit ist die aktuelle Stunde von der zuletzt kalibrierten Referenz entfernt).

Der strukturelle Zusammenhang <code>Bias ≈ mean(y) × (1 − Slope)</code> erklärt, warum bei stochastischen Haushalten (schwer vorhersagbares Verbrauchsverhalten) auch ein "gutes" Modell einen strukturellen Bias von mehreren hundert Wh aufweisen kann, ohne dass ein Modellfehler vorliegt.


=== Baseline vs. Peak ===

Ein zentrales Entwurfsprinzip beider Mechanismen ist der '''Peak-Schutz''': Additive und multiplikative Korrekturen werden nur auf die '''Grundlast''' (Baseline) angewendet, niemals auf Verbrauchsspitzen. Grund: Eine Korrektur, die im Mittel passt, würde bei einem punktuellen Peak (z. B. Backofen, Wallbox-Ladevorgang) den Vorhersagefehler eher vergrößern als verkleinern. Die Baseline-Erkennung erfolgt über das 30 %-Quantil des jeweiligen Prognosetyps (<code>CircularVal ($name, '99', $fanntyp.'_quantile30', 0)</code>): Liegt der (bereits driftkorrigierte) Vorhersagewert nicht mehr als 20 % über diesem Quantil, gilt er als Grundlast.



== Ablauf einer Prognose (aiFannConInfer) ==

[[Datei:prognose_datenfluss.png|right|thumb|400px|der Weg jeder einzelnen Prognosestunde (aiFannConInfer)]]
<code>aiFannConInfer</code> wird für jede der <code>MAXNEXTHOURS</code> zukünftigen Stunden aufgerufen und durchläuft je Stunde folgende Kette:

# Feature-Vektor aus <code>NextHours</code>/<code>History</code> aufbauen (Lag-Features, zyklische Kodierung, BEV-/WP-Aggregate usw. – siehe separate Wiki-Seite zur Feature-Registry).
# '''Netzwerk-Inferenz''': <code>_aiFannPredict</code> lässt das FANN-Modell laufen und denormalisiert den Output anhand der beim Training gespeicherten <code>MinVal</code>/<code>MaxVal</code>.
# '''Bias-/Drift-Korrektur''': <code>_aiFannApplyBiasCorrection</code> wandelt den rohen Modell-Output <code>$denorm_val</code> in den korrigierten Wert <code>$prediction</code> um (Details siehe unten).
# '''Horizont-Blending''': Für weiter in der Zukunft liegende Stunden wird die reine Modellprognose zunehmend mit einem historischen Referenzwert gemischt (<code>_aiFannGetHistoricalReference</code>, Mittelwert derselben Stunde der letzten 7 Tage). Der Blend-Anteil <code>blend_alpha</code> steigt mit der Anzahl der Stunden in die Zukunft auf maximal 80 %, weil die Modellprognose mit wachsendem Horizont zunehmend unsicherer wird und ein saisonaler Mittelwert stabiler ist.
# '''Hybridisierung mit der Legacy-Prognose''': <code>confc_final = alpha × prediction + (1 − alpha) × legacyconfc</code>, gesteuert über das Reading <code>aiConAlpha</code>. So kann der Anwender das Vertrauen in das KI-Modell gegenüber der klassischen Prognose stufenlos einstellen.
# Speicherung der Zwischenwerte (<code>conaifc</code>, <code>confc</code>, <code>conbiascorr</code>) in Circular- und History-Speicher zur späteren Auswertung durch das Driftmanagement.






<br>

== Die Bias-Korrektur im Detail (<code>_aiFannApplyBiasCorrection</code>) ==

Diese Funktion wird '''pro Prognosestunde''' aufgerufen und führt in dieser Reihenfolge vier Korrekturschritte aus: Drift-Level-Korrektur → Drift-Bias-Korrektur → statische Trainingskalibrierung → additive Bias-Zonenkorrektur.


=== Schritt 1: Drift-Slope-Korrektur (Level-Skalierung) ===

Der laufend aktualisierte <code>DriftSlope</code> (Verhältnis der aktuellen Live-Regressionssteigung zur Referenzsteigung, siehe unten) wird zunächst auf den Bereich <code>[0.80, 1.10]</code> geklemmt (<code>$ds_min</code>/<code>$ds_max</code>). Anschließend wird eine '''adaptive Gewichtung''' berechnet, damit kleine, verrauschte Abweichungen nicht voll durchschlagen:

<pre>
slope_dev    = |1.0 − DriftSlope|
rmse_dev     = ln(1 + max(0, DriftRmseRelRatio − 1))
mae_scale    = min(1.0, Mae / 200)
drift_weight = min(1.0, 0.4·slope_dev + 0.1·rmse_dev + 0.1·mae_scale)
ds_adapted   = 1.0 + (ds − 1.0) · drift_weight
</pre>

Der so gedämpfte Faktor <code>ds_adapted</code> wird danach nochmals '''zonenabhängig''' skaliert – je nachdem, wie stark und wie zuverlässig der aktuelle Drift ist:

{| class="wikitable"
! Drift-Zone !! Bedingung !! Wirkung auf ds_adapted
|-
| 1 (stabil) || <code>DriftSlope ∈ [0.85, 1.15]</code> und <code>DriftRmseRelRatio < 1.5</code> || nur 10 % der Abweichung wirksam
|-
| 2 (leichte Drift) || <code>DriftSlope ∈ [0.70, 1.30]</code> und <code>DriftRmseRelRatio < 2.5</code> || 40 % der Abweichung wirksam
|-
| 3 (starke Drift) || sonst || 70 % der Abweichung wirksam
|}

Nach der Zonenskalierung erfolgt ein finales Clamping auf <code>[0.70, 1.10]</code>. Ist die Drift-Korrektur aktuell deaktiviert (siehe nächster Absatz), wird <code>ds_adapted = 1.0</code> gesetzt und keine Korrektur angewendet. Der rohe Vorhersagewert wird dann multiplikativ skaliert: <code>res = val_predict × ds_adapted</code>.

'''Deaktivierungsbedingungen''' (<code>$drift_enabled = 0</code>):
* Modellalter <code>ModelAgeHours < AIMODELMINAGE</code> – ein frisches Modell hat noch keine belastbare Live-Fehlerstatistik.
* Nachtstunden <code>hod < 7</code> – nachts ist die Grundlast so niedrig und variabel (Standby-Verbräuche), dass eine Driftkorrektur hier eher schadet als nützt.


=== Schritt 2: Drift-Bias (additiver Versatz) ===

Der aktuell gemessene <code>DriftBias</code> (Differenz zwischen Live-Bias und Referenz-Bias, siehe Driftanalyse) wird auf maximal <code>±1.0 × Mae</code> geklemmt und – '''nur wenn die Vorhersage als Grundlast (<code>is_baseline</code>) erkannt wurde''' – additiv aufaddiert: <code>res += clamped_drift_bias</code>. Ist die Driftkorrektur deaktiviert, wird auch dieser Anteil auf 0 gesetzt.


=== Schritt 3: Statische Trainingskalibrierung (OLS, Peak-geschützt) ===

Falls beim letzten Training eine strukturelle Kalibrierung ermittelt wurde (<code>CalSlope</code>/<code>CalBias</code> im Modell-Datensatz, per Ordinary-Least-Squares-Regression bestimmt), wird sie – wiederum ausschließlich auf Grundlast-Werte – angewendet:

<pre>
cal_val       = CalSlope · res + CalBias
osl_delta     = cal_val − res
max_osl_delta = 0.15 · Mae            # Korrektur auf max. 15 % des MAE begrenzt
res           = clamp(res + osl_delta, 0, MaxVal)
</pre>

Der Grund für die enge Deckelung: <code>CalSlope</code> korrigiert einen strukturellen Steigungsfehler aus dem Training pauschal für den gesamten Wertebereich. Ohne Deckelung würde diese Korrektur bei Peaks (die per Definition außerhalb der Baseline-Prüfung liegen dürften, aber am Übergang) überkorrigieren. Kommt diese Kalibrierung zur Anwendung, wird die nachfolgende additive Bias-Zonenkorrektur (Schritt 4) '''übersprungen''' (<code>bias_zone = 3</code>, Kennzeichnung <code>+OSL</code> im Reading), um eine Doppelkorrektur zu vermeiden.


=== Schritt 4: Additive Bias-Zonenkorrektur ===

Nur falls Grundlast '''und keine''' OLS-Kalibrierung gegriffen hat, wird der geklemmte statische Bias (<code>clamped_bias</code>, max. 50 % des Mae) je nach Modellgüte anteilig aufaddiert. Die Modellgüte wird über drei Kennzahlen bewertet: <code>ModelSlope</code>, <code>bias_ratio = |bias| / max(Mae, 0.1)</code> und <code>RmseRel</code>.

{| class="wikitable"
! Zone !! Farbe !! Bedingung !! Korrekturanteil
|-
| 1 || grün || <code>Slope ∈ [0.9, 1.1]</code>, <code>bias_ratio ≤ 1.0</code>, <code>RmseRel ≤ 25 %</code> || 70 % des Bias
|-
| 2 || gelb || <code>Slope ∈ [0.7, 0.9)</code>, <code>bias_ratio ≤ 2.0</code>, <code>RmseRel ≤ 40 %</code> || 50 % des Bias
|-
| 2b || (profilabhängig) || <code>Slope ≥ z2_slope_min</code>, <code>bias_ratio ≤ z2_bias_max</code>, <code>RmseRel ≤ z2_rmse_max</code> (Schwellen aus <code>%profileweights{$profile}</code>) || 25 % des Bias
|-
| 3 || rot || keine der obigen Bedingungen erfüllt || keine Korrektur
|}

Die Zone-2b-Schwellen sind bewusst '''pro Profil''' konfigurierbar (<code>%profileweights</code>), da stochastische Haushalte (viele Einzelverbraucher, unregelmäßiges Verhalten) strukturell schlechtere Slope-/RMSE-Werte aufweisen als reguläre Haushalte, ohne dass dies ein Qualitätsmangel des Modells ist (siehe Bias-≈-mean×(1−Slope)-Zusammenhang oben). Ohne die Zone-2b-Ausnahme würden solche Profile dauerhaft in der roten Zone landen und nie eine Korrektur erhalten.

Die Funktion liefert am Ende <code>($res, $corr_val, $bias_zone, $drift_zone)</code> zurück, wobei <code>$corr_val = $res − $val_predict</code> die insgesamt angewendete Korrektur in Wh ist. Diese Werte werden pro Stunde als <code>conbiascorr</code>, <code>conaifc</code> und <code>confc</code> historisiert und stehen damit der nachfolgenden Driftanalyse als Trainings-/Prüfdaten zur Verfügung.



== Die stündliche Driftanalyse (<code>aiFannDetectDrift</code>) ==

Diese Funktion wird '''einmal pro volle Stunde und pro Prognosetyp''' (<code>fanntyp</code>, z. B. <code>con</code>) aufgerufen und '''darf nicht häufiger laufen''', da sie zustandsbehaftete EMA-Glättungen (siehe unten) fortschreibt, die bei Mehrfachaufruf verfälscht würden.

[[Datei:driftanalyse_datenfluss.png|right|thumb|400px|stündliche Driftanalyse und Rekalibrierung]]
=== 1. Adaptive Fenstergröße (<code>_aiFannSelectWindow</code>) ===

Bevor irgendwelche Kennzahlen gelöscht werden, wird die Fenstergröße für die nachfolgende Analyse bestimmt – sie muss '''vor''' dem Löschen ermittelt werden, weil sie selbst auf zuvor gespeicherten Kennzahlen (<code>ModelAgeHours</code>, <code>DriftScore</code>, <code>DriftSemRatio</code>) aufbaut. Grundprinzip: '''Peaks bzw. seltene Ausreißer sollen das Fenster vergrößern (verwässern)''', während '''dauerhafte, breit gestreute Drift das Fenster verkleinern soll''' (schnellere Reaktion auf neue Verhältnisse):

{| class="wikitable"
! Regel !! Bedingung !! Fenstergröße
|-
| Peak, breit gestreut || DriftScore > 2.5 und SemRatio > 0.7 || 120 h
|-
| Seltene extreme Peaks || DriftScore > 2.0 und SemRatio < 0.4 || 120 h
|-
| Dauerhafte Drift || DriftScore > 2.0, SemRatio ≥ 0.4, Alter > 72 h || 48 h
|-
| Schleichende Drift || 1.5 < DriftScore ≤ 2.0, SemRatio < 0.4, Alter > 48 h || 72 h
|-
| Stabiles Modell || DriftScore < 1.2, Alter > 72 h || 144 h
|-
| (keine Regel greift / fehlende Werte) || – || 96 h (Default)
|}


=== 2. Modellalter und Fresh-Model-Reset ===

Der Zeitstempel des letzten Trainingsabschlusses wird aus <code>CircularVal(..., 99, $fanntyp.'NNTrainLastFinishTs')</code> gelesen; die Differenz zum jüngsten verfügbaren Rohdatensatz ergibt <code>ModelAgeHours</code>. Ist das Modell jünger als <code>AIMODELMINAGE</code> Stunden, greift ein '''harter Reset''': Die Drift-Historie wird geleert, <code>DriftBias = 0</code>, <code>DriftSlope = 1</code> gesetzt, und die '''Referenzwerte''' <code>DriftRefBias</code>/<code>DriftRefSlope</code> werden auf den Modellzustand aus dem Training gesetzt (<code>ModelBias</code>/<code>ModelSlope</code>) – '''außer''' es ist bereits eine statische Kalibrierung (<code>CalSlope</code>/<code>CalBias</code>) aktiv; in diesem Fall werden die Referenzen auf <code>0</code>/<code>1</code> gesetzt, um die in Schritt 3 der Bias-Korrektur bereits erfolgende OLS-Korrektur nicht doppelt zu berücksichtigen. Die Funktion kehrt danach sofort mit dem Flag <code>fresh_model</code> zurück – es findet noch keine Drift-Bewertung statt.


=== 3. Leckage-Schutz: nur Daten des aktuellen Modells ===

Aus der Rohhistorie (<code>$data{$name}{aidectree}{airaw}</code>) werden ausschließlich Datensätze berücksichtigt, deren Zeitstempel '''nach''' dem Trainingsabschluss liegen (<code>post_train_idx</code>). Damit wird verhindert, dass die Drift-Bewertung durch Prognosen des '''vorherigen''' Modells verfälscht wird. Sind weniger als <code>AIMODELMINAGE</code> solcher Datensätze vorhanden, bricht die Analyse mit <code>insufficient_data</code> ab. Aus den verbleibenden Datensätzen wird das jüngste Fenster der Größe <code>$window</code> (<code>tail_idx</code>) für die eigentliche Analyse verwendet.


=== 4. Stündliche Fehlerberechnung und Glättung ===

Für jede Stunde im Analysefenster werden realer Wert (<code>$fanntyp</code>, z. B. <code>con</code>) und Prognosewert (<code>${fanntyp}aifc</code>) gelesen, auf Gültigkeit geprüft (definiert, numerisch, ≥ 0) und daraus:

* <code>slope_list</code>: Verhältnis <code>p/a</code> je Stunde (für spätere Varianzberechnung)
* <code>bias_hour = a − p</code>, geklemmt auf <code>±3 × DriftRefMae</code> (Ausreißerschutz), anschließend '''exponentiell geglättet''' (EMA, <code>alpha = 0.3</code>): <code>bias_smooth = 0.3·bias_hour + 0.7·bias_smooth_prev</code>

gebildet. Für die Bias-Varianz wird nur das letzte 24-h-Fenster verwendet (<code>bias_last24</code>), damit einzelne Peaks über ein 96-h-Fenster die Varianzschätzung nicht dominieren.


=== 5. Fehlermetriken (<code>_aiFannErrorMetrics</code>) ===

Auf Basis von <code>@targets</code>/<code>@preds</code> im Analysefenster werden auf Originalskala (Wh) berechnet:

* '''MAE''' (Mean Absolute Error): mittlerer absoluter Fehler
* '''RMSE''' und '''RMSErel''' (RMSE relativ zum '''Median''' der Zielwerte, robuster als Mittelwert-Bezug bei schiefen Verteilungen)
* '''MedAE''' (Median Absolute Error, ausreißerrobust)
* '''MAPE''' / '''MdAPE''' (mittlerer/medianer prozentualer Fehler)
* Bias-Kennzahlen (signed): <code>bias_mean</code>, <code>bias_median</code>, <code>bias_abs_mean</code>, <code>bias_abs_median</code>

Daraus: <code>drift_score = mae_live / DriftRefMae</code> – das zentrale Verhältnis "wie viel schlechter ist die aktuelle Fehlerlage gegenüber dem Referenzzustand".


=== 6. Regression Live (<code>_aiFannSlopeBias</code>, OLS) ===

Mittels gewöhnlicher kleinster Quadrate (Ordinary Least Squares) wird die lineare Regression <code>Prognose ~ Realwert</code> über das Analysefenster berechnet:

<pre>
slope = (n·Σxy − Σx·Σy) / (n·Σx² − (Σx)²)
bias  = (Σy − slope·Σx) / n
</pre>

mit <code>x</code> = Realwerte, <code>y</code> = Prognosewerte. Sonderfälle werden explizit behandelt: zu wenige Datenpunkte (<code>n < 2</code>), unterschiedliche Array-Längen (Truncation) sowie Null-Varianz in den Zielwerten (alle <code>x</code> identisch – dann ist die Steigung nicht bestimmbar, <code>slope = 0</code>, <code>bias = ȳ</code> als Fallback). Der Nenner wird gegen einen '''skalierten Epsilon-Wert''' statt gegen exakt 0 geprüft, um numerische Instabilität bei sehr kleinen, aber nicht exakt verschwindenden Nennern zu vermeiden.

Der resultierende <code>bias_live</code> wird nochmals per EMA mit dem vorherigen Wert geglättet (<code>0.7 × neu + 0.3 × alt</code>), bevor er als <code>DriftBiasLive</code> gespeichert wird – zusätzlich zur stundenweisen EMA aus Schritt 4. Diese doppelte Glättung dient dazu, sowohl kurzfristige (stundenweise) als auch mittelfristige (fensterweise) Sprünge zu dämpfen.


=== 7. Drift-Kennzahlen relativ zur Referenz ===

<pre>
slope_drift     = slope_live / DriftRefSlope
bias_drift      = bias_live  − DriftRefBias
rmse_rel_ratio  = rmse_rel_live / DriftRefRmse
bias_drift_norm = |bias_drift| / DriftRefMae
slope_rel_drift = |slope_drift − 1|
</pre>


=== 8. Semantik- und Peak-Anteil ===

Zusätzlich zu den globalen Fehlermaßen wird geprüft, '''wie verbreitet''' der Fehler im Fenster ist:

* <code>sem_ratio</code>: Anteil der Stunden, bei denen der absolute Fehler die Schwelle <code>0.5 × Mae_model</code> überschreitet. Hoch (>0.7) deutet auf '''flächendeckende, dauerhafte''' Drift hin; niedrig (<0.4) auf '''vereinzelte''' Ausreißer.
* <code>peak_ratio</code>: Anteil der Stunden mit Realwert oberhalb <code>Median + 2×Mae_model</code>.

Diese beiden Kennzahlen fließen sowohl in die Fenstergrößen-Heuristik (siehe oben) als auch in die Sicherheitslogik (siehe unten) ein.


=== 9. Der Drift-Index und die Ampel-Flags ===

Aus den bisherigen Größen wird ein gewichteter Gesamtindex gebildet:

<pre>
slope_penalty = slope_rel_drift < 0.3
              ? min(2.0, slope_rel_drift)                              # linear bei kleiner Abweichung
              : min(2.0, slope_rel_drift + slope_rel_drift²)           # quadratisch bei großer Abweichung

slope_boost   = slope_rel_drift > 0.4 ? 0.25 : 0.0                     # zusätzlicher Booster bei starkem Dynamikverlust

drift_index = 0.40 · min(3.0, drift_score)
            + 0.30 · min(3.0, rmse_rel_ratio)
            + 0.20 · min(2.0, slope_penalty)
            + 0.10 · min(2.0, bias_drift_norm)
            + slope_boost
</pre>

Die Gewichtung spiegelt die praktische Relevanz wider: der reine Fehleranstieg (<code>drift_score</code>) und die RMSE-Relation dominieren mit zusammen 70 %, echte Dynamikverluste (Slope) mit 20 % plus Booster, reine additive Verschiebung (Bias) nur mit 10 %, da Bias durch die separate additive Korrektur ohnehin laufend adressiert wird.

{| class="wikitable"
! Drift-Index !! Flag
|-
| > 3.0 || <code>severe</code>
|-
| > 2.0 || <code>moderate</code>
|-
| > 1.5 || <code>mild</code>
|-
| > 1.1 || <code>low</code>
|-
| > 1.02 || <code>very_low</code>
|-
| ≤ 1.02 || <code>stable</code>
|}


=== 10. Rekalibrierung ===

Das Flag der jeweiligen Stunde wird in <code>DriftZoneHistory</code> protokolliert (auf die letzten 20 Einträge begrenzt). Ein Zähler <code>DriftZone3Hours</code> erfasst, '''wie viele Stunden in Folge''' der Drift-Index über der "mild"-Schwelle (1.5) lag; er wird zurückgesetzt, sobald der Index wieder darunter fällt.

Bevor eine Rekalibrierung stattfinden darf, prüft <code>_aiFannDriftSafetyBlocked</code> eine Reihe von Plausibilitätsbedingungen (siehe nächster Abschnitt). Ist keine geblockt, und hat <code>DriftZone3Hours</code> die Schwelle erreicht (4 Stunden bei <code>severe</code>, sonst <code>DRIFTHZN3TH</code> = 8 Stunden), wird rekalibriert:

<pre>
bias_drift_effective = clamp(0.5·bias_drift + 0.5·(mae_live − DriftRefMae), ±2·DriftRefMae)
new_bias              = DriftRefBias + 0.4 · bias_drift_effective        # sanfte 40%-Anpassung

slope_error            = slope_live − DriftRefSlope
slope_drift_effective  = 0.6·slope_error + 0.4·(rmse_rel_ratio − 1.0)·0.1
new_slope               = clamp(DriftRefSlope + slope_drift_effective, 0.85, 1.15)
</pre>

<code>DriftRefBias</code> und <code>DriftRefSlope</code> werden mit den neuen Werten überschrieben, <code>DriftBias</code>/<code>DriftSlope</code> relativ dazu neu berechnet (sollten danach nahe 0 bzw. 1 liegen), <code>DriftZone3Hours</code> auf 0 zurückgesetzt und <code>DriftRefMae</code>/<code>DriftRefRmse</code> auf die aktuellen Live-Werte gesetzt – das neue Referenzniveau für die nächste Analyseperiode. Das Flag wird auf <code>recalibrated</code> gesetzt.

Wichtig: Die Rekalibrierung passiert '''bewusst nur in kleinen Schritten''' (40 % bzw. 60/40-Mischung), nicht als vollständiger Sprung auf die Live-Werte, um Überreaktionen auf kurzfristiges Rauschen zu vermeiden.


=== 11. Retrain-Empfehlung (<code>_aiFannRetrainRecommended</code>) ===

Wurde in diesem Durchlauf rekalibriert, wird die Empfehlung auf <code>none</code> (Grund <code>just_recalibrated</code>) gesetzt, da die Rekalibrierung das Problem bereits adressiert hat. Andernfalls wird anhand von vier unabhängigen Signalen aus den letzten 12 protokollierten Flags (<code>DriftZoneHistory</code>) ein Score gebildet:

{| class="wikitable"
! Signal !! Bedingung
|-
| <code>structural_block</code> || Blockgrund ist <code>slope_critical</code>, <code>negative_slope_drift</code> oder <code>model_bad_but_stable</code> '''und''' DriftIndex > 1.8
|-
| <code>persistent_drift</code> || DriftIndex > 2.0 '''und''' mindestens 8 der letzten 12 Flags <code>moderate</code>/<code>severe</code>
|-
| <code>severe_drift</code> || DriftIndex > 2.5 '''und''' DriftScore > 2.5
|-
| <code>context_block</code> || Blockgrund ist <code>slope_implausible</code>/<code>rmse_anomaly</code>/<code>unstable_slope</code>/<code>unstable_bias</code> '''und''' persistent (≥10 von 12) '''und''' DriftIndex > 2.0
|}

Bewusst '''nicht''' gewertet werden reine Datenfehler-Blocks wie <code>bias_implausible</code> oder <code>low_load_phase</code> – diese deuten auf Sensor-/Datenprobleme statt auf Modellprobleme hin und sollen kein Retraining auslösen. Score ≥ 2 → <code>urgent</code>, Score = 1 → <code>advised</code>, sonst <code>none</code>.



== Sicherheitslogik gegen Fehlrekalibrierung (<code>_aiFannDriftSafetyBlocked</code>) ==

Da eine fehlerhafte Rekalibrierung das Modell dauerhaft "verbiegen" würde, prüft diese Funktion vor jeder Rekalibrierung eine Kette von Plausibilitätskriterien und liefert bei Verdacht einen sprechenden Blockgrund statt <code>0</code>:

{| class="wikitable"
! Blockgrund !! Erkennt …
|-
| <code>no_data</code> || zu wenige Datenpunkte im Fenster (≤ 6)
|-
| <code>negative_slope_drift</code> || invertierte Dynamik (Slope-Drift oder Live-Slope negativ) – klares Datenproblem
|-
| <code>slope_critical</code> || nahezu konstante Prognose (<code>|slope_live| < 0.25</code>) bei gleichzeitig weit verbreitetem Fehler (<code>sem_ratio > 0.75</code>)
|-
| <code>low_load_phase</code> || dynamischer Nacht-Detektor: mindestens 5 der letzten 6 Stunden liegen nahe am 30 %-Quantil, kaum Peaks, kaum Semantik-Fehler → typische Grundlast-/Nachtphase, keine Rekalibrierung nötig
|-
| <code>slope_implausible</code> || extreme Slope-Werte kombiniert mit hoher Varianz oder breitem Fehleranteil, aber wenig Peaks → deutet auf API-/Sensorfehler statt echter Drift
|-
| <code>rmse_anomaly</code> || RMSE-Verhältnis überschreitet eine '''dynamische''' Grenze, die sich aus Peak-Anteil, Semantik-Anteil und Slope-Varianz ableitet (Grundlast → niedrigere Grenze, viele Peaks/Varianz → höhere Toleranz)
|-
| <code>bias_implausible</code> || Live-Bias überschreitet eine aus Quantil30/Quantil90/Medianlast abgeleitete Plausibilitätsgrenze bei gleichzeitig wenig Peaks → typisches Zeichen für Sensor-/API-Ausfälle
|-
| <code>model_bad_but_stable</code> || Modell ist zwar schlecht, aber nicht driftend (moderate, aber nicht wachsende Abweichungen) → Rekalibrierung würde nichts verbessern, eher Retraining nötig
|-
| <code>unstable_slope</code> || Slope-Varianz über dem dynamischen, lastabhängigen Grenzwert → zu instabil für eine belastbare Rekalibrierung
|-
| <code>unstable_bias</code> || hohes RMSE-Verhältnis '''und''' hohe normierte Bias-Varianz gleichzeitig
|}

Erst wenn '''keine''' dieser Bedingungen zutrifft, wird die Rekalibrierung freigegeben.


== Zusammenspiel: Beispielablauf ==

# '''Jede Prognosestunde''' (<code>aiFannConInfer</code>): Rohprognose → <code>_aiFannApplyBiasCorrection</code> wendet die zuletzt bekannten Referenzwerte (<code>DriftRefBias</code>/<code>DriftRefSlope</code> bzw. Trainingswerte, falls noch keine Rekalibrierung stattfand) an → korrigierter Wert wird gespeichert und historisiert.
# '''Einmal pro volle Stunde''' (<code>aiFannDetectDrift</code>): Die zuletzt historisierten Prognose-/Realwertpaare werden ausgewertet, ein Drift-Index gebildet, ein Ampel-Flag gesetzt.
# '''Bei anhaltender, plausibler Drift''' über mehrere Stunden (Zone3Hours-Schwelle erreicht, keine Sicherheitsblockade): <code>DriftRefBias</code>/<code>DriftRefSlope</code> werden sanft nachgeführt – ab der nächsten Prognosestunde wirkt die neue Referenz in <code>_aiFannApplyBiasCorrection</code>.
# '''Bei struktureller, nicht kompensierbarer Drift''' (persistente moderate/severe-Flags über 12 Stunden, oder strukturelle Blockgründe): Die Retrain-Empfehlung wird auf <code>advised</code> bzw. <code>urgent</code> gesetzt – dies ist ein Hinweis an den Anwender, ein neues Training anzustoßen, da die laufende Korrektur an ihre Grenzen stößt.

Damit ergibt sich eine Kaskade dreier Zeitskalen: '''Prognose''' (jede Stunde neu berechnet, sofort korrigiert) → '''Drift-Rekalibrierung''' (Stunden bis Tage, sanfte Nachführung) → '''Retraining''' (Wochen bis Monate, vollständige Neuanpassung).


== Wichtigste Kennziffern im Überblick ==

{| class="wikitable"
! Reading !! Bedeutung
|-
| <code>ModelBias</code> / <code>ModelSlope</code> || statische Werte aus dem letzten Training
|-
| <code>DriftRefBias</code> / <code>DriftRefSlope</code> || aktuell gültige, ggf. rekalibrierte Referenzwerte (haben Vorrang vor den Modellwerten)
|-
| <code>DriftBias</code> / <code>DriftSlope</code> || aktuelle Abweichung der Live-Fehlerlage von der Referenz
|-
| <code>DriftBiasLive</code> / <code>DriftSlopeLive</code> || geglättete Live-Regressionskennzahlen des Analysefensters
|-
| <code>DriftScore</code> || Verhältnis Live-MAE zu Referenz-MAE
|-
| <code>DriftIndex</code> || gewichteter Gesamt-Driftindikator (Basis der Ampel-Flags)
|-
| <code>DriftRmseRelRatio</code> || Verhältnis Live-RMSErel zu Referenz-RMSErel
|-
| <code>DriftSemRatio</code> || Anteil der Stunden mit signifikantem Fehler (Verbreitungsgrad der Drift)
|-
| <code>DriftFlag</code> || aktuelle Ampel/Status (<code>stable</code> … <code>severe</code>, <code>recalibrated</code>, <code>fresh_model</code>, oder <code>recalibration blocked: …</code>)
|-
| <code>DriftZoneHistory</code> || Protokoll der letzten 20 Flags
|-
| <code>DriftZone3Hours</code> || Anzahl aufeinanderfolgender Stunden über der "mild"-Schwelle
|-
| <code>DriftLastRecalTime</code> || Zeitpunkt der letzten Rekalibrierung
|-
| <code>ModelAgeHours</code> || Alter des aktuellen Modells seit Trainingsabschluss
|-
| <code>RetrainRecommendation</code> / <code>DriftRetrainReason</code> || Empfehlung <code>none</code>/<code>advised</code>/<code>urgent</code> mit Begründung
|-
| <code>conbiascorr</code> || pro Stunde tatsächlich angewendete Bias-/Drift-Korrektur in Wh (<code>corr_val</code> aus <code>_aiFannApplyBiasCorrection</code>)
|}


== Praxishinweise für Anwender ==

* '''<code>DriftFlag = stable/very_low/low</code>''': Kein Handlungsbedarf, das System korrigiert im Rahmen der normalen Bias-Korrektur.
* '''<code>DriftFlag = mild/moderate</code>''' über längere Zeit: Das System rekalibriert automatisch, sobald die Sicherheitsprüfung dies zulässt – meist kein Eingreifen nötig, kann aber beobachtet werden.
* '''<code>DriftFlag = recalibration blocked: …</code>''' über viele Stunden: Der Blockgrund gibt einen konkreten Hinweis (z. B. <code>low_load_phase</code> ist unkritisch, <code>slope_implausible</code>/<code>bias_implausible</code> deuten dagegen auf Sensor- oder API-Probleme hin, die geprüft werden sollten).
* '''<code>RetrainRecommendation = advised</code>''' oder '''<code>urgent</code>''': Ein neues Training des betreffenden Modells (<code>fanntyp</code>) sollte zeitnah angestoßen werden, da die laufende Korrektur die strukturelle Abweichung nicht mehr ausgleichen kann.
* '''<code>DriftFlag = fresh_model</code>''': Normal direkt nach einem Training – die Driftanalyse startet erst nach <code>AIMODELMINAGE</code> Stunden mit belastbaren Werten.

[[Kategorie:SolarForecast]]
[[Kategorie:AI::FANN]]