fit and predict to. The interface may still
change, and evaluate() does not cover it.
fit step. The history you pass is the context the model reads while it
forecasts.
One series
context is the history. Name the time column with timestamp= and the value to forecast
with target=; both default to columns of those literal names.
Give exactly one of prediction_length or future. Both or neither raises a ValueError,
and so does a prediction_length of zero or less.
Quantile columns are strings
mean column and one column per quantile level. The
level is stringified on the wire, so "0.9" is a label and 0.9 is a KeyError.
Those interval columns are what turn a forecast into a decision: order to the 0.5, hold
safety stock to the 0.9. Levels default to 0.1, 0.5 and 0.9, and quantiles=[...] takes
any levels strictly between 0 and 1.
Many series in one call
item_id= and every series is forecast in one call, against a MultiIndex of
(item_id, timestamp). Short histories work, because the model reads every series you sent
while forecasting each one.
Known future covariates
Any column incontext that is not the timestamp, the target or the item id is a covariate.
When you know those values over the horizon, pass a future frame instead of
prediction_length.
- Client-side. A covariate missing from
futureraisesValueErrornaming the columns, before anything is uploaded. - Server-side. The worker re-derives the covariate keys from your uploaded rows and
compares them to the declared list. Any difference fails the job with
schema_mismatch.
Every call sends the whole history
Forecasting never uses a fitted context, so none of the fit-once, predict-many story in The fitted context applies here. Every call re-uploads the full history and the model re-reads it. A forecast bills your context rows once and your output rows twice, so a long history costs you on every call.- Trim the history to the window that carries signal. Rows the model gains nothing from still cost upload time, forward-pass time and money.
- Batch series rather than looping. One call over 200 SKUs uploads one payload; 200 calls upload 200.
Missing values are passed through
Nothing in the forecast path fills, drops, interpolates or resamples. A missing target or covariate value is serialized as it stands and handed to the model. Gaps in the timestamps are not filled either, and irregular spacing is not detected. Resample to a regular grid and decide what a gap means before you call.Limits
Output rows are the horizon times the number of series, or the row count of
future. A
breach raises ValidationError with code dataset_too_large client-side, before the payload
is built.
When this will not help
- You need a measured accuracy number.
evaluate()works off a fitted training table, so it never covers a forecast. There is no accuracy path in the SDK for this call. - You forecast on a schedule. Every call re-sends the whole history and the model re-reads it, so there is no fit-once amortisation to find.
- Your covariates are themselves estimates. A
futureframe you had to guess puts a forecast inside your forecast, and nothing separates the two errors. - The series is irregular or gappy. Uneven spacing and missing periods are not detected. Resample to a regular grid first.
Next
- How Hollerith works — why the table is the context
- Limits — the full table, and the daily quota
- Errors —
schema_mismatchanddataset_too_largein full - Usage and billing — what a forecast bills