MLOps (machine learning operations) là tập hợp thực hành, quy trình và công cụ để đưa mô hình học máy vào vận hành và giữ cho nó hoạt động đúng theo thời gian: quản lý phiên bản dữ liệu và mô hình, tự động hoá huấn luyện và triển khai, giám sát chất lượng, phát hiện xuống cấp và cập nhật mô hình. Nó áp dụng tinh thần DevOps vào phần mềm có thêm một thành phần đặc biệt — mô hình — mà hành vi phụ thuộc vào dữ liệu chứ không chỉ vào mã.
MLOps cần thiết vì mô hình không hỏng theo cách phần mềm thường hỏng. Nó không báo lỗi, vẫn trả về con số mỗi ngày, chỉ là con số ngày càng sai khi thế giới thay đổi khác dữ liệu huấn luyện. Không có giám sát, doanh nghiệp thường phát hiện ra khi thiệt hại kinh doanh đã xảy ra. Bài viết giải thích cơ chế xuống cấp, thành phần của MLOps, mức trưởng thành, phiên bản cho ứng dụng mô hình ngôn ngữ (LLMOps) và lộ trình cho doanh nghiệp vừa.
Mô hình chỉ là phần nhỏ của hệ thống học máy
Bài báo "Hidden Technical Debt in Machine Learning Systems" của Sculley và cộng sự tại Google (NeurIPS 2015) là điểm mốc của tư duy MLOps. Luận điểm chính: trong một hệ thống học máy thật, đoạn mã mô hình chỉ là một ô nhỏ ở giữa, bao quanh bởi hạ tầng lớn hơn nhiều — thu thập dữ liệu, kiểm tra dữ liệu, trích xuất đặc trưng, quản lý cấu hình, phục vụ dự đoán, giám sát. Và chính phần bao quanh ấy tích tụ "nợ kỹ thuật" nhanh hơn phần mềm thông thường.
Các tác giả chỉ ra những dạng nợ đặc thù. Vướng víu (entanglement): thay đổi một đặc trưng đầu vào làm thay đổi hành vi toàn bộ mô hình, theo nguyên lý họ gọi là "thay đổi bất cứ thứ gì là thay đổi mọi thứ". Phụ thuộc dữ liệu không được khai báo: một bảng do bộ phận khác quản lý đổi định nghĩa cột, mô hình vẫn chạy nhưng sai. Vòng phản hồi: mô hình đề xuất sản phẩm ảnh hưởng hành vi mua, hành vi mua lại thành dữ liệu huấn luyện kỳ sau. Mã keo và rừng đường ống: các đoạn mã chắp nối dữ liệu mọc lên không kiểm soát.
Bài học quản trị: ngân sách và nhân sự cho một dự án học máy phải tính cả phần hạ tầng và vận hành dài hạn, không chỉ phần xây mô hình. Dự án dừng ở mô hình đạt độ chính xác tốt trên máy của nhà khoa học dữ liệu mới chỉ đi được một đoạn ngắn.
Vì sao mô hình xuống cấp theo thời gian
Trôi dạt dữ liệu (data drift). Phân bố dữ liệu đầu vào thay đổi so với lúc huấn luyện. Ví dụ một chuỗi bán lẻ mở thêm cửa hàng ở khu công nghiệp, nơi cơ cấu khách hàng khác hẳn các cửa hàng nội đô mà mô hình dự báo nhu cầu đã học.
Trôi dạt khái niệm (concept drift). Quan hệ giữa đầu vào và kết quả thay đổi, dù đầu vào trông vẫn giống cũ. Ví dụ sau khi đối thủ đổi chính sách giá, cùng một hồ sơ hành vi khách hàng nhưng xác suất rời bỏ đã khác. Những cú sốc lớn như dịch bệnh có thể vô hiệu hoá mô hình dự báo gần như chỉ sau một đêm.
Thay đổi ở hệ thống thượng nguồn. Bộ phận khác đổi đơn vị tính, đổi mã sản phẩm, sửa cách ghi nhận đơn hàng. Đây là nguyên nhân rất phổ biến và hoàn toàn không liên quan đến thế giới bên ngoài.
Vòng phản hồi do chính mô hình gây ra. Mô hình chấm điểm rủi ro từ chối một nhóm hồ sơ, nên doanh nghiệp không bao giờ quan sát được kết quả thật của nhóm đó; dữ liệu huấn luyện kỳ sau bị lệch theo quyết định của mô hình kỳ trước.
Nhãn đến trễ. Nhiều bài toán chỉ biết đúng sai sau vài tuần đến vài tháng, như khoản vay có trả được hay không. Trong khoảng trễ đó, phải giám sát bằng chỉ báo gián tiếp như phân bố đầu vào và đầu ra.
Các thành phần của một hệ thống MLOps
Không cần đủ mọi thành phần ngay từ đầu, nhưng nên biết bức tranh tổng thể để đầu tư dần:
- Quản lý phiên bản dữ liệu, mã và mô hình: biết chính xác mô hình đang chạy được huấn luyện từ dữ liệu nào, mã nào, tham số nào, để tái lập và quay lui khi cần.
- Kiểm tra dữ liệu tự động: trước khi huấn luyện và trước khi dự đoán, kiểm tra cột thiếu, giá trị ngoài miền, thay đổi phân bố bất thường.
- Đường ống huấn luyện tự động: từ lấy dữ liệu, tạo đặc trưng, huấn luyện, đánh giá đến đóng gói, chạy được bằng một lệnh hoặc theo lịch, không phụ thuộc máy cá nhân của ai.
- Kho đăng ký mô hình (model registry): lưu các phiên bản mô hình kèm chỉ số đánh giá, trạng thái (thử nghiệm, đang chạy, đã ngừng) và người phê duyệt.
- Triển khai an toàn: chạy bóng (mô hình mới dự đoán song song nhưng không ảnh hưởng quyết định), triển khai dần cho một phần lưu lượng, quay lui nhanh.
- Kho đặc trưng (feature store) ở tổ chức có nhiều mô hình dùng chung đặc trưng, để tránh mỗi nhóm tính một kiểu và lệch giữa lúc huấn luyện với lúc phục vụ.
- Giám sát và cảnh báo ở nhiều tầng: hệ thống, dữ liệu, chất lượng mô hình, chỉ số kinh doanh.
Mức trưởng thành MLOps
Tài liệu hướng dẫn kiến trúc MLOps của Google Cloud mô tả ba mức trưởng thành được dùng rộng rãi như một thước đo tham khảo:
| Mức | Đặc điểm | Dấu hiệu điển hình | Phù hợp khi |
|---|---|---|---|
| Mức 0 — thủ công | Huấn luyện và triển khai bằng tay, nhà khoa học dữ liệu bàn giao tệp mô hình cho kỹ sư | Huấn luyện lại vài lần một năm, không ai chắc mô hình đang chạy từ dữ liệu nào | Mô hình đầu tiên, ít thay đổi |
| Mức 1 — tự động hoá đường ống huấn luyện | Đường ống huấn luyện chạy tự động theo lịch hoặc khi có dữ liệu mới; có kiểm tra dữ liệu và đánh giá trước khi đưa lên | Huấn luyện lại liên tục, có kho đăng ký mô hình, có giám sát | Mô hình quan trọng, dữ liệu thay đổi thường xuyên |
| Mức 2 — tự động hoá cả CI/CD cho đường ống | Thay đổi mã đường ống cũng được kiểm thử và triển khai tự động | Nhiều mô hình, nhiều nhóm, thử nghiệm nhanh | Tổ chức có danh mục mô hình lớn |
Phần lớn doanh nghiệp vừa ở Việt Nam bắt đầu ở mức 0 và không cần nhảy thẳng lên mức 2. Mục tiêu hợp lý là đưa các mô hình quan trọng lên mức 1: huấn luyện lại tái lập được, có kiểm tra dữ liệu, có giám sát và quay lui được. Đầu tư vào nền tảng tự động hoá đầy đủ chỉ hợp lý khi số mô hình và tần suất thay đổi đủ lớn.
LLMOps: vận hành ứng dụng mô hình ngôn ngữ khác gì
Khi doanh nghiệp dùng mô hình ngôn ngữ qua API hoặc mô hình trọng số mở, phần lớn không huấn luyện mô hình, nhưng nhu cầu vận hành vẫn còn nguyên và chỉ đổi hình dạng. Thứ cần quản lý phiên bản giờ là câu lệnh hệ thống, cấu hình truy xuất, kho tài liệu và phiên bản mô hình của nhà cung cấp. Một dòng sửa trong câu lệnh có thể thay đổi hành vi nhiều như huấn luyện lại một mô hình.
Nguồn xuống cấp cũng khác. Nhà cung cấp cập nhật hoặc ngừng một phiên bản mô hình; tài liệu nội bộ lỗi thời mà không ai gỡ khỏi kho truy xuất; người dùng bắt đầu hỏi loại câu mới. Giám sát không còn dựa chủ yếu vào chỉ số độ chính xác trên nhãn, mà dựa vào bộ đề đánh giá chạy định kỳ, phản hồi người dùng, tỷ lệ chuyển cho người, chi phí token và độ trễ.
Vì vậy LLMOps tập trung vào: đánh giá hồi quy mỗi khi thay đổi bất cứ thành phần nào; ghi nhật ký đầy đủ đầu vào, ngữ cảnh truy xuất và đầu ra (trong giới hạn bảo vệ dữ liệu cá nhân); theo dõi chi phí theo tính năng; quản lý vòng đời tài liệu trong kho truy xuất; và kế hoạch chuyển đổi khi phiên bản mô hình đang dùng bị ngừng. Tư duy cốt lõi vẫn giống MLOps: mọi thứ ảnh hưởng tới hành vi hệ thống phải được quản lý phiên bản, kiểm thử trước khi thay đổi, và giám sát sau khi thay đổi.
Giám sát gì: năm tầng chỉ số
Một bảng giám sát mô hình hữu ích nên có đủ năm tầng, từ kỹ thuật đến kinh doanh:
- Tầng hệ thống: độ trễ, tỷ lệ lỗi, thông lượng, chi phí hạ tầng — giống mọi dịch vụ phần mềm.
- Tầng dữ liệu đầu vào: tỷ lệ giá trị thiếu, giá trị ngoài miền, thay đổi phân bố của các đặc trưng quan trọng. Trong chấm điểm tín dụng, chỉ số ổn định quần thể (PSI) hay được dùng, với quy ước kinh nghiệm phổ biến là dưới 0,1 coi như ổn định, trên 0,25 cần điều tra.
- Tầng đầu ra: phân bố dự đoán có lệch so với thường lệ không — ví dụ tỷ lệ hồ sơ bị xếp rủi ro cao đột ngột tăng gấp đôi.
- Tầng chất lượng khi có nhãn: sai số dự báo, độ chính xác, độ phủ tính trên dữ liệu mới khi kết quả thật về; so sánh theo nhóm khách hàng, khu vực để phát hiện suy giảm cục bộ.
- Tầng kinh doanh: chỉ số mà mô hình được xây để cải thiện — tỷ lệ hết hàng, tỷ lệ nợ xấu, tỷ lệ chuyển đổi. Mô hình có thể giữ nguyên độ chính xác kỹ thuật mà chỉ số kinh doanh vẫn xấu đi vì quy trình xung quanh thay đổi.
Mỗi chỉ số cần ngưỡng cảnh báo, người nhận cảnh báo và hành động tương ứng đã thống nhất trước: điều tra, huấn luyện lại, quay lui về phiên bản trước, hoặc tạm chuyển sang quy tắc dự phòng. Cảnh báo không có người xử lý chỉ tạo thêm tiếng ồn.
Lộ trình cho doanh nghiệp vừa
Không cần mua nền tảng lớn ngay. Một lộ trình thực tế cho tổ chức có vài mô hình đầu tiên:
- Kiểm kê mô hình đang chạy: ai xây, chạy ở đâu, dữ liệu từ đâu, ai dùng kết quả, lần huấn luyện gần nhất khi nào.
- Đưa mã và cấu hình vào kho quản lý phiên bản, ghi lại dữ liệu huấn luyện của mô hình đang chạy để tái lập được.
- Viết kịch bản huấn luyện chạy được từ đầu đến cuối trên máy chủ chung, không phụ thuộc máy cá nhân.
- Thêm kiểm tra dữ liệu và giám sát cơ bản ở tầng đầu vào và đầu ra, kèm cảnh báo.
- Đặt lịch đánh giá định kỳ khi nhãn thật về và quy tắc khi nào huấn luyện lại.
- Thoả thuận với các bộ phận sở hữu dữ liệu nguồn rằng mọi thay đổi định nghĩa dữ liệu phải được báo trước — biện pháp tổ chức rẻ nhất mà hiệu quả nhất.
Câu hỏi thường gặp
Bao lâu nên huấn luyện lại mô hình một lần?
Không có tần suất chung. Huấn luyện lại theo lịch đơn giản và dễ quản lý; huấn luyện lại khi giám sát phát hiện suy giảm tiết kiệm hơn nhưng cần hệ thống giám sát tốt. Nhiều tổ chức kết hợp: lịch cố định làm nền, cộng huấn luyện bất thường khi có cảnh báo. Tần suất phù hợp tìm được bằng cách đo tốc độ suy giảm thực tế.
Doanh nghiệp chỉ dùng mô hình ngôn ngữ qua API có cần MLOps không?
Cần phần tương ứng gọi là LLMOps: quản lý phiên bản câu lệnh và cấu hình, bộ đề đánh giá hồi quy, nhật ký, giám sát chi phí và chất lượng, kế hoạch khi nhà cung cấp đổi phiên bản. Không có những thứ này, ứng dụng có thể tụt chất lượng sau một bản cập nhật mà không ai biết.
MLOps có phải việc của nhà khoa học dữ liệu không?
Là việc chung. Nhà khoa học dữ liệu hiểu mô hình và chỉ số; kỹ sư dữ liệu và kỹ sư nền tảng lo đường ống, hạ tầng, triển khai; người nghiệp vụ định nghĩa chỉ số kinh doanh và ngưỡng chấp nhận. Ở tổ chức nhỏ, một người có thể kiêm nhiều vai, nhưng cả ba góc nhìn phải có mặt.
Quay lui mô hình khác quay lui phần mềm ở điểm nào?
Quay lui mô hình cần phiên bản cũ còn tương thích với dữ liệu đầu vào hiện tại. Nếu thượng nguồn đã đổi định dạng hay ý nghĩa một cột, mô hình cũ cũng có thể sai. Vì vậy nên có thêm phương án dự phòng không phụ thuộc mô hình, như quy tắc đơn giản hoặc chuyển cho người xử lý.
Có nên mua nền tảng MLOps trọn gói không?
Khi số mô hình còn ít, công cụ mã nguồn mở và dịch vụ sẵn có của nhà cung cấp đám mây thường đủ, kèm kỷ luật quy trình. Nền tảng trọn gói đáng cân nhắc khi có nhiều nhóm cùng xây mô hình và chi phí phối hợp bắt đầu lớn. Công cụ không thay được việc định nghĩa ai chịu trách nhiệm mô hình nào.