Câu hỏi xác định trạng thái trong OpenAI Decisions API: Quyết định đầu tiên trong 15 phút

Hãy soạn một câu hỏi xác định trạng thái (predicate question) với các tiêu chí có thể quan sát được cho một quyết định thực tế trong công việc của bạn; xem xét cấu trúc yêu cầu và phản hồi cụ thể, đồng thời đánh giá xác suất thu được mà không nên đặt quá nhiều niềm tin vào đó.

15 phút để có một câu trả lời thực tế

Trong Bài 1, bạn đã chọn một quyết định từ công việc của mình. Bây giờ, bạn sẽ chuyển đổi nó thành một "câu hỏi dạng khẳng định/phủ định" – loại hình đơn giản nhất trong ba dạng câu hỏi – đó là một bài kiểm tra kiểu "có/không" (yes/no) trả về kết quả dưới dạng xác suất. Đến cuối bài học này, bạn sẽ có một Decision Spec Sheet gói gọn trong một trang, có thể chuyển cho lập trình viên. Nếu chọn thực hiện yêu cầu (request) tùy chọn, bạn còn nhận được câu trả lời thực tế từ API.

Bạn không cần phải viết code lập trình. Nếu muốn thực hiện yêu cầu này, bạn có thể sao chép các khối nội dung bên dưới (được lấy từ hướng dẫn về Decisions của OpenAI và được đánh dấu là tùy chọn).

Bước 1: Chọn một quyết định dạng "Có/Không" (2 phút)

Một câu hỏi dạng khẳng định/phủ định tốt cần đảm bảo các yếu tố:

• Có/Không. Ví dụ: "Email này có yêu cầu hoàn tiền không?" (Thay vì hỏi: "Email này muốn gì?").
• Có thể quan sát được. Bằng chứng phải nằm ngay trong văn bản hoặc hình ảnh. (Thay vì hỏi: "Khách hàng này có khả năng rời bỏ dịch vụ không?").
• Có thể đảo ngược. Nếu kết quả sai, dữ liệu chỉ bị chuyển nhầm luồng xử lý chứ không bị hủy hoại vĩnh viễn.

Hãy viết quyết định đó thành một câu bắt đầu bằng từ "Liệu..". hoặc "Có phải.."..

Bước 2: Soạn hướng dẫn dựa trên các tiêu chí có thể quan sát được (5 phút)

Lời khuyên từ OpenAI rất ngắn gọn: "Hãy đặt câu hỏi dựa trên các tiêu chí có thể quan sát được". Dưới đây là ví dụ của họ về việc kiểm tra ảnh sản phẩm và lý do tại sao cách tiếp cận này hiệu quả:

"Sản phẩm có xuất hiện hư hại nào có thể nhìn thấy được không, chẳng hạn như vết nứt, vết rách hoặc vết móp? Hãy bỏ qua các bóng đổ hoặc hư hại trên bao bì".

Phân tích:

• Nêu rõ các bằng chứng cần tìm (vết nứt, vết rách, vết móp).
• Loại trừ các trường hợp dễ gây nhầm lẫn (bóng đổ, hư hại trên bao bì).
• Chỉ tập trung vào một điều kiện duy nhất, không gộp nhiều điều kiện cùng lúc.

Bây giờ, hãy soạn câu hỏi của riêng bạn. Sử dụng câu lệnh (prompt) dưới đây để kiểm chứng độ chặt chẽ của nó.

Nơi thực hiện: Mở ChatGPT (chatgpt.com), Claude (claude.ai) hoặc Gemini và bắt đầu một cuộc trò chuyện mới.

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

Hãy đóng vai trò là người đánh giá cho một câu hỏi dạng có/không (yes/no) mà tôi sẽ gửi tới Decisions API của OpenAI dưới dạng một "mệnh đề kiểm chứng" (predicate). API này chỉ trả về một xác suất (từ 0 đến 1) cho biết khả năng mệnh đề đó là đúng. Các hướng dẫn hiệu quả cần nêu rõ những tiêu chí có thể quan sát được và loại trừ các trường hợp dễ gây nhầm lẫn (dương tính giả). Ví dụ từ OpenAI: "Sản phẩm có hư hại hữu hình nào không, chẳng hạn như vết nứt, vết rách hoặc vết móp? Hãy bỏ qua các bóng đổ và hư hại trên bao bì."

Quyết định của tôi: [một câu bắt đầu bằng "Có phải..." hoặc "Liệu..."]
Nội dung đầu vào sẽ là: [ví dụ: toàn bộ văn bản email của khách hàng / ảnh chụp sản phẩm bị trả lại]
Các trường hợp trông có vẻ là "có" nhưng thực tế không phải: [ví dụ: khách hàng hỏi về chính sách đổi trả nhưng không yêu cầu hoàn tiền]

Hãy cung cấp cho tôi:
1. Một câu hướng dẫn đã được viết lại (tối đa 40 từ), bao gồm các tiêu chí có thể quan sát được và ít nhất một điều khoản "bỏ qua" cụ thể.
2. Một tên gọi cho câu hỏi theo định dạng snake_case (ví dụ: needs_refund_review).
3. Ba ví dụ đầu vào: một trường hợp chắc chắn là "có", một trường hợp chắc chắn là "không", một trường hợp nằm ở ranh giới giữa hai khả năng; kèm theo đó là phạm vi xác suất dự kiến ​​cho mỗi trường hợp.

Cách điền thông tin: Thay thế nội dung trong ba dấu ngoặc vuông bằng quyết định thực tế của bạn. Ví dụ: "Email này có yêu cầu hoàn tiền không? Đầu vào: toàn bộ văn bản email. Các trường hợp dễ nhầm lẫn: câu hỏi về chính sách, khiếu nại nhưng không kèm yêu cầu hoàn tiền".

Kết quả bạn nhận được: Một câu hướng dẫn đã được tinh chỉnh, một tên gọi và ba trường hợp kiểm thử.

Cách sử dụng kết quả: Dán phần hướng dẫn và tên gọi đó vào Decision Spec Sheet của bạn (xem bên dưới).

Nếu kết quả chưa phù hợp: Nếu câu hỏi được viết lại yêu cầu giải thích hoặc liệt kê, hãy phản hồi: "Chỉ chấp nhận điều kiện dạng có/không. Không yêu cầu giải thích".

Bước 3: Xem cấu trúc yêu cầu chính xác (3 phút)

Đây là yêu cầu dạng plain text. Tên các trường và cấu trúc tuân theo hướng dẫn của OpenAI; chỉ có phần văn bản ví dụ là do chúng tôi soạn. Hãy đọc qua, ngay cả khi bạn không thực thi nó.

curl https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer ${OPENAI_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "input": "Chào bạn, tôi đã đặt mua chiếc ấm màu xanh vào ngày 2 tháng 10, nhưng khi nhận hàng thì nắp ấm bị nứt. Tôi muốn được hoàn lại tiền.",
    "questions": [{
      "type": "predicate",
      "name": "needs_refund_review",
      "instructions": "Khách hàng có yêu cầu hoàn tiền một cách rõ ràng không? Hãy bỏ qua các câu hỏi về chính sách đổi trả nếu trong đó không có yêu cầu hoàn tiền."
    }]
  }'

Chức năng của từng trường:

• model: trong giai đoạn thử nghiệm công khai (public beta), chỉ hỗ trợ gpt-6-luna.
• input: dữ liệu làm căn cứ (evidence), ở dạng chuỗi plain. Đối với hình ảnh, bạn cần gửi các tin nhắn người dùng (user messages) bao gồm cả thành phần input_text và input_image (xem Bài 7).
• questions: một danh sách, trong đó mỗi mục bao gồm loại câu hỏi (type), tên định danh duy nhất (unique name) và các hướng dẫn (instructions).

Và cấu trúc của dữ liệu phản hồi trả về, dựa theo ví dụ minh họa từ OpenAI:

{
  "answers": [
    {
      "type": "predicate",
      "name": "needs_refund_review",
      "probability": 0.92
    }
  ]
}

Dành cho nhà phát triển (tùy chọn):

Để chạy thử, hãy thiết lập biến môi trường OPENAI_API_KEY trong shell của bạn, sau đó dán block curl vào terminal. Nếu không muốn sử dụng terminal, bạn có thể truy cập Decisions Playground của OpenAI (tại platform.openai.com/decisions, yêu cầu đăng nhập) để thực hiện các truy vấn tương tự. Lưu ý rằng trong giai đoạn thử nghiệm (beta), một thành viên trong cộng đồng đã báo cáo rằng các nhãn trường trên Playground không khớp với tên trường trong API; vì vậy, hãy ưu tiên sử dụng tên gọi được nêu trong hướng dẫn này thay vì các nhãn trên Playground.

Bước 4: Hiểu đúng về các con số (3 phút)

Theo cách diễn giải của OpenAI: Giá trị xác suất (probability) "là ước tính của mô hình về khả năng một điều kiện là đúng. Bạn có thể sử dụng giá trị này để đánh dấu các hình ảnh cần xem xét lại dựa trên một ngưỡng (threshold) do bạn tự chọn".

Hãy tập ba thói quen sau ngay từ bây giờ:

1. Hãy nói "mô hình ước tính là 0,92" thay vì "độ chính xác là 92%". Độ chính xác là chỉ số bạn tự đo lường dựa trên tập dữ liệu đã được gán nhãn của riêng mình (xem chi tiết tại Bài 5).
2. Xác định ngưỡng trước khi xem kết quả. Ví dụ, đối với quy trình xử lý yêu cầu hoàn tiền - nơi việc bỏ sót yêu cầu có thể khiến khách hàng không hài lòng - bạn có thể đặt ngưỡng là 0,3 (mọi kết quả trên 0,3 sẽ được chuyển đi xem xét lại). Ngược lại, nếu một cảnh báo sai (false alarm) gây lãng phí thời gian của chuyên viên, bạn nên đặt ngưỡng cao hơn.
3. Giữ lại các trường hợp nằm ở ngưỡng giữa (từ 0,4 đến 0,6); đây chính là những trường hợp giúp bạn đánh giá xem các hướng dẫn của mình đã đủ rõ ràng hay chưa.

Sản phẩm của bạn: Bảng thông số quyết định (Decision Spec Sheet)

Hãy sao chép nội dung này vào một tài liệu và điền các thông tin cần thiết. Đây sẽ là nền tảng cho dự án cuối khóa của bạn.

BẢNG THÔNG SỐ QUYẾT ĐỊNH (DECISION SPEC SHEET)

Quyết định (một câu):
Loại câu hỏi: xác định trạng thái (predicate)
Tên câu hỏi (định dạng snake_case):
Hướng dẫn (các tiêu chí có thể quan sát được + điều khoản loại trừ):
Dữ liệu đầu vào mà mô hình sẽ tiếp nhận:
Ý nghĩa của xác suất: "ước tính của mô hình về khả năng điều kiện đó là đúng", KHÔNG PHẢI là độ chính xác đã được đo lường.
Chi phí nếu đưa ra kết luận CÓ sai:
Chi phí nếu đưa ra kết luận KHÔNG sai:
Ngưỡng đánh giá dự kiến ​​(sẽ được kiểm thử trong Bài 5):
Kiểm tra lại (Beta): tên các trường dữ liệu và mô hình đã được xác nhận đối chiếu với tài liệu tại developers.openai.com/api/docs/guides/decisions vào ngày [ngày]

Những điểm chính cần lưu ý

• Câu hỏi xác định trạng thái (predicate) là một dạng kiểm tra có/không, trả về giá trị xác suất từ ​​0 đến 1. Hãy nêu rõ các tiêu chí có thể quan sát được và chỉ định những yếu tố mà mô hình cần bỏ qua.
• Mỗi câu hỏi cần có một tên gọi duy nhất; API sẽ phản hồi lại tên này để bạn có thể đối chiếu câu trả lời với câu hỏi tương ứng.
• Giá trị xác suất là một ước tính, không phải là độ chính xác. Hãy chọn một ngưỡng dựa trên chi phí của các sai sót và thực hiện kiểm thử sau đó.
• Hiện tại, bạn đã có một bảng thông số quyết định (Decision Spec Sheet) cho một quyết định thực tế trong công việc của mình.