Bài 39: MLOps là gì? Khác biệt với DevOps truyền thống

Sau bài này bạn sẽ:

• ✅ Hiểu MLOps là discipline gì, không phải framework hay tool đơn lẻ
• ✅ Biết 3 artifact (code, data, model) tạo ra sự khác biệt giữa MLOps và DevOps
• ✅ Nắm lifecycle của một model từ data ingestion đến monitoring
• ✅ Phân biệt 3 maturity levels và xác định team mình đang ở đâu
• ✅ Có cái nhìn tổng quan về tools landscape để biết sẽ học gì ở bài 40–44

MLOps (Machine Learning Operations) là tập hợp practice, quy trình và tool để đưa model ML từ giai đoạn thử nghiệm sang production, rồi duy trì nó hoạt động ổn định theo thời gian.

Định nghĩa ngắn hơn: MLOps = DevOps + Data + Model.

Điều quan trọng cần hiểu ngay từ đầu: MLOps là một discipline, không phải một framework hay tool cụ thể. Bạn có thể làm MLOps với MLflow, hoặc với Weights & Biases, hoặc với Kubeflow — nhưng tool không phải là MLOps. Practice, quy trình và văn hóa kỹ thuật mới là MLOps.

Nguồn gốc

Nền tảng lý thuyết được đặt ra từ paper "Hidden Technical Debt in Machine Learning Systems" (Sculley et al., Google, NeurIPS 2015) — paper này chỉ ra rằng code ML chỉ là một phần nhỏ của hệ thống ML thực tế; phần còn lại (data pipeline, feature engineering, serving infrastructure, monitoring) tốn công sức không kém và hay bị bỏ qua.

Term "MLOps" bắt đầu phổ biến rộng từ khoảng 2018–2019, trùng với thời điểm nhiều công ty đưa model vào production và nhận ra rằng làm notebook là một chuyện, vận hành production là chuyện hoàn toàn khác.

Cách làm phổ biến khi mới bắt đầu: train model trong notebook Jupyter → export file .pkl hoặc .pt → copy thủ công lên server → chạy. Cách này hoạt động với POC nhưng có nhiều vấn đề khi scale lên.

Reproducibility

Train cùng data, cùng code phải cho ra cùng model (hoặc ít nhất cùng performance range). Nếu không reproduce được, khi model gặp sự cố ở production bạn không có cách debug. Câu hỏi "model này được train với data nào, code version nào?" phải trả lời được trong vài phút, không phải vài ngày.

Traceability

Mỗi model artifact ở production phải trace được về: commit code, dataset version, hyperparameter, người approve deploy. Đây là yêu cầu cơ bản khi có audit hoặc khi cần rollback.

Continuous integration

Code thay đổi → tự rebuild, retest, redeploy. Không phải copy file thủ công. Áp dụng cho cả pipeline ML: thay đổi feature engineering code → tự validate lại trên held-out set trước khi merge.

Continuous training

Data thực tế thay đổi theo thời gian. Model train 6 tháng trước có thể giảm accuracy hôm nay vì distribution của input đã drift. MLOps cung cấp cơ chế retrain định kỳ hoặc trigger khi phát hiện drift, không chờ user complain.

Monitoring

Với web app thông thường, bạn monitor latency và error rate. Với ML, ngoài các metrics đó còn cần monitor distribution của input, distribution của output, và accuracy so với ground truth (nếu có). Model có thể "không lỗi" theo nghĩa kỹ thuật (trả về 200 OK) nhưng predict sai hoàn toàn.

Governance

Ai có quyền approve model lên production? Có audit trail không? Một số domain (tài chính, y tế, pháp lý) có yêu cầu bắt buộc về explainability và audit.

DevOps xử lý artifact chính là code (source, binary, container image). MLOps phải xử lý đồng thời 3 loại artifact: code + data + model. Đây là nguồn gốc của hầu hết sự phức tạp.

Artifact: Code + Data + Model

Trong DevOps, deploy version mới nghĩa là deploy code mới. Trong MLOps, bạn có thể deploy cùng code nhưng model khác (train lại trên data mới), hoặc cùng model nhưng data pipeline khác. Ba thành phần này thay đổi độc lập và đều ảnh hưởng đến behavior của hệ thống.

Testing: data validation không phải chỉ unit test

Code test theo nghĩa thông thường vẫn cần. Nhưng thêm vào đó:

• Data validation: schema đúng không? có missing values vượt ngưỡng không? distribution có bất thường không?
• Model evaluation: accuracy / F1 / BLEU trên held-out set phải đạt threshold trước khi deploy
• Behavioral test (slice test): model có perform tốt đều trên các nhóm người dùng / ngôn ngữ / domain không? (cf. "Checklist for NLP" — Ribeiro et al., ACL 2020)

Deployment: probabilistic behavior

Code web app deploy xong hoạt động đúng như test — deterministic. Model deploy xong trả về prediction dựa trên pattern học từ training data. Nếu production data khác training data, model sẽ degrade mà không có exception hay stack trace nào. Đây là lý do monitoring trong MLOps phức tạp hơn nhiều.

Một model đi từ ý tưởng đến production qua 8 phase. Các phase này không nhất thiết tuyến tính — bạn có thể lặp lại nhiều lần.

Phase 1: Data ingestion + validation

Thu thập data từ nguồn (database, S3, API, stream). Kiểm tra schema (các cột đúng không?), missing values, outlier, và distribution tổng thể. Tools: Great Expectations, Pandera, TensorFlow Data Validation.

Phase 2: Data preparation

Feature engineering, normalization, encoding categorical, split train/validation/test. Kết quả của phase này phải versioned — nếu thay đổi feature engineering, phải tạo version mới, không ghi đè.

Phase 3: Model training

Chọn algorithm, tune hyperparameter, train. Mỗi lần train là một experiment run cần được track đầy đủ: code version, data version, hyperparameter, metric. Bài 40 (MLflow) và bài 41 (W&B) đi sâu vào phần này.

Phase 4: Model evaluation

Đánh giá trên held-out test set (không dùng validation set để tune rồi lại test trên đó — data leakage). Metric phụ thuộc bài toán: accuracy/F1 cho classification, RMSE/MAE cho regression, BLEU/ROUGE cho text generation, MRR/nDCG cho retrieval. Phải đạt ngưỡng trước khi qua phase tiếp theo.

Phase 5: Model versioning + registry

Lưu model artifact (file weight, config) kèm metadata: metric trên test set, data version dùng để train, code commit, người tạo. Model Registry cung cấp interface để compare, promote (staging → production), và rollback. Bài 42 đi sâu vào phần này.

Phase 6: Deployment

Serve model theo 2 mode chính: real-time inference (request → response trong milliseconds, dùng FastAPI / TorchServe / Triton) hoặc batch inference (chạy định kỳ trên tập data lớn, output lưu vào DB hoặc file). Module 1–6 trong series này đã cover deployment.

Phase 7: Monitoring

Track các metric ở production: input distribution (có drift so với training data không?), output distribution, latency, error rate, và accuracy nếu có ground truth. Khi phát hiện vấn đề → trigger alert.

Phase 8: Retraining

Khi drift vượt ngưỡng hoặc theo schedule (ví dụ weekly). Retraining lý tưởng là trigger tự động pipeline từ phase 1, không phải chạy notebook tay lại. Kết quả retrain → đi qua evaluation → vào registry → deploy nếu metric cải thiện.

Google Practitioners Guide (2021) định nghĩa 3 levels. Không phải level cao hơn thì tốt hơn một cách tuyệt đối — level phù hợp phụ thuộc vào quy mô team và nhu cầu thực tế.

Level 0 — Manual

Scientist train model trong notebook, export file, push lên server thủ công hoặc copy qua SSH. Không có version control cho model, không có pipeline tự động, không có monitoring có cấu trúc.

Đặc điểm: deploy = "copy file lên server". Retrain = "chạy lại notebook". Đây là điểm xuất phát của đa số team mới.

Vấn đề: không reproducible, không audit trail, model degrade theo thời gian mà không ai biết.

Level 1 — ML pipeline automation

Pipeline code được viết dưới dạng script / DAG (Directed Acyclic Graph) và có thể chạy tự động. Experiment tracking bật. Data và model versioning có cơ bản. Có thể trigger retrain khi cần mà không cần người chạy tay.

Tools đặc trưng: MLflow tracking, DVC, Airflow hoặc Prefect cho orchestration.

Phù hợp với: phần lớn startup AI production-ready. Level này là target hợp lý cho cá nhân và team nhỏ.

Level 2 — CI/CD automation

Mỗi lần push code → tự động chạy data validation → train → evaluate → nếu đạt threshold → deploy lên staging → sau approval → deploy production. Monitoring tự động trigger alert và có thể trigger retrain pipeline.

Tools đặc trưng: GitHub Actions / GitLab CI tích hợp với ML pipeline, feature store, online model registry với approval workflow.

Phù hợp với: team có dedicated ML platform engineer, nhiều model production, yêu cầu compliance cao.

Khi bắt đầu: hướng đến Level 1. Level 2 thêm overhead đáng kể và không cần thiết cho team nhỏ hoặc khi model train không thường xuyên.

MLOps ecosystem lớn và phân mảnh. Phần này chỉ overview — các bài 40–44 sẽ đi sâu vào từng tool.

Experiment tracking và model registry

• MLflow — open source, self-hosted, tracking + registry + model serving UI. Phổ biến nhất trong corporate environment. Bài 40.
• Weights & Biases (W&B) — managed SaaS, UI tốt hơn MLflow, có cộng đồng lớn trong research. Bài 41.
• Neptune.ai, Comet — alternatives managed, ít phổ biến hơn hai cái trên.

Data versioning

• DVC (Data Version Control) — open source, hoạt động như Git nhưng cho large file, tích hợp S3/GCS/Azure. Bài 43.
• LakeFS — Git-like versioning cho data lake (S3-compatible). Phù hợp cho team lớn với data lake.
• Pachyderm — pipeline + versioning kết hợp, cần Kubernetes.

Pipeline orchestration

• Apache Airflow — battle-tested, phổ biến nhất, Python DAG. Curve học cao hơn nhưng mature.
• Prefect, Dagster — alternatives hiện đại hơn Airflow, DX tốt hơn, cả hai có managed tier.
• Kubeflow Pipelines — native Kubernetes, phù hợp khi infra đã là k8s.

Feature store

• Feast — open source feature store, tích hợp với nhiều offline/online store.
• Tecton — managed enterprise feature store.
• AWS SageMaker Feature Store, Vertex AI Feature Store — nếu đã dùng managed ML platform của cloud provider.

Model serving

• TorchServe — serving cho PyTorch model.
• TensorFlow Serving — serving cho TensorFlow model.
• Triton Inference Server (NVIDIA) — multi-framework, GPU-optimized, phù hợp production lớn.
• Ray Serve — serving tích hợp trong Ray ecosystem, linh hoạt.
• vLLM, TGI (Text Generation Inference) — chuyên cho LLM với optimized throughput.

Monitoring

• Evidently — open source, drift detection và data quality report. Nhẹ, dễ integrate.
• Whylabs, Arize, Fiddler — managed monitoring platform với UI.
• Prometheus + Grafana — cho infrastructure metrics (latency, throughput, resource usage). Module 8 đi sâu.

CI/CD cho ML

• GitHub Actions, GitLab CI — CI/CD phổ thông, có thể extend cho ML workflow.
• CML (Continuous Machine Learning) — layer trên GitHub/GitLab Actions, tự động post metric report vào PR comment.

LLMOps = MLOps + các thành phần đặc thù cho LLM:

• Prompt versioning: prompt thay đổi ảnh hưởng đến output như code thay đổi → cần track version
• Prompt evaluation: chạy prompt trên tập câu hỏi chuẩn (eval set), đo chất lượng bằng LLM judge hoặc human annotation
• RAG quality: retrieval precision, context relevance, answer faithfulness
• Hallucination detection: model trả về fact không có trong context hay không
• Cost tracking: token usage + cost per request (quan trọng với managed API như OpenAI, Anthropic)

Điểm khác biệt lớn nhất: LLM ít khi được "retrain" trên data riêng của team (vì chi phí rất cao). Focus của LLMOps shift sang prompt engineering, RAG pipeline quality, và fine-tuning nhẹ (LoRA, QLoRA) thay vì full training.

Tools LLMOps

• LangSmith (LangChain) — trace, debug, evaluate LangChain / LangGraph pipeline
• Helicone — proxy + observability cho OpenAI/Anthropic API, track cost và latency
• PromptLayer — version control và analytics cho prompt
• Arize Phoenix — open source, trace + evaluation cho LLM và ML

Nếu team chủ yếu dùng LLM API (không train model riêng), LLMOps là relevant hơn MLOps truyền thống. Nhưng nguyên tắc nền tảng — reproducibility, traceability, monitoring — vẫn giống nhau.

Nên đầu tư vào MLOps khi

• Team có hơn 2 ML engineer làm việc trên cùng project
• Model được retrain hơn 1 lần/tháng
• Có hơn 1 model đang chạy production đồng thời
• Khách hàng hoặc regulation yêu cầu audit trail (tài chính, y tế, pháp lý)
• Model failure có tác động trực tiếp đến doanh thu hoặc người dùng

Chưa cần MLOps đầy đủ khi

• Đang làm POC, hackathon, hoặc project học tập
• Chỉ có 1 model, train 1 lần, không có kế hoạch retrain
• Team 1 người, model nhỏ, không có SLA
• Infra budget chưa cho phép chạy thêm service (MLflow server, artifact storage, ...)

Quan trọng: đừng cố implement Level 2 ngay từ đầu khi chưa có Level 1 vững chắc. Over-engineering MLOps sớm là một trong những lý do khiến nhiều project bị chậm — bỏ nhiều thời gian setup pipeline hơn là làm model tốt hơn.

Với team nhỏ hoặc startup, managed platform (AWS SageMaker, Google Vertex AI, Databricks MLflow Managed) thường cost-effective hơn tự build và maintain infrastructure MLOps.

Nếu bạn đang ở Level 0 và muốn dần lên Level 1, thứ tự ưu tiên hợp lý:

1. Git + Dockerfile — đã có ở Module 6. Code phải reproducible trước khi làm thêm bất cứ thứ gì.
2. Experiment tracking — MLflow (bài 40) hoặc W&B (bài 41). Từ bây giờ mỗi lần train đều có log. Chi phí setup thấp, lợi ích ngay lập tức.
3. Model registry — bài 42. Sau khi có tracking, promote model tốt nhất vào registry thay vì để file .pkl trong thư mục.
4. Data versioning — bài 43 (DVC). Bước này quan trọng khi bắt đầu retrain thường xuyên hoặc khi data thay đổi.
5. CI/CD — bài 44 (GitHub Actions). Automation pipeline validate + train + deploy sau khi đã có 1–4 vững.
6. Monitoring — Module 8. Chỉ monitor được khi đã có model đang chạy ổn định.

Không cần làm tất cả cùng lúc. Mỗi bước mang lại giá trị độc lập.

MLOps cần đầu tư thời gian. Để biết đầu tư có hiệu quả không, cần đo bằng số liệu cụ thể:

• Lead time: thời gian từ lúc commit code (hoặc có data mới) đến lúc model lên production. Mục tiêu: giảm dần từ "vài tuần" xuống "vài ngày" hoặc "vài giờ".
• Deploy failure rate: tỷ lệ lần deploy dẫn đến incident (model không serve được, metric tụt mạnh). Mục tiêu: giảm bằng cách có validation gate trước deploy.
• MTTR (Mean Time To Recovery): khi model có vấn đề ở production, mất bao lâu để phát hiện + rollback + fix. Monitoring tốt giảm phần phát hiện; registry + versioning tốt giảm phần rollback.
• Số experiment / tuần: proxy đo productivity của team ML. Nếu tracking tốt, team có thể chạy và compare nhiều experiment hơn trong cùng thời gian.

"Notebook là source of truth"

Notebook tốt cho exploratory analysis nhưng không phải production code. Notebook trộn data loading, feature engineering, training, visualization vào cùng một file — không test được, không reproduce được khi state kernel thay đổi. Khi cần reproduce một model từ 3 tháng trước, notebook state không đủ thông tin. Giải pháp: refactor thành Python script có argparse / config file, commit vào Git.

Model file trong Git

File .pkl hay .pt có thể từ vài chục MB đến vài GB. Git không được thiết kế cho binary blob lớn — clone chậm, diff vô nghĩa, history phình to. Dùng DVC hoặc Model Registry để lưu artifact, Git chỉ giữ code và config.

Dùng latest tag cho model

Nếu model registry chỉ có một tag latest, bạn không thể biết production đang dùng version nào khi cần debug. Pin tag cụ thể cho mỗi lần deploy: v1.2.3 hoặc commit hash.

Không có monitoring

Model degrade lặng lẽ là trường hợp phổ biến nhất. User không complain vì họ không biết output đúng phải như thế nào, hoặc đã chuyển sang dùng competitor. Monitoring input distribution là bước tối thiểu.

Retrain từ scratch hàng tuần mà không track

Nếu mỗi lần retrain không log metric, bạn không biết model có đang cải thiện không. Có thể data pipeline bị lỗi và model đang được train trên data xấu hơn — nhưng không ai biết.

Mua tool đắt trước khi có pipeline cơ bản

Một số team mua enterprise MLOps platform (Databricks, SageMaker Studio, Vertex AI Workbench) trước khi có experiment tracking cơ bản hay script train reproducible. Tool đắt không tự đưa team lên Level 1. Nền tảng cần phải là practice, sau đó mới là tool.

• ✅ MLOps = practice + tool để đưa model từ notebook → production và duy trì ổn định. Không phải framework, là discipline.
• ✅ Khác DevOps ở 3 điểm: artifact (code + data + model), testing (thêm data validation + model eval), monitoring (thêm drift + accuracy).
• ✅ Lifecycle gồm 8 phase: data ingestion → preparation → training → evaluation → versioning → deployment → monitoring → retraining.
• ✅ 3 maturity levels: Level 0 (manual), Level 1 (pipeline automation), Level 2 (full CI/CD). Target thực tế cho phần lớn team: Level 1.
• ✅ LLMOps = MLOps + prompt versioning, prompt eval, RAG quality, hallucination detection, cost tracking.
• ✅ Bắt đầu với experiment tracking (MLflow / W&B) → model registry → data versioning → CI/CD. Không cần làm tất cả cùng lúc.
• ✅ Anti-pattern cần tránh: notebook là source of truth, model file trong Git, dùng latest tag, không có monitoring.

Bài 40: Experiment Tracking với MLflow — cài đặt MLflow, log parameter + metric + artifact trong training script, so sánh experiment runs qua UI, và lưu model vào MLflow model registry.