What is a sound retraining policy based on?
Why B is the answer
Performance thresholds or data changes
A sound retraining policy is based on performance thresholds or changes in the data.
In detail
- Retrain on performance thresholds or data changes.
- Check that retraining pays for itself.
Use case
An illustrative scenario, not a real incident.
A team retrains when accuracy falls below its target, or when inputs shift, rather than on a whim.
See it in different ways
flowchart TD A["Code changes"] --> B["CI: test and build"] B --> C["CD: deploy the pipeline"] D["New data or a trigger"] --> E["CT: retrain the model"] E --> F["Model Registry"]
sequenceDiagram participant B as Cloud Build participant P as Agent Platform Pipelines participant R as Model Registry participant E as Endpoint B->>P: Runs after a change P->>P: Validate data and train P->>R: Register if it passes R->>E: Deploy E-->>P: Retrain on a threshold
flowchart TD
Q{"What does monitoring show?"}
Q -->|"Below threshold"| A0["Retrain"]
Q -->|"Stable"| A1["Wait"]Key point: Retrain on thresholds or data changes.
Why the other options are wrong
- A. A fixed count of new notebooks
- Notebook counts mean nothing.
- C. A retrain after every single prediction
- That is far too often.
- D. Whatever day the team has free
- A free day is not a policy.