MLOps & Triển khai

MLOps là sự giao thoa giữa Machine Learning, DevOps và Data Engineering: áp dụng các thực hành kỹ thuật phần mềm (versioning, automation, testing, CI/CD, monitoring) vào toàn bộ vòng đời của mô hình học máy. Mục tiêu là biến việc đưa mô hình ra production từ một sự kiện thủ công, mong manh, "chỉ chạy trên máy của tôi" thành một quy trình lặp lại được, tự động và đáng tin cậy.

Một con số hay được trích dẫn trong ngành: khoảng 87% dự án ML không bao giờ lên được production (theo các khảo sát của VentureBeat, Gartner...). Lý do hầu như không phải vì thuật toán kém, mà vì các vấn đề kỹ thuật vận hành:

• Khoảng cách notebook → production: code trong Jupyter viết rời rạc, không đóng gói, phụ thuộc phiên bản thư viện tuỳ hứng, không ai chạy lại được.
• Không tái lập được (reproducibility): không biết mô hình đang chạy được train bằng data nào, tham số gì, commit code nào.
• Training-serving skew: pipeline xử lý feature lúc train khác lúc serve → mô hình dự đoán sai lệch âm thầm.
• Thiếu giám sát: dữ liệu thực tế trôi (drift) theo thời gian, hiệu năng tụt dần mà không ai biết cho tới khi có sự cố nghiệp vụ.
• Không có quy trình cập nhật: retrain và deploy lại là việc thủ công, rủi ro, nên người ta ngại làm.

Vòng đời ML end-to-end (ML lifecycle) là một vòng lặp liên tục chứ không phải đường thẳng:

Sau khi train xong, mô hình (bao gồm các tham số đã học) cần được serialize ra file để tải lại lúc phục vụ. Các lựa chọn phổ biến trong hệ sinh thái Python:

# Lưu & nạp mô hình scikit-learn bằng joblib
import joblib
joblib.dump(model, "model_v3.joblib")      # lưu
model = joblib.load("model_v3.joblib")     # nạp lại

# Xuất sang ONNX (từ sklearn)
from skl2onnx import to_onnx
onx = to_onnx(model, X_train[:1].astype("float32"))
with open("model.onnx", "wb") as f:
    f.write(onx.SerializeToString())

Model Registry là kho tập trung để quản lý các mô hình đã đăng ký: mỗi mô hình có nhiều version, mỗi version gắn stage (Staging, Production, Archived), kèm metadata (ai train, metric, data version, commit code). Nó cho phép promote/rollback mô hình mà không đổi code phía serving — service chỉ trỏ tới "mô hình ở stage Production". MLflow, SageMaker và Vertex AI đều có registry.

Không phải mô hình nào cũng cần một API real-time. Chọn kiểu phục vụ theo yêu cầu độ trễ và cách tiêu thụ dự đoán:

FastAPI là framework Python phổ biến nhất để bọc mô hình thành REST API online: hiệu năng cao (dựa trên ASGI/uvicorn), validate input tự động qua Pydantic, và sinh docs OpenAPI/Swagger sẵn tại /docs. Mẫu chuẩn: nạp mô hình một lần lúc khởi động (không nạp trong mỗi request), rồi định nghĩa endpoint /predict:

# app.py
from fastapi import FastAPI
from pydantic import BaseModel, Field
import joblib, numpy as np

# Nạp mô hình MỘT LẦN khi service khởi động
model = joblib.load("model_v3.joblib")
app = FastAPI(title="Churn Predictor", version="3.0")

# Schema input: Pydantic validate kiểu & ràng buộc tự động
class Customer(BaseModel):
    tenure: int = Field(..., ge=0, description="Số tháng gắn bó")
    monthly_charges: float = Field(..., ge=0)
    total_charges: float
    contract_type: int  # đã encode 0/1/2

class Prediction(BaseModel):
    churn: bool
    probability: float

@app.get("/health")
def health():
    return {"status": "ok"}

@app.post("/predict", response_model=Prediction)
def predict(c: Customer):
    x = np.array([[c.tenure, c.monthly_charges,
                   c.total_charges, c.contract_type]])
    prob = float(model.predict_proba(x)[0, 1])
    return Prediction(churn=prob > 0.5, probability=round(prob, 4))

Chạy local: uvicorn app:app --host 0.0.0.0 --port 8000. Test nhanh:

curl -X POST http://localhost:8000/predict \
  -H "Content-Type: application/json" \
  -d '{"tenure":5,"monthly_charges":80.5,"total_charges":402.5,"contract_type":0}'
# => {"churn": true, "probability": 0.7213}

Docker hoá để đảm bảo môi trường đồng nhất giữa dev và production:

# Dockerfile
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app.py model_v3.joblib ./
EXPOSE 8000
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

docker build -t churn-api:3.0 .
docker run -p 8000:8000 churn-api:3.0

Khi thử hàng chục cấu hình mô hình, bạn cần ghi lại một cách có hệ thống: tham số nào cho metric nào, artifact (mô hình, biểu đồ) ở đâu. MLflow là công cụ mã nguồn mở phổ biến nhất, gồm bốn thành phần: Tracking (log params/metrics/artifacts), Projects (đóng gói code tái lập), Models (định dạng chuẩn để deploy), và Model Registry (quản lý version + stage).

import mlflow, mlflow.sklearn
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import f1_score, roc_auc_score

mlflow.set_experiment("churn-prediction")

with mlflow.start_run(run_name="rf-baseline"):
    params = {"n_estimators": 300, "max_depth": 12}
    model = RandomForestClassifier(**params).fit(X_train, y_train)

    proba = model.predict_proba(X_test)[:, 1]
    pred  = (proba > 0.5)

    # 1) Log tham số
    mlflow.log_params(params)
    # 2) Log metric
    mlflow.log_metric("f1", f1_score(y_test, pred))
    mlflow.log_metric("auc", roc_auc_score(y_test, proba))
    # 3) Log artifact + mô hình, đăng ký vào Registry
    mlflow.log_artifact("feature_importance.png")
    mlflow.sklearn.log_model(model, "model",
                             registered_model_name="churn-rf")

Mở UI bằng mlflow ui để so sánh các run cạnh nhau. Sau đó có thể promote một version lên Production trong Registry và service serving load qua URI models:/churn-rf/Production.

Versioning dữ liệu với DVC: Git version code rất tốt nhưng không hợp để lưu file dữ liệu lớn. DVC (Data Version Control) lưu con trỏ nhỏ (hash) trong Git còn dữ liệu thật ở remote storage (S3, GCS), cho phép git checkout một commit rồi dvc checkout để lấy đúng phiên bản dữ liệu tương ứng — chìa khoá của reproducibility.

dvc init
dvc add data/train.csv        # tạo train.csv.dvc (con trỏ), thêm vào .gitignore
git add data/train.csv.dvc .gitignore
dvc remote add -d storage s3://my-bucket/dvcstore
dvc push                      # đẩy dữ liệu lên remote

Trong tổ chức lớn, cùng một feature (vd "tổng chi tiêu 30 ngày của khách hàng") được nhiều mô hình dùng chung, và phải nhất quán giữa lúc train và lúc serve. Feature Store (Feast, Tecton, Databricks Feature Store...) là hệ thống trung tâm để định nghĩa, tính toán, lưu trữ và phục vụ feature một cách chuẩn hoá. Nó giải quyết đúng vấn đề training-serving skew.

CI/CD trong ML phức tạp hơn phần mềm thông thường vì có thêm hai "tài sản" thay đổi: dữ liệu và mô hình, không chỉ code. Người ta hay chia thành ba đường ống:

• CI (Continuous Integration): mỗi khi push code — lint, unit test cho hàm feature engineering, kiểm tra schema dữ liệu, chạy train nhanh trên tập nhỏ để chắc pipeline không vỡ.
• CT (Continuous Training): pipeline tự động train lại mô hình khi có data mới hoặc theo lịch, log vào MLflow, và chỉ promote nếu vượt baseline.
• CD (Continuous Deployment): tự động đóng gói & deploy mô hình đã được duyệt lên Staging → Production, thường qua canary/shadow trước khi mở 100% traffic.

Các loại test đặc thù cho ML (ngoài unit test code thông thường):

Không giống phần mềm thông thường (đúng thì cứ đúng mãi), mô hình ML xuống cấp theo thời gian vì thế giới thay đổi trong khi mô hình đứng yên. Có hai loại "trôi" cần phân biệt:

Cách phát hiện drift trên từng feature/đầu ra:

• PSI (Population Stability Index): so sánh phân phối theo bin giữa tập tham chiếu và tập hiện tại. Quy ước: PSI < 0.1 ổn định, 0.1–0.25 dịch chuyển vừa (theo dõi), > 0.25 dịch chuyển mạnh (cần hành động). Rất phổ biến trong tín dụng.
• KS test (Kolmogorov–Smirnov): kiểm định thống kê cho biến liên tục, so sánh hai hàm phân phối tích luỹ; p-value nhỏ ⇒ hai phân phối khác nhau đáng kể.
• Chi-square test: cho biến phân loại — so sánh tần suất category giữa hai giai đoạn.
• Performance degradation: khi có nhãn thực (ground truth) về sau, theo dõi trực tiếp AUC/F1/accuracy tụt dần — bằng chứng mạnh nhất, nhưng thường trễ.

# PSI đơn giản giữa phân phối tham chiếu và hiện tại
import numpy as np
def psi(ref, cur, bins=10):
    edges = np.percentile(ref, np.linspace(0, 100, bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf
    r = np.histogram(ref, edges)[0] / len(ref)
    c = np.histogram(cur, edges)[0] / len(cur)
    r, c = np.clip(r, 1e-6, None), np.clip(c, 1e-6, None)
    return np.sum((c - r) * np.log(c / r))

print(psi(ref_scores, live_scores))   # > 0.25 => cảnh báo drift

Khi nào retrain? Có ba chiến lược, thường kết hợp: (1) theo lịch — retrain định kỳ (hằng tuần/tháng) đơn giản, dễ vận hành; (2) theo trigger — retrain khi PSI/KS vượt ngưỡng hoặc metric tụt dưới SLA; (3) online/continual — cập nhật liên tục, phức tạp và rủi ro nhất. Kèm theo là alerting: đẩy metric drift & performance lên Prometheus/Grafana hoặc công cụ chuyên dụng (Evidently, WhyLabs, Arize) và bắn cảnh báo qua Slack/PagerDuty khi vượt ngưỡng.