Learn the vocabulary of a feature computed differently between a training pipeline and a live serving pipeline.
0 / 5 completed
1 / 5
At standup, a dev mentions a model performing noticeably worse in production than its offline test metrics suggested, traced to a feature being computed differently by the live inference pipeline than it was during training. What is this problem called?
Training-serving skew is a model performing noticeably worse in production than its offline test metrics suggested, traced to a feature being computed differently by the live inference pipeline than it was during training. Model drift describes a model's performance degrading over time as the real-world data distribution genuinely shifts, which is a related but distinct problem from a computation mismatch between two pipelines. This pipeline-to-pipeline inconsistency is exactly what training-serving skew names and diagnoses.
2 / 5
During a design review, the team wants the exact same code and logic to compute a feature for both the training pipeline and the live serving pipeline, rather than maintaining two separate implementations. Which capability supports this?
A shared feature store computes a feature identically for both the training pipeline and the live serving pipeline, using the exact same code and logic rather than two separately maintained implementations that can quietly drift apart. Maintaining two entirely separate implementations leaves the door open for a subtle inconsistency to creep in unnoticed. This shared computation logic is the core architectural fix for eliminating training-serving skew at its source.
3 / 5
In a code review, a dev notices a bug where the training pipeline computes a feature named 'avg_purchase' as an average over the last 30 days, while the online serving pipeline computes the same-named feature as an average over the last 7 days. What does this represent?
A feature-definition inconsistency between the training and serving pipelines, like the same-named feature meaning a 30-day average in one pipeline and a 7-day average in the other, is a textbook cause of training-serving skew, since the model was trained on one distribution of values but sees a different one live. A feature computed identically by both pipelines carries no such inconsistency, which is exactly the goal a shared feature store is meant to achieve. Spotting this kind of naming-versus-definition mismatch in a code review is one of the more effective ways to catch training-serving skew before it reaches production.
4 / 5
An incident report shows a model's live accuracy dropped sharply right after launch despite strong offline test metrics, and the root cause was traced to the serving pipeline computing a key feature differently than the training pipeline had computed the same-named feature. What practice would prevent this?
Unifying feature computation behind a shared feature store or pipeline ensures training and serving always compute the same feature identically, eliminating exactly the kind of inconsistency that caused the accuracy drop in this incident. Continuing to maintain separate implementations for training and serving leaves that same risk open to recur with any future feature. This unification is the standard architectural fix once training-serving skew has been identified as the root cause of a production performance gap.
5 / 5
During a PR review, a teammate asks why the team unifies feature computation behind a shared feature store instead of maintaining separate, independently optimized feature code for the training pipeline and the serving pipeline. What is the reasoning?
Separate, independently maintained feature code can quietly drift into computing the same-named feature differently over time, as each pipeline is updated on its own schedule without the other necessarily being kept in sync. A shared feature store guarantees both pipelines compute the feature identically, since they're both calling the exact same underlying logic. The tradeoff is the added upfront engineering investment of building and maintaining a shared feature store, rather than letting each pipeline's feature code evolve independently.
What does the "Training-Serving Skew Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to training-serving skew vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.