MLOps 8 — Nền tảng MLOps ngân hàng end-to-end

Bảy bài trước của series đi sâu từng trụ cột: tổng quan vòng đời, experiment tracking, feature store, pipeline, model registry & deploy, monitoring & drift, và governance & responsible AI. Bài cuối này làm việc ngược lại: ghép các mảnh rời thành một nền tảng vận hành được cho một ngân hàng thật, rồi kiểm chứng kiến trúc bằng hai mô hình đi hết vòng đời.

Điểm mấu chốt: một nền tảng MLOps không phải là "một công cụ" mà là một tập thành phần được nối với nhau bằng hợp đồng dữ liệu (data contract) và quy trình. Ngân hàng có thêm ràng buộc khắc nghiệt — dữ liệu nhạy cảm không được rời on-prem, mọi quyết định phải audit được, mô hình tín dụng phải validate độc lập theo quy định — nên kiến trúc phải đặt governance ở trung tâm chứ không phải chắp vá sau.

1. Kiến trúc tham chiếu end-to-end

Toàn bộ nền tảng có thể nhìn thành một dòng chảy tuyến tính (dữ liệu → feature → train → deploy → giám sát) khép lại thành vòng lặp retrain, được bao bọc bởi một lớp governance xuyên suốt.

Đọc theo từng chặng:

(1) Nguồn dữ liệu. Dữ liệu gốc nằm ở core banking (số dư, giao dịch, hồ sơ), được đẩy vào data warehouse (kho phân tích, mô hình hoá theo chủ đề) và lakehouse (kết hợp linh hoạt của data lake với quản trị dạng bảng — xem Lakehouse) để chứa dữ liệu thô, event stream giao dịch, log. Đây là ranh giới giữa "hệ thống nguồn của sự thật" và thế giới ML.

(2) Feature store. Nơi tính năng (feature) được định nghĩa MỘT lần rồi dùng lại. Hai mặt: offline store (lịch sử đầy đủ, phục vụ train và batch scoring) và online store (giá trị mới nhất, low-latency, phục vụ serving thời gian thực). Điểm sống còn là cả hai cùng sinh ra từ MỘT định nghĩa để tránh training/serving skew — feature lúc train khác lúc serve.

(3) Experiment tracking. Mọi lần train ghi lại params, metrics, dataset version, code version, artifact. Đây là "sổ cái khoa học" — không có nó thì không tái lập được kết quả, không so sánh được model.

(4) Pipeline train + CI/CD. Train không còn là chạy notebook tay mà là pipeline có mã hoá: đọc feature → train → đánh giá → nếu đạt ngưỡng thì đăng ký. CI/CD kiểm thử code pipeline, data validation, và test chất lượng model trước khi cho lên.

(5) Model registry. Kho phiên bản mô hình, có trạng thái (Staging/Production/Archived), gắn metadata governance (ai duyệt, validate ra sao, model card). Là ranh giới giữa "thử nghiệm" và "tài sản vận hành".

(6) Serving. Hai chế độ: batch (chấm điểm hàng loạt theo lịch, ví dụ điểm tín dụng cả danh mục mỗi đêm) và online (API đồng bộ, độ trễ mili-giây, ví dụ chặn giao dịch gian lận ngay lúc phát sinh).

(7) Monitoring & retrain loop. Giám sát chất lượng dự đoán, data drift, concept drift. Khi vượt ngưỡng → kích hoạt lại pipeline train (retrain) → vòng lặp khép kín.

Governance/Security/Audit không phải một hộp riêng ở cuối mà là lớp bao quanh: kiểm soát truy cập dữ liệu (xem Access control), lineage feature→model→quyết định, log audit mọi lần scoring, và cổng phê duyệt ở registry.

Ánh xạ các bài trong series vào kiến trúc

2. Build vs Buy

Câu hỏi lớn nhất khi khởi động: tự xây trên OSS hay mua nền tảng tích hợp?

Tự xây (OSS stack). Ghép các thành phần mở, mỗi cái làm tốt một việc:

Ưu điểm: kiểm soát tuyệt đối, chạy được on-prem, không khoá nhà cung cấp, chi phí license = 0. Nhược điểm: bạn phải tự tích hợp, tự vá bảo mật, tự vận hành HA — gánh nặng "platform engineering" rất thực.

Mua (nền tảng tích hợp / cloud): AWS SageMaker, Google Vertex AI, Databricks (Unity Catalog + MLflow managed), Azure ML. Các nền tảng này gói sẵn tracking + pipeline + registry + serving + monitoring, tích hợp IAM, autoscale. Ưu điểm: thời gian ra thị trường nhanh, ít người vận hành. Nhược điểm: khoá nhà cung cấp, chi phí theo mức dùng, và — quan trọng với ngân hàng — dữ liệu có thể phải rời khỏi biên giới on-prem.

Tiêu chí chọn cho ngân hàng

Với ngân hàng Việt Nam, thứ tự ưu tiên thường là:

1. Tuân thủ & chủ quyền dữ liệu. Nhiều loại dữ liệu (định danh khách hàng, giao dịch) bị ràng buộc phải xử lý trong nước / on-prem. Điều này thường loại bỏ cloud public thuần hoặc buộc dùng phiên bản on-prem của Databricks/hybrid.
2. Chi phí tổng. OSS "free license" nhưng tốn 3-6 kỹ sư platform; nền tảng managed đắt license nhưng cần ít người hơn. So sánh TCO chứ không so license.
3. Kỹ năng đội hiện có. Nếu đội đã mạnh Kubernetes + Python, OSS khả thi. Nếu mỏng, managed giảm rủi ro.
4. Mức độ chín của use case. Giai đoạn đầu (1-2 model) nên nghiêng managed/đơn giản; khi có hàng chục model mới đáng đầu tư platform tự xây.

Thực tế phổ biến: hybrid — MLflow + Feast + Airflow tự host on-prem cho dữ liệu nhạy cảm, dùng cloud cho khối lượng tính toán không chứa PII.

3. Vai trò & tổ chức đội

Nền tảng chỉ chạy nếu có mô hình sở hữu rõ ràng. Tách hai vai trò:

• Platform team (nền tảng). Sở hữu hạ tầng: feature store, registry, CI/CD template, serving runtime, monitoring chung. Họ không build model — họ build "đường ray" để ML team đi nhanh và an toàn. Thước đo: thời gian từ ý tưởng → production, độ tin cậy nền tảng.
• ML team / Data Scientist. Sở hữu mô hình cụ thể: feature nghiệp vụ, train, đánh giá, cải thiện. Họ tiêu thụ nền tảng qua interface chuẩn, không tự dựng hạ tầng riêng cho mỗi model.
• Model Risk / Validation (bắt buộc ở ngân hàng). Đội độc lập thẩm định mô hình tín dụng trước khi lên production — tách bạch khỏi đội xây model để tránh xung đột lợi ích.

Nguyên tắc: paved road (đường đã lát) — platform team cung cấp con đường mặc định tốt; ML team được tự do đi đường khác nhưng phải tự chịu trách nhiệm vận hành.

4. Use case xuyên suốt — Phát hiện gian lận (online)

Đây là mô hình real-time, high-stakes: phải quyết định trong < 100ms có chặn giao dịch hay không, dữ liệu lệch nghiêm trọng (gian lận rất hiếm), và kẻ gian liên tục thay đổi thủ đoạn (concept drift nhanh). Liên hệ nghiệp vụ ở Transaction monitoring.

Đi hết vòng đời trên kiến trúc:

Ý tưởng → Feature. Data scientist định nghĩa feature trong feature store, ví dụ "số giao dịch của tài khoản trong 1 giờ qua", "độ lệch số tiền so với trung bình 30 ngày", "giao dịch ở thành phố lạ". Định nghĩa được đăng ký một lần:

# Minh hoa dinh nghia feature (pseudocode Feast-style) — KHONG phai SQL chay duoc
tx_1h = FeatureView(
    name="txn_velocity",
    entities=["account_id"],
    ttl="2h",
    features=["count_1h", "sum_amount_1h", "distinct_city_1h"],
    source=stream_source_transactions,  # tinh tu event stream
)

Backfill lịch sử vào offline store để train; đồng thời một job streaming cập nhật online store liên tục để serving có giá trị mới nhất.

Train. Pipeline đọc offline features + nhãn gian lận (được xác nhận trễ, thường sau vài ngày điều tra), train model (ví dụ gradient boosting), log vào MLflow. Vì gian lận cực hiếm, phải xử lý mất cân bằng và đánh giá bằng precision/recall ở ngưỡng nghiệp vụ chứ không phải accuracy.

Deploy online. Model đạt ngưỡng → đăng ký registry → promote sang Production → serving API tải model. Rollout canary: 5% lưu lượng qua model mới, theo dõi rồi mới mở rộng (chi tiết ở mlops-05).

Luồng một request lúc chạy:

Giám sát. Theo dõi phân phối điểm số, tỷ lệ chặn, và — quan trọng — feedback chậm: khi nhãn thật về (giao dịch được xác nhận gian lận/hợp lệ), tính lại precision/recall thực. Cảnh báo khi drift hoặc recall tụt.

Retrain. Vì thủ đoạn đổi nhanh, retrain định kỳ (ví dụ hàng tuần) hoặc theo trigger drift. Toàn bộ chạy qua đúng pipeline train ở trên — không có "sửa tay" trên production.

5. Use case xuyên suốt — Chấm điểm tín dụng (batch)

Trái ngược hoàn toàn: batch, độ trễ không quan trọng, nhưng phải giải thích được và validate độc lập theo quy định. Nghiệp vụ ở Scorecard tín dụng.

Feature. Feature ổn định, tính từ warehouse: thu nhập, lịch sử trả nợ, tỷ lệ dư nợ/hạn mức, số sản phẩm đang dùng. Không cần online store — chỉ dùng offline store cho cả train và scoring.

Train. Ưu tiên mô hình giải thích được (logistic regression / scorecard, hoặc GBM kèm SHAP). Log vào MLflow kèm hệ số, feature importance, và các báo cáo fairness (điểm có thiên lệch theo nhóm không).

Validation độc lập. Trước khi lên production, đội Model Risk thẩm định: kiểm định trên tập giữ lại, kiểm tra ổn định (PSI), kiểm tra fairness, và ký duyệt. Cổng duyệt này gắn ở registry — model không lên được nếu thiếu chữ ký (governance ở mlops-07).

Deploy batch. Một Airflow DAG chạy hàng đêm: đọc offline features của toàn danh mục → load model từ registry → chấm điểm → ghi kết quả kèm lý do giải thích vào warehouse.

# Minh hoa DAG batch scoring (pseudocode Airflow) — KHONG phai SQL chay duoc
with DAG("credit_score_nightly", schedule="0 2 * * *"):
    feats = get_offline_features(entity="customer_id", asof=today)
    model = registry.load("credit_scorecard", stage="Production")
    scores = model.predict(feats)
    reasons = explain(model, feats)      # SHAP -> ly do tu choi
    write_to_warehouse(scores, reasons)  # phuc vu can bo tin dung

Giám sát & retrain. Vì tín dụng drift chậm, retrain thưa hơn nhiều (quý/nửa năm), và mỗi lần retrain lại phải qua validation độc lập — không tự động promote như fraud. Đây là khác biệt cốt lõi: cùng một nền tảng, hai chính sách governance khác nhau tùy rủi ro.

Đối chiếu hai use case

6. Thực hành tốt & cạm bẫy

Nên:

• Một định nghĩa feature dùng chung train & serve — chống training/serving skew ngay từ gốc.
• Không sửa tay trên production. Mọi thay đổi model đi qua pipeline + registry, có version, rollback được.
• Governance là cổng, không phải giấy tờ. Cài phê duyệt vào registry để không lên được nếu thiếu duyệt.
• Bắt đầu ở mức thấp phù hợp. 1-2 model đầu tiên không cần platform hoành tráng — nâng cấp khi số model tăng.

Cạm bẫy:

• Xây platform vàng khi chưa có model nào chạy. Đầu tư hạ tầng trước nhu cầu → tốn kém, sai hướng.
• Bỏ quên feedback loop chậm. Fraud/credit đều có nhãn thật về trễ; nếu không thiết kế đường thu nhãn, không đo được chất lượng thật.
• Copy feature engineering vào code serving. Nguồn phổ biến nhất của skew.
• Cloud tiện tay làm rò dữ liệu PII ra ngoài biên on-prem — vi phạm tuân thủ.

7. Checklist trưởng thành MLOps ngân hàng

• Feature định nghĩa tập trung, dùng chung offline/online.
• Mọi lần train được track (params, data version, code version).
• Pipeline train tự động, có CI/CD và data validation.
• Model registry có trạng thái, model card, và cổng phê duyệt.
• Deploy có versioning + rollback + rollout an toàn (canary/shadow).
• Monitoring drift + performance + feedback nhãn thật.
• Retrain loop tự động (hoặc bán tự động với validation).
• Lineage feature → model → quyết định, audit mọi lần scoring.
• Fairness & giải thích cho model rủi ro cao.
• Quyền truy cập dữ liệu theo vai trò, PII không rời on-prem.

Use case thực tế

Một ngân hàng có 8 mô hình ML rời rạc, mỗi đội tự dựng riêng: 3 cách tính feature "số dư trung bình 90 ngày" khác nhau, không đội nào tái lập được kết quả của đội khác, và khi cơ quan quản lý hỏi "vì sao từ chối khách hàng X ngày 15/03" thì mất 2 tuần truy vết thủ công.

Chương trình gộp về một nền tảng chung (MLflow + Feast + Airflow on-prem, MinIO cho artifact) triển khai theo 3 quý:

• Quý 1: dựng feature store, đưa 12 feature dùng chung lên; loại bỏ 3 định nghĩa "số dư 90 ngày" còn một. Kết quả: skew giữa train và serve của model fraud giảm rõ, recall thực tăng.
• Quý 2: đưa registry + cổng phê duyệt vào; mọi model tín dụng phải có chữ ký Model Risk mới promote được. Thời gian từ "model sẵn sàng" → production giảm từ ~6 tuần xuống ~1 tuần nhờ pipeline chuẩn.
• Quý 3: bật monitoring drift + audit log mọi lần scoring. Khi cơ quan quản lý hỏi lại về quyết định từ chối, đội tra lineage feature → model version → điểm số → lý do trong vài phút thay vì 2 tuần.

Bài học: giá trị lớn nhất không đến từ model tốt hơn mà từ chuẩn hoá và audit được — đúng thứ ngân hàng cần nhất.

Ghi nhớ

• Nền tảng MLOps = chuỗi nguồn dữ liệu → feature store → tracking → pipeline → registry → serving → monitoring → retrain, bao quanh bởi governance/security/audit.
• Feature store hai mặt (offline/online) từ MỘT định nghĩa là lá chắn chính chống training/serving skew.
• Build vs buy: OSS (MLflow+Feast+Airflow) cho kiểm soát và on-prem; managed (SageMaker/Vertex/Databricks/Azure ML) cho tốc độ. Ngân hàng ưu tiên chủ quyền dữ liệu, TCO, kỹ năng đội — thường chọn hybrid.
• Tách platform team (đường ray) và ML team (model); riêng ngân hàng có thêm Model Risk thẩm định độc lập.
• Cùng một nền tảng phục vụ hai chính sách khác nhau: fraud online, retrain nhanh tự động; credit batch, giải thích được, validate và ký duyệt bắt buộc.
• Cạm bẫy lớn nhất: xây platform trước khi có model, quên feedback loop chậm, và để feature engineering serving lệch với train.