AI phân loại sai yêu cầu khách hàng: workflow nên xử lý confidence score thế nào?

Calibration trả lời câu hỏi thực dụng: trong nhóm dự đoán có score khoảng 0,8, mô hình có đúng xấp xỉ 80% trên dữ liệu đại diện hay không? Nếu thực tế chỉ đúng 60%, score đang overconfident; nếu đúng 90%, score đang underconfident. Calibration không làm mọi dự đoán đúng hơn, nhưng giúp threshold có ý nghĩa hơn khi workflow ra quyết định.

Hãy tạo tập validation tách biệt, có nhãn do người hiểu nghiệp vụ xác nhận và phản ánh dữ liệu production: tiếng Việt có dấu/không dấu, lỗi chính tả, email dài, câu nhiều intent, ảnh OCR, khách mới và tình huống ngoài phạm vi. Vẽ reliability diagram hoặc chia score thành các bucket, rồi so sánh confidence trung bình với accuracy thực tế. Với classifier hỗ trợ xác suất, có thể đánh giá thêm Brier score hoặc log loss. Nếu thay model, prompt, taxonomy hoặc dữ liệu, cần đo lại thay vì giữ nguyên threshold cũ.

Tối thiểu nên lưu top1_intent, top1_score, top2_intent, top2_score, margin = top1 - top2, phiên bản model/prompt và các entity đã trích xuất. Top score cao nhưng margin nhỏ cho thấy hai intent đang cạnh tranh. Ví dụ refund_request = 0.82 và payment_dispute = 0.80 đáng nghi hơn refund_request = 0.82 và intent kế tiếp 0.25.

Tiếp theo, kiểm tra None hoặc out_of_scope, ngôn ngữ, độ đầy đủ của input và required entities. Một nhãn change_booking không thể tự chạy nếu thiếu booking ID, ngày mới hoặc xác thực người yêu cầu. Cuối cùng, áp business rules: khách hàng có quyền thực hiện không, yêu cầu có nằm trong thời hạn cho phép không, giao dịch có tồn tại không và action có thể rollback hay không. Các rule tất định này quan trọng hơn việc cố nâng score bằng prompt.

1. Auto-process. Chỉ dùng khi intent đạt threshold riêng, margin đủ lớn, input nằm trong phạm vi, entity bắt buộc đầy đủ và action có rủi ro thấp hoặc có cơ chế đảo ngược. Ví dụ tự gắn tag hoặc đưa ticket vào đúng queue thường ít rủi ro hơn tự hoàn tiền.

2. Ask clarification. Dùng khi hai intent gần nhau, yêu cầu chứa nhiều ý hoặc thiếu dữ liệu mà chính khách hàng có thể bổ sung. Câu hỏi nên cụ thể: “Anh/chị muốn tắt gia hạn từ kỳ tiếp theo hay hủy dịch vụ ngay?” Không nên hỏi chung chung “Bạn có thể nói rõ hơn không?”.

3. Review queue. Dùng khi action có tác động đáng kể, dữ liệu mâu thuẫn hoặc case hiếm nhưng vẫn cần xử lý. Màn hình review nên hiển thị nội dung gốc, top intents, entities, rule đã fail và action dự kiến; không chỉ hiện một score.

4. Fail closed hoặc out-of-scope. Dùng khi không xác định được yêu cầu, nội dung có dấu hiệu prompt injection, thiếu quyền, hoặc downstream validation thất bại. Dừng an toàn không có nghĩa bỏ ticket: workflow vẫn phải ghi nhận, thông báo và tạo đường xử lý tiếp theo.

Với intent general_question, phân loại nhầm có thể chỉ chuyển ticket sang queue khác và sửa được. Với cancel_service, refund_payment, change_bank_account hoặc reset_access, false positive có thể gây mất tiền, gián đoạn dịch vụ hoặc rủi ro bảo mật. Hai nhóm không nên dùng cùng threshold và cùng nhánh tự động.

Hãy lập ma trận cho từng intent: tác động nếu xử lý nhầm, tác động nếu bỏ sót, khả năng rollback, yêu cầu xác thực và SLA review. Sau đó tối ưu threshold theo cost có trọng số thay vì chỉ tối đa F1 toàn mô hình. Với intent rủi ro cao, policy có thể yêu cầu xác nhận nghiệp vụ dù score rất cao. Với intent rủi ro thấp, threshold có thể linh hoạt hơn nếu workflow có reconciliation và khả năng sửa sai nhanh. Các giá trị threshold phải được rút ra từ validation set và shadow traffic của chính hệ thống, không sao chép từ ví dụ của nhà cung cấp.

Bước đầu, chuẩn hóa input và lưu bản gốc bất biến cùng request_id. Classifier chỉ trả structured result gồm intent, score, top candidates, entities, model version và lý do ngắn có thể audit; nó không trực tiếp gọi action.

Tiếp theo, policy engine đọc cấu hình được version hóa theo intent: auto_threshold, review_threshold, minimum_margin, required entities, risk tier và allowed actions. Policy kiểm tra thêm authentication, customer state, duplicate request và business constraints. Kết quả routing cùng toàn bộ evidence được lưu trước khi gọi downstream.

Ở nhánh action, dùng idempotency key để retry không tạo hiệu ứng trùng. Ở nhánh clarification, giữ cùng conversation/request ID để câu trả lời mới được hợp nhất với yêu cầu gốc. Ở nhánh review, dùng lease hoặc atomic claim để hai nhân viên không xử lý cùng ticket. Nếu model hoặc policy lỗi, mặc định đi theo đường an toàn đã khai báo, không tự bypass gate.

Theo dõi precision, recall và F1 theo từng intent, confusion matrix giữa các intent gần nhau, calibration error theo bucket và tỷ lệ out-of-scope. Ở cấp workflow, cần thêm auto-processing rate, clarification rate, review rate, override rate của reviewer, false auto-action rate, thời gian xử lý và số sự cố phải rollback.

Đặc biệt, đo precision trên nhánh auto-process: trong các yêu cầu hệ thống đã tự hành động, bao nhiêu trường hợp thực sự đúng? Đây thường là chỉ số quan trọng hơn accuracy toàn bộ khi mục tiêu là giảm rủi ro. Đồng thời theo dõi recall cho intent khẩn cấp để tránh threshold quá cao làm bỏ sót. Phân tích theo ngôn ngữ, kênh, nhóm khách hàng và loại input để phát hiện drift ẩn sau số trung bình.

Triển khai policy mới bằng replay trên dữ liệu lịch sử, sau đó shadow mode: hệ thống tính quyết định nhưng chưa thực thi action. Chỉ tăng dần tỷ lệ auto-process khi acceptance criteria đạt trong một khoảng đủ đại diện. Mọi override của nhân viên và phản hồi của khách nên quay lại dataset sau khi được làm sạch và xác nhận nhãn.

Câu hỏi thường gặp về confidence score trong AI workflow

Có nên dùng confidence 0,8 làm ngưỡng mặc định?

Không nên coi 0,8 là ngưỡng chuẩn. Hãy đo phân bố score, precision, recall, calibration và cost lỗi theo từng intent trên dữ liệu của chính hệ thống.

Confidence cao có thể bỏ qua business validation không?

Không. Score chỉ nói về lựa chọn nhãn của classifier. Quyền người dùng, trạng thái hợp đồng, dữ liệu bắt buộc và điều kiện giao dịch vẫn phải được kiểm tra tất định.

Khi nào nên hỏi lại khách thay vì chuyển nhân viên?

Khi sự mơ hồ có thể giải quyết bằng một câu hỏi ngắn và cụ thể, chẳng hạn chọn giữa tắt gia hạn và hủy ngay. Case rủi ro, mâu thuẫn hoặc cần xác minh nên vào review.

Margin giữa top-1 và top-2 có thay thế threshold không?

Không. Margin là tín hiệu bổ sung. Cả hai score có thể thấp hoặc cùng cao; workflow vẫn cần out-of-scope, required entities và risk policy.

Có cần human review cho mọi yêu cầu confidence thấp?

Không nhất thiết. Yêu cầu thiếu dữ liệu có thể hỏi lại tự động; ngoài phạm vi có thể chuyển queue phù hợp; chỉ những case cần phán đoán hoặc action nhạy cảm mới cần người có quyền review.