Đưa một mô hình Machine Learning từ notebook lên môi trường thật không chỉ là chuyện đóng gói API rồi bấm triển khai. Mô hình có thể chạy tốt trên tập kiểm thử nhưng vẫn gặp vấn đề khi tiếp xúc với dữ liệu thật: định dạng đầu vào thay đổi, phân phối dữ liệu lệch, độ trễ cao, hoặc dự đoán sai ở một nhóm người dùng cụ thể. Vì vậy, thay vì thay thế mô hình cũ ngay lập tức, nhiều đội ngũ nên triển khai theo từng bước. Hai cách thực tế và dễ áp dụng là shadow deployment và canary deployment. Shadow deployment là gì? Shadow deployment nghĩa là mô hình mới được chạy song song với hệ thống hiện tại, nhưng kết quả của nó chưa trả về cho người dùng. Người dùng vẫn nhận kết quả từ mô hình cũ hoặc logic cũ, còn mô hình mới chỉ “quan sát” cùng dữ liệu đầu vào và ghi lại dự đoán để phân tích. Ví dụ: một hệ thống duyệt bình luận đang dùng mô hình A để phát hiện nội dung spam. Bạn muốn thử mô hình B. Với shadow deployment, mỗi bình luận mới vẫn được xử lý bởi mô hình A như bình thường, nhưng đồng thời cũng gửi sang mô hình B. Kết quả của B được lưu lại để so sánh: B có phát hiện thêm spam không, có chặn nhầm nhiều hơn không, thời gian phản hồi có ổn không. Cách này hữu ích khi bạn muốn kiểm tra mô hình trong điều kiện thật mà chưa muốn chịu rủi ro ảnh hưởng đến người dùng. Cần theo dõi gì khi chạy shadow? Không nên chỉ lưu dự đoán rồi “để đó”. Ít nhất nên theo dõi các nhóm chỉ số sau: - Tỷ lệ khác biệt giữa mô hình mới và mô hình cũ: hai mô hình bất đồng ở những trường hợp nào? - Phân phối điểm dự đoán: mô hình mới có thường xuyên tự tin quá mức không? - Độ trễ: mô hình mới có làm pipeline chậm đi đáng kể không? - Lỗi kỹ thuật: request lỗi, timeout, dữ liệu thiếu trường, sai kiểu dữ liệu. - Mẫu cần kiểm tra thủ công: chọn các trường hợp mô hình mới và cũ cho kết quả trái ngược để con người đánh giá. Một lỗi phổ biến là chỉ nhìn vào độ chính xác tổng thể nếu có nhãn sau đó. Trong thực tế, bạn nên kiểm tra theo lát cắt dữ liệu: loại người dùng, khu vực, thiết bị, loại nội dung, thời điểm trong ngày. Nhiều mô hình không hỏng toàn bộ, mà hỏng ở một nhóm nhỏ nhưng quan trọng. Canary deployment là gì? Canary deployment là bước tiến thêm: mô hình mới bắt đầu phục vụ thật, nhưng chỉ cho một phần nhỏ lưu lượng. Ví dụ ban đầu cho 1% người dùng, sau đó tăng lên 5%, 20%, 50% nếu các chỉ số vẫn ổn. Ví dụ: một mô hình gợi ý sản phẩm mới được triển khai cho 2% phiên truy cập. Nếu tỷ lệ nhấp, tỷ lệ mua, độ trễ và tỷ lệ lỗi không xấu đi so với nhóm dùng mô hình cũ, đội ngũ có thể tăng dần lưu lượng. Nếu phát hiện vấn đề, rollback về mô hình cũ nhanh hơn nhiều so với việc đã thay thế toàn bộ hệ thống. Điểm quan trọng của canary là phải có tiêu chí dừng rõ ràng trước khi triển khai. Đừng chờ “cảm giác có vẻ không ổn”. Hãy định nghĩa trước: nếu độ trễ p95 vượt ngưỡng, tỷ lệ lỗi tăng, hoặc chỉ số kinh doanh giảm trong một khoảng quan sát nhất định thì tự động dừng hoặc giảm lưu lượng. Shadow khác canary như thế nào? - Shadow: mô hình mới không ảnh hưởng người dùng, phù hợp để kiểm tra kỹ thuật và hành vi dự đoán trong dữ liệu thật. - Canary: mô hình mới có ảnh hưởng một phần người dùng, phù hợp để đo tác động thực tế. Thông thường, nên đi theo thứ tự: kiểm thử offline, shadow deployment, canary deployment, rồi mới rollout toàn bộ. Không phải dự án nào cũng cần đầy đủ tất cả bước, nhưng với hệ thống có rủi ro cao như tài chính, y tế, kiểm duyệt nội dung, chống gian lận, quy trình này rất đáng cân nhắc. Một checklist triển khai thực tế Trước khi bật shadow hoặc canary, hãy chuẩn bị: 1. Phiên bản hóa mô hình và dữ liệu đầu vào Mỗi dự đoán nên ghi lại model_version, thời gian, đặc trưng đầu vào quan trọng, kết quả dự đoán và trạng thái xử lý. Nếu có lỗi, bạn cần biết lỗi đến từ phiên bản nào. 2. Có cơ chế rollback nhanh Triển khai mô hình mới mà rollback khó thì rất nguy hiểm. Tốt nhất nên có khả năng chuyển lưu lượng về mô hình cũ bằng cấu hình, không cần sửa code lớn. 3. Theo dõi cả chỉ số ML và chỉ số hệ thống Chỉ số ML như precision, recall, AUC, tỷ lệ bất đồng là cần thiết, nhưng chưa đủ. Cần theo dõi thêm latency, throughput, timeout, chi phí tính toán, dung lượng log. 4. Chọn mẫu để đánh giá thủ công Với nhiều bài toán, nhãn thật đến muộn hoặc không đầy đủ. Việc lấy mẫu các ca quan trọng để con người xem lại giúp phát hiện lỗi sớm hơn. 5. Đừng tăng lưu lượng quá nhanh Nếu canary 1% ổn trong vài phút không có nghĩa là 100% sẽ ổn. Một số lỗi chỉ xuất hiện theo khung giờ, nhóm người dùng hoặc loại dữ liệu hiếm. Lời khuyên cuối cùng Một mô hình tốt không chỉ là mô hình có điểm số cao trong báo cáo thử nghiệm. Mô hình tốt còn phải chịu được dữ liệu thật, vận hành ổn định, có thể giám sát và có đường lui khi gặp sự cố. Shadow và canary deployment giúp đội ngũ AI chuyển từ tư duy “triển khai một lần rồi hy vọng” sang tư duy “triển khai có kiểm soát”. Đây là khác biệt lớn giữa một demo chạy được và một hệ thống Machine Learning đáng tin trong sản phẩm thật.