Production ML Is a System, Not a Model

A data scientist shows a notebook with a model that scores 94% on held-out data. Six months after launch, the feature is doing worse than the rule it replaced, nobody is sure why, and the person who built the model has moved teams. Nothing was wrong with the model. What failed was everything around it. This is the half of AI system design that has nothing to do with large language models, and it is the half interviewers probe hardest.

A great recipe does not make a great restaurant. The restaurant also needs reliable suppliers, a kitchen line that can serve a full dining room on a Friday night, a thermometer to catch a failing fridge, and a way to hear from customers. A model is the recipe. The data pipelines are the suppliers, the serving system is the kitchen line, monitoring is the thermometer, and user feedback is the reviews. Most of a restaurant's work, and most of an ML system's, is not the recipe.

• -Goal and metric: what the business wants, and how you will know you got it.
• -Data and labels: where examples come from and what counts as the right answer.
• -Features: the numbers the model sees, which must be available at prediction time.
• -Training and offline evaluation: fitting the model and measuring it on held-out data.
• -Serving: returning predictions fast enough, reliably, with versions you can roll back.
• -Monitoring: noticing when data or behavior changes, then retraining or fixing.

A paper from Google researchers, widely cited under the title "Hidden Technical Debt in Machine Learning Systems", argues that ML systems are easy to build and expensive to maintain. Models become entangled with their input features, other teams start depending on a model's output without telling anyone, and a model's predictions can quietly change the data it will later learn from. The rest of this module is about keeping those costs down.

Google's Rules of Machine Learning guide opens with advice that surprises beginners: do not be afraid to launch a product without machine learning, and keep the first model simple while you get the infrastructure right. A simple rule gives you a baseline to beat and a working pipeline to build on. A model that cannot beat a rule is not worth its upkeep.

The block below puts numbers on that. An online store flags risky orders for a person to review. A simple rule flags orders over $500. A model catches more fraud at better precision but costs $4,000 a month to run. The dollar figures are invented. Press Run, and compare the last column across the three rows, where only the volume of orders or the fraud rate changes.

With 200,000 orders and a 0.50% fraud rate, the model earns $37,571 a month more than the rule. Cut the fraud rate to 0.05%, or cut the order volume to 20,000, and the gain falls to $157. The model is just as accurate in all three rows. What changed is how much there is to catch. ML earns its keep where the volume is large, the rule leaves a lot on the table, and a wrong decision is costly.

In an interview, and in real work, say these three things out loud before you name a model.

• -The business goal: reduce money lost to fraud without annoying honest customers.
• -The metric that measures it: dollars of fraud loss per 1,000 orders, plus the share of good orders that get blocked.
• -The prediction task: for each new order, estimate the chance it is fraud, then flag it if the chance is above a threshold.

The task is only a means. If the metric does not move, the model has not done its job, however good its accuracy looks. Naming the layers also exposes the decision hidden inside the task: someone must choose the threshold, and that choice trades fraud losses against friction.