Eine KI-Prognose wird heute mit alten Daten getestet und liefert überzeugende Ergebnisse. Trotzdem bleibt eine entscheidende Frage offen: Hätte das System diese Informationen auch damals schon kennen können? Ein Liefertermin wurde vielleicht erst später korrigiert, ein Tagesumsatz erst am nächsten Morgen bestätigt. In der heutigen Datei sehen solche Werte vollständig aus. Zum damaligen Entscheidungszeitpunkt waren sie es nicht.
Zeitreihenvalidierung bei KI prüft Prognosen entlang der zeitlichen Reihenfolge. Für Fachkräfte in Planung, Controlling oder Prozessarbeit ist das mehr als eine technische Einstellung. Es geht um einen fairen Vergleich zwischen dem damaligen Wissensstand und einem später beobachteten Ergebnis. Die folgende eigenständige Lernübung zeigt das anhand einer fiktiven Lagerplanung, ohne Programmierkenntnisse vorauszusetzen.
Die Prüffrage: Was war am Montagmorgen bekannt?
Ein erfundener Betrieb möchte jeden Montag um 8 Uhr den Bedarf an Verpackungsmaterial für die kommende Woche prognostizieren. Verwendet werden abgeschlossene Wochenverbräuche und bereits bekannte Aufträge. Ein Planungsbericht soll zeigen, ob die Prognose für diese Aufgabe brauchbar ist. Wir bewerten hier weder ein reales Unternehmen noch eine tatsächlich gemessene Modellleistung.
Für die Übung reicht „Bedarf der nächsten Woche“ als Beschreibung nicht. Das Team legt fest: Die Prognose umfasst die sieben Tage ab diesem Montag; sie wird vor Beginn der ersten Schicht erstellt. Ergebnisse späterer Wochen dürfen nicht in das Lernen für diesen damaligen Zeitpunkt einfließen. Auch der Datenstand wird festgehalten, nicht nur das Datum der Tabellenzeile.
Das ist der wesentliche Perspektivwechsel: Ein Rücktest soll die frühere Entscheidung nachstellen. Er darf nicht stillschweigend das Wissen verwenden, das erst nach dieser Entscheidung entstanden ist.
Warum ein Zufallssplit die falsche Zeitrichtung erzeugen kann
Bei einer zufälligen Aufteilung können ältere und jüngere Wochen in beiden Beständen landen. Das Modell lernt dann möglicherweise aus späteren Wochen und wird an einer früheren Woche bewertet. Diese Anordnung bildet unseren angenommenen Montagmorgen-Einsatz nicht ab.
Die offizielle scikit-learn-Dokumentation zu TimeSeriesSplit beschreibt eine zeitlich geordnete Kreuzvalidierung: Frühere Abschnitte dienen zum Lernen, der jeweils folgende Abschnitt zur Prüfung. In der üblichen wachsenden Variante kommen bei späteren Durchläufen zusätzliche vergangene Daten hinzu. Für vergleichbare Zeitdauern der Prüfabschnitte nennt die Dokumentation gleichmäßig verteilte Beobachtungszeitpunkte als Voraussetzung.
Damit ist nicht jeder Zufallssplit grundsätzlich falsch. Entscheidend ist die Einsatzfrage. Wer künftige Wochen prognostizieren will, benötigt jedoch eine begründete zeitliche Prüfung. Gute Kennzahlen aus einer unpassenden Aufteilung beantworten diese Frage nicht automatisch.
Eine eigene Abfolge statt eines einzigen Tests
Für unser Mini-Beispiel nehmen wir zwölf vollständig erfundene, aufeinanderfolgende Wochen an. Die Wochen sind eindeutig abgegrenzt. Ihre Nummern sind keine echten Kalenderwochen und keine Vorgabe für eine ausreichende Datensatzgröße. Der Zweck ist, die Richtung der Prüfung sichtbar zu machen:
- Erster Durchlauf: Aus den Wochen 1 bis 6 lernen; Prognosen für die Wochen 7 und 8 prüfen.
- Zweiter Durchlauf: Aus den Wochen 1 bis 8 lernen; Prognosen für die Wochen 9 und 10 prüfen.
- Dritter Durchlauf: Aus den Wochen 1 bis 10 lernen; Prognosen für die Wochen 11 und 12 prüfen.
Innerhalb jedes Durchlaufs bleibt die Zukunft außerhalb des Lernbestands. Dass Woche 7 im zweiten Durchlauf inzwischen Vergangenheit ist, ist kein Widerspruch. Der simulierte Entscheidungszeitpunkt hat sich weiterbewegt. Diese Übungsabfolge nimmt an, dass die Ergebnisse der bisherigen Wochen rechtzeitig vollständig verfügbar sind; genau das muss in einem realen Projekt gesondert geprüft werden.
Auch der Prognosehorizont muss passen. Würde unser Team am Montag beide nächsten Wochen auf einmal vorhersagen, dürfte es für die zweite Woche nicht bereits den tatsächlichen Verbrauch der ersten Woche verwenden. Wenn es dagegen jeden Montag neu prognostiziert, kann der inzwischen verfügbare Wochenabschluss eine zulässige Eingabe sein. Derselbe Wert kann also je nach Einsatzablauf verfügbar oder unzulässig sein.
Drei Zeitangaben für jede wichtige Eingabe
Im fiktiven Lagerfall unterscheiden wir drei Angaben: Auf welche Woche bezieht sich die Information? Wann wurde sie erstmals erfasst? Wann stand ihre endgültige Fassung dem Planungssystem zur Verfügung? Die dritte Frage wird leicht übersehen, wenn heute nur die letzte Version einer Tabelle vorliegt.
Der Wochenverbrauch ist noch nicht abgeschlossen
Angenommen, der Verbrauch der Vorwoche wird erst am Montag um 10 Uhr freigegeben. Unsere Prognose startet um 8 Uhr. Der freigegebene Endwert gehört deshalb nicht in die damalige Eingabe. Das Team müsste klären, ob es einen damals gespeicherten vorläufigen Wert verwenden kann oder auf eine ältere abgeschlossene Woche zurückgreifen muss.
Eine Auftragsänderung kommt erst später
Ein Auftrag für die kommende Woche war am Montagmorgen kleiner und wurde am Dienstag erweitert. Enthält die heutige Datei nur die erweiterte Menge, entsteht beim Rücktest ein Wissensvorsprung. Zur Prüfung benötigen wir den dokumentierten Auftragsstand von Montagmorgen. Fehlt dieser, muss der Bericht die Einschränkung offenlegen.
Ein Durchschnitt blickt versehentlich nach vorn
Ein selbst gebautes Merkmal könnte den Verbrauch einer Woche mit der vorherigen und der folgenden Woche mitteln. Für eine Darstellung vergangener Verläufe kann das sinnvoll sein. Für unsere Prognose wäre die folgende Woche unbekannt. Die zeitliche Sortierung allein macht diese Eingabe nicht zulässig; ihre Berechnung muss ebenfalls zum Entscheidungszeitpunkt passen.
Eine Zeitgrenze reicht nicht für den ganzen Arbeitsablauf
Die offizielle Dokumentation zu Datenlecks und Vorverarbeitung erläutert, dass beim Modellaufbau keine Informationen genutzt werden sollen, die zur Prognosezeit fehlen. Gelernte Vorverarbeitung, etwa Mittelwerte zur Ersetzung fehlender Werte, wird nur anhand der Trainingsdaten angepasst. Die so bestimmten Regeln werden anschließend auf die Prüfdaten angewendet. Eine passend aufgebaute Pipeline unterstützt diese Trennung.
Für unser Lagerteam folgt daraus ein zusätzlicher Prüfauftrag: Nicht nur die Wochenlisten, sondern auch Datenbeschaffung, Versionsstand und Vorbereitung dokumentieren. Eine Pipeline kann keine nachträglich korrigierte Auftragsdatei in ihren historischen Zustand zurückversetzen. Dafür braucht es geeignete Datenstände oder eine ausdrücklich begrenzte Auswertung.
Bei zeitverzögerten Zielwerten kann außerdem ein Abstand zwischen Lern- und Prüfabschnitt nötig sein. TimeSeriesSplit bietet dafür den Parameter „gap“, der Beobachtungen am Ende des Lernbestands auslässt. Welche Lücke sinnvoll ist, ergibt sich nicht aus einer pauschalen Tageszahl, sondern aus Datenverfügbarkeit und Prognoseaufgabe.
Wie das Team den Rücktest berichten sollte
Ein brauchbarer Bericht nennt für jeden Durchlauf den simulierten Prognosezeitpunkt, den Lernzeitraum, den Prüfhorizont und die verwendeten Datenversionen. Ergebnisse unterschiedlicher Abschnitte sollten zunächst getrennt erkennbar bleiben. Ein unauffälliger Durchschnitt kann verdecken, dass die Planung in einer besonderen Phase deutlich schlechter funktionierte.
Im Beispiel würde das Team deshalb zusätzlich notieren, ob eine Betriebsunterbrechung oder eine geänderte Verpackungsregel den Vergleich beeinflusst. Das erklärt noch keine Ursache, macht aber den nächsten Untersuchungsschritt konkret. Zwölf erfundene Wochen belegen weder Saisontauglichkeit noch eine sichere Leistung in künftigen Monaten. Eine Einsatzentscheidung braucht einen angemessenen Datenumfang und fachliche Anforderungen.
FAQ zur Zeitreihenvalidierung bei KI
Genügt es, die Datei nach Datum zu sortieren?
Nein. Prüfen Sie zusätzlich, welche Version jeder Eingabe damals verfügbar war und ob die Merkmalsberechnung spätere Informationen verwendet.
Muss der Lernbestand immer wachsen?
Nein. Die gezeigte Abfolge ist eine Variante. Ein begrenztes historisches Fenster kann eine andere begründete Modellierungsentscheidung sein. Es sollte den späteren Aktualisierungsablauf nachvollziehbar abbilden.
Garantiert eine zeitliche Prüfung eine verlässliche Prognose?
Nein. Sie verbessert die Passung unseres Tests zur Einsatzfrage, ersetzt aber weder ausreichende Daten noch fachliche Bewertung und laufende Kontrolle.
Fazit: Den damaligen Wissensstand mitprüfen
Zeitreihenvalidierung bei KI beginnt mit dem Zeitpunkt der Entscheidung. Unser Lagerbeispiel zeigt: Eine ältere Tabellenzeile ist nicht automatisch eine damals verfügbare Information. Lassen Sie deshalb die Abfolge und die Datenstände erklären, bevor Sie einen Rücktest als Entscheidungsgrundlage verwenden.
Sie möchten KI-Ergebnisse im Berufsalltag fundierter beurteilen? Das öffentlich angebotene Programm KI-Grundlagenkompetenzen für die digitale Arbeitswelt nennt Datenlogik und fachliche Ergebnisbewertung. Der Artikel ist eine redaktionelle Ergänzung, keine Zusage zu einem speziellen Zeitreihenmodul. Besprechen Sie Ihre Lernziele über den Kontakt zu GrandEdu Media.