Tôi Huấn Luyện Sáu Mô Hình Phát Hiện Gian Lận, Nhưng Mô Hình Tốt Nhất Lại Không Được Đưa Vào Sản Xuất

Trong quá trình làm đồ án tốt nghiệp, tôi đã huấn luyện sáu mô hình khác nhau trên cùng một bộ dữ liệu gian lận, ghi nhận toàn bộ quá trình và chọn ra một "nhà vô địch". Nhưng hiện tại, mô hình đang vận hành hệ thống lại không phải là mô hình chiến thắng đó. Bài viết này là câu chuyện về khoảng cách giữa việc tối ưu các chỉ số trong phòng thí nghiệm và việc đưa ra quyết định đúng đắn cho một hệ thống thực tế.

NairaShield là một hệ thống phát hiện gian lận dựa trên AI do tôi xây dựng trong đồ án tốt nghiệp, chuyên xử lý các giao dịch ngân hàng. Ban đầu, nó chỉ là một bài toán phân loại đơn giản, nhưng cuối cùng lại trở thành một quy trình hỗ trợ ra quyết định phức tạp, một phần vì sự khác biệt về vấn đề, và một phần vì giảng viên hướng dẫn của tôi không hài lòng với phiên bản đơn giản đó.

Hợp Nhất Hai Bộ Dữ Liệu Không Cùng Cấu Trúc

Tôi đã huấn luyện trên hai bộ dữ liệu công khai không có cùng một lược đồ chung. PaySim là một bộ mô phỏng giao dịch tiền di động, có các thuộc tính như oldbalanceOrg và newbalanceOrig. Trong khi đó, bộ dữ liệu IEEE-CIS fraud detection lại bao gồm các giao dịch thẻ, không có các thuộc tính trên mà thay vào đó là ProductCD, card1, card2 và nhiều đặc tính ẩn danh khác.

Điều tôi mất quá nhiều thời gian để nhận ra là khi có một lược đồ thống nhất, các đặc trưng được chọn phải là những đặc trưng mà cả hai bộ dữ liệu đều có. Số dư tài khoản trong PaySim không được sử dụng vì IEEE-CIS không có trường tương tự. Mô hình được triển khai thực tế chỉ được huấn luyện trên ba yếu tố: số tiền giao dịch, kênh giao dịch (đã được mã hóa one-hot), và nguồn dữ liệu (đã được mã hóa one-hot).

Cân Bằng Dữ Liệu Khi Gian Lận Hiếm Khi Xảy Ra

Vì tỷ lệ gian lận trong cả hai nguồn dữ liệu đều rất thấp, một mô hình có thể đạt độ chính xác cao chỉ bằng cách dự đoán "không gian lận" cho tất cả các trường hợp. Để giải quyết vấn đề này, tôi đã sử dụng SMOTE để tăng cường mẫu cho lớp thiểu số trên tập huấn luyện, với một phương án dự phòng tự viết để đảm bảo hệ thống hoạt động trong các môi trường triển khai tối giản.

Sáu Mô Hình và Một Bảng Tính Tự Phản Bác

Tôi đã huấn luyện Random Forest, Logistic Regression, XGBoost (ở cả bản tham số mặc định và tối ưu), và LightGBM (cũng ở cả bản tham số mặc định và tối ưu). Tất cả đều được đánh giá bằng cùng một bộ hàm để đảm bảo tính so sánh công bằng.

Biểu đồ so sánh hiệu suất của các mô hình

Kết quả cho thấy một số điều đáng chú ý:

• Logistic Regression có độ hồi tưởng (recall) cao nhất (0.95), nhưng lại là mô hình kém khả dụng nhất vì độ chính xác (precision) rất thấp (0.14), nghĩa là hầu hết các cảnh báo đều là dương tính giả.
• Việc tinh chỉnh tham số cho XGBoost cải thiện một chút AUC-PR nhưng lại làm giảm precision, cho thấy tối ưu hóa không có nghĩa là tốt hơn cho mọi trường hợp.
• LightGBM bản mặc định đạt hiệu quả về AUC-PR cao nhất trong tất cả các mô hình được thử nghiệm.

Mặc dù vậy, API sản xuất vẫn sử dụng XGBoost (Tuned) vì quyết định này được đưa ra trước khi hoàn thành việc so sánh với LightGBM. Nhìn lại bây giờ, đó là một quyết định đáng để xem xét lại.

SHAP Làm Cho Các Con Số Có Trách Nhiệm Giải Trình

Mỗi dự đoán bị gắn cờ sẽ đi kèm với một danh sách các đặc trưng đã khiến nó được phân loại là gian lận. Vì câu trả lời "mô hình nói vậy" không phải là một câu trả lời chấp nhận được cho ngân hàng hay cơ quan quản lý, tôi đã sử dụng SHAP (SHapley Additive exPlanations) để giải thích quyết định của mô hình.

Điều Giảng Viên Hướng Dẫn Của Tôi Thực Sự Muốn

Điểm xuyên suốt mà giảng viên của tôi muốn tôi hướng tới không phải là một thuật toán khác. Ông muốn tôi xây dựng phần tiếp theo sau khi một giao dịch bị gắn cờ. Điều này dẫn đến việc tạo ra Trung Tâm Thông Báo Quy Định (Regulatory Notification Center), một lớp đánh giá với các vai trò khác nhau dựa trên mô hình của Ngân hàng Trung ương Nigeria, EFCC và NDIC. Mỗi cơ quan có tài khoản đăng nhập riêng và hàng đợi xử lý các giao dịch bị gắn cờ. Việc xây dựng quy trình này cũng là lý do tôi phải đưa LightGBM vào so sánh.

Cổng Độ Tin Cậy (Confidence Gate) Đến Từ Đâu

API không xử lý dự đoán gian lận như một câu trả lời "có" hoặc "không" đơn giản. Thay vào đó, nó sử dụng một hệ thống nhiều mức:

• Điểm số dưới 0.50: Giao dịch được phép thực hiện bình thường.
• Điểm số từ 0.50 đến dưới 0.80: Giao dịch bị gắn cờ nhưng không bị chặn, được chuyển đến trạng thái PENDING_OTP, tức là cần có sự xác minh thứ hai của con người trước khi hoàn tất.
• Điểm số từ 0.80 trở lên: Giao dịch bị chặn.
• Điểm số từ 0.85 trở lên: Một cảnh báo khẩn cấp sẽ được gửi qua SMS hoặc email.

Sơ đồ kiến trúc xử lý và cảnh báo giao dịch

Một giao dịch không bao giờ nhận được một câu trả lời đơn nhất. Nó được định tuyến đến người hoặc bộ phận tiếp theo cần xem xét.

Kỳ Bảo Vệ Đồ Án

Trong buổi bảo vệ, tôi đã trả lời rằng mô hình XGBoost (Tuned) đang được sử dụng. Tôi đã không đề cập rằng LightGBM bản mặc định đã đánh bại nó về chỉ số quan trọng nhất chỉ vài ngày trước đó. Các câu hỏi từ hội đồng cũng khiến tôi nhận ra một hạn chế: hệ thống hiện tại xử lý hai giao dịch triệu đô của một CEO và một sinh viên là giống hệt nhau. Không có danh tính tài khoản hay lịch sử giao dịch nào trong số mười ba đặc trưng mà mô hình sử dụng.

Câu trả lời trung thực là hệ thống của tôi hiện tại xử lý một triệu đô la theo cùng một cách bất kể nó rời khỏi tài khoản của ai. Tuy nhiên, điều nó làm là không chỉ dựa vào con số đó để đưa ra quyết định. Nếu một giao dịch triệu đô được dự đoán là gian lận với xác suất trên 0.85, nó sẽ bị gắn cờ và chuyển đến một con người để xem xét, người có nhiều ngữ cảnh hơn mô hình.

Suy Nghĩ Cuối Cùng và Điều Tôi Sẽ Làm Khác

Nếu được làm lại, tôi sẽ thêm các đặc trưng hành vi theo từng tài khoản như số tiền giao dịch trung bình và độ lệch so với lịch sử giao dịch của người dùng. Tôi cũng sẽ xem xét lại việc mặc định chọn XGBoost (Tuned) thay vì LightGBM bản mặc định. Cả hai thay đổi này đều xuất phát từ cùng một sai lầm: tôi đã chốt một mô hình sản xuất trước khi quá trình so sánh hoàn tất.

Bài học quan trọng nhất rút ra là điểm số cao nhất trên bảng tính không đồng nghĩa với quyết định sản xuất đúng đắn. Một mô hình không bao giờ là toàn bộ hệ thống. Cổng độ tin cậy, nhật ký kiểm toán và con người đọc cảnh báo PENDING_OTP mới chính là những yếu tố thực sự bắt được gian lận, ngang bằng với vai trò của mô hình.