Online and Incremental Learning

## Two ways to keep a model current A model is a summary of the data it was fitted on. When more data arrives, you have two structurally different options. **Batch refitting (the default).** You keep the historical data, and every so often you throw the current model away and run the whole fitting procedure again over everything — old rows plus new. The output is a new artifact that has no memory of the previous one. This is what almost every tabular pipeline does. **Incremental (online) updating.** You keep the *model*, not the data. Each new example, or each chunk of examples, is used to adjust the parameters you already have, and is then discarded. After the update the row is gone; its influence survives only inside the parameters. Note what this axis is *not* about. Whether one gradient step is computed from one row, 256 rows, or the entire training set is a question about the optimizer inside a single fit. Batch-versus-online here is about *when the model is refit as the world produces new data* — a deployment question, not an optimizer question. Candidates routinely conflate the two, and interviewers listen for it. ## Which algorithms can actually be updated Incremental updating is not a property you can bolt on; it depends on how the method stores what it learned. - **Count-based models.** If the fit is a table of counts — class frequencies and per-feature frequencies — those counts are *sufficient statistics*: merging two datasets is just adding two tables. New data means incrementing counters, and the result is bit-for-bit what a full refit would have produced. - **Gradient-updated parameter vectors.** A linear or logistic model fitted by stochastic updates has a natural per-example update rule: `w <- w - lr * grad`. Feeding it a new row is exactly what training already did. - **Centroid models.** A streaming k-means assigns the incoming point to its nearest centroid and moves that centroid a small step toward it. - **Stream-designed trees.** Hoeffding trees (very fast decision trees) were built for this: they accumulate statistics at each leaf and use a statistical bound to decide when enough examples have been seen to commit to a split. And which cannot: - **CART trees and random forests.** A split threshold is chosen by scanning candidate cut points against the statistics of *all* rows reaching that node. One extra row cannot revise that choice; honouring it means regrowing the tree. "Add data" and "refit" are the same operation here. - **Gradient-boosted ensembles** (including XGBoost, LightGBM and CatBoost as algorithms) are a partial case. You can continue training by appending trees fitted to the current residuals, but every tree already in the ensemble is frozen and was fitted against the old data's residuals. Append long enough on new-only data and you get a hybrid whose early stages describe a world that no longer exists. ## What each costs you | | Batch refit | Incremental update | |---|---|---| | Data you must keep | all of it | only the current row/chunk | | Compute per update | a full training run | one cheap step | | Time for new data to reach predictions | one cycle | seconds | | Reproducibility | rerun on the data, get the model back | depends on the exact order of every update ever applied | | Algorithm choice | anything | only updatable families | | Recovery from bad data | refit without it | restore a parameter snapshot; the bad rows are unrecoverable | That reproducibility row is the one people underrate. A batch artifact can be regenerated from the data; an online model is a path-dependent object, and if a corrupt hour of events got folded in, there is no "remove those rows" — only rolling back to a saved snapshot of the parameters and replaying. ## A worked case A ride-hailing surge model predicts a multiplier from recent demand, supply and weather. Refitting it from scratch every hour on the trailing weeks is simple, reproducible and fully auditable, and an hour of staleness is usually tolerable — but it is a full training run every hour, and during a stadium emptying out, an hour is an eternity. Updating the same model on each chunk of completed trips as they close costs almost nothing per update and tracks the surge as it happens, at the price of an artifact whose exact state depends on the order chunks arrived in, and which no one can regenerate from the warehouse. The usual production answer is not one or the other: incremental updates between cycles for freshness, plus a periodic cold refit from scratch as the anchor that resets accumulated path dependence and restores reproducibility. ## How to decide Ask three questions. How stale can a prediction be before it is wrong in a way that costs money? Does the data even fit in memory for a batch fit? And can you afford an artifact you cannot regenerate? If staleness is cheap and the data fits, batch refitting is the boring correct answer, and choosing online learning without one of those pressures is complexity you will pay for at the first incident.