MLOps: Start Here

#From Notebook to Product

Imagine you cook a very good dish at home. You tasted it, you liked it, and you wrote the recipe down. That is a model in a notebook: it worked on the data you had, on the day you tried it.

You already know what a model is: a rule, learned from past examples, that turns some numbers about a case into a prediction. In this lesson the model is deliberately tiny. It guesses whether a customer of a phone plan is about to leave. A tiny model lets you do every step by hand, and the steps are the same for a huge one.

In one sentence: MLOps is the running work that keeps a model useful after the notebook, like running a kitchen is different from cooking one dish.

#One Prediction's Journey

• score = 2 x calls + 3 x late - 0.5 x months
• If the score is 4 or more, the answer is "leaves". Otherwise it is "stays".

These numbers are made up for the exercise. A real model would learn them from thousands of past customers. What matters here is the journey, which has six stops.

1. Request. Something outside asks: "what about this customer?"
2. Check. Look at the request before using it. Is anything missing? Is any number impossible?
3. Features. Turn the request into the numbers the model expects. Here the three numbers are already the features.
4. Model. Do the sum and compare with the cutoff.
5. Answer. Send the answer back.
6. Log. Write down what came in and what went out, so that later you can look back.

Be the service. A request arrives: calls = 2, late = 1, months = 6.

Now a second request arrives with months = -3. A customer cannot have been with the plan for minus three months. At stop 2 the check sees a negative number and stops the journey. The service answers "rejected" and logs the reason. It did not guess. That one line of checking saved a nonsense score being sent to a real person.

The picture shows that the model is only stop 4. Five of the six stops are not the model at all. That is the first big idea of this lesson: in a product, most of the work is around the model.

In one sentence: a prediction makes a six-stop journey, and the model is only one of the stops.

#The Answer Arrives Later

When labels arrive, you match each one to the line in your log and mark the answer right or wrong. Suppose five answered requests get their labels:

Four of five are right, so the accuracy of this batch is 4 / 5 = 0.8, or 80 out of 100. Request r4 is not in the table: it was rejected, so it has no answer to check.

This is where the log pays off. Without the log you could not match anything.

In one sentence: the true answer arrives later, so you log every answer, match labels when they come, and alert when the measured accuracy crosses the line you set.

#Run the Journey

Do: Run the cell once. Then add a request r7 with the key "late" left out, and run again. Last, change the alert line from 0.75 to 0.85.

Notice: r1 gives leaves, the same as your hand trace, and r4 is rejected with "months is negative". Four of five checked answers are right, which is 0.8. With the line at 0.75 only week 4 alerts. With 0.85, weeks 3 and 4 both alert.

Why: The check is a few lines, yet it keeps nonsense out of the model. The alert line is a choice a person makes, and moving it changes how early you hear bad news and how often you are woken for nothing. The model here is made-up weights, not a trained one.

In a real service the same shape runs behind a web address, and the model is a file loaded at start-up. The next block shows that shape. It needs a web framework and a server, so it cannot run in the browser. It is a read-only copy for Google Colab or your own computer.

# Copy to Colab (needs the fastapi and uvicorn packages; it cannot run in the browser)
# The same six stops behind a web address.
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI()
MODEL = {"calls": 2, "late": 3, "months": -0.5, "cutoff": 4}


class Customer(BaseModel):
    calls: int
    late: int
    months: int


@app.post("/predict")
def predict(customer: Customer):                      # stop 1: the request arrives
    if min(customer.calls, customer.late, customer.months) < 0:
        raise HTTPException(status_code=422, detail="a number is negative")   # stop 2: check
    score = (MODEL["calls"] * customer.calls            # stops 3 and 4: features and model
             + MODEL["late"] * customer.late
             + MODEL["months"] * customer.months)
    answer = "leaves" if score >= MODEL["cutoff"] else "stays"
    print("log:", customer, score, answer)             # stop 6: log it
    return {"answer": answer, "score": score}          # stop 5: answer sent

Compare the two. The logic is identical. What the web version adds is a way for other programs to ask, and a framework that checks types for you.

In one sentence: the service is a few lines that run the six stops, and the printed log is what lets you compare answers with outcomes later.

#The Loop and Its Five Jobs

Put the pieces together and you get a loop, not a line. A model is built, shipped, watched, and when it goes stale, rebuilt. The lessons in this track each teach one job of that loop.

You do not need to learn all five at once. Read them in order, and keep the six-stop journey in your head as the thing every lesson is secretly about.

Two slips are worth knowing now.

• Judging only on launch day. A good score once says nothing about next month. Plan the weekly check before you ship, not after something goes wrong.
• No log, no learning. If you did not write down what the service answered, labels cannot be matched later and monitoring has nothing to measure.

In one sentence: the work is a loop of build, ship, watch and rebuild, and each later lesson teaches one part of it.

#Where to Go Next

You can now follow a prediction through its six stops and say why a running model needs watching.

• Next: Testing ML Systems: Start Here. It shows three kinds of checks that decide, before a new model ships, whether it is allowed to.
• Then, the story: AI Ops History & Future tells how the field arrived at these habits.
• After that: The ML Production Lifecycle is the full tour of the loop in this lesson.
• Python first: if the code here felt fast, start with Python Setup.

This track has levels. This is the start, Level 0. After it come the pipeline, then shipping and running, then cost and scale, then trust, security and law.

In one sentence: read the testing lesson next, then follow the track in order.

#Key Takeaways

• A model in a notebook is not yet a product, and MLOps is the running work that closes the gap
• One prediction makes six stops: request, check, features, model, answer, log, and the model is only one of them
• The true outcome arrives later, so log every answer and match labels when they come
• A model can go stale with no error and no code change, so you measure accuracy and alert below a line you set
• The work is a loop of build, ship, watch and rebuild

#Quick Check