Retraining triggers

Drift tells you the model is decaying — but retraining is not free and not always the answer. The skill is knowing when retraining is justified versus premature.

When retraining is justified

A good trigger is a real, sustained signal plus the material to learn from:

• Confirmed drift — data or concept drift you've actually detected, not a hunch.
• Accuracy below the bar for a while — a sustained dip, not one bad day.
• Enough new labeled data — you have meaningfully more ground truth than last time, so retraining can actually improve the model.

The practical rule combines them: retrain when there's a real signal AND enough new labels. Run the editor — drift is real and there are 500 new labels (≥ the 200 minimum), so retraining is justified.

When retraining is premature

• A single bad day (noise, not a trend).
• Too few new labels — you'd retrain on basically the same data and just burn compute (and risk a worse model from a tiny, skewed batch).
• No new data at all — nothing to learn; the model can't improve.

Premature retraining wastes effort and can lower quality (overfitting a small recent batch). "Wait for a real signal and real data" is often the right call.

Why a builder cares

Teams either never retrain (stale model rots) or retrain reflexively on every blip (churn, regressions, wasted cost). A simple trigger — confirmed signal AND enough new labels — keeps you in the middle. You'll write that decision next.