Does using a model on new inputs retrain it?

Usually no. Ordinary inference leaves learned parameters unchanged unless an explicit learning mechanism is enabled.

Is a retrained model always deployed?

No. It should remain a candidate until it meets the relevant acceptance criteria.

Must retraining start from the old weights?

No. Teams may refit from scratch or continue from an existing model; the chosen procedure should be documented.

AI Glossary / Governance, ethics and safety / Intermediate

Retraining

Definition

Retraining updates a previously trained machine-learning model through another training process using different training data. It can incorporate newer observations, corrected labels or revised data coverage so that the resulting model better addresses an intended task.

What it means

A deployed model does not automatically improve simply because more data passes through it. Inference usually applies existing parameters; retraining changes the learned model through an explicit learning process.

Teams use the word for several workflows, including fitting a replacement from scratch on an updated dataset or continuing training from existing parameters. Those procedures are not identical and should be named clearly. Retraining is also distinct from changing a decision threshold, refreshing a retrieval index or updating application instructions when no model training occurs.

How it works

Begin with a reason to reconsider the current model, such as observed performance deterioration, changed data coverage or corrected labels. Check whether the problem really requires new training: an input-processing defect may need a software fix instead.

Prepare and version the new training dataset, decide how historical and recent examples will be used and run the selected training procedure. Evaluate the candidate against the existing model using relevant held-out data, including important subgroups and operational constraints.

Deployment is a separate decision. A newly trained artifact can be rejected if it fails acceptance criteria. If released, retain its data lineage, configuration, evaluation evidence and rollback path. Monitor outcomes because offline improvements may not fully predict behavior under operational conditions.

Three practical examples

Demand forecasting: A team incorporates recent patterns while preserving enough seasonal history to avoid learning only the latest short-term conditions.
Document classification: Corrected labels and newly introduced document types are included in an updated training dataset, with separate evaluation of old and new categories.
Equipment analysis: A model is reassessed after a sensor or operating regime changes. Engineers first check whether units and preprocessing remain compatible before assuming retraining is the answer.

Think of it this way

Think of revising a map after new roads appear. The revision should use reliable observations and still preserve useful existing information. Unlike a map update, retraining changes statistical parameters in ways that may affect many outputs, so improvements in one area can coincide with regressions elsewhere.

Worked example

A fictional classifier is evaluated on two groups of one hundred examples each. The current model gets ninety correct in group A and eighty in group B, for 170/200=85% overall accuracy.

A retrained candidate gets eighty-five correct in A and ninety in B, giving 175/200=87.5%. Overall accuracy improves by 2.5 percentage points, but group A declines by five percentage points.

The team must assess that trade-off against the application's requirements rather than assuming the candidate is better in every respect. The invented counts also need uncertainty and representativeness considerations before supporting a deployment decision.

Illustrative case study

Fictional case: Route Ledger schedules monthly retraining for a delivery model. One month's data contains a temporary reporting error, and the newly trained candidate performs worse on a clean validation set.

The pipeline retains the existing model, flags the data issue and records the rejected candidate. Engineers correct the source problem before considering another training run. This invented case illustrates why automated retraining should include evaluation gates rather than automatic promotion of every new artifact.

Common misconceptions and mistakes

Retraining more often does not guarantee better performance. New data can be noisy, unrepresentative or affected by the model's own earlier decisions. Repeated training may reinforce those problems.

A detected distribution shift is a reason to investigate, not proof that retraining is necessary or sufficient. Changes in the relationship between inputs and outcomes may matter differently from harmless changes in input frequency. Avoid using the final test set repeatedly for tuning. Also distinguish continued training from a full refit, since they may preserve or overwrite prior behavior differently.

Business use

Businesses should choose retraining triggers and review procedures based on the application's change rate, feedback availability and consequences of errors. A schedule can be useful, but evidence-based triggers may also be appropriate.

Budget for data validation, evaluation and operational rollout, not just compute time. Keep a record of which model version served each period so outcomes can be traced. Define who can approve changes and how to recover from regressions. The objective is sustained usefulness of the complete system, not simply a high count of training runs.

Check your understanding

A new model performs better overall but substantially worse on an important subgroup. Is the higher average enough to approve replacement?

Answer: No. The subgroup regression and application requirements need assessment before deployment.

Related terms

Concept drift
Fine-tuning
Model drift
data validation
model versioning
continuous training
evaluation gate
rollback

Learn next

Write a retraining policy for a simple model. Specify the trigger, data window, quality checks, comparison baseline and acceptance criteria. Include a case in which the new candidate is rejected. Distinguish the training process from the separate decision to release it into operation.

Sources

ITU-T Y Supplement 97, term 3.1.102, referencing ISO/IEC 22989: https://www.itu.int/rec/T-REC-Y.Sup97-202511-I/en Google Cloud, MLOps: Continuous delivery and automation pipelines in machine learning: https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning ISO/IEC 22989:2022: https://www.iso.org/standard/74296.html Examples are original and do not prescribe a universal retraining frequency.

Previous: Retrace(lambda) Next: Retrievability