MLOps năm 2026: MLflow, Model Registry và Câu Hỏi Phỏng Vấn Kỹ Thuật

Các câu hỏi phỏng vấn MLOps đã chuyển từ một chuyên môn ngách thành một phần cốt lõi trong hoạt động tuyển dụng data science và machine learning engineering vào năm 2026. Các đội ngũ không còn chỉ hỏi cách một mô hình được huấn luyện; họ tìm hiểu cách nó được theo dõi, quản lý phiên bản, triển khai và giám sát sau khi lưu lượng thực tế chạm đến. Hướng dẫn này đi qua những câu hỏi thường xuyên xuất hiện trong các buổi phỏng vấn MLOps, được nhóm theo từng giai đoạn của vòng đời, với các ví dụ MLflow phản ánh những thiết lập production.

Câu Hỏi Phỏng Vấn MLOps Về Vòng Đời Machine Learning

Q1: MLOps là gì và nó khác DevOps như thế nào?

MLOps áp dụng các nguyên tắc DevOps như tự động hóa, CI/CD và giám sát vào các hệ thống machine learning, sau đó bổ sung ba mối quan tâm mà phần mềm truyền thống không có: quản lý phiên bản dữ liệu, quản lý phiên bản mô hình, và kiểm định liên tục đối với các phân phối dữ liệu trực tiếp. Trong DevOps cổ điển, mã nguồn là artifact duy nhất thay đổi. Trong MLOps, mã nguồn, dữ liệu và mô hình đã huấn luyện mỗi thứ được quản lý phiên bản một cách độc lập, và bất kỳ yếu tố nào trong ba yếu tố này đều có thể âm thầm làm suy giảm chất lượng đầu ra mà không cần thay đổi một dòng mã nào. Bài báo thường được trích dẫn Hidden Technical Debt in Machine Learning Systems chỉ ra rằng mã của mô hình chỉ chiếm một phần nhỏ trong một hệ thống ML thực tế, với các pipeline dữ liệu, giám sát và cấu hình chiếm phần lớn diện tích bề mặt.

Q2: Trình bày các giai đoạn của một vòng đời ML trong production.

Một câu trả lời tốt nêu ra năm giai đoạn và artifact mà mỗi giai đoạn tạo ra: thu thập và kiểm định dữ liệu (một tập dữ liệu được quản lý phiên bản), thử nghiệm (các lần chạy được theo dõi kèm metrics), đăng ký mô hình (một mô hình được quản lý phiên bản, có thể thăng cấp), triển khai (một endpoint phục vụ hoặc job batch), và giám sát (dữ liệu đo lường về drift và hiệu năng phản hồi ngược trở lại quá trình huấn luyện lại). Người phỏng vấn lắng nghe vòng lặp phản hồi: giám sát phải kết nối trở lại với thử nghiệm, nếu không hệ thống chỉ là một pipeline một chiều và sẽ mục nát theo thời gian.

Theo Dõi Thí Nghiệm Với Ví Dụ Hướng Dẫn MLflow

Theo dõi thí nghiệm là nền tảng mà hầu hết các câu hỏi MLOps được xây dựng dựa trên đó, nên một câu trả lời kiểu hướng dẫn MLflow thể hiện việc ghi log thực tế sẽ có sức nặng. MLflow ghi lại các tham số, metrics và artifact cho mỗi lần chạy, điều này khiến bất kỳ kết quả nào cũng có thể tái lập được từ run ID của nó.

Q3: MLflow tracking ghi lại một thí nghiệm như thế nào, và tại sao run ID lại quan trọng?

Mỗi lần gọi mlflow.start_run() mở ra một lần chạy ghi log các siêu tham số, metrics và mô hình đã được tuần tự hóa. Run ID là handle bất biến gắn một metric trở lại đúng với mã, tham số và ảnh chụp dữ liệu đã tạo ra nó, đó chính là điều khiến một thí nghiệm có thể tái lập nhiều tháng sau đó.

# train_with_mlflow.py
import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import f1_score

mlflow.set_tracking_uri("http://localhost:5000")  # tracking server
mlflow.set_experiment("churn-prediction")

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

    f1 = f1_score(y_val, model.predict(X_val))

    mlflow.log_params(params)                       # hyperparameters
    mlflow.log_metric("val_f1", f1)                 # validation metric
    mlflow.sklearn.log_model(model, name="model")   # MLflow 3.x uses name=

    print("run_id:", run.info.run_id)               # reproducibility handle

Đối số name thay thế cho artifact_path đã lỗi thời trong MLflow 3.x, một thay đổi đáng nhắc đến để cho thấy sự nắm bắt về API hiện tại. Những ứng viên tham chiếu đến việc theo dõi feature và dataset thông qua các mẫu kiểm định ML pipeline thường đạt điểm cao hơn, bởi vì khả năng tái lập phụ thuộc vào toàn bộ pipeline, không chỉ riêng mô hình.

Model Registry 2026: Quản Lý Phiên Bản Và Thăng Cấp

MLflow Model Registry biến một run artifact thành một đối tượng được quản trị và có thể thăng cấp. Thay đổi lớn nhất gần đây, đồng thời là một câu hỏi phỏng vấn thường gặp trong năm 2026, là việc chuyển hướng khỏi các stage được đặt tên cố định.

Q4: MLflow Model Registry thăng cấp một mô hình như thế nào, và điều gì đã thay đổi trong năm 2026?

Các phiên bản MLflow trước đây thăng cấp mô hình qua các stage cố định mang tên Staging, Production và Archived. MLflow 3.x loại bỏ các stage đó để chuyển sang dùng alias và tag, bởi vì một danh sách stage được mã hóa cứng không thể diễn đạt các topology triển khai thực tế như champion, challenger hay shadow. Một alias là con trỏ có thể thay đổi trỏ tới một phiên bản, nên việc thăng cấp trở thành thao tác gán lại alias thay vì biến đổi bản thân mô hình.

# register_and_promote.py
import mlflow
from mlflow import MlflowClient

client = MlflowClient()

# Register a logged run artifact as a new model version
result = mlflow.register_model(
    model_uri=f"runs:/{run_id}/model",
    name="churn-classifier"
)

# MLflow 3.x: aliases replace deprecated stages
client.set_registered_model_alias(
    name="churn-classifier",
    alias="champion",        # production traffic resolves here
    version=result.version
)

# Any service loads the current champion without knowing the version
model = mlflow.pyfunc.load_model("models:/churn-classifier@champion")

Vì các bên tiêu thụ nạp models:/churn-classifier@champion, một lần rollback chỉ là một thao tác gán lại alias sang phiên bản trước đó, không cần triển khai lại. Tài liệu chính thức của MLflow Model Registry trình bày chi tiết về việc quản trị alias và các trigger webhook.

Các Mẫu Triển Khai Machine Learning Và Phục Vụ Mô Hình

Các câu hỏi về triển khai phân biệt những ứng viên đã đưa mô hình vào thực tế với những người mới chỉ huấn luyện chúng. Lựa chọn mẫu triển khai đi theo ngân sách độ trễ, chứ không phải theo sở thích cá nhân.

Q5: So sánh triển khai machine learning theo batch, online và streaming.

| Mẫu triển khai | Độ trễ | Trường hợp sử dụng điển hình | Bề mặt phục vụ | |---------|---------|------------------|-----------------| | Batch | Hàng giờ đến hàng ngày | Chấm điểm churn, làm mới gợi ý | Job theo lịch ghi vào một bảng | | Online (thời gian thực) | Hàng chục mili giây | Kiểm tra gian lận, xếp hạng tại thời điểm request | Endpoint REST hoặc gRPC | | Streaming | Dưới một giây, liên tục | Phát hiện bất thường trên luồng sự kiện | Consumer trên một message queue |

Câu hỏi tiếp theo hầu như luôn hỏi cách phục vụ trường hợp online. Một mô hình MLflow đóng gói môi trường riêng của nó, nên việc phục vụ nó chỉ là một lệnh nhắm vào một registry URI.

# serve_model.sh
# Serve the current champion as a REST endpoint on port 5001
mlflow models serve \
  --model-uri "models:/churn-classifier@champion" \
  --host 0.0.0.0 --port 5001 --env-manager uv

Q6: Các triển khai blue-green và canary giảm rủi ro cho việc tung ra một mô hình như thế nào?

Blue-green duy trì hai môi trường giống hệt nhau và chuyển toàn bộ lưu lượng cùng một lúc sau khi mô hình mới vượt qua các kiểm tra, mang lại một đường rollback tức thì. Canary định tuyến một tỷ lệ nhỏ lưu lượng tới phiên bản mới, quan sát các metric trực tiếp, rồi tăng dần. Đối với mô hình, canary thường an toàn hơn vì các vấn đề về chất lượng mô hình chỉ lộ ra khi gặp đầu vào thực tế, và một canary giới hạn phạm vi ảnh hưởng chỉ trong một phần nhỏ người dùng.

Kiểm Thử Và CI/CD Cho Các Pipeline Machine Learning

Q7: CI/CD kiểm thử điều gì trong một ML pipeline mà một pipeline phần mềm tiêu chuẩn không có?

Một pipeline CI phần mềm chạy các bài kiểm thử unit và integration trên mã. Một ML pipeline bổ sung thêm các bài kiểm thử dữ liệu và mô hình bên trên: kiểm định schema trên dữ liệu đầu vào, kiểm tra phân phối để một lần chạy huấn luyện không âm thầm nạp vào các feature bị hỏng, và một cổng chất lượng mô hình khiến build thất bại khi một ứng viên đạt điểm thấp hơn champion hiện tại trên một tập holdout cố định. Do đó, continuous delivery cho ML thăng cấp một artifact mô hình, không chỉ là một container image, và cổng thăng cấp là một ngưỡng metric chứ không chỉ đơn thuần là một bộ kiểm thử màu xanh. Một pipeline nghiêm ngặt cũng cố định (pin) các ảnh chụp dữ liệu và phiên bản phụ thuộc để bất kỳ lần chạy lại nào cũng mang tính xác định, đó là điều phân biệt một build có thể tái lập với một build tình cờ vượt qua ngày hôm nay.

Giám Sát, Data Drift Và Huấn Luyện Lại Mô Hình

Một mô hình đã triển khai sẽ suy giảm khi thế giới dịch chuyển bên dưới nó, nên các câu hỏi về giám sát là nơi tín hiệu về trình độ senior xuất hiện.

Q8: Data drift được phát hiện như thế nào, và metric nào định lượng nó?

Data drift nghĩa là phân phối của đầu vào production đã dịch chuyển khỏi phân phối huấn luyện. Population Stability Index (PSI) là một thước đo phổ biến và không phụ thuộc framework: nó chia phân phối tham chiếu thành các bin, so sánh các tần suất production với những bin đó, và cộng tổng các chênh lệch log có trọng số.

# population_stability_index.py
import numpy as np

def psi(reference, production, bins=10):
    # Bin edges come from the reference (training) distribution
    edges = np.quantile(reference, np.linspace(0, 1, bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf

    ref_pct = np.histogram(reference, edges)[0] / len(reference)
    prod_pct = np.histogram(production, edges)[0] / len(production)

    # Clip to avoid division by zero and log(0)
    ref_pct = np.clip(ref_pct, 1e-6, None)
    prod_pct = np.clip(prod_pct, 1e-6, None)

    return float(np.sum((prod_pct - ref_pct) * np.log(prod_pct / ref_pct)))

# PSI < 0.1 stable | 0.1-0.25 moderate shift | > 0.25 major drift, investigate
score = psi(reference_scores, production_scores)

Ngoài một metric tự triển khai, các đội ngũ production còn tìm đến những công cụ như Evidently để theo dõi feature drift, target drift và chất lượng dữ liệu theo lịch. Một câu trả lời hoàn chỉnh phân biệt data drift (đầu vào dịch chuyển) với concept drift (mối quan hệ đầu vào-đầu ra dịch chuyển), bởi vì loại thứ hai không thể được phát hiện chỉ bằng cách quan sát đầu vào và đòi hỏi các kết quả đã được gán nhãn.

Q9: Điều gì nên kích hoạt một pipeline huấn luyện lại?

Huấn luyện lại theo thời gian với một nhịp cố định là lựa chọn đơn giản nhất nhưng lãng phí tài nguyên tính toán khi không có gì thay đổi và phản ứng chậm khi có sự cố. Các trigger tốt hơn là dựa trên metric: huấn luyện lại khi PSI vượt qua một ngưỡng, khi một metric đánh giá trực tiếp giảm xuống dưới một mức sàn, hoặc khi một backtest theo lịch trên dữ liệu vừa được gán nhãn bị suy giảm. Job huấn luyện lại sau đó đăng ký một challenger, và một đợt canary rollout sẽ so sánh nó với champion hiện tại trước khi bất kỳ alias nào được gán lại.

Câu Hỏi Phỏng Vấn Thiết Kế Hệ Thống MLOps

Q10: Thiết kế một nền tảng phục vụ hàng trăm mô hình với các feature nhất quán.

Trung tâm được kỳ vọng là một feature store, thứ giải quyết training-serving skew bằng cách tính toán các feature một lần và phục vụ những giá trị giống hệt nhau cho cả huấn luyện lẫn suy luận. Các công cụ như Feast cung cấp một offline store cho huấn luyện và một online store độ trễ thấp cho việc phục vụ. Một thiết kế đầy đủ cũng nêu tên một model registry để quản lý phiên bản, một tracking server cho lineage, một orchestrator cho các pipeline, và một lớp giám sát khép kín vòng lặp trở lại việc huấn luyện lại. Việc đặt câu trả lời trên nền tảng công việc feature thực tế, chẳng hạn như các đánh đổi được trình bày trong hướng dẫn phỏng vấn feature engineering này, báo hiệu kinh nghiệm thực hành thay vì chỉ ghi nhớ sơ đồ.

Kết Luận

• Định hình MLOps như DevOps cộng thêm quản lý phiên bản dữ liệu và mô hình: khả năng tái lập, an toàn khi thăng cấp và giám sát là ba trục mà người phỏng vấn chấm điểm
• Nắm rõ thay đổi API của MLflow 3.x: alias và tag thay thế các stage Staging và Production đã lỗi thời, và log_model giờ nhận name thay vì artifact_path
• Khớp mẫu triển khai với ngân sách độ trễ, và mặc định chọn canary thay vì blue-green cho việc tung ra mô hình vì các vấn đề chất lượng chỉ xuất hiện khi gặp đầu vào trực tiếp
• Định lượng drift bằng một metric cụ thể như PSI, và phân biệt data drift với concept drift, vì chỉ một trong hai là nhìn thấy được khi không có nhãn
• Kích hoạt huấn luyện lại dựa trên metric thay vì dựa vào lịch, và định tuyến challenger thu được qua một canary trước khi gán lại alias champion
• Nêu tên một feature store trong bất kỳ câu trả lời thiết kế hệ thống nào để khép lại khoảng cách training-serving skew trước khi nó được nêu lên như một câu hỏi tiếp theo