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?

Training-serving skew occurs when feature values used during model training differ from feature values provided during real-time inference. The centralized feature store is the appropriate MLOps component because it acts as a central repository for storing and serving curated features. It typically uses 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 feature definition, it guarantees feature consistency between training and serving.

The code repository version control system is not the right solution because version control systems, such as Git, manage application source code, not feature data values. The centralized model registry is not the right solution because a model registry stores, versions, and manages trained machine learning model artifacts, not feature variables. The orchestration engine is not the right solution because orchestrators, such as Apache Airflow or Prefect, manage and schedule pipeline workflows rather than storing and serving features.