OpenAI Decisions API เทียบกับ Responses API

APIs การตัดสินใจ เทียบกับ APIs การตอบกลับ: ตั๋วใบเดียวที่ถูกส่งไปมาทั้งสองทาง, สิ่งที่แต่ละอันส่งกลับมา, การเรียกเก็บเงินตามอินพุตเท่านั้น เทียบกับการเรียกเก็บเงินตามเอาต์พุตพร้อมการคำนวณ, และเมทริกซ์คุณสมบัติ

INEZA Felin-Michel

INEZA Felin-Michel

10 October 2026

OpenAI Decisions API เทียบกับ Responses API

Apidog สำหรับองค์กร

การติดตั้งแบบ On-Premises

SSO & RBAC

รองรับมาตรฐาน SOC 2

สำรวจ Apidog Enterprise

ใช้ 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 ของเรา

button

ตารางคุณสมบัติ

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 คำขอ:

ดังนั้นส่วนต่างที่เห็นได้ชัดสำหรับป้ายกำกับเพียงอย่างเดียวคือ $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 เมื่อเอาต์พุตเป็นหนึ่งในสิ่งเหล่านี้:

เลือก Responses API เมื่อมีสิ่งใดสิ่งหนึ่งเหล่านี้เป็นจริง:

ไปป์ไลน์หลายแห่งต้องการทั้งสองอย่าง: Decisions API สำหรับการจัดประเภทและคัดกรอง, Responses API สำหรับการเขียนคำตอบ

การย้ายตัวจัดประเภทจาก Responses API ไป Decisions API

หากคุณจัดเส้นทางคำขอด้วย schema enum ที่เข้มงวดอยู่แล้ว การย้ายก็ทำได้ง่าย:

  1. ใช้อินพุตเดิม โดยตัดทอนให้เหลือแค่ตั๋วแบบดิบ; คำถามย้ายออกจากพรอมต์
  2. ใส่คำถามลงใน questions เป็น choice โดยใช้ค่า enum ของคุณเป็น choices[].value และคำอธิบายสั้น ๆ หนึ่งบรรทัดสำหรับแต่ละตัวเลือก ค่าสามารถเป็นสตริงหรือบูลีนได้ และ true กับ "true" นั้นแตกต่างกัน
  3. ลบตัวแยกวิเคราะห์ อ่าน answers[0].choice และ answers[0].confidence; คำตอบจะมาตามลำดับที่คุณถามและสะท้อนชื่อที่คุณตั้งไว้ จากนั้นกำหนดเกณฑ์จากตัวอย่างที่มีการติดป้ายกำกับ
  4. ตรวจสอบเส้นทางอินพุต Decisions API รับเฉพาะข้อความจากผู้ใช้เท่านั้น: ไม่มีบทบาทระบบหรือผู้ช่วย, ไม่มีฟังก์ชันเรียก, ไม่มีไฟล์, ไม่มี file_id รวมกฎพรอมต์ระบบเข้าไว้ใน instructions หรือคำอธิบายตัวเลือก รูปภาพจะถูกส่งเป็น base64 data URLs; เอกสารอ้างอิงยังระบุ URL สาธารณะแบบ HTTP(S) ดังนั้นให้ทดสอบรูปภาพที่โฮสต์ไว้ก่อน
  5. แยกการเชื่อมโยง "จัดประเภท, จากนั้นหากเป็นฝ่ายบัญชี ให้ตัดสินสิทธิ์ในการคืนเงิน" กลายเป็นสองคำขอ

ทดสอบทั้งสองในโปรเจกต์ 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 สำหรับการเรียกครั้งแรกและขั้นตอนการทดสอบแบบครบวงจร

ฝึกการออกแบบ API แบบ Design-first ใน Apidog

ค้นพบวิธีที่ง่ายขึ้นในการสร้างและใช้ API