Mô hình chỉ là một phần nhỏ của hệ thống. Bốn khối cần dựng:
1. Serving. Chọn theo yêu cầu độ trễ:
- Batch: chấm điểm định kỳ, ghi kết quả xuống bảng để ứng dụng đọc. Đơn giản, rẻ, đủ cho phần lớn bài toán (dự đoán rời bỏ, xếp hạng gợi ý hằng đêm).
- Realtime: dịch vụ có endpoint đồng bộ. Cần đóng gói cả bước tiền xử lý cùng mô hình để tránh training-serving skew, đặt ngân sách độ trễ, và có phương án dự phòng (trả về quy tắc mặc định) khi mô hình lỗi hoặc quá hạn.
2. Kiểm thử trước khi mở lưu lượng.
- Shadow mode: mô hình nhận lưu lượng thật, ghi lại dự đoán nhưng chưa dùng để ra quyết định. So sánh với hệ thống hiện hành.
- Canary / A-B: mở dần theo tỷ lệ nhỏ, đo chỉ số nghiệp vụ chứ không chỉ AUC.
3. Giám sát — ba tầng, đừng chỉ có tầng đầu.
- Hạ tầng: độ trễ, tỷ lệ lỗi, throughput.
- Dữ liệu: tỷ lệ null, giá trị ngoài miền, phân phối từng feature, tỷ lệ giá trị phân loại chưa từng thấy. Đây là tầng bắt sự cố sớm nhất vì không cần chờ nhãn.
- Mô hình: phân phối điểm dự đoán, tỷ lệ dự đoán dương, và khi nhãn về thì tính metric theo lát cắt. Nhãn thường trễ vài ngày đến vài tháng — thiết kế pipeline gom nhãn ngay từ đầu, nếu không sẽ không bao giờ biết mô hình đúng hay sai.
4. Huấn luyện lại. Chốt trước: theo lịch cố định hay theo cảnh báo drift; dùng cửa sổ dữ liệu nào; ngưỡng nào thì được thay mô hình đang chạy; ai duyệt; rollback ra sao. Mô hình phải được phiên bản hoá cùng dữ liệu và code sinh feature — không thì không thể quay lại bản trước.
Hai điểm hay bị bỏ sót: feature store hoặc ít nhất một nơi dùng chung code sinh feature cho train và serve, và vòng phản hồi — nếu mô hình chặn một nhóm giao dịch thì nhóm đó không còn nhãn, dữ liệu huấn luyện kỳ sau sẽ lệch; cần giữ một phần lưu lượng không can thiệp để thu nhãn không thiên lệch.