Online vs Batch Updates for Live Models

A model deployed into live trading doesn't get to stay frozen forever — markets change, and a model trained on last year's data slowly stops fitting this year's. There are two basic ways to keep it current: batch updates, where the model is periodically retrained from scratch on a rolling window of recent data, or online updates, where the model's parameters shift a little with every new observation as it arrives.

Neither is universally right. Batch updates are stable and easy to audit but stale between refreshes; online updates stay current but can drift toward whatever happened most recently, including noise.

The two approaches side by side

A batch process retrains weekly or monthly on, say, the trailing two years of data, then deploys the frozen result until the next scheduled retrain. It is easy to test, easy to roll back to a known-good version, and behaves identically all week — but a real shift in market conditions on day two of the week goes unaddressed until the next retrain.

An online process updates model weights after every new batch of labeled outcomes, sometimes daily, sometimes intraday. It adapts immediately to a changing environment, but because each individual update is based on limited new data, it is more exposed to overfitting recent noise, and a bad stretch of days can measurably degrade the model before anyone notices.

Worked example

A momentum-timing model is retrained monthly (batch) using the trailing 18 months of data. A volatility regime shift happens two weeks after the March retrain, and the model keeps using pre-shift assumptions until the April retrain — two weeks of degraded performance that a faster-adapting model might have avoided. The desk builds an online variant that updates a subset of parameters daily using an exponentially weighted recent window. The online version picks up the regime shift within three trading days. But six months later, a single unusual week — a flash crash followed by a sharp snapback — pushes the online model's parameters into an aggressive, overfit state that takes another two weeks to correct, a failure mode the batch model, protected by its longer averaging window, never experienced.

What this means in practice

The right choice depends on how fast the underlying relationship actually changes relative to how noisy the data is. Slow-moving relationships (value spreads, long-horizon momentum) favor batch retraining, where noise from any single day gets averaged out before it can move the model. Fast-moving relationships (short-horizon microstructure signals) can justify the responsiveness of online updates, but only alongside guardrails — capping how much any single update can move a parameter — so the model can't be dragged too far by one bad day.