MLOps 1 — Tổng quan & vòng đời ML production

Có một sự thật dễ gây sốc cho người mới làm ML trong doanh nghiệp: mã của mô hình là phần nhỏ nhất của một hệ thống ML production. Notebook train mô hình chấm điểm tín dụng với AUC đẹp có thể chỉ vài trăm dòng; nhưng để mô hình đó chạy được mỗi ngày, với dữ liệu chưa từng thấy, trong khi thế giới bên ngoài liên tục thay đổi, và vẫn tuân thủ quy định của cơ quan quản lý — đó là một hệ thống lớn gấp bội, với hàng loạt mắt xích quanh phần "khoa học" bé nhỏ ở giữa.

Series này là bản đồ chi tiết cho toàn bộ phần hạ tầng bao quanh đó. Bài mở đầu trả lời câu hỏi nền tảng: MLOps là gì, vì sao ML lại khác phần mềm thường đến mức cần một bộ thực hành riêng, và vòng đời một mô hình production trông ra sao. Bài này mở rộng và hệ thống hoá phần tổng quan đã chạm tới ở ML 8 — Triển khai & MLOps; các bài sau sẽ đào sâu từng trụ cột.

1. MLOps là gì

MLOps (Machine Learning Operations) là tập các thực hành đưa nguyên tắc DevOps — tự động hoá, kiểm thử, versioning, giám sát, lặp nhanh — vào vòng đời của mô hình machine learning, đồng thời bổ sung những đặc thù mà phần mềm thường không có. Mục tiêu không phải "làm mô hình tốt hơn" mà là đưa mô hình ra production một cách đáng tin cậy, lặp lại được, và duy trì được theo thời gian.

Cần phân biệt rõ MLOps với hai thứ hay bị lẫn:

• Không phải là DevOps áp thẳng. DevOps version code; ML version code + dữ liệu + mô hình. DevOps test hàm; ML còn phải test chất lượng dự đoán. DevOps deploy xong là ổn định; mô hình ML tự suy giảm dù không ai đụng vào code.
• Không phải là "một công cụ". MLOps không phải MLflow, không phải Kubeflow, không phải một feature store cụ thể. Đó là một tập nguyên tắc và quy trình; công cụ chỉ là phương tiện hiện thực hoá.

Một định nghĩa gọn: MLOps = ML + DevOps + Data Engineering, gắn kết để biến một mô hình từ "thử nghiệm trong notebook" thành "tài sản vận hành trong hệ thống".

2. Vì sao ML khác phần mềm thường

Đây là câu hỏi cốt lõi. Câu trả lời nằm ở một đặc điểm: một dự đoán ML được quyết định bởi ba thứ cùng lúc — dữ liệu, mô hình, và code — và thay đổi bất kỳ cái nào cũng đổi kết quả.

Trong phần mềm thường, hành vi là hàm của code: cùng code + cùng input → cùng output, kiểm soát được. Trong ML, hành vi là hàm của cả ba biến, và một trong ba — dữ liệu — không nằm trong tầm kiểm soát của bạn: nó do thế giới thực sinh ra và thay đổi liên tục. Đây là gốc rễ của mọi khác biệt.

Technical debt ẩn của ML

Bài báo kinh điển của Google — "Hidden Technical Debt in Machine Learning Systems" (Sculley và cộng sự, 2015) — chỉ ra rằng mã ML tạo ra nợ kỹ thuật ở những chỗ không ngờ tới, mà bảo trì phần mềm truyền thống không có:

• Ranh giới trừu tượng bị xói mòn: ML "trộn tín hiệu" — mọi feature dính vào nhau, khó tách rời như module code sạch.
• Chuỗi phụ thuộc dữ liệu ngầm (data dependencies): feature A được tính từ nguồn B; ai đó đổi B mà không báo, mô hình sai lặng lẽ. Google gọi đây là món nợ đắt hơn cả phụ thuộc code, vì không có compiler nào bắt được.
• CACE — "Changing Anything Changes Everything": đổi một feature, một siêu tham số, một mẫu dữ liệu → toàn bộ trọng số mô hình dịch chuyển. Không có "thay đổi cục bộ" trong ML.
• Glue code & pipeline jungle: phần lớn code thực ra là ống dẫn dữ liệu chằng chịt quanh một lõi ML bé xíu.

Mô hình chỉ là phần nhỏ

Chính bài báo trên có một sơ đồ trứ danh: hộp "ML Code" nằm giữa, rất nhỏ, bao quanh là hàng loạt hộp lớn hơn nhiều — thu thập dữ liệu, kiểm chứng dữ liệu, quản lý cấu hình, hạ tầng serving, giám sát, quản lý tài nguyên, phân tích quy trình. Toàn bộ series này chính là mô tả những hộp lớn đó.

Training/serving skew

Đây là căn bệnh đặc trưng nhất của ML production. Training/serving skew là khi mô hình nhận đầu vào lúc serving khác với lúc training — không phải vì mô hình sai, mà vì đường dẫn dữ liệu hai bên lệch nhau. Ba nguồn gây skew phổ biến:

1. Logic tính feature khác nhau: feature "tổng dư nợ 90 ngày" được tính bằng SQL lúc train, viết lại bằng Python lúc serving — lệch một chút là đủ.
2. Dữ liệu thay đổi giữa hai thời điểm: giá trị điền khuyết (imputation) dùng mean của tập train, nhưng phân phối serving đã đổi.
3. Rò rỉ thời gian (time travel): lúc train vô tình dùng dữ liệu tương lai mà lúc serving không thể có.

Điểm nguy hiểm: mô hình không báo lỗi. Nó vẫn trả về những con số trông bình thường, chỉ là sai. Đây là lý do trung tâm khiến series có hẳn một bài về feature store — cơ chế đảm bảo cùng một định nghĩa feature cho cả train lẫn serving.

Drift — mô hình suy giảm theo thời gian

Ngay cả khi bạn triển khai hoàn hảo, mô hình vẫn già đi. Vì dữ liệu thực thay đổi, một mô hình đứng yên sẽ dần lệch khỏi thực tế — hiện tượng gọi là drift:

Loại drift	Cái gì đổi	Ví dụ ngân hàng
Data drift (covariate shift)	Phân phối đầu vào P(X)	Thu nhập trung bình khách nhảy từ 15 lên 25 triệu sau 6 tháng
Concept drift	Quan hệ P(y|X)	Sau khủng hoảng, "hồ sơ thế nào là rủi ro" đã khác dù hồ sơ trông y hệt
Label drift	Phân phối nhãn P(y)	Tỉ lệ vỡ nợ nền tăng do suy thoái

Phần mềm thường không có khái niệm này — code không "hết hạn". Mô hình ML thì có, và đó là lý do giám sát + retraining (bài 6) là mắt xích bắt buộc, không phải tuỳ chọn.

3. Vòng đời ML end-to-end

Gộp các đặc thù trên lại, ta có bức tranh vòng đời. Điểm mấu chốt: đây không phải quy trình một chiều "train rồi deploy", mà là một vòng lặp liên tục — mô hình được huấn luyện, triển khai, giám sát, và khi suy giảm thì quay lại huấn luyện phiên bản mới.

Đọc theo từng mắt xích:

1. Business: khung hoá bài toán — dự đoán cái gì, chỉ số thành công là gì, chi phí sai lệch ra sao. Bước này quyết định mọi bước sau (nối lại ML 1 — Workflow).
2. Data: thu thập, kiểm chứng, làm sạch. Nợ kỹ thuật ML chủ yếu nằm ở đây.
3. Feature: biến dữ liệu thô thành tín hiệu mô hình học được — chỗ dễ sinh training/serving skew nhất.
4. Train: thử nghiệm mô hình, ghi lại mọi run (experiment tracking, bài 2).
5. Evaluate: không chỉ đo AUC — mà là validation gate: vượt ngưỡng tối thiểu? tốt hơn mô hình đang chạy? đạt fairness? Nếu không đạt → quay lại làm feature/train.
6. Deploy: đóng gói và đưa vào phục vụ (bài 5).
7. Monitor: theo dõi drift và hiệu năng (bài 6) — mắt xích đóng vòng lặp.
8. Retrain: khi giám sát báo suy giảm, kích hoạt huấn luyện lại → quay về bước train.

Ba vòng phản hồi đáng nhớ: evaluate → feature (chưa đủ tốt thì cải tiến), monitor → retrain (đường tự chữa lành), và monitor → business (khi drift là do bài toán đã đổi bản chất, phải khung hoá lại).

4. Các mức trưởng thành MLOps

Không phải team nào cũng cần MLOps đầy đủ ngay. Google định nghĩa ba mức trưởng thành (maturity levels), mô tả bạn đang tự động hoá được đến đâu:

Level 0 — Quy trình thủ công

Toàn bộ vòng đời làm tay: data scientist chạy notebook, train, rồi bàn giao artifact cho team ops để deploy. Đặc điểm:

• Ranh giới train và serve tách rời — hai team, hai codebase, mảnh đất màu mỡ cho training/serving skew.
• Không tự động, phát hành hiếm (vài tháng một lần).
• Không giám sát chủ động — chỉ biết mô hình hỏng khi nghiệp vụ than phiền.

Đây là điểm khởi đầu của hầu hết dự án, và ổn cho giai đoạn PoC. Nó thất bại khi mô hình cần cập nhật thường xuyên.

Level 1 — Tự động hoá pipeline ML

Nâng cấp then chốt: tự động hoá pipeline huấn luyện để có thể retrain liên tục. Không còn "train một lần"; toàn bộ chuỗi data→feature→train→evaluate→deploy được đóng gói thành pipeline chạy lại được. Đặc điểm:

• Continuous training (CT): pipeline tự trigger retrain khi có dữ liệu mới hoặc phát hiện drift.
• Cùng code feature dùng cho cả train lẫn serving (thường qua feature store) → triệt tiêu skew.
• Có giám sát và trigger tự động, nhưng deploy pipeline mới vẫn còn thủ công.

Level 2 — CI/CD ML đầy đủ

Tự động hoá cả việc xây và triển khai chính pipeline. Đây là mức của các tổ chức chạy nhiều mô hình, cập nhật nhanh:

• CI: commit code → tự build, test cả code lẫn thành phần pipeline.
• CD: pipeline đóng gói được tự triển khai qua các môi trường (dev→staging→prod).
• CT: pipeline production tự retrain và tự phát hành mô hình mới qua validation gate.

Bài học thực tế: đừng nhảy thẳng lên Level 2. Mức trưởng thành phải khớp với nhu cầu — một mô hình chấm điểm cập nhật hằng quý không cần CI/CD pipeline đầy đủ. Đầu tư quá sớm là lãng phí; đầu tư quá muộn là nợ kỹ thuật chồng chất.

5. Các trụ cột của series

Mỗi mắt xích trong vòng đời tương ứng một trụ cột, và mỗi trụ cột là một bài sâu trong series:

Trụ cột	Giải quyết vấn đề	Bài
Experiment tracking	Tái lập được: run nào, tham số nào, metric nào	MLOps 2
Feature store	Nhất quán feature train/serving, tái dùng	MLOps 3
Pipeline & orchestration	Tự động hoá vòng lặp, continuous training	MLOps 4
Model registry & serving	Version model, deploy an toàn, rollback	MLOps 5
Monitoring & drift	Phát hiện suy giảm trước khi mất giá trị	MLOps 6
Governance & responsible AI	Lineage, giải thích, fairness, audit	MLOps 7
Platform cho ngân hàng	Ráp mọi trụ cột thành nền tảng	MLOps 8

6. Vai trò trong một team MLOps

MLOps là môn thể thao đồng đội — không một cá nhân nào ôm hết vòng đời. Bốn vai trò cốt lõi:

• Data Scientist: khung hoá bài toán, làm feature, thử nghiệm mô hình, chọn chỉ số. Sở hữu phần "khoa học".
• ML Engineer: biến notebook thành pipeline production — đóng gói, serving, tối ưu độ trễ, xây hạ tầng train/deploy. Là cầu nối chính giữa DS và ops.
• Data Engineer: đảm bảo dữ liệu và feature chảy đúng, đúng lúc, đúng chất lượng — nền móng cho mọi thứ phía trên.
• Ops / Platform / SRE: vận hành hạ tầng, giám sát độ sẵn sàng, đảm bảo SLA.

Với ngân hàng còn thêm Model Risk / Compliance — người xác nhận mô hình đạt yêu cầu quản trị rủi ro trước khi lên production. Ranh giới giữa các vai trò chính là nơi công việc dễ rơi rớt; MLOps tốt là làm các ranh giới đó có công cụ và quy trình rõ ràng, thay vì trông vào thiện chí phối hợp.

7. Vì sao ngân hàng cần MLOps chặt

Bối cảnh ngân hàng đẩy yêu cầu MLOps lên một mức khác. Mô hình chấm điểm tín dụng hay phát hiện gian lận không chỉ cần chính xác — chúng phải:

• Ổn định: một API scoring sập ở quầy giao dịch là mất khách trực tiếp; drift âm thầm khiến duyệt nhầm hàng loạt khoản vay là rủi ro tài chính thật.
• Tuân thủ: cơ quan quản lý yêu cầu tái dựng được chính xác mỗi quyết định — version dữ liệu nào, feature nào, model nào tại thời điểm đó. Đây là lý do lineage và audit trail không phải "nice to have".
• Giải thích được: từ chối một khoản vay phải nêu được lý do (nối lại governance ở MLOps 7).
• Công bằng: không phân biệt đối xử theo nhóm nhạy cảm — có kiểm chứng, có tài liệu.

Nói cách khác, với ngân hàng, phần "ops" và "governance" của MLOps nặng ký hơn cả phần mô hình. Đây là chủ đề bài cuối series về nền tảng MLOps cho ngân hàng.

Use case thực tế

Bối cảnh. Team dữ liệu NCB có một mô hình chấm điểm tín dụng chạy ở Level 0: một data scientist train bằng notebook mỗi quý, dump file .pkl, gửi ops deploy tay. Sau 8 tháng, tỉ lệ nợ xấu thực tế của nhóm được duyệt tăng bất thường, nhưng không ai phát hiện đến khi báo cáo quý cho thấy con số.

Chẩn đoán theo lăng kính bài này.

1. Không giám sát (đặc trưng Level 0): không ai đo drift. Tính lại PSI biến thu nhập giữa tập train (tháng 10/2025) và dữ liệu tháng 6/2026 → PSI = 0.31 (> 0.20, dịch chuyển lớn). Data drift đã âm thầm diễn ra nhiều tháng.
2. Training/serving skew: feature "tổng dư nợ 90 ngày" tính bằng SQL lúc train, viết lại bằng pandas lúc serving — lệch cách xử lý giao dịch đang chờ, làm feature serving thấp hơn train ~4%.
3. Không tái lập được: file .pkl không kèm version dữ liệu/tham số, không thể dựng lại chính xác mô hình đang chạy để so sánh.

Lộ trình nâng cấp lên Level 1.

Bước	Hành động	Trụ cột
1	Đưa mọi run vào MLflow, ghi param + data_version	Experiment tracking
2	Chuyển feature sang định nghĩa dùng chung train/serve	Feature store
3	Đóng gói data→train→eval thành pipeline retrain được	Pipeline
4	Đăng ký model, deploy qua alias @champion	Registry & serving
5	Bật giám sát PSI hằng tháng + alert khi > 0.20	Monitoring

Kết quả kỳ vọng. Skew biến mất (một định nghĩa feature); drift được bắt trong tuần thay vì quý; mỗi quyết định tái dựng được cho audit. Từ "một mô hình đẹp trong notebook" thành "một tài sản đang được vận hành có kiểm soát".

Ghi nhớ

• MLOps = ML + DevOps + Data Engineering — áp nguyên tắc DevOps (tự động hoá, versioning, test, giám sát) vào vòng đời mô hình, cộng đặc thù ML. Là tập thực hành, không phải một công cụ.
• ML khác phần mềm thường vì hành vi phụ thuộc cả ba: dữ liệu + mô hình + code. Đổi bất kỳ cái nào cũng đổi kết quả (CACE — "Changing Anything Changes Everything").
• Technical debt ẩn: phụ thuộc dữ liệu ngầm, glue code, pipeline jungle — món nợ mà compiler không bắt được. Mô hình chỉ là phần nhỏ trong hệ thống lớn bao quanh.
• Training/serving skew và drift (data / concept / label) là hai căn bệnh đặc trưng — mô hình không báo lỗi, chỉ sai dần. Đây là lý do feature store và monitoring là bắt buộc.
• Vòng đời ML là vòng lặp liên tục: business→data→feature→train→evaluate→deploy→monitor→retrain, có các đường phản hồi tự chữa lành.
• Ba mức trưởng thành (Google): Level 0 thủ công → Level 1 tự động hoá pipeline (continuous training) → Level 2 CI/CD ML đầy đủ. Chọn mức khớp nhu cầu, đừng nhảy cóc.
• Vai trò: data scientist, ML engineer, data engineer, ops — cộng model risk/compliance ở ngân hàng. MLOps làm các ranh giới giữa họ có công cụ rõ ràng.
• Ngân hàng cần MLOps chặt hơn: ổn định, tuân thủ, giải thích được, công bằng — phần ops/governance nặng ký hơn cả phần mô hình.

---

Bài tiếp theo: MLOps 2 — Experiment tracking. Nền tảng: ML 1 — Workflow · ML 8 — Triển khai & MLOps. Liên quan: TS 8 — Đưa dự báo ra production · Credit 3 — Scoring & scorecard.