Bạn thêm AI để chuyển ticket khẩn sang hàng đợi ưu tiên. Dashboard báo accuracy 90%, nhưng đội hỗ trợ vẫn bỏ sót toàn bộ việc khẩn. Hai điều này có thể xảy ra đồng thời khi dữ liệu lệch lớp: phần lớn ticket vốn không khẩn.
Bài này giúp bạn xây một phép kiểm tra nhỏ trước khi quyết định đưa bộ phân loại vào quy trình. Dữ liệu bên dưới hoàn toàn tự tạo để minh họa phép tính, không phải kết quả của một model hay hệ thống thực tế.
Điều kiện và phạm vi
Ví dụ dùng Python chuẩn, đã chạy bằng Python 3.9.6. Tài liệu được đối chiếu ngày 24/10/2026. Chúng ta chỉ xét hai nhãn: 1 là khẩn, 0 là thông thường. Việc xác định một ticket có thực sự khẩn cần quy tắc nghiệp vụ và người gán nhãn; công thức không tự giải quyết phần đó.
1. Ghi đủ bốn loại kết quả
Theo cách gọi trong tài liệu Google, TP là dự đoán khẩn đúng; FP là báo khẩn nhầm; FN là bỏ sót ticket khẩn; TN là nhận đúng ticket thường. Confusion matrix của Google giải thích quan hệ giữa nhãn thật, dự đoán và ngưỡng phân loại.
Với đội hỗ trợ, hãy dịch các ô này thành việc cụ thể. FP khiến người trực phải mở thêm ticket không cần ưu tiên. FN khiến một ticket cần xử lý sớm tiếp tục nằm trong hàng đợi thường. Nếu chỉ ghi tổng số dự đoán đúng, bạn mất dấu hai kiểu lỗi có tác động khác nhau này.
Accuracy tính tỷ lệ dự đoán đúng trên mọi ticket. Precision hỏi trong các ticket bị gắn nhãn khẩn, bao nhiêu ticket thực sự khẩn. Recall hỏi trong các ticket thực sự khẩn, hệ thống tìm ra bao nhiêu. Các công thức tương ứng được trình bày trong tài liệu về các metric phân loại.
2. Tự tính trên một bộ dữ liệu nhỏ
Lưu đoạn sau thành ticket_metrics.py. Hàm trả None khi không có mẫu số, để bạn phân biệt “chưa tính được” với một kết quả bằng 0.
def metrics(actual, predicted):
if not actual or len(actual) != len(predicted):
raise ValueError("Hai danh sach phai cung do dai va khong rong")
if any(type(x) is not int or x not in (0, 1)
for x in actual + predicted):
raise ValueError("Chi chap nhan nhan integer 0 hoac 1")
tp = sum(a == 1 and p == 1 for a, p in zip(actual, predicted))
fp = sum(a == 0 and p == 1 for a, p in zip(actual, predicted))
fn = sum(a == 1 and p == 0 for a, p in zip(actual, predicted))
tn = sum(a == 0 and p == 0 for a, p in zip(actual, predicted))
divide = lambda n, d: n / d if d else None
return {
"tp": tp, "fp": fp, "fn": fn, "tn": tn,
"accuracy": divide(tp + tn, len(actual)),
"precision": divide(tp, tp + fp),
"recall": divide(tp, tp + fn),
}
actual = [1] * 10 + [0] * 90
always_normal = [0] * 100
candidate = [1] * 8 + [0] * 2 + [1] * 12 + [0] * 78
print(metrics(actual, always_normal))
print(metrics(actual, candidate))Chạy bằng python3 ticket_metrics.py. Trường hợp luôn chọn thường cho TP=0, FP=0, FN=10, TN=90: accuracy là 0.9, precision không xác định, recall là 0.0. Trường hợp thứ hai cho TP=8, FP=12, FN=2, TN=78: accuracy là 0.86, precision là 0.4, recall là 0.8. Đây là kết quả phép tính trên fixture đã chạy, không phải benchmark AI.
3. Chọn tiêu chí theo cách vận hành
Candidate thứ hai tìm được tám trong mười ticket khẩn nhưng đưa thêm mười hai ticket thường vào hàng ưu tiên. Bạn cần hỏi đội hỗ trợ có đủ khả năng rà hai mươi ticket đó hay không. Chỉ từ accuracy giảm 90% xuống 86% chưa thể kết luận candidate kém hơn cho mục tiêu này.
Một cách thực hành là ghi trước điều kiện chấp nhận: ai xử lý FP, ai rà FN, ticket nào phải có người kiểm tra và khi nào được tắt tự động chuyển hàng đợi. Con số mục tiêu phải xuất phát từ năng lực thực tế của nhóm; không sao chép một ngưỡng tùy ý từ ví dụ.
Nếu model trả score, thay đổi ngưỡng sẽ thay đổi cách chia nhãn. Hãy chọn ngưỡng trên validation set, rồi đánh giá trên test set được giữ riêng. Hướng dẫn chia tập dữ liệu giải thích vai trò khác nhau của các tập và nguy cơ điều chỉnh quá nhiều theo kết quả test.
Kiểm tra trước khi dùng dữ liệu thật
Rà vài mẫu của từng ô thay vì chỉ xem dashboard. Đọc lại cả nội dung gốc, nhãn chuẩn và lý do dự đoán nếu có. Với ticket được gửi lại nhiều lần, cân nhắc gom cùng một nhóm trước khi chia tập để câu gần như giống nhau không rơi vào cả hai phía. Đây là lựa chọn thiết kế bộ đánh giá cần ghi lại để người khác tái tạo được.
Các lỗi dễ gặp là đảo nhãn dương, coi precision không xác định là 100%, hoặc thử nhiều prompt trên test set rồi báo kết quả tốt nhất. Khi số ticket khẩn ít, luôn công bố cả số lượng TP/FP/FN/TN để người đọc thấy quy mô mẫu.
Gợi ý tiếp theo
Tạo một file đánh giá có ID ticket đã ẩn thông tin riêng tư, nhãn chuẩn, nhãn dự đoán và phiên bản cấu hình. Bắt đầu bằng đánh giá ngoại tuyến; chỉ mở tự động hóa sau khi đã xác định trách nhiệm xử lý lỗi. Precision và recall giúp bạn đặt đúng câu hỏi, còn quyết định vận hành cần thêm bằng chứng từ dữ liệu của nhóm.
