During evaluation, a carnival ticket-fraud model scores almost perfectly on the training weeks and collapses on the validation weeks. The gap appears before go-live. The network that hosts the lab is healthy. What is the team seeing?
Select an answer to reveal the explanation.
Short Explanation
Think of a student who aces the practice packet and bombs a new packet. Glowing training weeks and collapsed validation weeks is overfitting, caught in evaluate. A healthy lab network is not a switch outage, and a high training score is the opposite of underfitting.
Full Explanation
A carnival ticket-fraud model that scores almost perfectly on the training weeks and collapses on the validation weeks—before go-live and on a healthy lab network—is overfitting discovered in the evaluate stage. That diagnosis fits because the model memorized training-week quirks and failed to generalize, which is exactly what a validation split is meant to reveal before tickets go live. Blaming a production networking outage is unsupported when the network that hosts the lab is healthy and the failure is a metric gap on validation data, not packet loss on a switch. Calling it underfitting is backwards: underfitting shows a poor fit on training data, whereas a near-perfect training score shows the opposite problem. Calling the situation successful deployment confuses lifecycle stages; evaluation is not deployment, and live ticket monitoring has not started merely because validation scores exist. The gap appearing before go-live is good news only if the team treats it as a stop sign. Exam caveat: high train / low validation is the classic overfitting signature discovered during evaluate—not a networking story and not underfitting. Operational check: plot train versus validation metrics by week, simplify or regularize the model, add more diverse training weeks if needed, and do not deploy until the validation gap closes to an agreed tolerance.