Flache Prognosen

Joannes Vermorel

Statistical forecasting ist eine kontraintuitive Wissenschaft. Dies wurde bereits in der Vergangenheit gesagt, aber wir werden diesen Punkt nochmals betonen.

Häufig fragen uns Leute um Unterstützung, weil sie soeben einige Daten zu Lokad hochgeladen haben und die von ihnen erhaltenen Prognosen flach sind. Anders ausgedrückt: Die prognostizierten Werte sind für alle zukünftigen Zeiträume konstant. Z. B.: konstante Verkaufszahlen für die nächsten 6 Monate, wenn sechsmonatige monatliche Verkaufsprognosen betrachtet werden.

Es ist jedoch vollkommen klar, dass es keine Chance gibt, dass die Geschäftsverkäufe in den nächsten 6 Monaten vollkommen flach verlaufen, also warum liefert Lokad weiterhin solch bedeutungslose Ergebnisse?

Nun, wir wissen ganz sicher, dass sich das Geschäft in den nächsten sechs Monaten (zumindest ein wenig) verändern wird. Daran besteht kein Zweifel. Doch das Problem bleibt: Wie können wir eine Prognose erstellen, die diesen zukünftigen Veränderungen so nahe kommt? 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 lautet: Je komplexer das Modell ist, desto mehr Daten werden benötigt, damit es zuverlässig ist. Modelle, die für jeden Zeitschritt unterschiedliche Prognosen liefern, sind definitiv komplexer als solche, die für alle Schritte denselben Wert prognostizieren.

Andererseits können wir auch sagen, dass diese komplexeren Modelle auf begrenzten Datensätzen weniger zuverlässig sind, was bedeutet, dass ihre Verwendung in bestimmten Situationen sehr wahrscheinlich die Gesamt-Prognosegenauigkeit verringert.

Zurück zu der Situation, in der sich Personen über flache Prognosen beschweren: In der Regel liegt es einfach daran, dass die soeben hochgeladenen Daten entweder sehr kurz sind (zum Beispiel nur 3 Monate monatliche Historie) oder sehr lückenhaft (wie bei einem eCommerce, bei dem es pro Produkt nur wenige Verkäufe gibt). In solchen Situationen liefert Lokad häufig flache Prognosen.

Es ist kein Fehler, es ist ein Feature zur Verbesserung der Genauigkeit.

Leserkommentare (6)

Hallo Johan, die effiziente Darstellung von Zeitreihen in relationalen Datenbanken ist eine ziemlich knifflige Angelegenheit. Kurz gesagt, hängt sie stark von der Länge der betrachteten Zeitreihen ab. Ich bezweifle daher, dass es in diesem Bereich irgendetwas gibt, das einem “Industry Standard” nahekommt. Andererseits ist im Quellcode selbst alles stark von der Länge und Anzahl der betrachteten Zeitreihen abhängig. Hoffe, das hilft. Joannes Vermorel (vor 7 Jahren)

Wir arbeiten an einem Zeitreihenprojekt mit einer typischen Time Series Definition und Beobachtungen. Kannst du uns eventuell mit Folgendem helfen:

1. Hast du eine Industry Standard-Struktur für die Time Series Definition und zugehörige Beobachtungen aus der Perspektive des DB-Designs?
2. Was ist die Best Practice hinsichtlich des Codes, der eine Time Series repräsentiert, z. B. [Level 1].[Level 2].[Sequence Number].[Version]. Jegliche Hinweise und Unterstützung würden sehr geschätzt werden. Johan Strydom (vor 7 Jahren)

Hallo Izi, das ist ein interessanter Gedanke :-) Ich habe von Anfang an an diese Art von “Attacke” gedacht, obwohl sie auf unserer Website nicht weit verbreitet wird. Um dies zu tun, müsstest du sehr genau die Daten kennen, die dein Ziel an Lokad sendet. Außerdem musst du sehr genau wissen, nach welchem Typ von Korrelationen wir suchen. Einfache Verschiebungen in Zeitreihen sind in echten Geschäftsdaten nicht “natürlich”. Schließlich würde es dich etwas Geld kosten, da wir Daten von nicht zahlenden Nutzern nicht vertrauen. Bezüglich unserer Techniken verwenden wir eine komplexe Mischung aus vielen Modellen, zu denen auch bekannte Klassiker gehören. Dieses Thema ist für uns offensichtlich etwas heikel, aber ich werde versuchen, später einen nicht allzu detaillierten Überblick zu posten. Es sei darauf hingewiesen, dass es sich noch in schneller Entwicklung befindet. Joannes Vermorel (vor 9 Jahren)

Also, wenn ich falsche Daten hochlade, die sorgfältig so gestaltet sind, dass sie mit einem Lieferanten/Partner korrelieren, von dem ich weiß, dass er euer Produkt nutzt, kann ich dann seine Ergebnisse durcheinanderbringen? Das ist interessant und scheint auch ziemlich einfach zu sein! Ansonsten wäre es schön, mehr über die von euch verwendeten Techniken zu erfahren (z. B. ARIMA, ANN, etc.). vor 9 Jahren

Hallo Stephen, Gute Anmerkung. Das Grundproblem ist, dass der Benutzer möglicherweise nicht nur die Prognosen selbst möchte, sondern auch die Begründung dahinter oder zumindest einen Kommentar. In Zukunft werden wir wahrscheinlich versuchen, die Client-Apps von Lokad mit automatisierten Richtlinien zu verbessern, die die von Lokad gelieferten Prognosen “kommentieren”. Joannes Vermorel (vor 9 Jahren)

Hallo Joannes, Denkst du, dass dies nützliches Nutzerfeedback ist, um zu beschreiben, was der Benutzer erwartet? Eventuell könntest du den Benutzer darauf beschränken, eine Prognoseaufgabe nur für ein paar Monate, sagen wir 3, durchzuführen, und wenn es länger dauert, würde er eine Warnung bezüglich der Auswirkungen auf die Prognosegenauigkeit erhalten. Ich vermute, es könnte auch von der Verfügbarkeit der historischen Daten abhängen, sodass es vielleicht eine Möglichkeit gäbe, beides miteinander in Beziehung zu setzen, da bin ich mir nicht sicher. Außerdem denke ich, dass es aus Sicht der Benutzer, obwohl es korrekter wäre, ihnen eine flache Prognose zurückzugeben, eventuell sinnvoll wäre, sie in irgendeiner Weise über diesen Fall zu informieren und/oder ihnen die Option zu geben, diese zu akzeptieren oder ein naiveres Ergebnis zu akzeptieren? Stephen (vor 9 Jahren)