第 2 部：從 Notebook 到 Endpoint，瞭解 Amazon SageMaker 的機器學習工作流程

In Part 1, I wrote about how I started looking at Amazon SageMaker as more than just a place to train machine learning models.

The next thing I wanted to understand was simple:

How does a model actually go from an experiment to something an application can use?

As a software engineer, the workflow felt much more familiar once I compared it to taking code from development to production.

Let's walk through it.

1. Start With the Data

Every ML model starts with data.

Imagine we want to predict whether a customer might cancel a subscription. We could have historical data such as:

Subscription Type
Months Active
Monthly Usage
Support Requests
Cancelled

Before training anything, that data needs to be prepared. This might include cleaning missing values, selecting useful features, and splitting the data into training and testing sets.

The basic idea is simple: better input data gives the model a better chance of learning useful patterns.

2. Experiment

Next comes experimentation.

SageMaker provides notebook environments where we can explore data and test different approaches.

A very simple example might start with:

import pandas as pd

data = pd.read_csv("customers.csv")

print(data.head())

At this stage, we're exploring the data and trying different ideas.

I think of this a lot like local development.

The main question is:

Can we make this work?

But something working in a notebook doesn't mean it's ready for production.

3. Train the Model

Once we have an approach, we can train the model.

Historical Data
      ↓
   Training
      ↓
 Trained Model

SageMaker can run training jobs using managed compute resources.

This separation is useful because the notebook can remain our workspace for experimentation while the actual training happens separately.

4. Evaluate It

A successful training job doesn't necessarily mean we have a good model.

We still need to evaluate the results.

Depending on the problem, we might look at metrics such as:

• Accuracy
• Precision
• Recall
• F1 score

This part feels similar to testing software.

Code compiling successfully doesn't mean we should deploy it.

The same applies to ML.

The question isn't just:

Did the model train?

It's:

Does it perform well enough for what we're trying to do?

5. Manage the Model

As teams experiment, they may end up with several model versions.

Model v1
Model v2
Model v3

At that point, we need to know which model performed best, which version is approved, and which one is running in production.

This is where model versioning and registration become useful.

The idea isn't too different from managing software releases. We want some control over what gets promoted to production.

6. Deploy the Model

This was the part that made the overall workflow click for me.

A trained model sitting in storage isn't very useful to an application.

The application needs a way to send data to the model and get a prediction back.

SageMaker can deploy a model behind an inference endpoint.

Conceptually, it looks like this:

Application
     ↓
SageMaker Endpoint
     ↓
     Model
     ↓
 Prediction

For a software engineer, this starts to feel familiar.

The application sends input to an endpoint and receives a result back.

The implementation is different from a traditional API, but the interaction is easy to understand.

7. Monitor What Happens Next

Deployment isn't the end.

Once a model is running in production, we still need to think about:

• Reliability
• Latency
• Scaling
• Cost
• Monitoring

ML systems also have another challenge: the data can change over time.

A model trained using yesterday's patterns may not perform the same way as user behavior and real-world data change.

So the workflow becomes a cycle:

Prepare Data
     ↓
Train
     ↓
Evaluate
     ↓
Deploy
     ↓
Monitor
     ↓
Improve
     ↓
Repeat

The Connection to Software Development

This comparison helped me understand the bigger picture.

A typical software workflow might look like:

Code → Build → Test → Deploy → Monitor

An ML workflow might look like:

Data → Train → Evaluate → Deploy → Monitor

They aren't the same, but the engineering mindset is similar.

Getting something to work is only one step. Making it reliable in production is the bigger challenge.

Where SageMaker Fits

SageMaker provides tools across different parts of this lifecycle:

Data & Experimentation
        ↓
     Training
        ↓
 Model Management
        ↓
    Deployment
        ↓
    Monitoring

That's why I find it more useful to think of SageMaker as a platform around the ML lifecycle, rather than simply a service for training models.

Final Thoughts

My biggest takeaway is:

Training a model is not the same as building an ML system.

The model is only one part.

We still need to prepare data, evaluate results, manage versions, deploy safely, and monitor what happens in production.

For software engineers getting started with ML, understanding this workflow is a useful first step. You don't need to become a data scientist to understand how a model fits into a production application.

In Part 3, I'll go one level deeper and look at what happens when we deploy a model behind a SageMaker endpoint.

If you're learning SageMaker too, I'd be interested to hear which part of the ML workflow took the longest to click for you.