ML 全流程 — 从数据到上线

这套系统做了什么？

真实数据 → 真实训练 → 真实模型 → 真实预测 → 真实监控
   ↑          ↑          ↑          ↑          ↑
California  sklearn    ONNX/JSON   Go HTTP   Prometheus
Housing    3种算法    NFS存储      0.3ms延迟   实时指标
20640条                K8s CRD

不是模拟。每一步都在 K8s 集群上真实运行。

第一章：数据 — 一切的起点

什么是机器学习？

传统编程：人写规则 → 程序执行

if income > 100000 and location == "SF":
    price = 500000

机器学习：数据写规则 → 程序学习

给模型 20000 条 (特征, 房价) 数据
模型自己找出: 收入、位置、房龄 如何影响房价

我们用的数据集：California Housing

sklearn 内置，20640 条加州房屋数据（1990 年人口普查）：

特征含义示例值为什么重要
MedInc街区中位数收入（万美元）3.5收入越高的区域房价越高
HouseAge房屋中位数年龄25新房 vs 老房
AveRooms户均房间数5.2房子大小
AveBedrms户均卧室数1.1卧室占比
Population街区人口1200人口密度
AveOccup户均居住人数3.0拥挤程度
Latitude纬度37.5地理位置（越北越贵？不一定）
Longitude经度-122.0地理位置（沿海 vs 内陆）

目标变量（Target）： 房价中位数，单位 $100,000。值 2.5 = $250,000。

为什么选这个数据集？

候选为什么选/不选
California Housing ✓20640 条够大、8 特征够复杂、CPU 秒级训练、真实数据
Iris150 条太小，什么都学不到
Boston Housing已被 sklearn 弃用（含种族相关变量，有伦理争议）
MNIST图像数据，CPU 训练慢，不是我们的场景

第二章：特征工程 — 让数据适合模型

训练集/测试集分割

X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2)
# 80% 用来训练 (16512 条)
# 20% 用来测试 (4128 条)

为什么要分？ 防止"作弊"。如果用全部数据训练又用全部数据评估，模型可能只是"背答案"（过拟合），遇到新数据就不行。测试集模拟"从未见过的数据"。

标准化（StandardScaler）

scaler = StandardScaler()
X_scaled = scaler.fit_transform(X)  # 每个特征: (x - 均值) / 标准差

为什么要标准化？

原始数据范围差异巨大：

  • MedInc: 0.5 ~ 15 (收入)
  • Population: 3 ~ 35682 (人口)

如果不标准化，Population 的数值大几千倍，线性回归会认为它"更重要"——这是错的，仅仅是单位不同。

标准化后所有特征都在 [-3, 3] 范围内，模型公平对待每个特征。

重要细节： fit_transform(X_train) 是用训练集算均值和标准差，transform(X_test) 是用训练集的参数转换测试集。不能用测试集的统计量——那等于"偷看答案"。

第三章：模型训练 — 三种算法对决

1. 线性回归（LinearRegression）— 基线

y = w₁·MedInc + w₂·HouseAge + ... + w₈·Longitude + b

就是一条多维直线。简单、快速、可解释，但假设特征和目标是线性关系。

我们的结果： R² = 0.576（57.6% 的房价变化被解释）

2. 随机森林（RandomForest）— 集成

100 棵决策树，每棵用不同的数据子集训练，最终取平均。

树1: 如果 MedInc > 5 且 Latitude < 38 → 预测 3.2
树2: 如果 AveRooms > 5 且 HouseAge < 20 → 预测 3.5
...
最终预测 = (3.2 + 3.5 + ... ) / 100

Bagging（装袋）： 每棵树看不同的数据，减少过拟合。

我们的结果： R² = 0.774

3. 梯度提升（GradientBoosting）— 冠军

也是多棵树，但依次训练。每棵新树专门纠正前面树的错误：

树1预测: 3.0 (实际 3.5, 误差 +0.5)
树2专门学习误差: 预测误差 0.3 (还差 0.2)
树3再学剩余误差: 预测误差 0.15
...
最终 = 3.0 + 0.3 + 0.15 + ... ≈ 3.5

Boosting（提升）： 每一步针对性地改进。

我们的结果： R² = 0.811（最优！）

评估指标

指标公式我们的值含义
MAE平均|预测-实际|0.335 ($33,500)平均偏差 3.3 万美元
RMSE√(平均(预测-实际)²)0.498 ($49,800)惩罚大偏差
R²1 - 残差方差/总方差0.81181.1% 房价变化被解释

第四章：模型导出 — ONNX 与 JSON

为什么不直接用 Python 做推理？

Python 推理Go 推理
内存占用50-100MB（numpy/sklearn）5-10MB
并发GIL 限制，需多进程goroutine 原生并发
启动时间2-5 秒（import 库）50ms
部署Python 环境 + 依赖单个二进制文件

生产中的标准做法： Python 训练 → ONNX/TorchScript 导出 → Go/C++/Rust 推理。

我们的导出格式

ONNX（Open Neural Network Exchange）： 跨平台模型序列化格式。Python 训练的模型可以在任何 ONNX Runtime（Go/C++/Java/C#）中运行。

JSON 参数： 对于线性回归，模型就是 weights 和 intercept。直接存 JSON，Go 纯代码实现预测数学：

// model_params.json
{
  "weights": [0.8296, 0.1179, -0.2654, ...],  // 8个权重
  "intercept": 2.0719                          // 截距
}

// scaler_params.json  
{
  "mean": [3.8706, 28.6394, ...],   // 8个均值
  "std": [1.8998, 12.5856, ...]     // 8个标准差
}

Go 预测代码核心（6 行）：

// 标准化
for i, x := range features {
    scaled[i] = (x - scaler.Mean[i]) / scaler.Std[i]
}
// 预测: y = Σ(xi * wi) + b
prediction := model.Intercept
for i, x := range scaled {
    prediction += x * model.Weights[i]
}

第五章：K8s 部署 — Operator 模式

为什么用 CRD + Operator？

传统方式：手动创建 Deployment + Service + HPA + ConfigMap...

Operator 方式：

apiVersion: ml.k8s-lab.io/v1alpha1
kind: MLModel
metadata:
  name: housing-model-v1
spec:
  modelPath: /models/housing-model-v1.onnx
  version: "v1"
  replicas: 2

一个 CR 搞定。Operator 自动创建 Deployment + Service，自动管理生命周期。

我们的 MLModel CRD

kubectl get mlmodel -n ml-platform

NAME               VERSION   TYPE               PHASE     REPLICAS   READY   ENDPOINT
housing-model-v1   v1        GradientBoosting   Serving   2          2       housing-model-v1-svc.ml-platform.svc:8080

Operator 做了什么？

1. Watch 到 MLModel CR 创建
2. 创建 Deployment: 2 副本推理容器，挂载 NFS 模型文件
3. 创建 Service: ClusterIP，端口 8080
4. 持续监控: Deployment Ready 后更新 MLModel 状态为 "Serving"
5. 级联删除: 删 MLModel → 自动删 Deployment + Service

第六章：真实预测 — 验证结果

测试 1: 旧金山湾区高收入区

输入: {"features": [8.3, 20, 6.0, 1.0, 1500, 3.0, 37.78, -122.42]}
输出: {"prediction": 4.1596, "price_usd": "$415,957", "latency_ms": 0.392}

MedInc=8.3（高收入），旧金山坐标 → 预测 $416K。合理！

测试 2: 洛杉矶内陆低收入区

输入: {"features": [2.5, 35, 4.5, 1.2, 3000, 4.5, 34.05, -118.25]}
输出: {"prediction": 1.7937, "price_usd": "$179,366", "latency_ms": 0.176}

MedInc=2.5（低收入），LA 内陆 → 预测 $179K。合理！

推理性能

  • 延迟: 0.2-0.4ms（纯 Go + 简单线性运算）
  • 内存: Pod 约 5MB
  • 并发: Go 原生支持数千并发请求

第七章：行业对比 — 我们造了什么轮子？

我们的组件行业工具区别
train.pyMLflow / Kubeflow PipelinesMLflow 管理实验、模型版本；我们手写理解本质
MLModel CRDKServe InferenceServiceKServe 支持 TF/PyTorch/ONNX 自动推理；我们手写 Operator
Go inferenceTriton / TF ServingTriton 支持多框架、动态 batching；我们理解核心逻辑
NFS 模型存储S3 / Model Registry生产用对象存储；我们用 NFS 简化

学习价值： 理解了这些组件在做什么之后，使用 KServe/MLflow 等工具时就不是"黑盒调用"，而是知道底层在干什么。

完整架构图

┌──────────────────────────────────────────────────────┐
│                    ML Platform                        │
│                                                       │
│  ┌─────────────┐    ┌──────────────┐   ┌───────────┐ │
│  │ Training Job │    │ MLModel CRD  │   │ Inference │ │
│  │ (Python)     │───→│ (K8s 资源)   │──→│ (Go)      │ │
│  │ sklearn      │    │ version,path │   │ HTTP API  │ │
│  │ 3种算法      │    │ replicas     │   │ 0.3ms     │ │
│  └──────┬───────┘    └──────┬───────┘   └─────┬─────┘ │
│         │                   │                  │       │
│         ▼                   ▼                  ▼       │
│  ┌──────────────┐    ┌──────────────┐   ┌───────────┐ │
│  │ NFS Storage  │    │ Go Operator  │   │Prometheus │ │
│  │ model files  │    │ Reconcile    │   │ 指标采集   │ │
│  │ JSON params  │    │ Deploy+Svc   │   │ Grafana   │ │
│  └──────────────┘    └──────────────┘   └───────────┘ │
└──────────────────────────────────────────────────────┘