Các workflow và giới hạn thực tế trong OpenAI Decisions API

Giờ đây, bạn đã có thể soạn thảo cả ba loại câu hỏi (Bài 2 - 4), thiết lập ngưỡng dựa trên chi phí sai sót (Bài 5), cũng như chuyển các trường hợp từ chối hoặc những trường hợp không rõ ràng cho con người xử lý (Bài 6). Bài học này sẽ kết hợp các thành phần đó thành những workflow, đồng thời trình bày các giới hạn mà OpenAI công bố cho phiên bản thử nghiệm công khai (public beta), cùng với những giới hạn khác không được nêu rõ.

Mô hình 1: Nhiều câu hỏi độc lập, một yêu cầu duy nhất

Theo hướng dẫn từ OpenAI: "Hãy đặt các câu hỏi độc lập vào cùng một mảng questions để đánh giá trên cùng một dữ liệu đầu vào. Ví dụ, đối với ảnh chụp sản phẩm, bạn có thể kiểm tra hư hại và phân loại sản phẩm trong cùng một yêu cầu. Mỗi câu hỏi có thể sử dụng một loại hình khác nhau".

Như vậy, một yêu cầu duy nhất tại quầy xử lý hàng trả lại có thể bao gồm:

• visible_damage (dạng khẳng định/phủ định - predicate)
• product_category (dạng lựa chọn - choice)
• packaging_condition (dạng chấm điểm - score)

Tất cả đều dựa trên cùng một dữ liệu đầu vào, và kết quả trả về cho mỗi mục sẽ được gắn với tên tương ứng. Chi phí được tính dựa trên số lượng token đầu vào; do đó, một yêu cầu chứa ba câu hỏi sẽ có chi phí tương đương với một yêu cầu chứa một câu hỏi (cộng thêm phần văn bản cho các câu hỏi bổ sung).

Mô hình 2: Những quyết định phụ thuộc lẫn nhau, các yêu cầu riêng biệt

Cũng theo hướng dẫn này: "Đối với các quyết định phụ thuộc vào câu trả lời trước đó, hãy gửi những yêu cầu riêng biệt. Chẳng hạn, trước tiên hãy kiểm tra hư hại, sau đó sử dụng kết quả đó để quyết định xem có cần yêu cầu xác định loại hình sửa chữa hay không".

Trong cùng một yêu cầu, một câu hỏi không thể truy cập vào câu trả lời của câu hỏi khác. Nếu bước thứ hai phụ thuộc vào bước thứ nhất, code của bạn cần thực hiện lệnh gọi thứ nhất, áp dụng ngưỡng đã thiết lập, rồi mới thực hiện lệnh gọi thứ hai (hoặc chuyển trường hợp đó cho con người xử lý).

Mô hình 3: Hình ảnh – Cách duy nhất được phiên bản Beta chấp nhận

Hướng dẫn quy định nghiêm ngặt: "Hình ảnh phải ở dạng dữ liệu base64 nhúng trực tiếp (inline). Các đường dẫn hình ảnh qua HTTP/HTTPS hoặc định dạng file_id đều không được endpoint này hỗ trợ". Bạn cần kết hợp phần văn bản (input_text) và phần hình ảnh (input_image) vào cùng một tin nhắn từ người dùng. Dưới đây là ví dụ từ OpenAI về việc phân tích hư hại, đã được tinh giản cho phù hợp với định dạng này:

{
  "model": "gpt-6-luna",
  "input": [{
    "role": "user",
    "content": [
      {"type": "input_text", "text": "Inspect the product in this photo."},
      {"type": "input_image", "image_url": "data:image/png;base64,<BASE64 OF product.png>"}
    ]
  }],
  "questions": [{
    "type": "predicate",
    "name": "visible_damage",
    "instructions": "Does the product have visible damage, such as a crack, tear, or dent? Ignore shadows and damage to the packaging."
  }]
}

Các hệ quả thực tế: Ứng dụng của bạn sẽ tải file xuống, kiểm tra xem file đó có được phép sử dụng hay không, chuyển đổi sang định dạng base64, rồi gửi đi. Nếu hình ảnh là yếu tố quyết định lộ trình, thì việc thử lại mà không có hình ảnh đó sẽ dẫn đến một quyết định khác; trong trường hợp này, hãy chuyển yêu cầu sang quy trình xem xét (review). Một số tài liệu tham khảo đề cập đến giới hạn 128 thành phần hình ảnh cho mỗi yêu cầu; tuy nhiên, thông tin này không có trong hướng dẫn của OpenAI (tính đến ngày 13 tháng 10 năm 2026), vì vậy hãy xác minh lại trước khi xây dựng hệ thống dựa trên giới hạn đó.

Mô hình 4: Lựa chọn giọng nói và hành động

OpenAI cung cấp một hướng dẫn bổ sung về việc sử dụng tính năng Decisions với API Live (voice) của họ: Mô hình giọng nói vẫn tiếp tục hội thoại trong khi ứng dụng của bạn gửi bản ghi lời nói cùng trạng thái hiện tại của ứng dụng đến Decisions. Hệ thống này sẽ đưa ra một danh sách các lựa chọn ngắn gọn (ví dụ: back, reload, noop), sau đó thực thi hành động đã chọn. Có hai quy tắc từ hướng dẫn này có thể áp dụng cho mọi quy trình làm việc: Luôn bao gồm tùy chọn "không làm gì cả" (chọn noop nếu không có hành động nào phù hợp) và xác thực lựa chọn đó dựa trên trạng thái hiện tại trước khi thực thi. Hãy luôn lưu trữ API key trên máy chủ của bạn.

Một vài lưu ý về các card:

• Chi phí. Tài liệu hướng dẫn nêu rằng bạn chỉ phải trả phí cho các token đầu vào (input token). Hãy tính tổng cho toàn bộ yêu cầu: bao gồm các chỉ dẫn, mô tả lựa chọn, mô tả cấp độ và bất kỳ hình ảnh nào đi kèm. Mặc dù trang bảng giá của mô hình có đề cập đến các tùy chọn Batch, Flex và Fast, nhưng tài liệu hướng dẫn cho /v1/decisions lại không nhắc đến chúng; vì vậy, đừng lập ngân sách dựa trên các mức chiết khấu mà bạn chưa thể xác nhận.
• Lưu cache. Mục chi phí cho Decisions không đề cập đến việc đọc từ cache. Người dùng trên diễn đàn OpenAI cho biết tính năng lưu trữ đầu vào vào cache không khả dụng trong giai đoạn thử nghiệm (beta), dù có gợi ý rằng nó có thể được bổ sung sau này. Hãy thiết kế hệ thống với giả định rằng mọi yêu cầu đều sẽ tính phí đầy đủ.
• Ngữ cảnh. Trang thông tin về mô hình gpt-6-luna liệt kê cửa sổ ngữ cảnh là 1.050.000 token và giới hạn đầu vào tối đa là 922.000 token; trong đó, các câu lệnh (prompt) vượt quá 272.000 token đầu vào sẽ bị tính phí gấp đôi. Một phản hồi trên diễn đàn cho biết hạn mức tiêu chuẩn cho endpoint này là 272.000 token đầu vào – thông tin này không có trong tài liệu hướng dẫn chính thức. Dù thế nào đi nữa, nhiều ngữ cảnh hơn không đồng nghĩa với tốt hơn: hãy chỉ gửi những bằng chứng cần thiết cho việc ra quyết định, thay vì gửi toàn bộ dữ liệu lưu trữ.
• Tốc độ. OpenAI cho biết tốc độ này "nhanh hơn khoảng 10 lần so với Responses API". Hiện chưa có dữ liệu benchmark nào được công bố. Bạn nên tự đo lường toàn bộ quy trình dựa trên lưu lượng truy cập thực tế của mình, bao gồm cả thời gian chờ trong hàng đợi và các bước xử lý thủ công bởi con người.

Thử nghiệm: Lập sơ đồ workflow của bạn

Nơi dá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 nội dung.

Hãy giúp tôi lập sơ đồ workflow trên Decisions API của OpenAI. Các quy tắc từ tài liệu hướng dẫn của OpenAI: Những câu hỏi độc lập có thể cùng nằm trong một yêu cầu và sử dụng chung dữ liệu đầu vào; Một câu hỏi phụ thuộc vào câu trả lời trước đó cần một yêu cầu (request) riêng biệt; hình ảnh phải được cung cấp dưới dạng dữ liệu base64 nhúng trực tiếp (không dùng URL lưu trữ bên ngoài hay ID file); bạn chỉ trả phí dựa trên số lượng token đầu vào; việc từ chối trả lời được coi là một loại phản hồi riêng biệt.

Quy trình của tôi, từng bước một: [mô tả từ 3 đến 6 bước mà con người hiện đang thực hiện]
Các dữ liệu đầu vào có sẵn tại mỗi bước: [văn bản / hình ảnh / cả hai]
Các quyết định phụ thuộc vào quyết định trước đó: [liệt kê nếu có]

Hãy cung cấp cho tôi:
1. Một bảng gồm các cột: bước | tên câu hỏi | loại (khẳng định/lựa chọn/điểm số) | dùng chung yêu cầu với | lý do cần yêu cầu riêng...
2. Đối với mỗi yêu cầu: ước tính sơ bộ về số lượng token đầu vào (bao gồm hướng dẫn + các tùy chọn + bằng chứng) và chi phí hàng tháng (với mức giá 0,10 USD cho mỗi 1 triệu token đầu vào) dựa trên [N] mục mỗi tháng; hãy ghi chú rõ: "đây là ước tính, vui lòng kiểm tra lại trên trang bảng giá".
3. Ba trường hợp cần sự can thiệp của con người (các "làn đường" xử lý): từ chối (refusal), phương án dự phòng (fallback), và trường hợp kết quả dưới ngưỡng quy định (below threshold).

Những gì bạn sẽ nhận được: Kế hoạch yêu cầu, ước tính chi phí và các điểm cần sự can thiệp của con người.

Cách sử dụng kết quả: Đây chính là phần "workflow và các giới hạn" trong bản tóm tắt dự án cuối khóa của bạn. Hãy giữ nguyên chú thích rằng chi phí chỉ là ước tính.

Nếu kết quả chưa hợp lý: Chẳng hạn như đặt một câu hỏi phụ thuộc vào cùng một yêu cầu với câu hỏi mà nó phụ thuộc vào, hãy phản hồi: "Hãy tách các quyết định phụ thuộc thành các yêu cầu riêng biệt".

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

• Các câu hỏi độc lập có thể dùng chung một yêu cầu; những câu hỏi phụ thuộc thì không.
• Ngưỡng (threshold) và quy trình xem xét (review lane) sẽ nằm giữa các lần gọi API.
• Hình ảnh phải được cung cấp dưới dạng dữ liệu base64 nhúng trực tiếp. Không sử dụng URL lưu trữ bên ngoài hay ID file.
• Chi phí chỉ tính trên dữ liệu đầu vào với mức giá 0,10 USD cho mỗi 1 triệu token (có thể áp dụng hệ số nhân tùy theo khu vực hoặc ngữ cảnh dài). Các tính năng xử lý hàng loạt (batch) và lưu cache (caching) hiện chưa được đề cập cho endpoint này.
• Cần tách biệt các dữ kiện đã được xác thực khỏi những báo cáo từ cộng đồng, và kiểm tra lại cả hai nguồn thông tin này trước khi triển khai thực tế.