MLOps cho FDE: năm việc phải dựng xong trước khi model chạy trong hệ thống của khách

Thử hình dung bạn vừa đưa một model dự báo nhu cầu vào hệ thống đặt hàng của một chuỗi siêu thị. Trong notebook sai số rất đẹp, buổi demo với ban giám đốc cũng trơn tru. Ba tuần sau, quản lý kho gọi điện: đơn đặt sữa tươi tăng gấp đôi bình thường, và trong phòng không ai biết model đang chạy là phiên bản nào.

Tình huống này hiếm khi do model dở. Tài liệu kiến trúc MLOps của Google Cloud nói thẳng rằng phần khó là dựng được một hệ thống ML tích hợp và giữ cho nó chạy liên tục trong production. Ở ít nhất một công ty tuyển FDE, phần việc này được ghi thẳng vào mô tả công việc.

Tin tuyển dụng Forward Deployed Infrastructure Engineer của Palantir liệt kê việc phải làm tại nơi triển khai: monitoring và alerting, quản lý cấu hình, nâng cấp hệ thống.

Người được tuyển cũng cùng chịu trách nhiệm chẩn đoán, xử lý và phòng ngừa sự cố production, kể cả trực on-call. Nếu bạn nhắm tới những vị trí như vậy, đây là kỹ năng được kiểm tra trong công việc hằng ngày chứ không chỉ để ghi cho đẹp CV.

Vì sao model chưa phải là sản phẩm?

Năm 2015, nhóm của D. Sculley công bố bài “Hidden Technical Debt in Machine Learning Systems” tại NIPS. Họ nhận thấy hệ thống ML thực tế thường kéo theo chi phí bảo trì rất lớn và kéo dài, với các nguồn như sự phụ thuộc vào dữ liệu hay những thay đổi của thế giới bên ngoài.

Siêu thị đổi mã hàng, máy POS cập nhật phần mềm, khách hàng đổi thói quen mua sắm sau Tết. Model vẫn giữ nguyên, nhưng dữ liệu nó nhận vào đã khác.

Vì vậy, ML có thêm một yêu cầu mà phần mềm thường không có. Google Cloud gọi đó là continuous training (CT), tức tự động train lại rồi đưa model mới ra phục vụ.

Họ cũng lưu ý rằng CD trong ML không còn là deploy một gói phần mềm hay một service, mà là deploy cả một hệ thống, và CI phải kiểm thử cả dữ liệu lẫn từng thành phần.

Martin Zinkevich, trong “Rules of Machine Learning”, đưa ra một lời khuyên ngắn gọn: giữ model đầu tiên thật đơn giản và làm đúng hạ tầng trước. Với FDE, thứ tự ưu tiên vì thế khá rõ. Những ngày đầu tại site của khách nên dành để dựng pipeline dữ liệu, chưa phải lúc tinh chỉnh tham số.

Làm thử với chuỗi siêu thị: năm việc dựng theo thứ tự

Việc đầu tiên là biết chính xác cái gì đang chạy. Quay lại cuộc gọi về sữa tươi: câu hỏi đầu tiên luôn là “model nào?”. Bài viết CD4ML trên trang của Martin Fowler đề xuất coi model như một artifact, có version và được deploy giống như mọi bản build. Ở mức tối thiểu, mỗi dòng log dự đoán phải ghi đủ thông tin để truy ngược lại:

log_prediction({
    "model_version": "demand-v14",
    "feature_snapshot": "2026-10-01",
    "store_id": "HCM-021",
    "sku": "SUA-TUOI-1L",
    "prediction": 240,
})

Có dòng log này, bạn trả lời được trong vài phút thay vì mất vài ngày. Bạn cũng rollback được về phiên bản trước khi kho đang chờ đơn.

Tiếp theo là chỉ dùng một nguồn feature. Giả sử feature “doanh số trung bình 7 ngày” lúc train được tính từ data warehouse sau khi đã trừ hàng trả lại. Lúc chạy thật, feature đó lại lấy từ luồng POS realtime, nơi hàng trả chưa được trừ. Nếu một mã hàng trong warehouse bán ròng 100 hộp mỗi ngày mà POS báo 115, model sẽ nhìn thấy một thế giới đông khách hơn 15% so với lúc nó được học. Đó là training-serving skew.

Google Cloud khuyên dùng feature store làm nguồn dữ liệu chung cho cả lúc thử nghiệm lẫn lúc phục vụ để tránh skew. Nhưng ngay cả khi chưa có feature store, bạn vẫn phải đo skew, đúng như quy tắc số 37 của Zinkevich.

Cách làm đơn giản nhất là ghi lại giá trị feature lúc serving, sau đó tính lại offline cho cùng ngày, cùng cửa hàng, rồi so sánh hai con số.

Việc thứ ba là kiểm thử hạ tầng tách khỏi ML. Zinkevich viết rằng hạ tầng phải được test độc lập với phần machine learning. Với chuỗi siêu thị, bạn có thể thay model bằng một baseline “ngốc”: tuần trước bán bao nhiêu thì tuần này dự báo bấy nhiêu. Sau đó cho baseline chạy hết đường ống, từ lúc đọc dữ liệu, sinh dự báo, cho tới khi ghi đơn vào hệ thống đặt hàng.

Nếu baseline cũng làm hỏng đơn hàng thì lỗi nằm ở pipeline, và bạn biết điều đó trước khi lỡ đổ lỗi cho model. Chỉ khi baseline chạy sạch mới nên thay model thật vào.

Sau đó là giám sát trên dữ liệu thật. Google Cloud định nghĩa monitoring là thu thập thống kê về hiệu năng của model dựa trên dữ liệu thật. Với bài toán dự báo, mỗi ngày khi số bán thực tế về, bạn so với dự báo của hôm trước rồi tính sai số theo từng nhóm hàng. Bên cạnh đó, bạn kiểm tra cả đầu vào như số dòng dữ liệu nhận được và tỷ lệ giá trị rỗng, vì dữ liệu hỏng thường lộ ra ở đây trước tiên.

Monitoring mà không có alert thì chỉ là một dashboard không ai mở. Ngưỡng cảnh báo nên được chốt cùng quản lý kho, bằng ngôn ngữ của họ, chẳng hạn “sai quá bao nhiêu phần trăm thì phải báo”. Ngưỡng do bạn tự đặt trong code thì họ không hiểu và cũng chẳng ai theo dõi.

Cuối cùng là đường quay về train. CD4ML nhấn mạnh rằng sau khi deploy phải hiểu được model chạy ra sao trong production và đưa dữ liệu thật quay về vòng train. Ở siêu thị, số bán thực tế hằng ngày chính là nhãn cho lần train sau. Sau khi train lại, cần một bước duyệt: model mới chỉ được thay model cũ khi nó tốt hơn trên vài tuần dữ liệu gần nhất.

Lúc 2 giờ sáng, bạn cần sẵn câu trả lời nào?

Một cách kiểm tra mức độ sẵn sàng là đặt mình vào cuộc gọi on-call và xem mỗi câu hỏi cần thứ gì để trả lời.

Câu hỏi của khách	Thứ phải có từ trước
Model nào đang chạy?	Version model ghi vào từng dòng log
Sai do dữ liệu hay do model?	Số đo skew và kết quả chạy baseline
Model bắt đầu tệ đi từ bao giờ?	Thống kê hiệu năng trên dữ liệu thật, có alert
Sửa xong thì đưa lên kiểu gì?	Pipeline train lại có bước duyệt và rollback

Nếu ô nào trong cột bên phải còn trống, đó là việc cần làm trước khi model được phép ghi bất kỳ đơn hàng nào.

Những lỗi FDE hay mắc

Lỗi thứ hai là tin rằng dùng chung code tính feature thì không thể có skew, trong khi nguồn dữ liệu đầu vào có thể đã khác nhau. Lỗi thứ ba là chỉ theo dõi độ trễ và CPU, tưởng như vậy là đã monitor model.

Lỗi khó thấy nhất là bàn giao mà không bàn giao alert. Khi bạn rời site, cần có người bên khách biết cảnh báo gửi đến đâu và nhận được thì phải làm gì.

Thể hiện kỹ năng này trong CV thế nào?

Khi đọc JD của một vị trí FDE, hãy tìm các cụm như monitoring, alerting, upgrades, on-call, production issues. Đó là dấu hiệu công ty cần người biết vận hành hệ thống, không chỉ người biết train model.

Trong CV, thay vì viết “deploy model dự báo”, hãy viết cụ thể hơn, ví dụ “dựng pipeline có version, đo skew giữa train và serving, đặt alert theo ngưỡng do nghiệp vụ chốt”.

Trước buổi phỏng vấn, nên chuẩn bị sẵn một câu chuyện có thật: lần gần nhất model của bạn chạy sai trên dữ liệu thật, bạn phát hiện ra bằng cách nào và mất bao lâu để khoanh vùng lỗi. Một câu chuyện như thế chứng minh đúng phần việc mà những tin tuyển dụng kiểu này mô tả, rõ hơn mọi con số độ chính xác.