You trained a model, got 95% accuracy on the test set, and shipped it to production. A month later, the business comes back with a question: "Why have the recommendations turned to nonsense, and why is the demand forecast off by 40%?" Sound familiar? This isn't a rare glitch but a typical situation faced by almost everyone deploying machine learning. In this article, we'll break down why a model that shows excellent test metrics falls apart in real-world operation, how to spot the problem in advance, and what to do if it's already too late. And we'll also look at how this is taught in the TensorFlow + Data Science Professional course. For a deeper dive into this topic, see Vector Databases.
Why a model on the test set is not yet a model in production
The test set and real data are two different worlds. On the test set, you evaluate the model on data that resembles the training data: the same period, the same conditions, the same users. In production, data comes from the future, and its distribution may differ. This is called data drift. The model doesn't know the world has changed and keeps applying old patterns.
Moreover, during data preparation it's easy to introduce data leakage — when features contain information that won't be available at prediction time. For example, you're predicting customer churn and use the feature "number of support requests in the last month." But at prediction time this feature doesn't exist yet — the customer may leave earlier. The model will show 95% on the test set, but in reality it will err because the feature only works on historical data. For a deeper dive into this topic, see A/B Testing That Survives Scrutiny.
Another classic is overfitting: the model has memorized the training set too well, including noise, and doesn't generalize to new data. On a test set that was part of the training data (if you split incorrectly), it will show high accuracy, but on new data it will fail.
A real case study: customer churn prediction
Imagine you're building a model for a telecom company that predicts whether a customer will leave in the next month. You have a year of data: demographics, plan, number of calls, support requests, payments. You randomly split the data into train and test (80/20), train gradient boosting, and get ROC AUC 0.95. Great! You ship it to production.
A month later, it turns out the model is wrong in 30% of cases. Why? Let's find out.
Step 1. Check the split. A random split for time-based data is a gross mistake. If you have a year of data and you shuffled it randomly, the test set may contain records from January while the train set has December. But customer behavior changes over time: more calls in winter, fewer in summer. A model trained on all months except one will use future data to predict the past. This is future leakage. The correct approach is a time-based split: train on the first 9 months, test on the last 3.
Step 2. Check for target leakage. You use the feature "average bill for the last month." But if a customer left, their bill in the last month before leaving may have dropped. This feature indirectly contains information about the target. In production, you predict churn in advance, when the bill hasn't dropped yet. The model on the test set sees this feature and shows high accuracy, but in reality it doesn't.
Step 3. Data drift. After launch, the model runs for a month. During this time, the company launched a new promotion, and customers started calling more. The feature "number of calls" has shifted. The model trained on old data doesn't account for this shift and errs.
Step 4. Lack of monitoring. You don't track metrics in production. You learn about the problem from the business when customers have already left.
Where else it breaks: typical failure scenarios
1. Overfitting on small data
If there's little data, the model easily overfits. Sign: accuracy on train 99%, on test 70%. Solution: simplify the model, add regularization, collect more data, or use augmentation.
2. Incorrect validation for time series
For time series, you can't use k-fold cross-validation with random shuffling. You need TimeSeriesSplit — when training is on the past and validation is on the future. Otherwise, you'll get an optimistic estimate and future leakage.
3. Concept drift
Even if the feature distribution hasn't changed, the relationship between features and the target can change. For example, you're predicting purchase probability, and suddenly fashion changes: what was once liked is no longer liked. The model won't notice this.
4. Leakage through ID or service fields
Sometimes data contains identifiers that are indirectly related to the target. For example, a customer ID, if it's assigned sequentially and customers with large IDs are new ones who churn more often. The model may use the ID as a feature and overfit.
5. Lack of drift monitoring
Without monitoring, you won't know the data has changed until it's too late. You need to track the distribution of key features and model metrics.
How to spot the problem in advance
Here are a few practical steps to help identify problems before the model falls apart.
1. Check the split. For time-based data, use a chronological split. Make sure the train set contains no data from the future relative to the test set.
2. Analyze feature importance. If a feature has abnormally high importance, check whether it contains leakage. For example, the feature "number of days since last contact" may be a consequence of churn, not a cause.
3. Compare train and test distributions. Use statistical tests (e.g., the Kolmogorov-Smirnov test) for numerical features and chi-square for categorical ones. If the distributions differ significantly, the data may be non-stationary.
4. Set up drift monitoring. In production, regularly compare the distribution of input features with the training set. If drift exceeds a threshold, trigger retraining.
5. Validate on a holdout set. Keep a separate dataset that is used neither for training nor for hyperparameter tuning. Use it for final validation.
Paths to mastering Data Science and MLOps
If you've realized your models suffer from these problems, there are several ways to deepen your knowledge.
Self-study — free but requires discipline. You read documentation, articles, watch lectures. Risk: you may miss important details, and there's no one to discuss mistakes with. Time: from several months to years.
Practice on real projects — the most effective way, but requires access to data and the opportunity to make mistakes. In a company, you can learn from your mistakes, but the cost of a mistake can be high.
Structured courses — provide a system and feedback. For example, the TensorFlow + Data Science Professional course is built around practical tasks: you don't just study theory but work through specific cases with leakage, data drift, and monitoring setup. This helps you see typical mistakes and learn to avoid them.
Trade-off: self-study is cheaper but may take more time and lead to gaps. Courses cost money but save time and provide feedback. Practice in a company is the best option but isn't always available to beginners.
Who this path suits and who it doesn't
This material and course will be useful if you're already familiar with the basics of machine learning but want to learn how to deploy models to production and avoid typical mistakes. If you're just starting, you should first master basic algorithms and Python.
The course isn't for those looking for a magic pill: deploying ML requires attention to detail and a willingness to dig into data. It also doesn't replace practice on real projects — but it provides tools that will help you go through that practice more successfully.
In closing, I want to say: if you're tired of models not working in production and want to understand how to build reliable ML systems, check out TensorFlow + Data Science Professional. The course covers these problems with concrete examples and helps you develop the habit of checking data for leakage and drift before launch. For a deeper dive into this topic, see Observability in Production.