Giới thiệu

Ứng dụng production, không chỉ là chứng minh độ chính xác cao ở tập test, mà phải là một hệ thống vận hành ổn định, chính xác, nhanh lẹ.

Dưới đây là một số nguyên tắc mình đúc rút được khi triển khai ứng dụng production.

I. Bắt đầu từ vấn đề của công ty, vấn đề của khách hàng, không phải từ thuật toán

Nhiều sai lầm trong quá khứ, mình thường bắt đầu bằng model, không tìm hiểu kỹ vấn đề mà khách hàng gặp phải.

Các DS thường hay lao vào optimizer hyper-parameter, lựa chọn NN hay tree base model. Mà quên mất rằng, model được build cho người sử dụng model dùng, mà người sử dụng model là ai, chắc chắn không phải chúng ta rồi.

Chúng ta cần ngồi lại với người trực tiếp sử dụng model để:

• Theo dõi quy trình hiện tại

• Hiểu chi phí quy bằng tiền của false positive và false negative

• Vẽ sơ đồ workflow , quy trình chỗ model áp dụng

• Xác định mức “tốt tối thiểu” của mô hình

Ví dụ: Bạn dev mô hình phát hiện gian lận , bắt được 98% gian lận, nhưng 10% giao dịch hợp lệ bị gắng cờ nhầm gian lận. Về các con số thì khá tốt, nhưng triển khai thực tế thì rất tệ. Tưởng tượng công ty scale lên 1 ngày có 1 triệu giao dịch, và tổng đài chăm sóc khác hàng sẽ nghe hơn 10 vạn cuộc gọi khiếu nại của khách hàng vì mô hình bắt nhầm. Thật tồi tệ.

Mô hình tốt nhất là mô hình đơn giản nhất, và mang lại hiệu quả kinh doanh nhất. Business first, không phải model first.

II. Dữ liệu là vàng, chất lượng của dữ liệu là tính năng quan trọng nhất

Một dự án “nhỏ” mình từng làm, tốn hơn 1 năm trời, chỉ để lấy mẫu. Chỉ để tìm dữ liệu tốt nhất, phù hợp nhất.

Tôi biết, có những dự án ngoài kia, hoặc bias ở các DS, chăm chút vào tối ưu model, căn ke dropout, norm, 10 hay 20 layer ….

Các bước cần thực hiện:

• Tạo các model check chất lượng của dữ liệu, nhúng vào trong pipeline ( cái này là best practice)

• Theo dõi sự thay đổi của dữ liệu liên tục (data drift). Môi trường production là dữ liệu thật, data sau khoảng thời gian sẽ có pattern, trend theo xu hướng nào đó, và thường sẽ khác xa lơ xa lắc so với training data. Việc theo dõi giúp chúng ta tái đánh giá liên tục model và đưa ra phương hướng xử lý phù hợp khi mô hình có dấu hiệu “tệ” hơn.

• Ghi log rõ ràng nguồn dữ liệu và các bước biến đổi. Khi vận hành production, thường sẽ có hiện tượng “ké” model. Data source sẽ đến từ một nguồn nào đó, không phải từ nguồn mà ở bước 1, nguồn nơi chúng ta phân tích mô hình, tốn ít nhất 1 tuần quan sát và vẽ sơ đồ. Và sẽ phải trả lời câu hỏi “cái dữ liệu quỷ quái này chui ở đâu ra vậy”.

• Hệ thống cảnh báo khi đặc trưng thống kê thay đổi.

Chúng ta có thể xây dựng một mô hình linear model với dữ liệu chất lượng cao. So với Deep learning với dữ liệu thiếu nhất quán, bias, out of date.

• linear model với dữ liệu chất lượng cao, tốn thời gian build data, có người là làm được.

• Deep learning với dữ liệu thiếu nhất quán, tốn tiền mua GPU B100, nhưng model thường khó trả lời cho câu hỏi, vì sao nó chạy được, vì sao nó đúng, vì sao nó sai

Bạn chọn cái nào?

III. Thiết kê mô hình với khả năng giải thích ngay từ đầu

Các mô hình “Black-box” thường được áp dụng rộng rãi. Nhưng trong production, mô hình cần phải giải thích được. Khi mô hình dự đoán sai, gây hậu quả, chúng ta cần hiểu vì sao nó sai, và làm cách nào để mô hình không mắc phải lỗi đó nữa.

Chiến lược:

• Với mỗi mẫu dự đoán, sử dụng phương pháp giải thích mô hình machine learning như SHAP (SHapley Additive exPlanations - dựa trên lý thuyết Shapley values trong game theory) hoặc LIME (Local Interpretable Model-agnostic Explanations - giải thích cục bộ một dự đoán bằng cách tạo dữ liệu giả gần điểm cần giải thích, rồi huấn luyện một mô hình đơn giản (ví dụ: linear model) để xấp xỉ mô hình phức tạp trong vùng lân cận)

• Sử dụng phương pháp giải thích mô hình độc lập, và kiểm định cho toàn bộ các mô hình.

• Xây dựng một baseline đơn giản, có thể sử dụng rule-base làm base line. Vừa đơn giản, vừa dễ hiểu, vừa dễ giải thích.

• Tài liệu hóa các đặc trưng với ngôn ngữ của khách hàng, hoặc ngôn ngữ chung. Tuyệt đối không sử dụng các ngôn ngữ IT, ngôn ngữ CS trong tài liệu.

Ứng dụng mô hình SHAP: hiểu tại sao mô hình dự đoán một khách hàng có nguy cơ nợ xấu, hay tại sao mô hình gợi ý một sản phẩm nào đó.

Ứng dụng mô hình LIME: muốn biết tại sao mô hình phân loại một ảnh là “chó” thay vì “mèo”, LIME sẽ highlight vùng ảnh có ảnh hưởng nhất.

IV. Kiểm thử trong môi trường thực tế

Trong quá trình build model, chúng ta thường chia dữ liệu thành training data, validation data, tesing data. Pass testing data mới chỉ là bước đầu tiên ở việc POC thành công, không đồng nghĩa với production availability.

Các cách mở rộng tập validation:

• Tesing trên các khung giờ khác nhau, khu vực khác nhau, phân khúc người dùng khác nhau ….

• Giả lập các edge case - các tình huống hiếm gặp, ít xảy ra, nhưng khi xảy ra thì có thể gây crash hệ thống.

• Dùng các kỹ thuật kiểm tra sự khác biệt phân phối dữ liệu ở tập train, test và môi trường thiệt. Ví dụ, build một classifier với data train thì gắng nhãn 0, data test thì gắng nhãn 1. Train cái classifier đó. Nếu classifier không phân biệt được đâu là train , đâu là test, AUC ≈ 0.5, nghĩa là train và test là gần giống i sì nhau. Còn nếu AUC > 0.7, có nghĩa là train và test có thể phân biệt được. Nghĩa là có data shift. Một cách khác là vẽ phân phối của model rồi xem Mi và sigma.

-Tạo các bài kiểm thử (stress test) buộc mô hình hoạt động trong điều kiện vượt ngoài kịch bản bình thường, để kiểm tra độ bền vững và giới hạn của mô hình. Ví dụ:

• Quăng ký tự lạ, giun dế vào mô hình nhận dạng text.
• Quăng hình con voi vào mô hình nhận dạng cho chó mèo.
• Gửi 10 vạn request vào mô hình AI
• Dự đoán với input tuổi là từ 0-500 ( không biết có tu tiên giả nào còn sống hem)

Nếu mô hình chạy tốt với dữ liệu tháng trước nhưng thất bại với traffic hôm nay, thì không hữu ích thực sự.

V. Triển khai monitor

Monitor là một thành phần cực kỳ cần thiết trong hệ production. Các mô hình lớn, hiện tại, thường sẽ export metrics api tương thích với các ứng dụng logging.

Các thành phần thường cần phải monitor:

• Theo dõi phân phối dữ liệu đầu vào (phát hiện drift sớm)

• Chấm điểm độ tin cậy và phát hiện outlier

• Ghi nhận hiệu suất mô hình theo thời gian

• Liên kết kết quả dự đoán với KPI kinh doanh

• Cảnh báo tự động khi có bất thường

Mục tiêu là phát hiện vấn đề càng sớm càng tốt. Tránh gây ra lỗi lầm ở quy mô hệ thống. Kịp thời rollback hoặc retrain model.

VI. Lên kế hoạch retraining

Mô hình thường không giữ hiệu năng mãi được. Thị trường thay đổi, hành vi người dùng thay đổi, dữ liệu thay đổi ->hiệu quả sẽ giảm dần.

Các cách xây dựng mô hình bền vững:

• Tự động cập nhật pipline và feature engineering.

• Lập lịch retrain dựa trên ngưỡng hiệu suất.

• Dùng A/B testing với mô hình mới trước khi đưa vào production.

• Quản lý version cho mô hình, dữ liệu, code.

Mục tiêu cuối cùng không phải là mô hình hoàn hảo, mà là hệ thống vận hành ổn định.

VII. Tối ưu cho Business

Các tiêu chí như Accuracy, precision, recall… bản chất, chỉ là kỹ thuật. Còn production là Business. Mô hình hữu ích là mô hình mang lại giá trị đo lường về mặt doanh thu, chi phí, tăng trải nghiệm khách hàng, tăng thời gian ra quyết định. Đó là “thước đo” , “độ đo” mà chúng ta cần hướng tới, không phải là Accuracy, precision, recall. Các nguyên tắc:

• Xác định lại độ đo của mô hình.

• Xây dựng lại cost-sensitive learning. Mỗi lỗi khác nhau sẽ có mức độ tệ khác nhau. Các cách tính độ lỗi thông thường thường, thường quy đồng các misclassification đều “tệ” như nhau. Đây là một sai lầm nghiêm trọng và cần thay đổi. Cost-sensitive learning sẽ giúp chúng ta điều chỉnh mô hình sao cho tối thiểu hóa chi phí tổng thể, chứ không đơn thuần là tối thiểu hóa chi phí lỗi. Ví dụ:

  • Y tế

    False Negative (bỏ sót bệnh nhân bị ung thư) → chi phí cực cao (ảnh hưởng tính mạng).

    False Positive (dự đoán có ung thư nhưng thực ra không có) → chi phí thấp hơn (chỉ là kiểm tra thêm).

    → Ở đây, ta muốn mô hình “nhạy” hơn, chấp nhận một số false positive để tránh bỏ sót true case.

  • Ngân hàng / gian lận

    False Negative (bỏ sót giao dịch gian lận) → mất tiền thật.

    False Positive (chặn nhầm giao dịch hợp pháp) → gây khó chịu cho khách hàng.

    → Chi phí của hai loại lỗi khác nhau, nên ta phải cân bằng hợp lý.

• Theo dõi lợi tức đầu tư (ROI – Return on Investment) và hiệu quả chi phí của mô hình theo thời gian

  • ROI (Return on Investment)

    ROI = (Lợi ích kinh doanh do mô hình mang lại – Chi phí triển khai & vận hành) / Chi phí. Ví dụ:

    Mô hình phát hiện gian lận giúp tiết kiệm 1 triệu USD/năm.

    Chi phí hạ tầng + phát triển + bảo trì: 200k USD/năm.

    ROI = (1,000,000 – 200,000) / 200,000 = 4.0 (400%).

  • Cost-effectiveness (hiệu quả chi phí)

    Liên quan đến việc mô hình có xứng đáng với chi phí bỏ ra hay không.

    Ví dụ: một mô hình NLP cần GPU đắt đỏ, nhưng chỉ cải thiện accuracy từ 92% → 93%. Nếu lợi ích kinh doanh không tăng nhiều, thì cost-effectiveness thấp.

  • Cách theo dõi theo thời gian Business metrics: doanh thu tăng thêm, chi phí tiết kiệm, số khách giữ lại nhờ dự đoán churn…

    Operational metrics: chi phí hạ tầng (cloud, GPU), chi phí labeling, chi phí bảo trì mô hình.

    Ratio:

    ROI hàng tháng/quý.

    Chi phí trên mỗi prediction ($/inference).

    Lợi ích biên (marginal gain) khi retrain model.

  • Tại sao phải dõi lợi tức đầu tư (ROI – Return on Investment) và hiệu quả chi phí của mô hình theo thời gian

    Mô hình có thể mất hiệu lực (model decay) → ROI giảm dần.

    Giúp quyết định khi nào nên retrain hoặc ngừng sử dụng mô hình.

    Đảm bảo ML không chỉ “hay về kỹ thuật” mà còn có ý nghĩa kinh doanh.

• Xây dựng cơ chế phản hồi giữa dự đoán của mô hình và kết quả kinh doanh thực tế, để mô hình ngày càng chính xác và mang lại giá trị thực tiễn hơn. Mô hình ML nếu chỉ dự đoán xong, là thôi, thì chưa đủ. Chúng ta cần biết dự đoán trên có mang lại kết quả tốt cho business không (doanh thu, giữ chân khách hàng, giảm gian lận…). Và dùng dữ liệu phản hồi này để cải thiện mô hình.

  • Ví dụ:

    1. E-commerce (gợi ý sản phẩm):

    Model dự đoán khách A thích sản phẩm X.

    Người dùng thực sự có click/mua không? → đây chính là feedback.

    Kết quả được ghi nhận và đưa ngược về hệ thống để retrain.

    2. Ngân hàng (chấm điểm tín dụng):

    Model dự đoán khách hàng B sẽ trả nợ đúng hạn.

    Sau 6 tháng, dữ liệu thực tế: khách hàng có trả đúng hạn không?

    Kết quả này giúp điều chỉnh lại cost-sensitive model.

    3. Churn prediction:

    Model dự đoán khách C sắp rời bỏ dịch vụ.

    Doanh nghiệp gửi khuyến mãi giữ chân → khách có ở lại không?

    Nếu khách vẫn rời đi → signal cho thấy model/chiến lược giữ chân chưa tối ưu.

  • Cách xây dựng feedback loop

    Log predictions (lưu lại dự đoán + confidence score).

    Track outcomes (lưu kết quả kinh doanh thực tế, ví dụ: có click/mua/ở lại không).

    Compare predictions vs outcomes → tính metrics (accuracy, ROI, uplift).

    Close the loop: dùng dữ liệu mới này để retrain hoặc fine-tune mô hình định kỳ.

    Business monitoring: hiển thị dashboard đo lường tác động kinh doanh của model.

Hy vọng cách chia mục rõ ràng này sẽ giúp bạn dễ dàng nắm bắt nội dung và sử dụng cho bài viết của mình!