Tạo bản tóm tắt thiết kế trong OpenAI Decisions API

Bạn đã viết một câu hỏi xác định trạng thái (Bài 2), thiết kế các câu hỏi dạng lựa chọn và chấm điểm (Bài 3 - Bài 4), thiết lập ngưỡng dựa trên chi phí sai sót (Bài 5), xây dựng quy trình xử lý thủ công (Bài 6), đồng thời vạch ra luồng công việc cùng các giới hạn (Bài 7). Dự án tổng kết sẽ kết hợp những thành phần đó thành một Decision Design Brief – một tài liệu gói gọn trong một trang, đủ để lập trình viên dựa vào đó để xây dựng hệ thống và nhà quản lý có thể phê duyệt.

Hãy chọn một quyết định cụ thể. Lựa chọn phù hợp nhất cho lần đầu tiên là một quyết định có thể đảo ngược: Nếu kết quả sai, mục dữ liệu đó chỉ bị chuyển nhầm hàng đợi hoặc cần xem xét lại, chứ không dẫn đến việc gửi nhầm cho khách hàng, đưa ra thông báo từ chối, hay thực hiện thanh toán sai lệch.

1. Quyết định (một câu). Ví dụ: "Email gửi đến này có yêu cầu hoàn tiền một cách rõ ràng không?" Nếu bạn không thể diễn đạt trong một câu, thì đó là hai quyết định riêng biệt.

2. Loại câu hỏi và thông số kỹ thuật chi tiết. Xác định loại (khẳng định/phủ định, lựa chọn, hoặc thang điểm) kèm theo lý do (tham khảo bảng trong Bài 4). Sau đó, trình bày nội dung yêu cầu (request body) sử dụng các tên trường của OpenAI: model: "gpt-6-luna", input, và một mục questions bao gồm các thông tin: type, name, instructions, cùng choices hoặc levels nếu cần. Hãy dán nội dung công việc từ Bài 2 – 4 của bạn vào đây.

3. Ý nghĩa của con số. Ghi rõ một dòng, trích nguyên văn từ khóa học: "Xác suất là ước tính của mô hình, không phải là độ chính xác đã được đo lường". Đối với dạng lựa chọn hoặc thang điểm, hãy nêu tên các trường dữ liệu bạn sẽ sử dụng (ví dụ: probabilities, confidence, score) và xác định xem xác suất cho từng lựa chọn hoặc từng mức độ sẽ được áp dụng quy tắc xử lý riêng như thế nào.

4. Chi phí sai sót và ngưỡng quyết định. Xác định chi phí của lỗi dương tính giả (false positive), lỗi âm tính giả (false negative), tỷ lệ cơ sở (base rate), cùng với ngưỡng quyết định ban đầu hoặc phạm vi cần xem xét lại, kèm theo một câu giải thích lý do (tham khảo Bài 5).

5. Kế hoạch gắn nhãn dữ liệu mẫu. Bao gồm 50 dữ liệu đầu vào thực tế, người thực hiện gắn nhãn, các cột trong bảng tính, phân tích theo phạm vi, và một chỉ số duy nhất mà bạn sẽ báo cáo: Số lượng trường hợp "tự tin nhưng sai lệch" tại ngưỡng quyết định.

6. Chính sách từ chối và xem xét lại. Mô tả ba phương án xử lý (từ chối, phương án dự phòng, và trường hợp nằm dưới ngưỡng cần xem xét lại); nêu rõ những gì người đánh giá sẽ nhìn thấy, cách ghi lại các thay đổi do con người thực hiện, và quy trình kiểm tra ngẫu nhiên để phòng tránh thiên kiến ​​tự động hóa (tham khảo Bài 6).

7. Quy trình làm việc và các giới hạn. Xác định những câu hỏi nào có thể dùng chung một yêu cầu (request), những câu hỏi nào cần yêu cầu riêng biệt; cách thức gửi hình ảnh (nếu có); và ước tính chi phí (ghi rõ đây là con số ước tính) (tham khảo Bài 7).

8. Danh mục kiểm tra trước khi triển khai bản Beta. Xem bên dưới.

Danh mục kiểm tra trước khi ra mắt phiên bản Beta

Tính đến ngày 13 tháng 10 năm 2026, Decisions API đang ở giai đoạn thử nghiệm công khai (public beta) với một mô hình duy nhất. Danh mục kiểm tra này được tạo ra vì các thông tin trong giai đoạn beta thường xuyên thay đổi. Mỗi mục cần được đánh dấu xác nhận bởi một cá nhân cụ thể vào một ngày cụ thể.

DANH MỤC KIỂM TRA TRƯỚC KHI RA MẮT BẢN BETA — [tên quyết định]    ngày: [____]

[ ] Đọc lại tài liệu tại developers.openai.com/api/docs/guides/decisions. 
    Hiện vẫn là bản beta hay đã phát hành chính thức (GA)? Danh sách mô hình có còn giới hạn ở gpt-6-luna không?
[ ] Kiểm tra nhật ký thay đổi (changelog) cho các mục liên quan đến "Decisions" kể từ ngày [ngày cụ thể].
[ ] Các tên trường trong yêu cầu (request) của chúng ta đã khớp với các mẫu hiện tại trong tài liệu hướng dẫn chưa
    (model, input, questions, type, name, instructions, choices, levels)?
[ ] Xem lại thông tin giá cả: vẫn là 0,10 USD cho mỗi 1 triệu token đầu vào (chỉ tính đầu vào)? 
    Đã áp dụng các hệ số bổ sung (phụ phí theo khu vực / hệ số cho ngữ cảnh dài) vào ước tính chi phí chưa?
[ ] Đã xác nhận các biện pháp kiểm soát dữ liệu cho tài khoản của chúng ta (ZDR, HIPAA, quy định về lưu trữ dữ liệu) nếu
    dữ liệu đầu vào yêu cầu các tiêu chuẩn này. Đã nắm rõ các ngoại lệ về lưu trữ hình ảnh chưa?
[ ] Đã thực hiện kiểm tra thử nghiệm với 50 ví dụ; kết quả cho thấy quy trình chưa đủ điều kiện để tự động hóa hoàn toàn. 
    Các ngưỡng dự kiến ​​đã được so sánh trên một tập dữ liệu phát triển lớn, có nhãn và mang tính đại diện;
    sau đó được cố định và đánh giá trên một tập dữ liệu độc lập với quy mô phù hợp. Các trường hợp bỏ sót (misses): [__]; báo động giả (false alarms): [__]; 
    khối lượng cần xem xét (review volume): [__]; số trường hợp sai nhưng hệ thống vẫn tự tin (confident-wrong): [__] (kèm theo tổng số mẫu tương ứng).
[ ] Đã chạy thử nghiệm song song trên lưu lượng truy cập thực tế trong [__] tuần mà không thực hiện hành động tự động. 
    Tỷ lệ đồng thuận với con người: [__]%. Tỷ lệ từ chối (refusal rate): [__]%. Tỷ lệ chuyển sang quy trình dự phòng (fallback rate): [__]%.
[ ] Đã kiểm tra quy trình từ chối bằng cách đưa vào một trường hợp cần từ chối; kết quả cho thấy yêu cầu đã được chuyển đến kênh xem xét
    và KHÔNG bị chuyển đổi thành kết quả mặc định.
[ ] Đã kiểm tra các trường hợp tên câu trả lời bị thiếu, trùng lặp hoặc không xác định; ứng dụng đã từ chối các trường hợp này.
[ ] Kênh xem xét đã có nhân sự phụ trách; người đánh giá có thể thấy các giá trị xác suất (thay vì chỉ thấy nhãn); 
    nhật ký ghi lại các thay đổi thủ công đã hoạt động; đã lên lịch kiểm tra định kỳ hàng tuần để phát hiện các điểm kiểm tra ngẫu nhiên.
[ ] Hành động thực tế đầu tiên có thể đảo ngược. Quy trình hoàn tác: chuyển về [quy trình hiện tại]
    chỉ trong một bước. Người chịu trách nhiệm: [____].
[ ] Đã ấn định ngày đánh giá lại (sau 3 tháng hoặc khi phát hành chính thức - GA, tùy thời điểm nào đến trước).

Thực hành: Tạo và phản biện bản tóm tắt của bạn

Sử dụng hai câu lệnh (prompt): câu lệnh thứ nhất để soạn thảo; câu lệnh thứ hai để phản biện.

Nơi 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) bên trong khung văn bản.

Hãy soạn một bản "Tóm tắt Thiết kế Quyết định" (Decision Design Brief) dài một trang cho một quyết định mà tôi sẽ tự động hóa bằng Decisions API của OpenAI (phiên bản beta công khai, mô hình gpt-6-luna, endpoint POST /v1/decisions). Bản tóm tắt cần bao gồm 8 phần sau: 1) mô tả quyết định trong một câu; 2) loại câu hỏi và cấu trúc yêu cầu (request body) chi tiết, bao gồm các trường: model, input, và questions (với các thông số: type, name, instructions, choices hoặc levels); 3) ý nghĩa của con số đầu ra ("ước tính từ mô hình, không phải độ chính xác đã được đo lường"); 4) chi phí sai sót và ngưỡng tạm thời; 5) kế hoạch dán nhãn thử nghiệm với 50 ví dụ, kế hoạch đánh giá trên tập dữ liệu tách biệt, và chỉ số "tự tin nhưng sai lệch"; 6) chính sách từ chối và xem xét lại (các trường hợp từ chối, phương án dự phòng, quy trình chuyển cho con người nếu kết quả dưới ngưỡng; ghi lại các thay đổi/ghi đè; kiểm tra ngẫu nhiên ẩn danh); 7) quy trình làm việc và các giới hạn (yêu cầu độc lập hay phụ thuộc, hình ảnh chỉ chấp nhận định dạng base64, ước tính chi phí là 0,10 USD cho mỗi 1 triệu token đầu vào); 8) danh mục kiểm tra khi triển khai bản beta, bao gồm chạy thử nghiệm song song và bước thực hiện đầu tiên có thể hoàn tác.

Dữ liệu từ các bài học trước của tôi:
Thông số kỹ thuật quyết định: [dán nội dung từ Bài 2]
Các tùy chọn hoặc cấp độ (nếu có): [dán nội dung từ Bài 3 hoặc 4]
Chi phí sai sót và ngưỡng: [dán nội dung từ Bài 5]
Chính sách xem xét lại: [dán nội dung từ Bài 6]
Bảng quy trình làm việc: [dán nội dung từ Bài 7]

Đảm bảo độ dài gói gọn trong một trang. Đánh dấu bất kỳ thông tin nào bạn phải tự giả định bằng ký hiệu [ASSUMPTION].

Kết quả nhận được: Một bản tóm tắt dài một trang với các giả định đã được đánh dấu.

Cách xử lý kết quả: Tự mình giải quyết từng mục được đánh dấu [ASSUMPTION], sau đó sử dụng câu lệnh phản biện dưới đây trong cùng cuộc trò chuyện đó.

Bây giờ, hãy đóng vai một kiểm toán viên vận hành với tư duy hoài nghi. Hãy phân tích và phản biện bản tóm tắt nêu trên:
1. Tìm tất cả những chỗ mà xác suất hoặc mức độ tin cậy bị diễn giải sai thành một sự đảm bảo về độ chính xác, sau đó viết lại các câu đó.
2. Xác định các trường hợp mà việc từ chối phản hồi, thiếu câu trả lời hoặc kích hoạt cơ chế dự phòng có thể dẫn đến một hành động tự động; hãy loại bỏ các rủi ro này.
3. Chỉ ra sai lầm gây tốn kém nhất mà hệ thống này có thể mắc phải, đồng thời kiểm tra xem ngưỡng và quy trình xem xét có thực sự ngăn chặn được sai lầm đó hay không.
4. Liệt kê những nội dung cần được xác minh lại dựa trên tài liệu của OpenAI, vì API hiện vẫn đang trong giai đoạn thử nghiệm (beta).
Cung cấp bản tóm tắt đã được chỉnh sửa.

Nếu kết quả kiểm toán không tìm ra vấn đề gì, nghĩa là bạn chưa đủ hoài nghi. Hãy phản hồi: "Giả định rằng mô hình đang quá tự tin với dữ liệu của chúng ta, trong khi đội ngũ phụ trách xem xét lại đang thiếu nhân sự. Hãy thực hiện lại".

Kiểm tra nhanh: Tại sao bản tóm tắt lại coi hành động đầu tiên là "có thể đảo ngược"?

Trả lời: Vì ngưỡng thiết lập hiện chỉ mang tính thử nghiệm cho đến khi được đo lường trên lưu lượng truy cập thực tế; một hành động có thể đảo ngược sẽ giúp hạn chế chi phí nếu xảy ra sai sót trong quá trình tìm hiểu.

Các bước tiếp theo

• Đối với nhà phát triển: Hãy chạy các yêu cầu từ Bài 2 – 4 bằng các phiên bản SDK do OpenAI cung cấp. Sử dụng 50 ví dụ đã được gán nhãn làm bước khởi đầu để xây dựng tập đánh giá theo hướng dẫn của OpenAI; hãy thu thập một tập dữ liệu kiểm chứng lớn hơn và mang tính đại diện trước khi tự động hóa các hành động.

• Đối với quản lý vận hành và tuân thủ: Hãy mang bản tóm tắt này trao đổi với người chịu trách nhiệm quy trình hiện tại. Việc chạy thử nghiệm song song chính là điểm khởi đầu cho cuộc thảo luận này.

• Đối với tất cả mọi người: Hãy đặt lời nhắc trên lịch sau 3 tháng, hoặc vào ngày nhật ký thay đổi thông báo phiên bản chính thức (GA), để kiểm tra lại mọi thông tin đã nêu trong khóa học này.

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

• Một bản tóm tắt thiết kế quyết định (Decision Design Brief) bao gồm 8 phần: Quyết định cần đưa ra, thông số kỹ thuật chi tiết, ý nghĩa của các con số, chi phí sai sót và ngưỡng thiết lập, kế hoạch gán nhãn dữ liệu, chính sách xem xét, quy trình vận hành cùng các giới hạn, và danh mục kiểm tra trước khi triển khai thực tế.

• Hãy bắt đầu với một quyết định có thể đảo ngược và thực hiện chạy thử nghiệm song song. Hãy quan sát kỹ trước khi đưa ra hành động.

• Danh mục kiểm tra cho phiên bản beta là bắt buộc. Các tên trường, danh sách mô hình, giá cả và các giới hạn cần được xem xét lại vào một thời điểm cụ thể trước khi ra mắt chính thức.

• Con số này là ước tính. Bạn hãy đo lường độ chính xác của nó. Phần còn lại sẽ được xử lý thông qua quy trình thủ công.