Guide-linked quiz · Hard Level
Online and Offline Feature Serving Skew Quiz
Practice identifying feature-serving skew, point-in-time leakage, and freshness mismatches between historical training data and live requests.
Question 1 of 8
What is training/serving skew?
Preview every question8 questions
Answers and explanations appear as you take the quiz.
- What is training/serving skew?
- When a model is trained on a GPU but served on a CPU
- When a model is too large to fit in memory
- When the features computed offline during training differ from those served online in production
- When training takes longer than expected
- When building a historical training row, which feature timestamps should a point-in-time join allow?
- Values available at or before that row’s prediction time
- Values recorded only after the outcome
- The latest values regardless of historical time
- Only values from the next calendar month
- Which of the following is a classic cause of inflated offline accuracy that collapses in production?
- Using too few training examples
- Training on a faster machine than serving
- Storing features in a database
- Data leakage, where training uses information not available at prediction time
- A logged live feature distribution differs from training. What should the feature-serving team infer first?
- The serving code is certainly defective
- There is a mismatch to investigate; it may be drift or serving skew
- The feature has no predictive value
- The model must be running on different hardware
- Why is a cached online feature like 'orders in the last hour' a skew risk?
- The cached value can go stale and no longer match the freshly computed value used in training
- Caching always improves model accuracy
- Caching makes the feature impossible to compute offline
- Cached features cannot be numerical
- Why share one feature definition across batch training and online serving?
- To guarantee every cached value is fresh
- To eliminate changes in incoming populations
- To make timestamp checks unnecessary
- To reduce differences caused by separate transformation implementations
- A transaction model uses a chargeback flag recorded days after purchase. Why is its offline feature join invalid?
- The flag is categorical rather than numerical
- The flag was unavailable when the purchase prediction was made
- Chargeback flags cannot be stored historically
- Only GPU models may use transaction features
- Training recomputes a one-hour order count, but serving reads a ten-minute-old cached count. Which check targets this skew?
- Increase the number of model parameters
- Remove all timestamps from the feature store
- Compare counts for matching entities and times while recording cache freshness
- Switch both paths to a different programming language
Keep testing yourself
More quizzes picked for your level.