A model performs well in evaluation and poorly in production. What are the likely causes?

What is being tested

Whether you know the failure modes specific to machine learning systems, which differ from ordinary software failures.

The likely causes, most common first

1. Training-serving skew. A feature computed one way in training and differently at serving. The model receives inputs with a different distribution from those it learned on, and the failure is silent — no errors, just worse predictions.

This is the most common and most damaging cause, and it is what a feature store — or at minimum shared computation code between training and serving — exists to prevent.

2. Data leakage in training. A feature that was available at training time but is not available at prediction time, or one that encodes the answer. Evaluation looks excellent because the model was given information it will never have in production.

3. Distribution shift. The world changed between the training data and now. Seasonal effects, a product change, a competitor action, a shift in user behaviour.

4. The evaluation set was not representative. Randomly split from historical data when the real distribution is temporal — evaluating on the past while predicting the future.

5. Feedback loops. The model's own predictions change the behaviour it is predicting, which evaluation on static data cannot capture.

6. Latency-driven degradation. The serving path drops a slow feature, or uses a stale cached value, so production inputs differ from evaluation inputs in a way nobody documented.

What the platform must provide to make this diagnosable

• Shared feature computation between training and serving. The single highest-value component.
• Reproducibility — given a model, identify the code, data, parameters and environment that produced it. Without it, this investigation cannot start.
• Drift monitoring on input distributions, prediction distributions and, where feedback exists, outcome quality. This is the failure mode specific to ML: degradation without errors.
• Shadow evaluation — run the new model alongside the current one on production traffic before switching.

The architectural point

Deploy models with the same rigour as any service: canary, comparison against the incumbent, automated rollback. A model is a component whose behaviour degrades silently, which argues for more deployment discipline than ordinary code, not less.