Xử lý lỗi & sự không chắc chắn

Vì sao xử lý lỗi và sự không chắc chắn quan trọng

Mọi hệ thống AI đều sai. Câu hỏi không phải là có sai hay không mà là khi sai thì trải nghiệm ra sao. Một sản phẩm AX xuất sắc được đánh giá không phải bằng lúc mọi thứ hoạt động hoàn hảo mà bằng lúc mô hình đưa ra kết quả sai, mơ hồ, hoặc từ chối trả lời.

Cái giá của việc xử lý lỗi kém rất nặng. Một ứng dụng gọi xe tại Việt Nam dùng AI dự đoán thời gian đến. Khi mô hình sai lệch lớn vào giờ cao điểm, ứng dụng vẫn hiển thị con số chính xác đến từng phút mà không kèm khoảng dao động. Tài xế và khách hàng mất niềm tin, đánh giá một sao tăng vọt, và đội vận hành phải tắt tính năng trong ba tuần để làm lại. Nếu ngay từ đầu họ hiển thị khoảng ước lượng thay vì con số cứng, cùng một sai số sẽ được người dùng chấp nhận như bình thường.

Sự không chắc chắn không phải điểm yếu cần giấu mà là thông tin cần truyền đạt. Người dùng tha thứ cho AI sai nếu AI trung thực về giới hạn của mình. Họ không tha thứ cho AI tự tin sai.

Bức tranh lớn

Có ba loại tình huống cần xử lý: mô hình sai nhưng vẫn trả lời, mô hình không chắc, và mô hình không thể trả lời. Mỗi loại cần một chiến lược thiết kế riêng.

graph TD
A[AI xu ly yeu cau] --> B{Muc do tin cay}
B -->|Cao| C[Tra ket qua truc tiep]
B -->|Trung binh| D[Tra ket qua kem canh bao]
B -->|Thap| E[Hoi lam ro hoac de xuat lua chon]
B -->|Khong the| F[Tu choi lich su va chuyen huong]
C --> G[Cho phep phan hoi sai]
D --> G
E --> G
F --> G
G --> H[Ghi nhan de cai thien]

Nguyên tắc vàng là phần thưởng cho việc thừa nhận không biết phải lớn hơn phần thưởng cho việc đoán bừa. Thiết kế phải khuyến khích hệ thống nói tôi không chắc thay vì bịa ra câu trả lời.

Ví dụ chi tiết

Một nền tảng học tiếng Anh Việt Nam dùng AI chấm phát âm cho học viên.

Bước một, đội phát hiện mô hình đôi khi chấm sai với giọng vùng miền, đặc biệt giọng miền Trung. Bước hai, thay vì hiển thị điểm tuyệt đối, họ chuyển sang khoảng điểm và thêm dòng chú thích rằng kết quả có thể lệch với một số giọng. Bước ba, khi độ tin cậy thấp, hệ thống không chấm điểm mà mời học viên ghi âm lại rõ hơn hoặc nghe mẫu. Bước bốn, họ thêm nút này chấm chưa đúng để học viên phản hồi ngay, và mỗi phản hồi được đưa vào tập dữ liệu cải thiện. Bước năm, đội theo dõi tỷ lệ phản hồi sai theo vùng miền để ưu tiên thu thập dữ liệu.

Kết quả là học viên miền Trung không còn bỏ tính năng vì thấy được lắng nghe. Tỷ lệ hoàn thành bài luyện phát âm tăng 28 phần trăm và số phản hồi sai giúp đội cải thiện mô hình cho giọng vùng miền trong sáu tháng tiếp theo. Bài học là xử lý lỗi tốt biến điểm yếu của mô hình thành cơ hội xây niềm tin.

Lộ trình từng bước để làm chủ

graph LR
A[Phan loai cac loai loi] --> B[Thiet ke thong bao cho tung loai]
B --> C[Hien thi do khong chac chan]
C --> D[Cung cap duong phuc hoi]
D --> E[Thu phan hoi loi]
E --> F[Do luong va uu tien sua]

Trước tiên phân loại lỗi và sự không chắc chắn. Sau đó thiết kế thông báo phù hợp cho từng loại. Tiếp theo học cách hiển thị độ không chắc trực quan. Rồi cung cấp đường phục hồi. Cuối cùng thu phản hồi và đo lường để ưu tiên sửa.

Thói quen & kỷ luật

Working mindset: Lỗi không phải ngoại lệ cần giấu mà là trải nghiệm cần thiết kế.

Cần luyện tập gì (drills)

• Liệt kê mọi cách một tính năng Aic có thể thất bại và viết thông điệp cho từng trường hợp.
• Thiết kế lại một thông báo lỗi khô khan thành thông điệp có ích và có đường phục hồi.
• Thêm chỉ báo độ tin cậy trực quan cho một đầu ra AI mà không dùng con số phần trăm khô khan.

Checklist hành động tuần này

• [ ] Liệt kê ba kiểu thất bại của một tính năng AI bạn phụ trách
• [ ] Viết lại một thông báo lỗi để trung thực và hữu ích hơn
• [ ] Thêm đường phục hồi cho ít nhất một luồng khi AI không chắc
• [ ] Thêm nút phản hồi sai vào một đầu ra AI
• [ ] Ghi lại cách ba sản phẩm AI khác xử lý khi chúng không chắc

Chỉ số & North Star

North Star là tỷ lệ người dùng phục hồi thành công sau khi gặp lỗi AI mà không rời bỏ.

Dấu hiệu bạn đã thành thạo

Bạn thiết kế được thông điệp lỗi khiến người dùng cảm thấy được tôn trọng chứ không bực bội. Bạn biết khi nào AI nên im lặng hỏi lại thay vì đoán bừa. Bạn biến mọi lỗi thành một điểm thu phản hồi để cải thiện mô hình. Bạn cân bằng được giữa trung thực về giới hạn và giữ trải nghiệm mượt mà.

Cạm bẫy thường gặp

Chốt lại

• Mọi AI đều sai, chất lượng trải nghiệm nằm ở cách xử lý lúc sai.
• Bộc lộ sự không chắc chắn xây niềm tin thay vì phá hủy nó.
• Luôn cung cấp đường phục hồi và cơ chế thu phản hồi khi lỗi.
• Khuyến khích hệ thống thừa nhận không biết thay vì bịa câu trả lời.