bug: Chronos quantiles warning

[biiiipy]

Initial Checklist

• I confirm that I'm using the latest version of TimeCopilot.
• I confirm that I've reviewed my issue at https://github.com/AzulGarza/timecopilot/issues before opening this one.

What happened?

When passing level to forecast function, for Chronos it outputs warning about wrong quantiles. Simply take a look at this issue - https://github.com/AzulGarza/timecopilot/issues/262 :

tcf1 = TimeCopilotForecaster(
    models=[
        Chronos(repo_id="amazon/chronos-bolt-mini"),
    ]
)

fcst_df_missing = tcf1.forecast(df=df_missing, h=30, level=[80, 90])

Quantiles to be predicted ([0.04999999999999999, 0.09999999999999998, 0.9, 0.95]) are not within the range of quantiles that Chronos-Bolt was trained on ([0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9]). Quantile predictions will be set to the minimum/maximum levels at which Chronos-Bolt was trained on. This may significantly affect the quality of the predictions.

Relevant log output

Environment

timecopilot==0.0.22

[spolisar]

The rounding/trailing decimal part of this is addressed in a pending PR.

The quantile/level compatibility part is a limitation of the model. When forecasting with levels, the level gets converted into two quantiles. Some models, like Chronos, will only accept certain quantiles so if a level is used that converts to an unsupported quantile you will get an error/message like this.

The level->quantile conversion can be found here.

timecopilot/timecopilot/models/utils/forecaster.py

Lines 547 to 555 in eb231fa

	def _level_to_quantiles(level: int | float) -> tuple[float, float]:
	"""
	Given a prediction interval level (e.g. 80) return the lower & upper
	quantiles that delimit the central interval (e.g. 0.10, 0.90).
	"""
	alpha = 1 - level / 100
	q_lo = alpha / 2
	q_hi = 1 - q_lo
	return q_lo, q_hi

An option for addressing this, for at least some models, would be to check if the model supports the provided quantiles and raising an appropriate exception in the case that it does not. Some models already do this internally rather than printing a warning message and continuing with assumed quantiles. If this is done it may also be good to raise a slightly different error when using levels.