amazon-science
Support for static features and dynamic categorical features in Chronos-2
I've done some digging, assuming I've read this correctly, static features currently are entirely uninformative and useless. Categoricals get turned into numerics, if said value is the same across the entire series, instance norm takes the value and normalizes it to be completely uninformative noise. Not sure why I thought that in light of instance norm that this would function at all, but it in fact doesn't seem to currently support static features, or even categoricals under the right conditions: if a specified time slice doesn't include other options.
Failure case example: If I have 48 hours of 10 minute intervals of sales, and the random time slicing excludes the previous day, and we have a categorical feature for day of the week, said feature will get normalized to a single uninformative value.
The paper explicitly mentioned # of static features for a variety of datasets, img attached.
If that section of the paper was in fact not meant to reflect model capabilities i think a revision would be useful to reduce future confusion. Otherwise updating the model to properly handle these cases would be amazing.
@Thomas2419 thanks for opening the issue. Chronos-2 does NOT support static features. The tables in the appendix only highlight the properties of the forecasting tasks.
Note that you may be able to use static features in alternative ways. For example, you can use them to group time series and make joint predictions for time series that share static metadata. I would be curious to learn more about your experience, in case you try this.
Out of curiosity, are you working with a forecasting task where using static features brings large improvements? If yes, could you share more information about it?
Chronos-2 supports dynamic (numeric and categorical) features. For categorical features, the history of the time series must have examples of the different categories, otherwise the model won't be able to infer their effects on the target. This is a reasonable assumption on the data.
@abdulfatir Thank you for the clarification! I believe a truly wide variety of static features may assist for sales forecasting: city, state, longitude, latitude, this letting the model learn correlations between regional strength of an organization. Especially in zero shot situations, forecasting a new location with minor historical context but overlapping static features.
A particular use case I've been testing is short horizon stock price prediction. One could consider similar industries as a multivariate task; however, I am not treating them that way. Using static features for industry however in particular on stock data would enable significant learning of the overlap/correlation in how the market perceives industries.
I have git cloned the repo and will test with hacking in the option to pass an embedding into the model, then create an embedding of my desired features over the datasets I am testing. I will report back if I perceive significant impact on the zero-shot and eval performance.
In the fashion retail industry, static features can be very useful for forecasting product demand. ex : product hierarchy information such as category, brand, color, and size... These attributes don’t change over time, but they provide valuable context that generally helps the model to understand patterns across similar products — for instance, that certain brands or colors tend to perform better during specific seasons. By incorporating these static features, forecasts become more accurate and generalizable, even for new or less frequently sold items.
@GGA-PERSO @Thomas2419 Indeed the examples that you gave sound interesting and I have heard similar examples before. My intuition is that such static metadata information is helpful in the context of small deep learning models which can specialize the dynamics based on this information. However, the usefulness of this information for a large pretrained model is still unclear to me. One place where static metadata could be useful is in short context or cold-start scenarios, where you have limited history for a series but longer history for another similar series. Beyond this, I am not sure. I would be really curious to know if you have additional insights here.
@GGA-PERSO, @Thomas2419 maybe you also want to look at this
https://github.com/amazon-science/chronos-forecasting/blob/e48f48071f999825b4ed114230229dd771fac129/src/chronos/chronos2/pipeline.py#L452
https://github.com/amazon-science/chronos-forecasting/blob/e48f48071f999825b4ed114230229dd771fac129/src/chronos/chronos2/pipeline.py#L456
Note: categorical covariates are only supported as numpy arrays as torch does not support str dtype
