A bike-share cancellation model includes a column named refund-processed-at. That timestamp is written only after a reservation is already canceled. Lab scores look perfect, then new reservations score poorly. What problem is this?
Select an answer to reveal the explanation.
Short Explanation
Think of peeking at the final exam answer key while you study. A refund timestamp that only appears after cancel is future information the model would not have at reservation time. That is leakage, not a missing GPU, and a perfect lab score is the opposite of underfitting.
Full Explanation
Including a column named refund-processed-at—a timestamp written only after a reservation is already canceled—lets the bike-share cancellation model peek at post-event information during training, which is data leakage. Leakage fits because that feature would not exist at reservation-time prediction, so lab scores look perfect while new live reservations, which lack the future timestamp, score poorly. Underfitting cannot explain a perfect lab score; underfitting is failure to learn the pattern on training data, the opposite of glowing in-sample results. Blaming a missing GPU confuses a data-design flaw with hardware capacity; accelerators do not fix features that encode the future. Treating a post-cancel timestamp as healthy monitoring input is wrong because monitoring and scoring should use features available at prediction time, not outcomes that appear only after cancellation is already known. Any column that is a consequence of the label is a leakage suspect even when it looks brilliantly predictive offline. Exam caveat: features that appear only after the decision point inflate lab metrics and collapse in production—drop them before celebrating the score. Operational check: for every candidate column, ask whether it is known at reservation time; drop refund-processed-at and similar post-event fields, retrain, and re-evaluate on a time-based holdout that mimics live scoring.