Walk-Forward-validatie voor tijdreeksen

Forecasting asks what could have been predicted before an outcome occurred. A random train-test split often fails to represent that task because later observations can help train a model evaluated on earlier ones. Walk-forward validation advances a forecast origin through time and recreates the information boundary at each step. Choose an initial training period, a forecast horizon and a schedule for moving the origin. Train using the allowed history, predict the following period, save the predictions, and compare them with outcomes once available. Then move forward and repeat. An expanding window retains all earlier training data; a rolling window keeps only a recent span. Neither choice is universally best. The horizon should match the decision. A process that places orders four weeks ahead needs evaluation of four-week-ahead forecasts, not only next-day predictions. If the production model will be refitted monthly, an evaluation that refits every day may assess a different procedure. Write down both the horizon and update schedule. Features require the same discipline. A moving average must exclude the outcome being predicted. External information should be represented as it was available at the time, including publication delays and later revisions. A weather forecast available on the decision day is different from weather observations collected afterward. Scikit-learn's TimeSeriesSplit provides ordered training and test splits, with options for gaps and training-window limits. The split object alone cannot prevent leakage introduced while preparing features. Check every input's availability. Compare the model with a meaningful historical or seasonal baseline on identical forecast periods. Report errors by horizon and inspect changing conditions. A favorable average can conceal a period in which the process failed badly.