Thiết Kế Error State Và Suy Thoái Có Kiểm Soát

Thiết Kế Error State Và Suy Thoái Có Kiểm Soát

Lesson 29 đã đặt ngưỡng: dưới mức confidence thấp → "không tự thực thi, chuyển sang hỏi lại hoặc chuyển người duyệt". Lesson này đi sâu vào chính nhánh đó - khi model sai hoặc không tìm được câu trả lời, UI phải làm gì, không chỉ là "hiện tín hiệu" mà là thiết kế cả luồng phục hồi.

Ví dụ xuyên suốt bài: InvoiceBot - AI tự động trích xuất số liệu từ hóa đơn scan (nhà cung cấp, số tiền, ngày đến hạn) rồi tự điền vào hệ thống kế toán.

1. Ba loại failure cần thiết kế riêng, vì cách phục hồi khác nhau

Phần mềm rule-based có error state rời rạc và liệt kê hết được (404, validation fail, timeout). AI feature có một loại lỗi không nằm trong danh sách nào: model trả lời "thành công" về mặt kỹ thuật (không crash, không timeout) nhưng nội dung sai hoặc lạc đề - không có exception nào để catch, chỉ phát hiện qua confidence thấp (Lesson 29) hoặc phản hồi của user sau đó.

• No-result - model không có đủ căn cứ để trả lời. Loại dễ xử lý nhất vì hệ thống biết mình không biết. UI nên nói thẳng "không tìm thấy thông tin" thay vì cố trả lời bừa - cố trả lời bừa là hành vi gây hại nhất, vì user không phân biệt được với câu trả lời có căn cứ.
• Wrong answer trông tự tin - loại nguy hiểm nhất, model không tự biết mình sai. Không giải quyết được bằng thiết kế error state thuần túy - cần chặn từ trước bằng confidence threshold (Lesson 29) hoặc rule kiểm tra output (Hybrid - AI Literacy Lesson 1).
• Partial/inconsistent - đúng ý chính nhưng sai một chi tiết nhỏ. Khó nhất vì không có ranh giới rõ đúng/sai - hướng xử lý phổ biến là highlight riêng phần nghi ngờ (dựa trên confidence từng đoạn) thay vì gắn cờ cả câu trả lời.

2. Ví dụ: InvoiceBot chuyển thời điểm phát hiện lỗi từ cuối tháng về ngay lúc nhập

Bản đầu: model trích sai → dữ liệu sai đi thẳng vào sổ sách, kế toán chỉ phát hiện cuối tháng khi đối soát, phải lục lại hàng trăm hóa đơn để tìm ra hóa đơn nào bị nhập sai.

Thiết kế lại theo 3 loại: (a) hóa đơn quá mờ không đọc được số → không tự điền, đánh dấu "cần nhập tay" ngay (no-result); (b) số tiền trích ra không khớp định dạng dự kiến (số âm, quá lớn bất thường) → chặn tự động, không cho lưu tới khi user xác nhận (wrong-nhưng-tự-tin); (c) tên nhà cung cấp đúng nhưng địa chỉ trích sai một phần → lưu nhưng highlight riêng field địa chỉ, không chặn cả hóa đơn (partial). Lỗi vẫn xảy ra với tần suất y hệt, nhưng thời điểm phát hiện dịch chuyển từ "cuối tháng" về "ngay lúc nhập" - chi phí sửa lúc đó gần như bằng 0.

3. Nguyên tắc chung xuyên suốt cả 3 loại

Dù loại nào, một nguyên tắc chung xuyên suốt: undo/edit phải rẻ hơn việc phát hiện ra lỗi sau khi đã hành động. Vì lỗi AI không đoán trước được thời điểm xảy ra, chi phí sửa sai sau khi user đã tin và hành động theo luôn cao hơn nhiều so với thiết kế một bước "xem lại trước khi chốt" ngay từ đầu.

4. Ẩn dụ: nhân viên mới thẳng thắn và nhân viên nói sai mà chắc như đinh đóng cột

Giống khác biệt giữa một nhân viên mới thẳng thắn nói "em không chắc phần này, để em hỏi lại" (loại a - vô hại, chỉ chậm một nhịp) và một nhân viên nói sai mà giọng điệu chắc như đinh đóng cột (loại b - nguy hiểm nhất, vì không ai nghi ngờ để kiểm tra lại). Quản lý giỏi không cố "sửa tính cách" nhân viên - họ thiết kế quy trình review để bắt lỗi loại hai trước khi nó đi ra khách hàng.

Bài tập 31.1: ShiftPlanner - AI tự động xếp lịch làm việc cho nhân viên cửa hàng dựa trên yêu cầu nghỉ phép + dự báo lượng khách. Hiện tại: khi model không đủ dữ liệu dự báo cho một ngày cụ thể, nó vẫn tự điền lịch dựa trên "phỏng đoán trung bình" mà không báo gì - quản lý cửa hàng chỉ phát hiện khi ngày đó thiếu người nghiêm trọng. Xác định lỗi này thuộc loại nào trong 3 loại trên, và đề xuất 1 thay đổi UI cụ thể để nó không còn "trông tự tin" khi thực chất đang đoán mò.