Anatomy of an ML Pipeline

A model that scores 95% accuracy in a notebook on your laptop is not a product. Between that promising result and a system your users can trust sits a series of steps that most beginners underestimate: getting the right data, cleaning it, shaping it, training, testing, shipping, and then watching the model in the wild so it does not quietly rot. That series of steps is the ML pipeline, and the exam expects you to name its stages, tell the confusable ones apart, and understand why it never really ends. This lesson walks the whole path once, end to end.

Picture one concrete goal to anchor every stage: a bank wants a model that predicts which customers are about to close their accounts, so it can reach out before they leave. We will follow that churn model from raw data to production.

The pipeline at a glance

The pipeline has a natural order, and the order matters: each stage depends on the one before it, and you cannot skip ahead.

Read it in three chunks. First you prepare the data (collection, EDA, preprocessing, feature engineering). Then you build the model (training, tuning, evaluation). Then you run it in production (deployment, monitoring). And monitoring loops back to the start. Now let us walk each stage with the churn model in hand.

Preparing the data

Data collection comes first because a model can only learn from what you feed it. For the churn model, that means gathering account history, transaction records, support tickets, and login activity, then pulling them into one place. The rule that governs this whole phase: garbage in, garbage out. No later stage can rescue a model trained on the wrong or missing data.

Exploratory data analysis (EDA) is the stage where you look before you leap. Before changing a single value, you explore what the data actually contains: how many accounts you have, which fields are missing, whether "balance" is sometimes negative, whether churned customers are rare (they usually are). EDA does not transform the data. It builds your understanding of it, and that understanding shapes every decision that follows.

Data preprocessing is the cleaning stage. Real data is messy: missing values, duplicate rows, inconsistent formats ("USA" vs "U.S." vs "United States"), obvious errors like an age of 200. Preprocessing fixes these so the data is consistent and usable. You fill or drop missing values, standardize formats, and remove bad records.

Feature engineering is where you build the actual inputs the model will learn from, called features. This is not cleaning; it is creation. From a raw "last login" timestamp you might derive "days since last login." From a year of transactions you might compute "average monthly spend" and "spend trend over the last 3 months." Good features are often what separates a mediocre model from a strong one, because they hand the algorithm the signal in a form it can use.

These three data stages get confused constantly, so pin the distinction now. EDA is understand, preprocessing is clean, feature engineering is create. A missing value: EDA notices it, preprocessing fills it, feature engineering has nothing to do with it. That minimal example separates all three.

Building the model

Model training is the stage most people picture when they think of machine learning, though by now you can see it is only one step of many. You feed the prepared data to an algorithm, and it learns the patterns that link the features to the outcome (here, the features to "churned or stayed"). The output is a trained model.

Hyperparameter tuning adjusts the settings that control how training happens. These are not learned from the data; you set them. Think of the number of layers in a network or how fast the model adjusts during training. Tuning tries different combinations to find the ones that produce the best model, often automatically. It is dialing in the knobs on the training process, not on the data.

Evaluation is the honesty check. You measure the model on data it has never seen during training, a held-out test set, because a model that memorized its training data can look perfect and still fail on real customers. If the churn model catches only 40% of the customers who actually leave, evaluation is where you find out before your users do. The next lesson on metrics goes deep here; for now, know that evaluation is the gate between "trained" and "trusted."

Running in production

Deployment puts the model to work. You make it available so the rest of the bank's systems can send it a customer and get back a churn score, whether through an always-on endpoint answering in real time or a nightly batch job scoring every account at once. The following lesson covers those deployment choices in detail.

Monitoring is the stage beginners forget, and it is where models quietly fail. A churn model trained on last year's behavior can slowly lose accuracy as customers change, the economy shifts, or the bank launches new products. This is called drift. Monitoring watches the live model, so you catch the decay and act, usually by collecting fresh data and retraining. That is the arrow that loops back to the start.

Here is the misconception to kill: that shipping the model is the finish line. It is not. A deployed model is a perishable asset. The pipeline is a loop, not a line, because the world the model describes keeps moving, and a model that is never retrained is a model slowly going out of date.

Exam tips

• Know the stage order and be ready to place an activity in it. "Plotting distributions to understand the data" is EDA; "filling missing values" is preprocessing; "creating a days-since-last-purchase field" is feature engineering.
• The most common trap is blurring EDA, preprocessing, and feature engineering. Fix the verbs: understand, clean, create. A stem that describes cleaning is preprocessing, even if it uses the word "prepare."
• "The model's accuracy dropped three months after launch" is a monitoring-and-drift scenario, and the fix is retraining, not re-deploying the same model.
• Watch for answers that treat deployment as the last stage. Monitoring comes after, and the pipeline loops back to data.

Carry one picture out of this lesson: data in, model out, production, and back to data again. Every AWS service in the next lessons plugs into one of these stages, and MLOps (later in this topic) is the discipline of running this whole loop reliably and repeatedly. Next you will see where those models come from and how you actually put them into production.