Responses API กับ Chat Completions ต่างกันอย่างไร: คู่มือย้ายระบบ (2026)

OpenAI แนะนำให้โปรเจกต์ใหม่ใช้ Responses API พร้อมยืนยันว่า Chat Completions ยังคงรองรับต่อไป สอง endpoint จะอยู่ร่วมกันระยะยาว แต่โครงสร้างฟิลด์ การจัดการ state และระบบ tool ต่างกัน บทความนี้แยกความต่างเป็น 4 มิติ แสดงโค้ดที่ต้องแก้ตอนย้ายระบบ และจบด้วยตารางช่วยตัดสินใจ — ตัวอย่างทุกตัวรันได้จริงบน endpoint ของ EXAIV

นิยาม: Responses API คือ unified interface ที่ OpenAI เปิดตัวหลัง Chat Completions: รับ input เป็นอาร์เรย์ input, ส่ง output เป็นรายการ output ที่มี type ชัดเจน, เก็บ state ของบทสนทนาฝั่ง server โดยดีฟอลต์ (store) และมี hosted tools อย่าง web search, file search, code interpreter ในตัว ส่วน Chat Completions เป็นโปรโตคอลแบบ stateless: ทุก request ต้องแนบ messages ย้อนหลังครบ และ client เป็นผู้จัดการ context เอง

ตารางเดียวเห็นความต่างทั้งหมด

เปรียบเทียบโค้ด: งานเดียวกันสองแบบ

Chat Completions (EXAIV endpoint /api/ai/v1/chat/completions):

curl https://exaiv.com/api/ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "model": "gpt-6-sol",
    "messages": [
      { "role": "user", "content": "อธิบายว่า AI gateway คืออะไรในหนึ่งประโยค" }
    ]
  }'

Responses API (EXAIV endpoint /api/ai/v1/responses):

curl https://exaiv.com/api/ai/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "model": "gpt-6-sol",
    "input": "อธิบายว่า AI gateway คืออะไรในหนึ่งประโยค"
  }'

ระดับ SDK: client.chat.completions.create(...) เปลี่ยนเป็น client.responses.create(...) และอ่านผลลัพธ์จาก completion.choices[0].message.content เปลี่ยนเป็น response.output_text — รายละเอียดพารามิเตอร์ดูได้ที่เอกสาร Chat Completions และเอกสาร Responses

ย้ายระบบ 4 ขั้น

1. messages → input: ข้อความล้วนส่งเป็น string ได้เลย กรณีมีประวัติให้เปลี่ยนชื่ออาร์เรย์ messages เป็น input โครงสร้าง role/content คงเดิม
2. เปลี่ยนจุดอ่านผลลัพธ์: choices[0].message.content → วน output กรอง type === "message" หรือใช้ field สำเร็จรูป output_text
3. ย้าย system prompt ไป instructions: ข้อความ role: "system" ใน Chat มีพารามิเตอร์ระดับบนสุดแยกต่างหากใน Responses
4. เขียน tool definition ใหม่: สองรุ่นคล้ายกันแต่ไม่เท่ากัน ตรวจทีละฟิลด์; hosted tools ของ Responses (web_search ฯลฯ) เปิดด้วยชื่อ ไม่ต้องเขียน orchestration เอง

เลือกอย่างไร: ตามสถานการณ์

EXAIV ให้บริการทั้งสอง endpoint ใช้ API key เดียวกัน จึงไม่ต้องเลือกข้างถาวร: ของเดิมคงใช้ Chat Completions ของใหม่ใช้ Responses และสลับโมเดลเบื้องหลังได้จากหน้าโมเดล

ทำไมจึงมีสอง interface

ที่มาเชิงวิวัฒนาการช่วยให้ตัดสินใจได้ Chat Completions เป็น interface ยุคแรกของ OpenAI ที่เพราะโครงสร้างเรียบง่ายและใช้ข้ามผู้ให้บริการได้ จึงกลายเป็นมาตรฐาน de facto ที่วงการเลียนแบบ — แทบทุกผู้ให้บริการโมเดลวันนี้มี endpoint สไตล์ messages Responses API คือการออกแบบใหม่ของ OpenAI สำหรับยุค agent: การที่ "โมเดลอาจต้องทำหลายอย่าง" (เรียก tool, ค้นข้อมูล, รันโค้ด) กลายเป็นพลเมืองชั้นหนึ่งในชั้น interface โดยย้ายการจัดการ state และการรัน tool กลับไปฝั่ง server สอง interface นี้เป้าหมายต่างกัน — นั่นคือเหตุผลที่พวกมันอยู่ร่วมกันได้

ตารางแมปพารามิเตอร์ฉบับลงมือ

ความเทียบเคียงที่ใช้บ่อยที่สุดตอนย้ายระบบ:

ฟิลด์ที่แม่นยำดูที่เอกสารอ้างอิง ย้ายระบบแบบตรวจทีละฟิลด์

เจาะลึกการจัดการ state: store กับ previous_response_id

นี่คือความต่างเชิงปรัชญาที่ลึกที่สุด Chat Completions ตั้งสมมติว่า "server ไม่จำอะไรเลย": ทุกรอบคุณต้องส่งประวัติเต็มซ้ำ การจัดการ context window และควบคุมต้นทุนอยู่ที่ฝั่งคุณ Responses API เก็บบทสนทนาฝั่ง server ตั้งแต่ต้น (store: true) รอบถัดไปอ้าง previous_response_id แค่เดียว server จะพาบทสนทนาและบริบท tool ครบถ้วนมาคิดต่อ

ผลต่อผู้พัฒนาจริง ๆ:

• โค้ดน้อยลง: โมดูลที่คุยกันว่าต้องรักษา messages array, ตัดประวัติ, บีบ context ลบทิ้งได้
• token น้อยลง: server ใช้บริบทเดิมซ้ำได้ ค่าส่งซ้ำหายไป
• ระวังเรื่องข้อมูล: บทสนทนาถูกเก็บฝั่ง server ทีมที่มีข้อกำหนด data residency ใช้ store: false ได้ แลกกับการกลับไปโหมดส่งเต็มทุกรอบ

กับดักย้ายระบบ 5 อันดับ

1. ผลลัพธ์ว่าง: ยังอ่าน choices[0].message.content แต่เนื้อหาอยู่ใน output
2. tool call เงียบ: รูปแบบ tools สองรุ่นไม่เหมือน ก๊อปฟิลด์ตรง ๆ จะพังเงียบ ๆ ต้องตรวจทีละฟิลด์
3. ตัวแยก SSE พัง: ชนิด event ต่างกันสิ้นเชิง ตรรกะ delta ไปใช้กับ response.output_text.delta ไม่ได้
4. พังเพราะหลายคำตอบ: พารามิเตอร์ n ถูกถอด ตรรกะที่พึ่งพาต้องเขียนใหม่หรืออยู่กับ Chat
5. state รั่ว: store เปิดเป็นค่าเริ่มต้น ข้อมูลทดสอบจะถูกเก็บ — งานที่แคร์ข้อมูลปิดมันชัดเจน

FAQ

ย้าย streaming ทีละ event

ชื่อ event คือจุดที่กินเวลาย้ายระบบมากที่สุด แผนที่คร่าว ๆ:

สองความต่างเชิงโครงสร้างที่ต้องซึมซับ: delta ฝั่ง Chat เป็นเศษข้อความนิรนามที่คุณต่อเอง ขณะที่ event ของ Responses ระบุชื่อสิ่งที่มันแบกมา; และใน Responses หนึ่ง turn ที่มีหลาย tool เป็นวงจร request เดียว ไม่ใช่หลายรอบ request/response — ตัวแยก SSE, ตรรกะ retry และการจัดการ timeout ทั้งหมดต้องเขียนใหม่กับชื่อ event ใหม่ ส่วนนี้แหละที่ต้นทุนจริงมักมากกว่าประมาณการ

ใช้ Responses ผ่าน gateway

สามเรื่องที่ควรรู้เมื่อ endpoint ถูก proxy:

• hosted tools รันฝั่งต้นทาง: web search, code interpreter และเพื่อนรันฝั่ง OpenAI; gateway ส่งต่อ request และ stream ผลกลับมาโดยไม่แตะต้อง
• state ฝั่ง server ยังอยู่ต้นทาง: previous_response_id อ้าง state ที่เก็บฝั่ง OpenAI; gateway ถ่ายทอดแบบโปร่งใส
• key และการเรียกเก็บเงินเป็นของ gateway: key EXAIV เดียวใช้ได้ทั้งสอง endpoint คิดเงินตามโมเดลและ token ไม่ขึ้นกับ endpoint — ราคาสดที่หน้าราคา

เช็กลิสต์ก่อนย้าย

ห้าคำถามตามลำดับ — เจอคำตอบว่า "ยัง" ที่ข้อไหน ให้แก้ชั้นนั้นก่อน:

1. ยิงข้อความล้วนบน endpoint ใหม่ผ่านไหม (ไม่มี tool ไม่มี streaming)?
2. จุดอ่านผลลัพธ์คืนข้อความจริงไหม (ไม่ใช่ undefined)?
3. tool definition parse ผ่านโดยไม่มี schema error ไหม?
4. รอบ tool เต็มหนึ่งรอบจบไหม (เรียก → รัน → ต่อ)?
5. streaming เรนเดอร์ครบต้นจนจบด้วยชื่อ event ใหม่ไหม?

FAQ

อ่านต่อ

• Chat Completions API reference
• Responses API reference
• Anthropic Messages API reference