What MLOps Actually Is

MLOps is the discipline that keeps a model's behavior reproducible from raw data to a served prediction. It is not a tool or a single pipeline — it is the set of versioned artifacts, automated checks, and promotion rules that let you answer "what is running in production, and why?" without guessing. The weights are only one of those artifacts.

The idea

A notebook model has no memory. It cannot tell you which rows trained it, which commit produced the features, or which dependency upgrade moved the numbers. Production needs four things pinned:

• Data — the exact dataset version, including the train/validation split.
• Code and environment — commit hash, lockfile, container image digest.
• Model — weights plus the preprocessing and config that define them.
• Serving — which model version answered a request, and how to roll it back.

"The model" is therefore not a .pt file. It is weights and a fitted scaler and a label map and a runtime version. Loading the checkpoint alone reproduces nothing.

Production also changes the failure mode. In a notebook a bug raises an exception; in production it silently shifts the input distribution and returns confident nonsense. MLOps exists to convert silent failures into monitored, alertable numbers.

The usual maturity path is manual → scripted → pipeline → automated retraining with gates. Move one step when the current step has already caused a real loss, not before.

Worked example

A churn model's AUC falls from 0.82 to 0.74 over two weeks. Three causes fit that symptom, and each requires different evidence:

Without lineage the only available response is "retrain and hope," which masks the cause and destroys the evidence you needed. With a tracking run attached to the live version, you can compare the serving feature distributions against the training snapshot directly.

In code

from dataclasses import dataclass

@dataclass
class Promotion:
    run_id: str
    auc: float
    incumbent_auc: float
    threshold: float = 0.80

    def decide(self) -> str:
        if self.auc < self.threshold:
            return "reject: below absolute floor"
        if self.auc < self.incumbent_auc:
            return "reject: regression vs incumbent"
        return f"promote {self.run_id}"

The gate is the product. It turns a subjective "looks good to me" into a rule a pipeline can enforce without a human in the loop.

Check yourself

1. Which four artifacts must be pinned to reproduce a single prediction?
2. Why is a silent degradation worse than a crash in production?
3. What evidence distinguishes data drift from a feature-pipeline bug?

Key takeaways

• MLOps is versioning plus gates, applied across data, code, model, and serving.
• A model artifact is weights and preprocessing and config.
• Automate a step only when the manual version has already caused a real loss.