A financial institution's machine learning team is experiencing discrepancies in model predictions because the offline historical data used for model training is calculated differently than the real-time data streams used during production inference. What MLOps component should they implement to resolve this training-serving skew?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal: you have one team of data scientists training a model offline using old database dumps, and another team writing real-time code for production. If they calculate their features differently—say, one calculates average monthly spend using a 30-day window and the other uses a calendar month—your model is going to behave completely unpredictably. We call this training-serving skew, and it's a massive pain. Enter the feature store. This is a centralized database designed specifically for ML features. It serves the exact same, pre-calculated features to both your training pipeline and your live inference engine. No more recalculating, no more mismatch. It keeps everything perfectly in sync. Trust me, it's essential for any serious MLOps pipeline.
Full explanation below image
Full Explanation
Training-serving skew is a common issue in machine learning production systems, occurring when the feature values used during model training differ from the feature values provided to the model during real-time inference. A feature store is designed specifically to solve this problem. - Option A (A centralized feature store) is correct because it acts as a central repository for storing and serving curated features. It typically features a two-part architecture: an offline store (optimized for retrieving large volumes of historical features for batch training) and an online store (optimized for low-latency retrieval of the latest feature values for real-time inference). By deriving both datasets from a single definition, it guarantees feature consistency. - Option B (A code repository) is incorrect because version control systems (like Git) manage application source code, not feature data values. - Option C (A model registry) is incorrect because a model registry is used to store, version, and manage trained machine learning model artifacts, not feature variables. - Option D (An orchestration engine) is incorrect because orchestrators (such as Apache Airflow or Prefect) manage and schedule pipeline workflows, rather than storing and serving features.