[KI-Ideen-Notizbuch 02] Timestral: Zahlen für morgen prognostizieren, ohne einen Chatbot raten zu lassen

Das KI-Ideen-Notizbuch erkundet die Ideen und praktischen Möglichkeiten hinter neu entstehenden KI-Modellen und Werkzeugen.

Die Supportwarteschlange von morgen ist zunächst eine Zahl, bevor sie ein Absatz wird. Vielleicht möchten Sie wissen, ob eine weitere Person eingeplant werden muss, ob ein Server mehr Kapazität braucht oder ob die übliche Warenbestellung für das Wochenende reicht. Eine flüssige Erklärung hilft erst dann, wenn die Prognose eine solide Grundlage hat.

Timestral, von Mistral AI am 15. Oktober 2026 vorgestellt, ist eine Modellfamilie zur Vorhersage von Zahlenfolgen. Sie liefert probabilistische Prognosen statt Chatantworten, unterstützt mehrere zusammenhängende Reihen und wurde in vier Größen veröffentlicht: 5M, 28M, 123M und 209M Parameter. Ankündigung von Mistral

Diese Einführung führt von der Beschreibung zu einem ersten brauchbaren Versuch. Wir betrachten, welche Eingaben das Modell braucht, wie sich ein Prognosebereich lesen lässt und wie ein Vergleich mit einer einfachen Referenz funktioniert. Die Beispiele sind vorgeschlagene Übungen, damit Sie die Idee ausprobieren können, ohne eine Illustration für ein Messergebnis zu halten.

Die Timestral-5M-Seite von Mistral AI, aufgenommen am 20. Oktober 2026. Die Ansicht zeigt einen Prognose-Checkpoint, kein Diagramm aus einem für diesen Artikel durchgeführten Versuch.

Eine Prognose beginnt mit einer Zeitachse und einer Größe

Eine Zeitreihe hält eine Größe über aufeinanderfolgende Zeitschritte fest. Beispiele sind Anfragen pro Minute, Bestellungen pro Tag oder Temperaturen in regelmäßigen Abständen. Der Abstand gehört zur Bedeutung: 100 Anfragen pro Minute und 100 Anfragen pro Stunde beschreiben sehr unterschiedliche Systeme.

Formulieren Sie die Entscheidung vor der Modellwahl in einem Satz. „Das tägliche Supportvolumen von morgen schätzen, damit wir die Besetzung planen können“ ist klarer als „Erkenntnisse in unseren Daten finden“. Es legt Zielgröße, Prognosehorizont und die möglicherweise veränderte Handlung fest.

Entscheiden Sie anschließend, wofür eine Beobachtung steht. Ein heute erstelltes und ein heute gelöstes Supportticket sind unterschiedliche Ereignisse. Beide in einer praktischen Spalte zusammenzufassen, kann genau den Engpass verbergen, den Sie verstehen wollten.

Timestral kommt nach dieser Definition zum Einsatz. Es kann einen numerischen Verlauf verarbeiten, doch das Team bleibt für die Bedeutung der Zahlen verantwortlich. Ein Modell kann keine Zielgröße reparieren, die mitten in der Datei unbemerkt von Anfragen zu abgeschlossenen Aufträgen wechselt.

Das nützliche Ergebnis ist ein Bereich, auf den Sie reagieren können

Eine Punktprognose liefert eine einzelne Zahl. Eine probabilistische Prognose beschreibt mehrere mögliche Niveaus des zukünftigen Werts und zeigt damit den Spielraum um die zentrale Schätzung. Timestrals veröffentlichte Ausgabe enthält 21 Quantile pro vorhergesagtem Zeitschritt. Inferenz-Repository

Stellen Sie sich eine Übung vor, in der die Medianprognose für morgen bei 100 Tickets und ein höheres Quantil bei 140 liegt. Diese Zahlen sind erfunden, verdeutlichen aber die Entscheidung: Die normale Besetzung deckt vielleicht den zentralen Wert ab, während ein Reserveplan für einen geschäftigeren Tag vorsorgt. Die Prognose ist nützlich, weil sie Ihre Vorbereitung verändert.

Ein Quantil verspricht nicht, dass die Realität unter einer Linie bleibt. Sie müssen die Kalibrierung anhand wiederholter historischer Prognosen prüfen. Übersteigen Beobachtungen die als 90. Perzentil bezeichnete Prognose wesentlich häufiger als erwartet, ist dieses Niveau für Ihre Daten keine verlässliche Planungsgrenze.

Die passende Grenze hängt außerdem von der Entscheidung ab. Ein Lagerengpass verursacht andere Kosten als ein kleiner zusätzlicher Bestand. Deshalb kann ein Team auf Basis eines höheren Quantils statt des Medians handeln, während eine andere Aufgabe einen günstigeren, weniger vorsichtigen Plan verträgt.

Eigene Erklärungsgrafik. Kurve und Bereich sind erfunden, um ein Prognosefenster zu erklären; sie sind keine Ausgabe von Timestral.

Verwandte Signale helfen nur bei ehrlicher zeitlicher Zuordnung

Mistral beschreibt Timestral als multivariates Modell, das sowohl nur aus der Vergangenheit bekannte als auch im Voraus bekannte Kovariaten unterstützt. Einfacher gesagt: Es kann mehrere verwandte numerische Signale und Informationen nutzen, deren zukünftige Werte bereits vorliegen. Beschreibung der Veröffentlichung

Die Öffnungstage eines Geschäfts sind bekannt, bevor morgen beginnt. Die tatsächlichen Umsätze von morgen sind es nicht. Ein Prognoseversuch muss diesen Unterschied einhalten, selbst wenn das fertige Tabellenblatt praktischerweise beide Spalten enthält.

Bei einer Übung zur Serverkapazität könnte ein geplanter Produktstart im Voraus bekannt sein, das genaue Anfragevolumen aber nicht. Bei einer Bestellprognose kann ein Feiertagsindikator vorliegen, während die endgültige Bestellzahl die Zielgröße ist. Das sind illustrative Anwendungen der Unterscheidung, keine Behauptungen über eine eingesetzte Integration.

Das Wetter zeigt einen leicht zu übersehenden Fehler. Eine historische Datei kann das tatsächlich eingetretene Wetter enthalten. Für eine echte Prognose wäre damals nur die Wettervorhersage verfügbar gewesen. Die Auswertung mit später beobachteten Werten gibt dem System Informationen, die es zum Entscheidungszeitpunkt nicht gehabt hätte.

Beginnen Sie mit dem kleinsten Versuch, der eine Frage beantwortet

Das offizielle Repository bietet eigenständige Inferenz auf CPU oder GPU. Der CPU-Pfad erleichtert einen ersten Test, ohne die Modellgröße mit einer vollständigen Hardwareanforderung gleichzusetzen. Abhängigkeiten, geladene Tensoren, Verlaufslänge und Anzahl der Reihen tragen ebenfalls zum Arbeitsspeicherbedarf bei. Installation und Verwendung

Für eine Einführung ist der 5M-Checkpoint ein vernünftiger Kandidat, um die Schnittstelle kennenzulernen. Das ist ein vorgeschlagener Einstieg für eine kleine Übung, keine Behauptung, dass er größere Checkpoints auf Ihren Daten übertrifft. Bringen Sie zunächst die Verarbeitungskette zum Laufen, bevor Sie Modellgrößen vergleichen.

1. Öffnen Sie das offizielle Repository und prüfen Sie Installationsanleitung und Lizenzlinks. Arbeiten Sie in einer separaten Python-Umgebung.
2. Bereiten Sie eine regelmäßig abgetastete Reihe vor. Behalten Sie Zeitstempel und Einheiten in der Quelldatei, selbst wenn das numerische Array für das Modell nur Werte enthält.
3. Halten Sie die letzten Beobachtungen als Testhorizont zurück. Sie dürfen nicht in die Vergangenheit eingehen, aus der diese Prognose entsteht.
4. Laden Sie einen Checkpoint, fordern Sie den gewählten Horizont an und prüfen Sie sowohl die zentrale Prognose als auch die Quantile.
5. Vergleichen Sie mit einer einfachen Prognose aus demselben Verlauf. Wiederholen Sie das an mehreren früheren Stichtagen, bevor Sie Schlüsse ziehen.

Das Repository dokumentiert den folgenden Installationsweg und nennt Python 3.10 oder neuer sowie PyTorch 2.4 oder neuer als Voraussetzungen. Bei der Installation wird Code abgerufen; prüfen und fixieren Sie eine Revision, wenn Sie eine reproduzierbare Umgebung benötigen.

python -m venv .venv
# Activate the environment using your shell's activation command.
python -m pip install "git+https://github.com/mistralai/timestral.git"

Hier folgt eine bewusst kleine Anpassung der dokumentierten Inferenzschnittstelle. Die Werte sind synthetische Tageszahlen. Der Code bedeutet nicht, dass das Modell für diesen Artikel ausgeführt oder ein bestimmtes Ergebnis erzielt wurde.

import numpy as np
from timestral import TimestralForecaster

history = np.array([
    80, 83, 85, 88, 96, 61, 58,
    82, 84, 87, 91, 99, 64, 60,
    85, 86, 89, 94, 102, 66, 63,
], dtype=np.float32)

model = TimestralForecaster.from_pretrained("mistralai/Timestral-5M")
forecast = model.forecast(history, prediction_length=7)
print(forecast.median)
print(forecast.quantile(0.9))

Drei Wochen erfundener Daten reichen, um die API zu zeigen, nicht um die Leistung in einem Geschäftsprozess zu belegen. Ersetzen Sie sie vor einer Entscheidung durch eine ausreichend lange, gut verstandene Reihe. Prüfen Sie fehlende Beobachtungen und ungewöhnliche Ereignisse, statt jede Lücke stillschweigend zu null zu machen.

Drei Aufgaben zeigen, weshalb Prognosen etwas anderes als Textgenerierung sind

Die tägliche Supportplanung verknüpft Prognosen mit der Personalbesetzung. Als Eingabe eignet sich beispielsweise der Verlauf täglich neu erstellter Tickets mit einem Kalender für Wochenenden und bekannte Schließtage. Zu prüfen ist, ob die Prognose die Kapazitätsplanung verbessert, besonders an stärkeren Tagen, die ein einfacher Durchschnitt übersieht.

Die Serverplanung verbindet eine Prognose mit einer technischen Grenze. Die Anfragen pro Intervall können die Zielgröße sein; Fehler, Latenz und tragbare Kapazität müssen dennoch separat überwacht werden. Eine Prognose des erwarteten Bedarfs belegt nicht, dass eine Anwendung einer bestimmten Last standhält.

Die Bestandsplanung verbindet eine Prognose mit der Lieferzeit. Dauert die Nachlieferung mehrere Tage, ist nur die Nachfrage von morgen der falsche Horizont. Ein nützlicher Versuch prognostiziert den Zeitraum, in dem die nächste Bestellung noch nicht eintreffen kann, und vergleicht die Folgen von Fehlbeständen und Überbeständen.

Alle drei Beispiele folgen demselben Muster: Größe definieren, Entscheidungszeitpunkt festlegen und bestimmen, was sich durch die Prognose ändert. Das Modell wird dann zu einem Instrument innerhalb des Ablaufs. Dieses Instrument lässt sich leichter bewerten, wenn die beabsichtigte Handlung sichtbar ist.

Vergleichen Sie Prognosen zu dem Zeitpunkt, an dem sie möglich gewesen wären

Ein Backtest bildet frühere Prognosegelegenheiten nach. Wählen Sie einen historischen Stichtag, stellen Sie nur die davor verfügbaren Informationen bereit und prognostizieren Sie das nächste Intervall. Verschieben Sie den Stichtag nach vorn und wiederholen Sie den Vorgang, ohne zukünftige Beobachtungen rückwirkend in die Modellwahl einfließen zu lassen.

Beginnen Sie mit einer Referenz, die zum Muster passt. Bei einem Wochenrhythmus kann der Wert desselben Wochentags der Vorwoche nützlich sein; bei stabilen Prozessen mit kurzem Horizont der jüngste Wert. Keiner ist automatisch stark, doch beide zeigen, ob zusätzliche Komplexität ihren Aufwand rechtfertigt.

Behalten Sie Zeiträume mit null oder nahezu null im Blick. Prozentuale Fehler sind bei sehr kleinen Zielwerten schwer zu deuten. Verwenden Sie passende Kennzahlen und betrachten Sie neben dem Gesamtwert auch die tatsächlichen Fehlprognosen.

Für einen praktischen Pilotversuch ist eine kleine Tabelle der größten Abweichungen oft lehrreicher als ein einziger Durchschnitt. Hing der Fehler mit einem fehlenden Intervall, einem Feiertag, einem Systemausfall oder einer echten Nachfrageänderung zusammen? Die Antwort entscheidet, ob die Datenverarbeitung verbessert, zusätzliche Information ergänzt oder der Prognoseansatz überdacht werden sollte.

Eigenes Backtesting-Diagramm. Jede Prognose verwendet die an ihrem Stichtag verfügbaren Informationen; spätere Beobachtungen bleiben der Bewertung vorbehalten.

Kleine Gewichte sind nur ein Teil des Betriebs

Das Repository unterscheidet zwischen Code unter Apache 2.0 und Modellgewichten unter einer Modified MIT license. Lesen Sie die tatsächlichen Bedingungen des gewählten Checkpoints. Ein offenes Repository und ein separat lizenziertes Modell sind unterschiedliche Vertriebsartefakte. Lizenzerläuterung im Repository

Erstmalige Downloads und gewöhnliche Inferenz sind ebenfalls getrennte Phasen. Der dokumentierte Loader kann ein lokal zwischengespeichertes Modell nutzen. Eine Anwendung bleibt aber nur offline, wenn alle ihre Komponenten offline bleiben. Ein lokales Prognosemodell verhindert nicht, dass ein anderer Teil des Ablaufs Daten an einen entfernten Dienst sendet.

Halten Sie im wiederkehrenden Betrieb fest, welcher Checkpoint jede Prognose erzeugt hat und wann die Eingabedaten endeten. Ohne diesen Stichtag kann ein Diagramm für eine Vorhersage gehalten werden, obwohl spätere Beobachtungen bereits eingeflossen sind. Bewahren Sie die vorhergesagten Werte unverändert auf, um sie später mit dem tatsächlichen Verlauf vergleichen zu können.

Ein Prognosedienst braucht auch einen Plan für fehlende Daten und gescheiterte Durchläufe. Die gestrige Prognose als frisch anzuzeigen, lässt die Oberfläche irreführend gesund wirken. Zeigen Sie den letzten erfolgreich verarbeiteten Datenzeitpunkt und legen Sie fest, wann eine einfache Referenz besser als eine veraltete Modellausgabe ist.

Eine schnellere Prognose hilft nur, wenn die Entscheidung besser wird

Mistral berichtet über CPU-freundliche Inferenz und starke Benchmark-Ergebnisse der Familie. Das sind Gründe zur Prüfung, keine Messungen Ihrer eigenen Datenverarbeitung. Eine veröffentlichte Modelllaufzeit umfasst nicht jeden denkbaren Dateizugriff, jede Merkmalsberechnung, Warteschlange oder Grafik einer Anwendung. Ankündigung vom 15. Oktober

Es ist verlockend, im Pilotprojekt den größten noch lauffähigen Checkpoint in den Mittelpunkt zu stellen. Die bessere Frage ist, ob die Prognose rechtzeitig vorliegt und die wichtigen Fehler verbessert. Ein etwas genaueres Ergebnis nach Ablauf der Personalplanungsfrist hat nur begrenzten betrieblichen Wert.

Unterscheiden Sie außerdem numerische Verbesserungen von Verbesserungen der Planung. Ein kleinerer Durchschnittsfehler kann die teuersten Spitzentage unverändert lassen. Umgekehrt kann ein besser kalibriertes oberes Quantil die Planung verbessern, selbst wenn sich der Median kaum verändert.

Legen Sie diese Kriterien vor dem Modellvergleich fest. Dann kann der Pilot mit einer nützlichen Entscheidung enden: Referenz behalten, kleinen Checkpoint einsetzen oder eine anspruchsvollere Konfiguration begründen. Jedes dieser Ergebnisse kann bei klaren Belegen richtig sein.

Die Prognose sollte dokumentiert sein, bevor morgen beginnt

Unserer Ansicht nach ist Timestral interessant, weil es eine spezialisierte numerische Aufgabe in einen zugänglichen Modellablauf bringt. Die Ausgabe kann als Wettervorhersage für eine Arbeitslast dienen: eine zentrale Erwartung, ein Bereich und ein Anlass zur Vorbereitung. Der Nutzen entsteht, wenn diese Vorhersagen auf eine konkrete Planungsentscheidung treffen.

Beginnen Sie mit einer Größe und einem Horizont. Speichern Sie die Prognose, bevor das Ergebnis bekannt ist, und vergleichen Sie sie ehrlich mit einer einfachen Alternative. So wird aus einer vielversprechenden Modellveröffentlichung ein Versuch, dessen Ergebnis Sie tatsächlich nutzen können.

Quellen und Medien

Geprüft am 20. Oktober 2026. Beispiele und Diagramme dienen der Veranschaulichung und sind keine Ergebnisse einer Modellausführung. Der Autor hat den Screenshot der öffentlichen Model Card aufgenommen; die Erklärungsgrafiken sind eigene Arbeiten. Quellen und Lizenzhinweise finden Sie im Mediennachweis.

• Ankündigung von Mistral vom 15. Oktober 2026
• Offizieller Inferenzcode, Installation und Lizenzunterscheidung
• Timestral-5M-Checkpoint
• Lizenz des Checkpoints

Bewahren Sie Prognose und Ergebnis gemeinsam auf

Speichern Sie Datendefinition, Prognosestichtag und Prüfnotizen zusammen mit den ursprünglichen Quellenlinks. Telli.sh kann helfen, diese Versuchsunterlagen zu organisieren. Telli.sh-Konto erstellen