Statistische Prognose ist eine gegenintuitive Wissenschaft. Das wurde bereits in der Vergangenheit gesagt, aber wir werden diesen Punkt noch einmal betonen.

Häufig erhalten wir Anfragen von Personen, die Unterstützung benötigen, weil sie gerade Daten an Lokad übermittelt haben und die erhaltenen Prognosen flach sind. Mit anderen Worten, die prognostizierten Werte sind für alle zukünftigen Schritte konstant. Zum Beispiel konstante Verkaufswerte für die nächsten 6 Monate, wenn wir 6-monatige Verkaufsprognosen für den nächsten Monat erstellen.

Es ist jedoch völlig klar, dass die Geschäftsverkäufe in den nächsten 6 Monaten nicht perfekt flach sein werden. Warum erstellt Lokad also solche bedeutungslosen Ergebnisse?

Nun, wir wissen sicher, dass sich das Geschäft (zumindest ein wenig) in den nächsten sechs Monaten ändern wird. Daran besteht kein Zweifel. Das Problem ist jedoch: Wie können wir eine Prognose erstellen, die so nah wie möglich an diesen zukünftigen Veränderungen liegt? Wenn wir den statistischen Weg einschlagen, benötigen wir ein statistisches Modell für die Prognosen.

Das Problem ist, dass wir ein gutes Prognosemodell benötigen; und die Grundregel der statistischen Prognose besagt, dass je komplexer das Modell ist, desto mehr Daten benötigt werden, damit das Modell zuverlässig ist. Modelle, die für jeden zukünftigen Schritt unterschiedliche Prognosen erstellen, sind definitiv komplexer als solche, die für alle zukünftigen Schritte denselben Wert liefern.

Umgekehrt können wir auch sagen, dass diese komplexeren Modelle auf begrenzten Datensätzen auch weniger zuverlässig sind, was bedeutet, dass sie die insgesamt Prognosegenauigkeit in bestimmten Situationen wahrscheinlich verringern.

Zurück zur Situation, in der sich Personen über flache Prognosen beschweren, tritt in der Regel einfach das Phänomen auf, dass die gerade hochgeladenen Daten entweder sehr kurz sind (z. B. nur 3 Monate monatlicher Verlauf) oder sehr dünn (z. B. ein E-Commerce mit nur wenigen Verkäufen für jedes Produkt). In solchen Situationen erstellt Lokad häufig flache Prognosen.

Es handelt sich nicht um einen Fehler, sondern um eine Genauigkeitsverbesserungsfunktion.


Leserkommentare (6)

Hallo Johan, die effiziente Darstellung von Zeitreihen in relationalen Datenbanken ist eine ziemlich knifflige Angelegenheit. Kurz gesagt, es hängt sehr von der Länge der betrachteten Zeitreihen ab. Ich bezweifle, dass es in diesem Bereich eine Art “Branchenstandard” gibt. Auch für den Quellcode selbst hängt alles sehr von der Länge und Anzahl der betrachteten Zeitreihen ab. Ich hoffe, das hilft. Vor 7 Jahren | Joannes Vermorel


Wir arbeiten an einem Zeitreihenprojekt mit einer typischen Definition und Beobachtungen von Zeitreihen. Können Sie uns bei folgendem unterstützen:

  1. Haben Sie eine branchenübliche Struktur für die Definition von Zeitreihen und zugehörige Beobachtungen aus Sicht des Datenbankdesigns?
  2. Was ist bewährte Praxis in Bezug auf den Code, der eine Zeitreihe repräsentiert, z. B. [Ebene 1].[Ebene 2].[Sequenznummer].[Version]? Jeder Rat und jede Unterstützung wird geschätzt. Vor 7 Jahren | Johan Strydom

Hallo Izi, das ist ein interessanter Gedanke :-) Ich habe von Anfang an über diese Art von “Angriff” nachgedacht, obwohl er auf unserer Website nicht weit verbreitet ist. Im Grunde genommen müssten Sie die Daten, die Ihr Ziel an Lokad sendet, sehr genau kennen. Außerdem müssten Sie sehr genau wissen, welche Art von Korrelationen wir betrachten. Einfache Verschiebungen von Zeitreihen sind in realen Geschäftsdaten nicht “natürlich”. Schließlich würde es Sie etwas Geld kosten, da wir Daten von nicht zahlenden Benutzern nicht vertrauen. Was unsere Techniken betrifft, verwenden wir eine komplexe Mischung aus vielen Modellen, zu denen auch bekannte Klassiker gehören. Dieses Thema ist natürlich etwas heikel für uns, aber ich werde versuchen, später eine nicht allzu detaillierte Übersicht zu veröffentlichen. Es muss jedoch beachtet werden, dass es sich noch in einer schnellen Entwicklung befindet. Vor 9 Jahren | Joannes Vermorel


Wenn ich falsche Daten hochlade, die sorgfältig darauf abgestimmt sind, mit einem Lieferanten/Partner zu korrelieren, der Ihr Produkt verwendet, kann ich seine Ergebnisse durcheinander bringen? Das ist interessant und scheint ziemlich einfach zu sein! Andernfalls wäre es schön, mehr über die von Ihnen verwendeten Techniken zu erfahren (z. B. ARIMA, ANN usw.). Vor 9 Jahren | Izi


Hallo Stephen, Guter Punkt. Das eigentliche Problem hier ist, dass der Benutzer möglicherweise nicht nur die Vorhersagen selbst, sondern auch die dahinter liegende Logik oder zumindest einen Kommentar wünscht. In Zukunft werden wir wahrscheinlich versuchen, die Client-Apps von Lokad mit automatisierten Richtlinien zu verbessern, die die von Lokad gelieferten Vorhersagen “kommentieren” werden. Vor 9 Jahren | Joannes Vermorel


Hallo Joannes, denken Sie, dass dies nützliches Benutzerfeedback ist, um zu beschreiben, was der Benutzer erwartet? Möglicherweise könnten Sie den Benutzer darauf beschränken, nur eine Prognoseaufgabe für ein paar Monate, sagen wir 3, durchzuführen, und wenn mehr als das, würden sie vor den Auswirkungen auf die Prognosegenauigkeit gewarnt werden. Ich denke, es könnte auch von der Verfügbarkeit der historischen Daten abhängen, sodass es möglicherweise eine Möglichkeit gibt, die beiden in Beziehung zu setzen, bin mir aber nicht sicher. Auch denke ich, dass aus Sicht der Benutzer, auch wenn es korrekter wäre, ihnen eine flache Prognose zurückzugeben, sie möglicherweise auf irgendeine Weise über diesen Fall informiert und/oder die Möglichkeit haben könnten, sie zu akzeptieren oder ein naiveres Ergebnis zu akzeptieren? Vor 9 Jahren | Stephen