Chọn Đúng Điểm Dừng Human-in-the-Loop Theo Rủi Ro
Hiểu HITL là một trục 4 điểm dừng (review-before-execute, execute+undo, sample-based, no human) chứ không phải cờ bật/tắt, và chọn điểm dừng theo Cost of Failure của từng nhánh.
Chọn Đúng Điểm Dừng Human-in-the-Loop Theo Rủi Ro
AI Literacy Lesson 1 đã nhắc "Hybrid": khi Cost of Failure cao → Rule-based hoặc Hybrid kèm Human-in-the-Loop (HITL). Đó là quyết định kiến trúc. Lesson 31 cũng chạm tới nó ở loại failure "wrong nhưng tự tin" - "chặn từ trước bằng rule kiểm tra output". Lesson này tách riêng để trả lời câu hỏi UI cụ thể: con người đứng vào đâu trong luồng, và họ được làm gì ở vị trí đó?
Ví dụ xuyên suốt bài: HireFlow - công cụ AI sàng lọc hồ sơ ứng viên, gắn nhãn "phù hợp / không phù hợp / cần xem thêm" cho từng CV.
1. HITL không phải cờ bật/tắt, mà là một trục có nhiều điểm dừng
Nhầm lẫn phổ biến nhất: coi "có HITL" là một cờ bật/tắt. Thực tế nó là một trục có nhiều điểm dừng, mỗi điểm đánh đổi tốc độ lấy độ an toàn khác nhau:
- (a) Review-before-execute - AI đề xuất, người dùng phải bấm "duyệt" thì hành động mới thật sự xảy ra. An toàn nhất, chậm nhất.
- (b) Execute-with-easy-undo - AI tự thực thi ngay, nhưng để lại đường lùi rẻ và rõ ràng (nút undo nổi bật, log thay đổi). Nhanh hơn (a), chấp nhận được khi chi phí sai + chi phí sửa đều thấp.
- (c) Sample-based review - không review từng item, mà định kỳ lấy mẫu ngẫu nhiên (hoặc mẫu confidence thấp) để người kiểm tra hàng loạt, dùng để tinh chỉnh ngưỡng/model theo thời gian.
- (d) No human in loop - chỉ dùng khi Cost of Failure thấp và AI đã chứng minh độ tin cậy ổn định qua thời gian (thường bắt đầu ở (a)/(b), hạ dần xuống (d), không bắt đầu ngay ở đây).
Việc chọn điểm dừng nào không cố định theo sản phẩm, mà theo từng loại quyết định trong cùng sản phẩm - nối thẳng với ngưỡng confidence ở Lesson 29: confidence cao → có thể tụt xuống (b)/(d); confidence thấp → buộc phải ở (a).
HITL Là Một Trục Có 4 Điểm Dừng, Không Phải Cờ Bật/Tắt
Mỗi điểm đánh đổi tốc độ lấy độ an toàn khác nhau - chọn theo Cost of Failure của từng nhánh.
Chậm nhất
Cao nhất
Cost of Failure cao, volume thấp/vừa.
2. Ví dụ: HireFlow tách 2 nhánh theo mức rủi ro, không dùng chung 1 điểm dừng
Thiết kế ban đầu: model tự động loại CV bị gắn "không phù hợp" khỏi pipeline, nhà tuyển dụng chỉ thấy phần còn lại. Vấn đề: đây là quyết định Cost of Failure cao (loại nhầm một ứng viên giỏi = mất cơ hội tuyển, có thể vướng rủi ro pháp lý phân biệt đối xử) nhưng lại chạy ở mức (d) - không có ai review.
Sửa lại: CV bị gắn "không phù hợp" không bị xóa khỏi pipeline, mà chuyển vào tab riêng "AI đề xuất loại - cần xác nhận", nhà tuyển dụng phải chủ động duyệt qua (chuyển từ (d) sang (a) cho riêng nhánh rủi ro cao này). Nhánh "phù hợp" thì vẫn chạy ở mức (b) - tự động đưa vào pipeline chính, có nút "gỡ khỏi shortlist" dễ thấy nếu nhà tuyển dụng không đồng ý.
3. Bốn điểm dừng và khi nào dùng điểm nào
| Điểm dừng | Tốc độ | An toàn | Phù hợp khi |
|---|---|---|---|
| (a) Review-before-execute | Chậm nhất | Cao nhất | Cost of Failure cao, volume thấp/vừa |
| (b) Execute + easy undo | Nhanh | Vừa | Cost of Failure vừa, sửa sai rẻ và nhanh |
| (c) Sample-based review | Nhanh (không chặn từng item) | Vừa, giám sát dài hạn | Volume quá lớn để review từng cái |
| (d) No human in loop | Nhanh nhất | Thấp nhất | Cost of Failure thấp, model đã kiểm chứng ổn định |
Lưu ý quan trọng: (a) không phải lúc nào cũng "an toàn nhất nên luôn tốt hơn" - áp (a) cho toàn bộ sản phẩm bất kể Cost of Failure khiến user mệt mỏi vì phải duyệt mọi thứ, dẫn tới rubber-stamping (duyệt qua loa). Lúc đó "có con người trong loop" chỉ còn hình thức, không còn tác dụng an toàn thật.
4. Ẩn dụ: tổng biên tập phân bổ mức kiểm soát theo rủi ro bài viết
Giống một tổng biên tập báo với các cấp thực tập sinh khác nhau. Bài viết nhạy cảm (chính trị, pháp lý) - tổng biên tập đọc duyệt từng dòng trước khi đăng (a). Bài viết thường - đăng luôn nhưng biên tập viên có thể gỡ/sửa nhanh nếu độc giả phản ánh sai (b). Với hàng trăm bài dịch tin ngắn mỗi ngày - không đọc hết, chỉ lấy mẫu ngẫu nhiên mỗi tuần để đánh giá chất lượng chung (c). Không tổng biên tập nào áp cùng một mức kiểm soát cho mọi loại bài - họ phân bổ sự chú ý theo rủi ro.
Bài tập 32.1: RefundBot - AI tự động xử lý yêu cầu hoàn tiền cho một sàn TMĐT, chia làm 2 nhánh: (1) đơn hàng dưới 200k, lý do khớp chính sách rõ ràng (hàng lỗi, sai mẫu); (2) đơn hàng trên 2 triệu hoặc lý do mơ hồ ("không như mong đợi"). Hiện tại cả 2 nhánh đều chạy ở mức (a) - nhân viên CSKH phải duyệt từng đơn. Đề xuất mỗi nhánh nên ở điểm dừng nào trong 4 điểm, giải thích dựa trên Cost of Failure.