Prognosen aus Geschäftsdaten: Warum der damalige Wissensstand wichtiger ist als das Belegdatum
Ein Prognosemodell erzielt im Test hervorragende Ergebnisse, versagt aber im späteren Einsatz. Ein möglicher Grund ist Datenleckage: Im Test wurden Informationen verwendet, die zum tatsächlichen Vorhersagezeitpunkt noch nicht verfügbar gewesen wären. Bei Geschäftsdaten reicht es deshalb nicht, Datensätze lediglich nach ihrem fachlichen Datum zu sortieren und danach in Training und Prüfung aufzuteilen.
Ereignisdatum und Bekanntwerden trennen
Ein Auftrag kann ein früheres Leistungsdatum tragen, aber erst Tage später erfasst oder nachträglich korrigiert werden. Wird ein heutiger Datenexport für eine historische Prognose verwendet, enthält er möglicherweise Wissen aus dieser späteren Bearbeitung. Für einen realistischen Test muss rekonstruiert werden, welche Merkmale zum damaligen Stichtag tatsächlich vorlagen. Das betrifft besonders spätere Stornierungen, Endstatus, korrigierte Mengen und bestätigte Liefertermine. Das fachliche Bezugsdatum allein beschreibt diesen damaligen Informationsstand nicht zuverlässig.
Auch Vorverarbeitung kann verraten
Nicht nur offensichtliche Ergebnisfelder können zukünftiges Wissen enthalten. Wird beispielsweise eine Skalierung oder Merkmalsauswahl mit dem gesamten Datenbestand bestimmt, beeinflussen spätere Prüfdaten bereits die Modellbildung. Die Trennung muss deshalb vor solchen Lernschritten erfolgen. Anschließend werden die im Training bestimmten Regeln unverändert auf die Prüfdaten angewendet. Diese Reihenfolge gehört zum Versuchsaufbau und sollte bei wiederholten Modellläufen nachvollziehbar bleiben, statt von einer zufälligen Reihenfolge manuell ausgeführter Skripte abzuhängen.
Zeitlich passend prüfen
Eine zufällige Mischung alter und neuer Datensätze kann bei zeitlich abhängigen Vorgängen ein zu günstiges Bild erzeugen. Ein geeigneter Test nutzt frühere Informationen zur Vorhersage späterer Perioden. Mehrere zeitlich verschobene Prüfungen zeigen, ob das Ergebnis nur in einem einzelnen günstigen Zeitraum funktioniert. Dabei sind Vorhersagehorizont und tatsächlicher Aktualisierungsrhythmus zu berücksichtigen. Ein Modell für die nächste Woche darf nicht mit Informationen bewertet werden, die im realen Wochenlauf erst danach eintreffen würden.
Ein überprüfbarer Datenvertrag
Für jedes Merkmal sollten Herkunft, Erfassungszeit und erlaubter Verwendungszeitpunkt bekannt sein. Eine kleine manuell rekonstruierte Stichprobe hilft, die historische Sicht zu prüfen. Der Testvergleich sollte außerdem eine einfache fachliche Ausgangslösung enthalten. Gute Kennzahlen allein beweisen keine allgemeine Einsatzfähigkeit. Wenn sich Prozesse oder Datenflüsse ändern, kann die bisher gültige Annahme zur Verfügbarkeit eines Merkmals wegfallen. Deshalb gehört die Prüfung der Datenentstehung dauerhaft zur Prognoseentwicklung und nicht nur einmalig zur technischen Einführung.
Forecasts from business data: Why the historical information state matters more than document dates
A forecasting model performs exceptionally well in testing but fails during later operation. One possible cause is data leakage: the test used information that would not have been available at the actual prediction time. For business data, merely sorting records by a business date before dividing them into training and test sets is therefore insufficient.
Separate event dates from information availability
An order may carry an earlier service date but be entered or corrected several days later. A current export used for a historical forecast can contain knowledge from that later processing. A realistic test must reconstruct which features were actually available at the historical cut-off. Later cancellations, final statuses, corrected quantities and confirmed delivery dates are particularly relevant. The business reference date alone does not reliably describe what the organisation or application knew when the original prediction would have been made.
Preprocessing can leak information too
Obvious outcome fields are not the only source of future knowledge. If scaling or feature selection is fitted using the entire dataset, later test observations already influence model development. The separation must therefore happen before those learning steps. Rules learned from training data are then applied unchanged to the test set. That sequence is part of the experimental design and should remain traceable across repeated model runs, rather than depend on the accidental order in which someone executes individual processing scripts.
Evaluate in a suitable time order
Randomly mixing older and newer observations can give an overly favourable picture when transactions are temporally dependent. A suitable test uses earlier information to predict later periods. Several rolling evaluations help establish whether a result depends on one unusually favourable window. Forecast horizon and the real update cycle matter as well. A model intended to predict the next week must not be assessed using information that would only arrive after that prediction during the actual weekly business process.
Make the data contract testable
Each feature should have a known origin, recording time and permitted availability time. A small sample reconstructed manually helps verify the historical view. Evaluation should also compare the model with a simple business baseline. Strong metrics do not prove universal operational suitability. When processes or data flows change, assumptions about feature availability can cease to hold. Reviewing how data comes into existence is therefore a continuing part of forecasting work, rather than a one-off technical check before initial deployment. This keeps a promising test result connected to the conditions under which the prediction will really be used.