Các trường hợp từ chối, lỗi và quy trình xem xét thủ công trong OpenAI Decisions API

Bài 5 đã hướng dẫn bạn cách chuyển đổi xác suất thành hành động dựa trên một ngưỡng nhất định, đồng thời giữ lại các trường hợp nằm ở khoảng giữa để con người xử lý. Bài học này đề cập đến tình huống không có xác suất: Mô hình từ chối đưa ra câu trả lời. Nội dung này cũng xây dựng một quy trình riêng để xử lý các trường hợp nằm ở khoảng giữa đó.

Loại phản hồi "Từ chối" (Refusal)

Hãy xem bất kỳ ví dụ nào trong bộ công cụ phát triển phần mềm (SDK) thuộc hướng dẫn về Decisions của OpenAI. Tất cả các ví dụ đó đều thực hiện cùng một thao tác đầu tiên:

answer = decision.answers[0]
if answer.type == "refusal":
    print(f"Refused: {answer.name}")
elif answer.type == "predicate":
    print(f"Visible damage probability: {answer.probability}")

Đó là mẫu (đây là mẫu Python của OpenAI, đã được cắt bớt): Kiểm tra loại trước khi đọc bất kỳ thứ gì khác. Lời từ chối mang name của câu hỏi để bạn biết nó thuộc về câu hỏi nào. Các câu hỏi khác trong cùng yêu cầu vẫn có thể trả lời bình thường.

Ba sự thật cần ghi nhớ trong thông số kỹ thuật:

1. Từ chối là không trả lời, không phải là câu trả lời phủ định. Mô hình không nói "không có thiệt hại". Nó nói "Tôi sẽ không quyết định việc này".
2. Một HTTP thành công vẫn có thể chứa đựng sự từ chối. Yêu cầu đã có tác dụng; quyết định đã không xảy ra.
3. Đừng bao giờ biến lời từ chối thành lời từ chối. Không sai, không cấp 0, không phải con đường rẻ nhất. Điều đó tạo ra một câu trả lời mà mô hình chưa bao giờ đưa ra.

Xây dựng quy trình cho trường hợp đặc biệt trước khi bạn cần nó

Mọi quyết định tự động đều cần một nơi dành cho những trường hợp mà lẽ ra nó không nên quyết định. Đây là logic định tuyến bằng ngôn ngữ đơn giản. Nhà phát triển của bạn có thể biến nó thành code; bạn có thể biến nó thành một policy.

Một số chi tiết giúp phân biệt một quy trình thực tế với một kỳ vọng mơ hồ:

• Hãy kiểm tra contract. Nếu thiếu phản hồi, tên bị trùng lặp, hoặc kiểu dữ liệu không đúng như mong đợi, hãy từ chối kết quả đó và lưu lại thông tin chẩn đoán. Đừng tự ý chọn một hành động mặc định. (Đây là lời khuyên từ hướng dẫn của Wavect, cũng phù hợp với cách vận hành của các ví dụ trong bộ công cụ phát triển phần mềm - SDK).
• Chỉ cho phép thực hiện các hành động nằm trong danh sách được phê duyệt (allowlist) trong code của bạn. Mô hình sẽ chọn một nhãn (label); code ủa bạn sẽ ánh xạ nhãn đó tới một hành động đã xác định trước. Giá trị trả về tuyệt đối không được là một lệnh thực thi, một đường dẫn URL, hay bất kỳ thứ gì mà mô hình có thể bị thao túng để đưa ra.
• Đối với các lỗi timeout (hết thời gian chờ) hoặc lỗi truyền tải, hãy thiết lập cơ chế thử lại có giới hạn hoặc quy trình dự phòng (fallback) đã được ghi lại rõ ràng, đồng thời ghi nhật ký (log) sự kiện đó. Cần tách biệt giữa việc "thử lại quá trình phân loại" và "thử lại hành động" để tránh việc một thao tác bị thực hiện hai lần.
• Hãy ghi nhật ký quyết định: Phiên bản câu hỏi, mô hình được sử dụng, phản hồi trả về (kèm các chỉ số liên quan), quy trình mà dữ liệu được chuyển đến; nếu có sự can thiệp thay đổi từ con người, hãy ghi rõ ai là người thực hiện và lý do tại sao.

Tại sao quy trình có sự tham gia của con người là không thể thiếu?

Hai framework công khai cùng đưa ra quan điểm này từ các góc độ khác nhau:

• Đạo luật AI của EU (EU AI Act), Điều 14, yêu cầu các hệ thống AI có rủi ro cao phải được thiết kế sao cho con người giám sát có thể hiểu được năng lực và giới hạn của hệ thống, theo dõi quá trình vận hành, quyết định không sử dụng kết quả đầu ra, cũng như can thiệp hoặc dừng hệ thống lại. Đạo luật này đề cập đến "thiên kiến ​​tự động hóa" (automation bias) - xu hướng quá tin tưởng vào các gợi ý từ hệ thống tự động - và yêu cầu thiết kế giám sát phải có biện pháp đối phó với vấn đề này. Mặc dù hầu hết các tác vụ phân loại (routing) không được xếp vào nhóm "rủi ro cao" theo luật định, nhưng các nguyên tắc thiết kế này chính là hình thức bảo hiểm hiệu quả và tiết kiệm nhất mà bạn có thể áp dụng.
• Framework quản lý rủi ro AI của NIST tiếp cận vấn đề này thông qua các bước: Quản trị (Govern), Lập bản đồ (Map), Đo lường (Measure) và Quản lý (Manage). Cụ thể là: Xác định các rủi ro, đo lường chúng (như cách kiểm tra với 50 ví dụ đã nêu ở Bài 5), và quản lý chúng thông qua các cơ chế kiểm soát như xem xét lại (review) và quyền thay đổi quyết định (override).

Thiên kiến ​​tự động hóa trong thực tế

Nếu một người giám sát phê duyệt gợi ý của mô hình 200 lần liên tiếp, đó không phải là bằng chứng cho thấy mô hình đang hoạt động chính xác. Đó là dấu hiệu cho thấy bạn không còn khả năng đánh giá đúng sai nữa. Hai biện pháp đối phó đơn giản:

• Kiểm tra mù (blind spot-check): Định kỳ yêu cầu người giám sát tự đưa ra nhãn cho một mẫu dữ liệu trước khi xem kết quả từ mô hình, sau đó so sánh hai kết quả với nhau.
• Hãy hiển thị các con số, thay vì chỉ nêu tên nhãn. Một người đánh giá khi nhìn thấy mục "other" (khác) ở mức 0,41 và mục "billing" (thanh toán) ở mức 0,39 sẽ có cách đánh giá khác so với người chỉ nhìn thấy mỗi nhãn "thanh toán".

Thử ngay: Soạn thảo chính sách đánh giá của bạn

Cách thực hiện: Mở ChatGPT, Claude hoặc Gemini trong một cuộc trò chuyện mới.

Cách sao chép: Nhấn Cmd+A rồi Cmd+C (trên Mac) hoặc Ctrl+A rồi Ctrl+C (trên Windows) ngay trong khung văn bản.

Hãy soạn thảo một chính sách dài một trang về quy trình cần con người xem xét đối với các quyết định tự động được xây dựng dựa trên Decisions API của OpenAI. Cần lưu ý các điểm sau: API có thể trả về loại kết quả là "từ chối" (refusal) thay vì một con số; kết quả "từ chối" tuyệt đối không được chuyển đổi thành các giá trị mặc định như "không" (no) hay mức thấp nhất. Ba trường hợp bắt buộc phải chuyển cho con người xem xét bao gồm: các phản hồi "từ chối", các lựa chọn dự phòng (ví dụ: "khác"), và các kết quả nằm dưới ngưỡng (threshold) đã được kiểm chứng. Người đánh giá cần được xem các con số cụ thể do mô hình đưa ra, thay vì chỉ nhìn vào nhãn (label) kết quả; đồng thời, mọi thay đổi so với quyết định ban đầu đều phải được ghi lại kèm theo lý do.

Quyết định: [câu hỏi của bạn, trình bày trong một câu]
Người thực hiện đánh giá: [vai trò và khối lượng công việc dự kiến ​​hàng tuần]
Các bên có thể yêu cầu giải trình về quyết định: [ví dụ: khách hàng, kiểm toán viên, nhà tài trợ, cơ quan quản lý]

Nội dung cần có:
1. Chính sách gồm sáu phần ngắn gọn: các trường hợp cần xem xét lại; thông tin hiển thị cho người đánh giá; cách ghi lại các thay đổi so với quyết định ban đầu; cách xử lý các phản hồi "từ chối"; quy trình kiểm tra ngẫu nhiên hàng tuần để tránh "thiên kiến ​​tự động hóa" (automation bias); và thẩm quyền thay đổi ngưỡng.
2. Định dạng nhật ký (log) dạng một dòng, liệt kê các trường dữ liệu cần lưu giữ cho mỗi quyết định.
3. Hai dấu hiệu cảnh báo cho thấy quy trình xem xét của con người chỉ còn mang tính hình thức.

Kết quả đầu ra: Một chính sách gồm 6 phần, định dạng nhật ký và hai dấu hiệu cảnh báo.

Cách sử dụng: Đính kèm nội dung này vào Bảng thông số quyết định (Decision Spec Sheet) của bạn. Đây sẽ là phần "chính sách xem xét và xử lý từ chối" trong tài liệu tổng kết của bạn.

Lưu ý quan trọng: Nếu bất kỳ phần nào trong chính sách coi kết quả "từ chối" tương đương với "không" (no), hãy điều chỉnh lại: "Kết quả 'từ chối' không phải là một câu trả lời. Hãy chuyển trường hợp đó cho con người xem xét và ghi lại thông tin".

Những điểm chính cần ghi nhớ

• Luôn kiểm tra loại (type) và tên (name) trước khi đọc nội dung phản hồi. "Từ chối" là một loại kết quả riêng biệt và vẫn đi kèm với tên câu hỏi.
• "Từ chối" không phải là một câu trả lời. Tuyệt đối không quy đổi nó thành "sai" (false), "mức 0", hay bất kỳ giá trị mặc định đơn giản nào. Ngay cả khi phản hồi HTTP trả về trạng thái thành công (success), nó vẫn có thể chứa kết quả "từ chối".
• Ba trường hợp dẫn đến quy trình xem xét của con người: Phản hồi "từ chối", lựa chọn dự phòng, và kết quả nằm dưới ngưỡng quy định. Ghi chép mọi thứ, bao gồm cả các thao tác ghi đè và lý do.
• Thiết kế hệ thống để tránh thiên kiến ​​tự động hóa bằng cách kiểm tra ngẫu nhiên và cho người đánh giá xem số liệu.