When a scheduled refresh of the hotel pricing model fires, which stages of the training pipeline actually rerun?

middleshould knowfreq 46%

answer

retrain names three different things
features only, warm start, full refit
evaluate and register on every rung
definition change forces a full refit
periodic full refit resets the chain

basics

~20 s

Only as much as the refresh scope says. A refresh can recompute features and reuse the model, seed the fit from the previous model version, or rebuild the snapshot and fit from scratch — but every scope still evaluates, packages and registers a new model version.

solid answer

~40 s

"Retrain" names a ladder, not one action. The cheapest rung recomputes features — rolling occupancy and pace aggregates — and serves the same model version against fresher inputs; nothing is refit. The middle rung is a warm start: the previous model version seeds the fit, which reads only the new increment, so wall-clock and compute drop sharply. The top rung is a full refit: rebuild the dataset snapshot from raw booking and cancellation events and fit from scratch. Whichever rung fires, the tail stages are not optional — offline evaluation, packaging, registration of a new model version, and recording which code version, snapshot and feature-definition version produced it. Most systems run cheap rungs often and a full refit on a longer cycle.

"Retrain" names a ladder, not one action. The cheapest rung recomputes **features** — rolling occupancy and pace aggregates — and serves the same model version against fresher inputs; nothing is refit. The middle rung is a **warm start**: the previous model version seeds the fit, which reads only the new increment, so wall-clock and compute drop sharply. The top rung is a **full refit**: rebuild the dataset snapshot from raw booking and cancellation events and fit from scratch. Whichever rung fires, the tail stages are not optional — offline evaluation, packaging, registration of a new model version, and recording which code version, snapshot and feature-definition version produced it. Most systems run cheap rungs often and a full refit on a longer cycle.

code

json · 17 lines

json

{
  "trigger": "clock.nightly",
  "scope": "warm_start",
  "stages": {
    "snapshot_rebuild": "skip",
    "feature_recompute": "increment_only",
    "fit": "seed_from_model_version_47",
    "offline_eval": "run",
    "package_and_register": "run"
  },
  "lineage": {
    "code_version": "a91f4c2",
    "snapshot_id": "2026-09-17T02:00Z",
    "feature_definition_version": "11"
  },
  "full_refit_every": "P28D"
}

go deeper

for a junior

Know that refreshing a model is several stages — assembling data, fitting, evaluating, registering — and that a refresh can rerun some of them rather than all.

for a middle

Name the three scopes and what each one can and cannot fix, and know that evaluation and registration of a new model version happen on every scope.

for a senior

Match scope to trigger, and defend the periodic full refit that keeps a warm-start chain reproducible when someone asks what produced last Tuesday's rates.

for a principal

Weigh the recurring cost of full refits against the reproducibility and audit position the organisation needs, and decide who owns that policy.

"Retrain" is a ladder, not a verb

Asking what a refresh reruns is the fastest way to find out whether someone has operated one. Three rungs, cheapest first:

Feature refresh only. The rolling aggregates the model reads — occupancy for the stay date, booking pace over the last seven days, competitor rate position — are recomputed and written to the online feature store. The model version does not change at all. Cheap, frequent, and it fixes staleness of inputs while doing nothing about staleness of the learned relationship.
Warm start. The fit begins from the previous model version's parameters and reads the new increment of training rows rather than the whole history. Wall-clock and compute fall sharply, which is what makes short cadences affordable.
Full refit. The dataset snapshot is rebuilt from raw booking and cancellation events, features are recomputed over the whole window, and the fit starts from scratch. Most expensive, and the only rung that is fully reproducible from one snapshot plus one code version.

A design-round answer that says "we retrain nightly" without saying which rung has not answered the question: nightly warm starts and nightly full refits differ by an order of magnitude in cost and in what they can fix.

What every rung must still do

The stages after fitting are not part of the trade. Whatever rung fired:

offline evaluation against a frozen holdout that ends before the candidate's training cut, so the comparison is honest;
packaging the artifact with the exact feature-definition version it expects;
registration of a new model version, with its lineage recorded: code version, dataset snapshot id, feature-definition version, trigger that fired;
the standing gate before anything takes traffic — which is a separate subject, but the point here is that skipping evaluation to make a cheap rung cheaper removes the only thing standing between a bad increment and live rates.

A refresh that skips registration is not a refresh; it is an untracked change to production pricing.

When a full refit is not optional

situation	why a warm start will not do
a feature definition changed	the previous model version was fit reading a different quantity under the same name
the schema of a raw event changed	the increment and the history are no longer the same dataset
a data-quality defect was found and corrected	the bad rows are already inside the seeded parameters
the training window's composition changed	reweighting or extending the window only takes effect on a fit that reads it
the warm-start chain is long	the live artifact is no longer reproducible from one snapshot and one code version

That last row is the one teams discover late. Each warm start makes the live model a function of every increment before it. Reproducing it means replaying the whole chain in order. This is why systems that warm-start frequently also schedule a periodic full refit — every fourth week, say — which resets the chain to a single reproducible starting point.

What the refresh scope should be written down as

Making the scope an explicit, recorded field rather than an implicit property of a script is what lets you answer "what produced the model version that priced last Tuesday?" months later. The scope belongs next to the trigger that fired, because the two decide each other: a drift alarm on a single feature justifies a feature refresh; a drift alarm across the input vector justifies a fit; a feature-definition change forces a full refit regardless of what alarmed.

Matching the rung to the trigger

A practical mapping, and one worth stating in a design round:

clock, short interval → warm start, with a full refit on a longer cycle;
clock, long interval → full refit, since the increment is large anyway;
input drift on one feature → data-quality check first, then a feature refresh if the pipeline was at fault;
broad input or prediction drift → a fit, because the relationship is what moved;
feature-definition or schema change → full refit, unconditionally;
calendar or season turnover → a fit whose training window is reweighted toward comparable past periods.

The cost shape to remember

For most tabular pricing models the cost is dominated not by fitting but by rebuilding the snapshot — the point-in-time assembly of features as they stood when each booking was made. That is why the feature-refresh and warm-start rungs are so much cheaper: they avoid re-deriving history. It is also why "just retrain more often" is a bigger ask than it sounds if every run is a full refit.

## "Retrain" is a ladder, not a verb Asking what a refresh reruns is the fastest way to find out whether someone has operated one. Three rungs, cheapest first: 1. **Feature refresh only.** The rolling aggregates the model reads — occupancy for the stay date, booking pace over the last seven days, competitor rate position — are recomputed and written to the online feature store. The model version does not change at all. Cheap, frequent, and it fixes staleness of *inputs* while doing nothing about staleness of the *learned relationship*. 2. **Warm start.** The fit begins from the previous model version's parameters and reads the new increment of training rows rather than the whole history. Wall-clock and compute fall sharply, which is what makes short cadences affordable. 3. **Full refit.** The dataset snapshot is rebuilt from raw booking and cancellation events, features are recomputed over the whole window, and the fit starts from scratch. Most expensive, and the only rung that is fully reproducible from one snapshot plus one code version. A design-round answer that says "we retrain nightly" without saying which rung has not answered the question: nightly warm starts and nightly full refits differ by an order of magnitude in cost and in what they can fix. ## What every rung must still do The stages after fitting are not part of the trade. Whatever rung fired: - **offline evaluation** against a frozen holdout that ends before the candidate's training cut, so the comparison is honest; - **packaging** the artifact with the exact feature-definition version it expects; - **registration** of a new model version, with its lineage recorded: code version, dataset snapshot id, feature-definition version, trigger that fired; - **the standing gate** before anything takes traffic — which is a separate subject, but the point here is that skipping evaluation to make a cheap rung cheaper removes the only thing standing between a bad increment and live rates. A refresh that skips registration is not a refresh; it is an untracked change to production pricing. ## When a full refit is not optional | situation | why a warm start will not do | |---|---| | a feature definition changed | the previous model version was fit reading a different quantity under the same name | | the schema of a raw event changed | the increment and the history are no longer the same dataset | | a data-quality defect was found and corrected | the bad rows are already inside the seeded parameters | | the training window's composition changed | reweighting or extending the window only takes effect on a fit that reads it | | the warm-start chain is long | the live artifact is no longer reproducible from one snapshot and one code version | That last row is the one teams discover late. Each warm start makes the live model a function of *every* increment before it. Reproducing it means replaying the whole chain in order. This is why systems that warm-start frequently also schedule a **periodic full refit** — every fourth week, say — which resets the chain to a single reproducible starting point. ## What the refresh scope should be written down as Making the scope an explicit, recorded field rather than an implicit property of a script is what lets you answer "what produced the model version that priced last Tuesday?" months later. The scope belongs next to the trigger that fired, because the two decide each other: a drift alarm on a single feature justifies a feature refresh; a drift alarm across the input vector justifies a fit; a feature-definition change forces a full refit regardless of what alarmed. ## Matching the rung to the trigger A practical mapping, and one worth stating in a design round: - **clock, short interval** → warm start, with a full refit on a longer cycle; - **clock, long interval** → full refit, since the increment is large anyway; - **input drift on one feature** → data-quality check first, then a feature refresh if the pipeline was at fault; - **broad input or prediction drift** → a fit, because the relationship is what moved; - **feature-definition or schema change** → full refit, unconditionally; - **calendar or season turnover** → a fit whose training window is reweighted toward comparable past periods. ## The cost shape to remember For most tabular pricing models the cost is dominated not by fitting but by **rebuilding the snapshot** — the point-in-time assembly of features as they stood when each booking was made. That is why the feature-refresh and warm-start rungs are so much cheaper: they avoid re-deriving history. It is also why "just retrain more often" is a bigger ask than it sounds if every run is a full refit.

Why schedule a periodic full refit if the warm starts are working?
To reset reproducibility. After a chain of warm starts the live model version is a function of every increment in order, so rebuilding it means replaying the chain. A periodic full refit produces an artifact reproducible from one dataset snapshot plus one code version, which is what an audit, a rollback target or a debugging session actually needs.
The drift alarm fired on one engineered feature. Which rung should the refresh use?
None, until the feature is checked. A single feature moving alone usually indicates an upstream defect, so the first step is a data-quality check on that column. If the pipeline was at fault, recomputing the feature and backfilling it is the fix; a fit on the corrupted window would seed the defect into the next model version.

saying these in an interview costs you the question

Uses retraining to mean one thing without naming the scope
Skips offline evaluation because the refresh was only a warm start
Thinks recomputing features refreshes the learned relationship
Warm-starts indefinitely with no periodic full refit
Changes a feature definition and keeps seeding from the old model version

When a scheduled refresh of the hotel pricing model fires, which stages of the training pipeline actually rerun?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

"Retrain" is a ladder, not a verb

What every rung must still do

When a full refit is not optional

What the refresh scope should be written down as

Matching the rung to the trigger

The cost shape to remember

▾common follow-ups2 questions

▾red flags5 flags

"Retrain" is a ladder, not a verb

What every rung must still do

When a full refit is not optional

What the refresh scope should be written down as

Matching the rung to the trigger

The cost shape to remember

answer

go deeper