> Known-future covariates. Some drivers of sensor behaviour are known in advance, such as production schedules, planned shutdowns, weather forecasts. Timestral can condition on them to improve forecast quality, so a scheduled load increase is expected rather than flagged as a surprise.
To me this should be the entire basis of the system, not a condition to improve forecast quality? Like if you're modelling electricity consumption, if all you have is a window of N previous samples, you're going to get completely beaten by a comparatively simple system that knows the time of day, that there's holidays coming up, the weather forecast, etc.
I would also think that these time-series forecasting models would gain from a sophisticated understanding at least the labels of the covariates? A 5M model has no idea what a "bank holiday" is, it just sees an arbitrary class go from 0 to 1, and won't have any useful inductive biases as to what it means or how to link them to other pieces of information.
E.g., wouldn't you predict €/MWh of electricity far more accurately with access to price of natural gas (itself influenced by many geopolitical factors), breakdown in composition of production of each energy source, predictions about roll-out (requiring a sophisticated LLM capable of understanding news and their implications), etc. What's the use in trying to predict it from 2 variables and a narrow window looking back at just 8192 or 32768 samples?
Or perhaps I misunderstand the use-case and this is more for extremely short term movements?
You're right but, if the time series looks like music then you can apply your music domain knowledge. You don't have to only apply knowledge that's general across every domain, part of the magic of large neural nets is that you can do recognition and prediction at the same time thereby using (statistically) things known from training about how to identify a sequence and then also how to continue it.
Sure adding outside info helps even more, but with enough data it should become unnecessary (or so goes the theory).
Edit : working with GLM5.3 now, it's also slow. Maybe Mistral's under heavy load.
Disclaimer : Not Cofounder of The Forecasting Company here
Something is going on with the performance (as in speed of the service, not quality). Some days it's quite fast, some days it's so slow I interrupt it because I thought it was hanging.
I think they're shifting hosting capacity around, or otherwise messing with the model. Note that it's still a "preview" version, meaning they're still training it further for the final release and they are likely still figuring out the optimal hosting configuration as well.
It wouldn't surprise me to see further changes in both quality of the model and speed before the final release.
Speed looks nice too. I want an open weight model with this performance now.
EDIT: ours is Apache 2, whereas Timestral has a restrictive license
If you compare the 2, it's not a strict "timestral is better" story - the winrates are tight - your probably should try both on your use-case. We have a 42% winrate vs Timestral on fevbench for instance.
Ofc, our main value is not just these models, but also 1) extra capabilities (like our model that can natively account for stockouts/censored data, and others coming soon), 2) our systems and products around the model, and 3) we're all laser focused on time-series/forecasting
Seems unprofessional to me, you already started dunking on this release but added little to no arguments as to why or what is wrong here.
Honestly this might be very good for feature selection to refine a much more specialized model.