Retrain a computer vision model when new products, lighting, materials, or process parameters produce a measurable decline in reviewed production performance [S1][S3].
The workflow covers failure collection, annotation correction, dataset versioning, targeted fine-tuning, candidate comparison, and controlled deployment across cameras or production lines [S1][S2].
What Triggers Retraining After a Product Change
Retraining should be driven by production evidence rather than a fixed calendar interval. The five practical triggers are measurable performance decline, changed production images, repeated failure patterns, new inspection requirements, and annotation errors [S1].
A new SKU or packaging design changes the correct pass or fail relationship, while a supplier or material change alters color, texture, and reflectivity without changing the drawing [S3]. A tool that wears gradually can also shift the visible part profile, and dust on a lens can change the image distribution without any product change [S3].
Automatic drift monitoring can identify input distribution drift, while concept drift describes a changed relationship between an image and its correct label. Both forms appear in practice as more missed defects, false alarms, or manual reviews [S3]. A vision controller should therefore retain production counters and model-version metadata rather than report accuracy without a reference baseline.
Retraining every week or every month can waste compute and disrupt production. Scheduled retraining can be appropriate, but event-driven retraining after performance crosses a defined threshold is usually more aligned with a specific product change [S2][S4].
Build a Representative Retraining Dataset
A retraining dataset must represent the new product and operating variation, not merely add a small number of failed frames. The minimum useful set depends on defect rarity, visual separability, camera setup, and whether the candidate is a fine-tune or a new model [S1][S5].
Start by collecting images from the changed SKU across normal production conditions, including lighting, speed, temperature, camera position, material lots, and acceptable product variation. Correct existing annotations first because bad labels propagate into the next model version [S1][S2].
One engineering design proposes more than 10,000 images per product variant, 5 lighting conditions from 300 to 1,500 lux, and 3 parameter sets covering speed at plus or minus 15% and temperature at plus or minus 10 degrees Celsius [S4]. The same design calls for at least 500 examples of each defect type per scenario combination and domain-expert label agreement of at least 95% [S4]. These are proposed dataset-design parameters, not universal requirements.
The cited design calls for systematically capturing more than 10,000 images per product variant across five lighting conditions ranging from 300 to 1,500 lux and three process-parameter sets [S4].
Compare Fine-Tuning and Full Retraining
Fine-tuning usually provides the lower-cost route for a product change because it preserves learned features and adapts an existing model to new images; full retraining is more appropriate when the task, capture system, label policy, or defect morphology changes substantially [S1][S2].
The decision depends on four criteria: similarity to the existing task, available representative data, required inference behavior, and acceptable retraining effort. A close visual change with many labeled examples favors fine-tuning. A new inspection target, different sensor characteristics, or broad failure across many classes favors a broader rebuild and validation program [S1][S2].
Neither approach should be promoted solely because the training run completed. The candidate must outperform the deployed model on the same reviewed, versioned test set and on production metrics that reflect the business risk. Training improvements such as mixup, CutMix, label smoothing, or cosine learning-rate decay with warm restarts do not replace representative failure data [S5].
Control Retraining and Deployment Risk
A production rollout can combine shadow validation with offline retraining so the live inspection path is not changed on the first training result. One proposed pattern archives one frame per minute, trains offline after measured accuracy falls below 93%, and validates the candidate in shadow mode for 48 hours before a hot swap during a planned shift change [S4].
That pattern estimates maintenance accuracy at or above 95%, deployment below 5 minutes, and no unplanned downtime, but it also identifies risks that need engineering controls: shadow-station calibration can diverge from the main line, archived labels can be wrong, and model synchronization can fail during the swap [S4].
The stored dataset version must preserve images, annotations, preprocessing, augmentations, and model settings. Without that record, an apparent improvement may come from a changed preprocessing step rather than better learning [S1]. For multi-site deployments, calculate storage, cloud compute, and engineering labor before approval; new shelf or lighting data can involve terabytes of video, while hybrid retraining limits processing to targeted examples [S2].
Monitor the Deployed Model Continuously
Post-deployment monitoring needs at least 4 tracked quantities: false negatives, false positives, manual-review rate, and performance by product or condition. Production examples marked incorrect by operators provide a way to confirm degradation because a model can assign high confidence to an incorrect prediction [S1].
One drift study described a model falling from 98% accuracy at launch to approximately 90% six months later, while a peer-reviewed study of 128 model-dataset combinations reported measurable temporal degradation in 91% of cases [S3]. These figures illustrate why production monitoring matters, but they are not acceptance thresholds for every installation.
Monitor input drift by product variant, supplier, shift, lighting condition, camera, and material lot. Monitor concept drift by comparing model predictions with reviewed labels when the correct status changes [S3]. The vision light source should also be controlled because a fixture replacement or seasonal daylight change alters captured pixels without changing the physical product [S3].
Deployment remains continuous rather than one-time work: collect, filter, label, train, benchmark, log, deploy, and monitor in a repeatable loop [S2]. For industrial inspection stations, the compute budget and interruption tolerance affect the design, as covered in How Much Compute Does Real-Time Vision Inspection Need?.
Set Acceptance Criteria Before Training
Write the release criteria before collecting data. At minimum, define the production metric, threshold, required defect coverage, comparison test set, allowable regression, and deployment method. Retraining is justified only when the new dataset and candidate address the observed failure without undermining other classes [S1][S4].
One proposed quality gate requires at least 98% initial model accuracy across all dataset strata, with maintenance accuracy held at or above 95% for 6 months or more [S4]. Treat these as example engineering targets, while field-specific limits must come from defect cost, escape risk, false-alarm load, and inspection coverage.
Before training, rule out hardware, threshold, and workflow causes. A dirty lens, repositioned camera, incorrect industrial barcode scanner setting, changed confidence threshold, or modified pass/fail rule can resemble model drift but requires no retraining [S1]. After a genuine product change, close the loop with reviewed failure examples and release only a candidate that beats the deployed model on the agreed metrics [S1][S2].