ใช้ Decisions API เมื่องานเป็นการจัดประเภท, จัดเส้นทาง, ให้คะแนน หรือคัดกรองบางสิ่ง และคุณต้องการค่าความน่าจะเป็นกลับมา: มันทำงานบน GPT-6 Luna, คืนค่าคำตอบแบบมีประเภทแทนข้อความ, คิดค่าบริการเฉพาะอินพุตที่ $0.10 ต่อ 1 ล้านโทเค็นโดยไม่มีค่าใช้จ่ายเอาต์พุต, การอ่านแคช หรือการเขียนแคช, และ OpenAI ระบุว่ามันเร็วกว่า Responses API ประมาณ 10 เท่า ใช้ Responses API เมื่อคุณต้องการข้อความที่สร้างขึ้น, JSON ในโครงสร้างข้อมูล (schema) ของคุณเอง, การเรียกใช้เครื่องมือ, การสตรีมมิ่ง หรือสถานะการสนทนา Decisions API เข้าสู่ช่วงเบต้าสาธารณะเมื่อ 2026-10-06
บทความนี้จะแสดงการทำงานหนึ่งงาน (การจัดเส้นทางคำขอการสนับสนุน) ผ่านเอนด์พอยต์ทั้งสอง, เปรียบเทียบสิ่งที่แต่ละอันส่งคืน, คำนวณค่าใช้จ่ายหนึ่งครั้ง, และปิดท้ายด้วยหมายเหตุการโยกย้ายและวิธีการทดสอบทั้งสองในโปรเจกต์ Apidog เดียวกัน สำหรับโครงสร้างของเอนด์พอยต์เริ่มต้นที่ บทความหลักของ Decisions API; สำหรับข้อมูลอ้างอิงเบื้องต้น ดูที่ คู่มือ Responses API ของเรา
ตารางคุณสมบัติ
| Decisions API | Responses API (GPT-6 Luna) | |
|---|---|---|
| เอนด์พอยต์ | POST /v1/decisions |
POST /v1/responses |
| เอาต์พุต | คำตอบประเภท predicate, choice, score (พร้อม refusal) พร้อมค่าความน่าจะเป็นและความเชื่อมั่นจากเอนด์พอยต์ |
ข้อความที่สร้างขึ้น หรือ JSON ที่เป็นไปตามโครงสร้างข้อมูลของคุณผ่าน text.format |
| JSON schema ของคุณเอง | ไม่มี | มี, json_schema พร้อม strict: true |
| เครื่องมือ / การเรียกใช้ฟังก์ชัน | ไม่มี | มี |
| การสตรีมมิ่ง | ไม่มี | มี |
| สถานะการสนทนา | ไม่มี | มี |
| การแคชพรอมต์ | ไม่มีค่าใช้จ่ายแคช; ตาม ฟอรัมของ OpenAI, ยังไม่มีการแคช | มี, อินพุตที่แคชแล้ว $0.01 ต่อ 1M |
| การประมวลผลเป็นชุด (Batch) | ไม่มีเอกสาร | มี, 50% ของอัตรามาตรฐาน |
| รูปภาพ | มี, base64 data URLs; เอกสารอ้างอิงยังระบุ public HTTP(S) URLs, สูงสุด 128 ต่อคำขอ | มี, Luna รองรับทั้งข้อความและรูปภาพ |
| การตัดสินใจแบบต่อเนื่อง (ขึ้นอยู่กับกันและกัน) | คำขอแยกกัน | การตอบกลับที่สร้างขึ้นหนึ่งครั้งสามารถมีฟิลด์ที่ขึ้นอยู่กับกัน |
| ราคาต่อ 1 ล้านโทเค็น, บริบทสั้น | อินพุต $0.10; ไม่มีค่าใช้จ่ายเอาต์พุต | อินพุต $0.10, เอาต์พุต $0.50 รวมถึงโทเค็นการให้เหตุผล |
| ZDR / HIPAA | รองรับสำหรับลูกค้าที่มีสิทธิ์; การประมวลผลตามภูมิภาคในสหรัฐอเมริกาและสหภาพยุโรป | ไม่ได้ครอบคลุมในการเปรียบเทียบนี้; ดูหน้าการควบคุมข้อมูลของ OpenAI |
ทุกแถวมาจาก คู่มือ Decisions, เอกสารอ้างอิง API และ หน้าอัตราค่าบริการ ของ OpenAI
งานเดียวกันสองวิธี: จัดเส้นทางคำขอการสนับสนุน
คำขอระบุว่า "ฉันถูกเรียกเก็บเงินสองครั้งสำหรับคำสั่งซื้อของฉัน" แผนกต่าง ๆ ได้แก่ ฝ่ายบัญชี (billing), ฝ่ายเทคนิค (technical), ฝ่ายจัดส่ง (shipping) และอื่น ๆ นี่คือคำขอ Responses API พร้อม Structured Outputs ซึ่งเป็นวิธีที่ทีมส่วนใหญ่ทำในปัจจุบัน:
curl https://api.openai.com/v1/responses \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-6-luna",
"input": "Route this support ticket to one department.\n\nTicket: I was charged twice for my order.",
"text": {
"format": {
"type": "json_schema",
"name": "ticket_route",
"strict": true,
"schema": {
"type": "object",
"properties": {
"department": {
"type": "string",
"enum": ["billing", "technical", "shipping", "other"]
}
},
"required": ["department"],
"additionalProperties": false
}
}
}
}'
และคำขอ Decisions API สำหรับคำขอเดียวกัน:
curl https://api.openai.com/v1/decisions \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-6-luna",
"input": "I was charged twice for my order.",
"questions": [
{
"type": "choice",
"name": "department",
"instructions": "Which department should handle this ticket?",
"choices": [
{"value": "billing", "description": "Charges, refunds, invoices"},
{"value": "technical", "description": "Bugs, errors, login problems"},
{"value": "shipping", "description": "Delivery, tracking, returns in transit"},
{"value": "other", "description": "Anything else"}
]
}
]
}'
เนื้อหาของ Responses API จะมีคำถามอยู่ในพรอมต์และคำตอบที่อนุญาตอยู่ใน schema ในขณะที่เนื้อหาของ Decisions API จะมีคำขอแบบดิบเป็น input และคำถามเป็น choice ที่มีค่าไม่ซ้ำกันตั้งแต่ 2 ถึง 255 ค่า; ไม่มีฟิลด์ temperature, reasoning, stream หรือ text เนื่องจากไม่มีอยู่ในเอนด์พอยต์นั้น
สิ่งที่แต่ละอันส่งคืน
Responses API จะส่งคืนข้อความที่สร้างขึ้น ด้วย schema ที่เข้มงวด ข้อความนั้นจะเป็น JSON ที่ถูกต้อง ดังนั้นหลังจากแยกวิเคราะห์ คุณก็จะได้ป้ายกำกับ:
{"department": "billing"}
หากคุณต้องการตัวเลขความเชื่อมั่น คุณต้องเพิ่มฟิลด์ลงใน schema และขอให้โมเดลเขียนค่าหนึ่ง; สิ่งที่กลับมาคือข้อความที่สร้างขึ้นซึ่งดูเหมือนค่าความน่าจะเป็น แต่ไม่ใช่ค่าที่วัดได้จริง
Decisions API ส่งคืนป้ายกำกับพร้อมกับการกระจายข้อมูลเบื้องหลัง ตัวเลขด้านล่างคือตัวอย่างในคู่มือของ OpenAI สำหรับอินพุตนี้โดยเฉพาะ:
{
"model": "gpt-6-luna",
"answers": [
{
"type": "choice",
"name": "department",
"choice": "billing",
"probabilities": [
{"value": "billing", "probability": 0.95},
{"value": "technical", "probability": 0.02},
{"value": "shipping", "probability": 0.01},
{"value": "other", "probability": 0.02}
],
"confidence": 0.93
}
]
}
ออบเจกต์ usage จะตามหลัง answers (แสดงในส่วนค่าใช้จ่าย) ไม่มีตัวแยกวิเคราะห์ ไม่มี regex ฟิลด์ confidence คือสิ่งที่คุณใช้เป็นเกณฑ์ และคำแนะนำของ OpenAI คือการตั้งเกณฑ์นั้นจากตัวอย่างที่คุณติดป้ายกำกับเอง เนื่องจากไม่มีตัวเลขความแม่นยำหรือการสอบเทียบใด ๆ ที่เผยแพร่ การปฏิเสธจะมาในรูปแบบ {"type": "refusal", "name": "department"}; คำถามอื่น ๆ ในคำขอเดียวกันยังคงได้รับคำตอบ
ค่าใช้จ่าย: การคำนวณเพียงครั้งเดียว
เอนด์พอยต์ทั้งสองเรียกเก็บเงินจากอินพุต Luna ที่ $0.10 ต่อ 1 ล้านโทเค็นในบริบทสั้น (อินพุตสูงสุด 272K โทเค็น) ความแตกต่างอยู่ที่เอาต์พุต ลองใช้ตั๋ว 500 โทเค็นที่ 1,000,000 คำขอ:
- Decisions API: 500 / 1,000,000 x $0.10 = $0.00005 ต่อคำขอ ดังนั้น $50 สำหรับหนึ่งล้านคำขอ โดยไม่มีค่าใช้จ่ายเอาต์พุตหรือแคชที่ต้องเพิ่ม
- Responses API: อินพุต $50 เท่ากัน บวกกับเอาต์พุตที่ $0.50 ต่อ 1 ล้านโทเค็น ป้ายกำกับ JSON 40 โทเค็นคือ 40 / 1,000,000 x $0.50 = $0.00002 ต่อคำขอ หรือ $20 สำหรับหนึ่งล้านคำขอ จากนั้นเพิ่มโทเค็นการให้เหตุผล ซึ่ง Luna คิดค่าบริการเป็นเอาต์พุตที่ $0.50 เท่ากัน
ดังนั้นส่วนต่างที่เห็นได้ชัดสำหรับป้ายกำกับเพียงอย่างเดียวคือ $50 เทียบกับ $70 ส่วนต่างที่ใหญ่กว่าคือส่วนของการให้เหตุผล และวิธีที่ซื่อสัตย์ในการระบุคือ Decisions API ไม่คิดค่าบริการโทเค็นเอาต์พุตเลย; ตัวนับทั้งสองแสดงค่า 0 ในตัวอย่างอ้างอิงของ OpenAI:
"usage": {
"input_tokens": 42,
"input_tokens_details": {"cached_tokens": 0, "cache_write_tokens": 0},
"output_tokens": 0,
"output_tokens_details": {"reasoning_tokens": 0},
"total_tokens": 42
}
ข้อควรระวังสองประการ Responses API มีกลไกที่ Decisions API ไม่มี: reasoning.effort สามารถลดลงเหลือ none บน Luna, การแคชพรอมต์ ทำให้อินพุตที่ซ้ำกันมีราคา $0.01 ต่อ 1 ล้านโทเค็น และ Batch API ลดอัตรามาตรฐานลงครึ่งหนึ่ง ไม่มีเอกสารใดระบุสิ่งเหล่านี้สำหรับ Decisions API และอินพุตบริบทแบบยาว (มากกว่า 272K โทเค็น) เพิ่มอัตราอินพุตเป็นสองเท่าสำหรับทั้งสอง ดังนั้นคำขอ Decisions API ที่มีบริบทแบบยาวจะมีราคา $0.20 ต่อ 1 ล้านอินพุต (มาจากตัวคูณในหน้าอัตราค่าบริการ); การประมวลผลตามภูมิภาคเพิ่มขึ้น 10%
ความเร็ว
OpenAI ระบุว่า Decisions API เร็วกว่า Responses API ประมาณ 10 เท่า ไม่มีตัวเลขความหน่วงสัมบูรณ์ที่เผยแพร่ ดังนั้นให้ถือว่าข้อกล่าวอ้างนี้เป็นทิศทางมากกว่างบประมาณ และวัดค่า p50 และ p95 ของคุณเองก่อนที่คุณจะย้ายเส้นทางที่ใช้งานบ่อย นักพัฒนาคนหนึ่งในฟอรัมของ OpenAI รายงานว่าการตัดสินใจจากอินพุตรูปภาพใช้เวลาประมาณ 0.8 วินาทีในการเชื่อมต่อที่ช้า; นั่นเป็นเรื่องเล่าส่วนบุคคล ไม่ใช่เกณฑ์มาตรฐาน ทิศทางนี้เป็นไปได้: Responses API สร้างโทเค็น รวมถึงการให้เหตุผล และคุณต้องรอจนกว่าจะได้รับโทเค็นสุดท้าย
กฎการตัดสินใจ
เลือก Decisions API เมื่อเอาต์พุตเป็นหนึ่งในสิ่งเหล่านี้:
- ใช่/ไม่ใช่ พร้อมความน่าจะเป็น (
predicate): “ข้อความนี้เป็นสแปมหรือไม่?” - หนึ่งใน N หมวดหมู่ที่ไม่เรียงลำดับ (
choice): แผนก, เจตนา, โมเดลหรือเครื่องมือใดที่จะเรียกใช้ต่อไป รวมถึงตัวเลือกสำรอง เช่น "อื่น ๆ" - ระดับที่เรียงลำดับ (
score): ความรุนแรง, ความสำคัญ, ความเร่งด่วน คะแนนคือค่าเฉลี่ยถ่วงน้ำหนักความน่าจะเป็นของดัชนีระดับที่เริ่มต้นจาก 0 ดังนั้น 1.1 หมายถึงระหว่างระดับ 1 และระดับ 2 ใกล้เคียงกับ 1 - เกต/ตัวกรอง: เปรียบเทียบ
confidenceหรือprobabilityกับเกณฑ์และส่งรายการที่มีความเชื่อมั่นต่ำไปยังคิวของมนุษย์
เลือก Responses API เมื่อมีสิ่งใดสิ่งหนึ่งเหล่านี้เป็นจริง:
- คุณต้องการข้อความที่คนจะอ่าน: สรุป, คำตอบ, คำอธิบาย
- คุณต้องการออบเจกต์ในรูปแบบของคุณเอง: ฟิลด์ที่ดึงออกมา, โครงสร้างซ้อนกัน, อาร์เรย์ที่มีความยาวไม่แน่นอน นั่นคือขอบเขตของ Structured Outputs และคู่มือของ OpenAI ก็ระบุไว้เช่นนั้น
- โมเดลควรร้องขอการเรียกใช้เครื่องมือพร้อมอาร์กิวเมนต์: การเรียกใช้ฟังก์ชัน
- คุณต้องการการสตรีมมิ่ง, สถานะการสนทนา หรือโมเดลอื่นที่ไม่ใช่ Luna
- การตัดสินใจหนึ่งขึ้นอยู่กับอีกอัน และคุณต้องการทั้งสองอย่างในการเรียกเพียงครั้งเดียว Decisions API รองรับคำถามอิสระหลายข้อในอินพุตเดียว แต่การตัดสินใจที่ขึ้นอยู่กับกันต้องมีการร้องขอแยกกัน
ไปป์ไลน์หลายแห่งต้องการทั้งสองอย่าง: Decisions API สำหรับการจัดประเภทและคัดกรอง, Responses API สำหรับการเขียนคำตอบ
การย้ายตัวจัดประเภทจาก Responses API ไป Decisions API
หากคุณจัดเส้นทางคำขอด้วย schema enum ที่เข้มงวดอยู่แล้ว การย้ายก็ทำได้ง่าย:
- ใช้อินพุตเดิม โดยตัดทอนให้เหลือแค่ตั๋วแบบดิบ; คำถามย้ายออกจากพรอมต์
- ใส่คำถามลงใน
questionsเป็นchoiceโดยใช้ค่า enum ของคุณเป็นchoices[].valueและคำอธิบายสั้น ๆ หนึ่งบรรทัดสำหรับแต่ละตัวเลือก ค่าสามารถเป็นสตริงหรือบูลีนได้ และtrueกับ"true"นั้นแตกต่างกัน - ลบตัวแยกวิเคราะห์ อ่าน
answers[0].choiceและanswers[0].confidence; คำตอบจะมาตามลำดับที่คุณถามและสะท้อนชื่อที่คุณตั้งไว้ จากนั้นกำหนดเกณฑ์จากตัวอย่างที่มีการติดป้ายกำกับ - ตรวจสอบเส้นทางอินพุต Decisions API รับเฉพาะข้อความจากผู้ใช้เท่านั้น: ไม่มีบทบาทระบบหรือผู้ช่วย, ไม่มีฟังก์ชันเรียก, ไม่มีไฟล์, ไม่มี
file_idรวมกฎพรอมต์ระบบเข้าไว้ในinstructionsหรือคำอธิบายตัวเลือก รูปภาพจะถูกส่งเป็น base64 data URLs; เอกสารอ้างอิงยังระบุ URL สาธารณะแบบ HTTP(S) ดังนั้นให้ทดสอบรูปภาพที่โฮสต์ไว้ก่อน - แยกการเชื่อมโยง "จัดประเภท, จากนั้นหากเป็นฝ่ายบัญชี ให้ตัดสินสิทธิ์ในการคืนเงิน" กลายเป็นสองคำขอ
ทดสอบทั้งสองในโปรเจกต์ Apidog เดียว
วิธีที่ชัดเจนที่สุดในการตัดสินใจคือการรันคำขอทั้งสองกับตั๋วที่มีการติดป้ายกำกับชุดเดียวกันแล้วเปรียบเทียบ ใน Apidog ให้จัดเก็บคีย์เพียงครั้งเดียวเป็น ตัวแปรสภาพแวดล้อม และอ้างอิง {{OPENAI_API_KEY}} ใน Authorization: Bearer header ของคำขอที่บันทึกไว้ทั้งสอง เพื่อไม่ให้มีคีย์จริงปรากฏในเนื้อหาที่บันทึกไว้
ให้คำขอทั้งสองมีการยืนยันแบบเดียวกัน: แผนกเท่ากับ billing ในคำขอ Decisions API นั่นคือการยืนยัน JSONPath บน $.answers[0].choice โดยมี $.answers[0].confidence มากกว่า 0.8 และ $.usage.output_tokens เท่ากับ 0 ควบคู่กันไป ในคำขอ Responses API ป้ายกำกับจะอยู่ในข้อความที่สร้างขึ้น ดังนั้นสคริปต์สั้น ๆ หลังการร้องขอจะแยกวิเคราะห์เป็นตัวแปรที่การยืนยันตรวจสอบ จากนั้นเปรียบเทียบ usage ในการตอบกลับทั้งสอง: Decisions API รายงานเอาต์พุตและโทเค็นการให้เหตุผลเป็นศูนย์ ส่วน Responses API ไม่ใช่
เปลี่ยนคู่คำขอนี้ให้เป็นสถานการณ์ทดสอบที่ขับเคลื่อนด้วยข้อมูล โดยใช้ไฟล์ CSV ของข้อความตั๋วและแผนกที่คาดหวัง และการรันจะแสดงว่าแต่ละเอนด์พอยต์จัดเส้นทางตั๋วได้อย่างถูกต้องจำนวนเท่าใดเหนือเกณฑ์ความเชื่อมั่นของคุณ จำลองอาร์เรย์ answers เพื่อให้สามารถสร้างตัวจัดเส้นทางได้ก่อน เช่นใน การตอบกลับจำลองแบบมีเงื่อนไข และรันสถานการณ์ใน CI ด้วย Apidog CLI เพื่อให้การเปลี่ยนแปลงคำพูดหรือชื่อโมเดลทำให้การทดสอบล้มเหลว แทนที่จะจัดเส้นทางตั๋วผิดพลาด ดู การทดสอบแอปพลิเคชัน LLM สำหรับรูปแบบการยืนยันเพิ่มเติม
คำถามที่พบบ่อย
Responses API สามารถคืนค่าความน่าจะเป็นเหมือน Decisions API ได้หรือไม่? ไม่ใช่ในฐานะค่าที่วัดได้จริง ฟิลด์ confidence ใน JSON schema จะให้ค่าตัวเลขที่โมเดลเขียนขึ้น ซึ่งเป็นข้อความที่สร้างขึ้น Decisions API คืนค่าความน่าจะเป็นสำหรับตัวเลือกที่คุณระบุจากเอนด์พอยต์เอง
ฉันสามารถใช้โมเดลอื่นที่ไม่ใช่ GPT-6 Luna กับ Decisions API ได้หรือไม่? ไม่ได้ คู่มือระบุว่า gpt-6-luna เป็นโมเดลเดียวที่มีอยู่ในปัจจุบัน ดู ภาพรวม GPT-6 Luna ของเรา
Decisions API แตกต่างจาก TypeSafe’s Jev อย่างไร? ทั้งสองคืนค่าคำตอบแบบมีประเภทพร้อมความน่าจะเป็นและเรียกเก็บเฉพาะอินพุต ทั้งสองแตกต่างกันในด้านราคา, อินพุต และรูปแบบการตอบกลับ ดู Decisions API เทียบกับ Jev
Decisions API ใช้งานได้ฟรีหรือไม่? ไม่ได้ มันเรียกเก็บเงิน $0.10 ต่อ 1 ล้านโทเค็นอินพุต โดยไม่มีระดับ Decisions API ฟรีที่มีเอกสารกำกับ สำหรับวิธีการใช้ Luna ได้ฟรี ดู วิธีใช้ GPT-6 Luna ฟรี
ขั้นตอนถัดไป
นำตัวจัดประเภทที่คุณใช้งานผ่าน Responses API ในปัจจุบัน มาสร้างใหม่เป็นคำถามแบบ choice และรันทั้งสองแบบกับตั๋วที่มีการติดป้ายกำกับ 50 ใบใน Apidog ด้วยการยืนยันแบบเดียวกัน หากเกณฑ์ความเชื่อมั่นยังคงอยู่และการใช้งานแสดงโทเค็นเอาต์พุตเป็นศูนย์ คุณก็จะได้คำตอบ ดาวน์โหลด Apidog จากนั้นทำตาม วิธีการใช้ Decisions API สำหรับการเรียกครั้งแรกและขั้นตอนการทดสอบแบบครบวงจร
