A public-health department's case-report text classifier begins seeing incoming reports that look statistically different from its training corpus after a new intake form rolls out. Which monitoring capability is needed to catch this?
Select an answer to reveal the explanation.
Short Explanation
A new intake form can quietly change the vocabulary and structure of every report flowing in, even though nothing crashes or errors out. Input-distribution drift detection is built to notice exactly that kind of statistical shift between what's coming in now and what the classifier trained on. Catching that shift early keeps classifications trustworthy after a form redesign.
Full Explanation
Input-distribution drift detection compares statistical properties of incoming text, vocabulary, length, structure, feature distributions, against the training-data baseline, flagging a meaningful shift like the one a new intake form would introduce, even though the classifier keeps returning normal, error-free responses throughout. A raw volume counter tracks how many reports arrive per hour, useful capacity information, but it says nothing about whether the content of those reports still resembles what the model learned from. An HTTP-error alarm catches outright failures, malformed requests, timeouts, service errors, and a well-formed report submitted through the new form still gets a clean response even if the classifier is now working from shifted, less-familiar input patterns. Extending log retention preserves historical data for later analysis but is a passive archival step, not an active detection mechanism, so it does nothing to surface the drift as it happens. Scope caveat: drift detection flags a statistical change, not necessarily an accuracy drop, so a flagged shift after a form redesign should be paired with a sample accuracy check before triggering retraining. A concrete operational check: pull a sample of post-rollout reports and confirm which features, field length, new terminology, are driving the flagged drift.