An emergency management team debugging a flood-prediction model notices training loss oscillating wildly and failing to steadily decrease across epochs, rather than converging smoothly. Which cause is most plausible and directly addressable during training configuration?
Select an answer to reveal the explanation.
Short Explanation
Think of turning a steering wheel too hard while trying to center a car in its lane — overcorrect enough and you swerve past center every time instead of settling in. A learning rate set too high does that to training: each update jumps past the loss surface's minimum instead of easing toward it, producing exactly the wild oscillation described. Dialing the learning rate down is usually the first, most directly addressable fix to try.
Full Explanation
An excessively high learning rate causes each weight update during gradient descent to take too large a step, which can repeatedly overshoot the minimum of the loss surface rather than converging smoothly toward it, producing the oscillating, non-decreasing loss pattern described. This is one of the most directly addressable causes during training configuration, since learning rate is a straightforward hyperparameter to adjust and retest. The option blaming insufficient model capacity describes a different failure mode; an undersized model more typically shows a training loss that plateaus at a mediocre value because it lacks the capacity to fit the data well, rather than the sharp oscillation associated with an unstable optimization step size. The option attributing oscillation to a too-small validation set misattributes cause and effect; validation set size affects how reliably validation metrics estimate generalization, but training loss oscillation is a training-dynamics symptom tied to the optimization process on the training data, not a consequence of validation set sizing. The option claiming unshuffled data is the only possible cause overstates a single factor as exclusive; while unshuffled data with ordering bias can contribute to unstable gradients in some setups, it is far from the only, or even the most common, cause of this oscillation pattern, and learning rate is the more directly diagnosable first suspect. Scope note: after adjusting the learning rate, other contributors like gradient clipping needs or batch size should still be checked if oscillation persists. Operational check: rerun a short training job with a reduced learning rate and confirm the loss curve trends toward steady decline before assuming the fix worked.