Structured Output: ให้ AI ตอบเป็น JSON ที่ระบบใช้ต่อได้
เข้าใจความต่างของ JSON mode กับ Structured Outputs วิธีออกแบบ schema และสิ่งที่ต้องตรวจก่อนส่งข้อมูลจาก AI เข้าระบบจริง
คุณให้ AI อ่านแชตลูกค้าแล้วสรุปเป็นข้อมูลลง Google Sheet ร้อยครั้งแรกเรียบร้อยดี ครั้งที่ร้อยเอ็ด AI ขึ้นต้นคำตอบด้วย "แน่นอนค่ะ นี่คือข้อมูลที่ต้องการ" ก่อนตัว JSON สคริปต์ที่รออ่านข้อมูลพังทันที นี่คือเหตุผลที่งาน AI ที่ต่อกับระบบจริงต้องใช้ Structured Output
Structured Output คืออะไร
Structured Output คือการบังคับให้โมเดลตอบตามโครงสร้างที่กำหนดไว้ล่วงหน้า ส่วนใหญ่อยู่ในรูป JSON Schema ซึ่งระบุว่าต้องมี field อะไร แต่ละ field เป็นชนิดข้อมูลแบบไหน และ field ไหนห้ามขาด ผลลัพธ์จึงส่งต่อให้โค้ด ฐานข้อมูล หรือเครื่องมือ automation อ่านได้ทันทีโดยไม่ต้องตัดข้อความเอง
JSON mode กับ Structured Outputs ต่างกันยังไง
แค่ขอใน prompt
เขียนว่า "ตอบเป็น JSON เท่านั้น" ได้ผลในหลายครั้ง แต่ไม่มีอะไรรับประกัน
JSON mode
OpenAI อธิบายไว้ในประกาศเปิดตัว Structured Outputs (สิงหาคม 2024) ว่า JSON mode ทำให้ได้ JSON ที่ถูกไวยากรณ์ แต่ "ไม่รับประกันว่าจะตรงกับ schema ที่กำหนด" เช่น field อาจหายหรือชื่อผิด
Structured Outputs แบบ strict
ส่ง JSON Schema ไปพร้อมคำขอ แล้วระบบใช้ constrained decoding บังคับให้ทุก token ที่สร้างออกมาอยู่ในโครงสร้างนั้น ในประกาศเดียวกัน OpenAI รายงานว่าบนชุดทดสอบ schema ที่ซับซ้อน โมเดล gpt-4o-2024-08-06 ที่ใช้ Structured Outputs ได้คะแนน 100% เทียบกับต่ำกว่า 40% ของ gpt-4-0613 ฝั่ง Anthropic ก็มีฟีเจอร์ structured outputs ใน Claude API ทั้งแบบกำหนดรูปแบบคำตอบ และแบบ strict tool use สำหรับการเรียกเครื่องมือ ส่วน Gemini มี response schema ให้ใช้เช่นกัน
ออกแบบ Schema ให้ใช้งานได้จริง
- ทำ field ให้ required ให้มากที่สุด: เอกสาร Claude แนะนำแบบนี้เพื่อลดความซับซ้อนและคุมลำดับ field
- ใช้ enum กับค่าที่มีตัวเลือกจำกัด: เช่น หมวดคำถาม = สินค้า, จัดส่ง, คืนเงิน, อื่นๆ ระบบปลายทางจะไม่ต้องเดาคำพ้อง
- เขียน description ให้แต่ละ field: บอกความหมายและหน่วย เช่น ราคาเป็นบาท ไม่มีจุลภาค
- เผื่อทางออกเมื่อไม่มีข้อมูล: อนุญาตค่า null หรือเพิ่ม field อย่าง confidence แทนการบังคับให้ AI เดา
- อย่าซ้อนลึกเกินจำเป็น: schema ที่แบนกว่าตรวจง่ายกว่า และเอกสาร Claude ระบุว่ามีข้อจำกัดด้านความซับซ้อนของ schema
ตัวอย่าง: คัดแยกข้อความลูกค้าร้านออนไลน์
Prompt: "อ่านข้อความลูกค้าต่อไปนี้ แล้วสรุปตาม schema ที่กำหนด"
Schema ที่ใช้มี 4 field คือ category (enum: สินค้า, จัดส่ง, คืนเงิน, อื่นๆ), order_id (string หรือ null), urgency (enum: ต่ำ, กลาง, สูง) และ summary (string สั้นไม่เกินหนึ่งประโยค)
ข้อความ "สั่งเสื้อไปตั้งแต่วันจันทร์ เลขออเดอร์ A1023 ยังไม่ได้ของเลยค่ะ" จะได้ผลเป็น category = จัดส่ง, order_id = A1023, urgency = กลาง, summary = ลูกค้ายังไม่ได้รับสินค้าที่สั่งตั้งแต่วันจันทร์ จากนั้น automation ส่งเคสด่วนเข้าช่องทีมขนส่งได้ทันที
โครงสร้างที่ถูกต้องไม่ได้แปลว่าข้อมูลถูกต้อง Schema กันระบบพัง แต่ไม่ได้กัน AI เข้าใจผิด
ข้อควรระวัง
- OpenAI ระบุเองว่าค่าข้างในยังผิดได้แม้โครงสร้างถูก ควรมีการตรวจค่าในโค้ด เช่น รูปแบบเลขออเดอร์
- ถ้าคำตอบถูกตัดเพราะชนเพดาน max tokens หรือโมเดลปฏิเสธคำขอ ผลอาจไม่ตรง schema เอกสาร Claude แนะนำให้เช็ก stop_reason ทุกครั้ง
- ไม่ใช่ทุกฟีเจอร์ของ JSON Schema ที่รองรับ และการใช้ schema ใหม่ครั้งแรกอาจช้ากว่าปกติ
- ข้อมูลส่วนบุคคลที่ดึงออกมาต้องจัดเก็บตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล
เริ่มต้นยังไง
- เลือกงานที่ทุกวันนี้คุณคัดลอกข้อมูลจาก AI ไปวางเองด้วยมือ
- เขียน schema จากสิ่งที่ระบบปลายทางต้องการ ไม่ใช่จากสิ่งที่ AI ตอบได้
- เปิดโหมด structured output ของผู้ให้บริการที่ใช้ แทนการขอใน prompt อย่างเดียว
- ทดสอบกับข้อความจริงอย่างน้อย 30 ชิ้น รวมข้อความกำกวมและข้อความที่ไม่มีข้อมูล
Structured Output เป็นจุดเริ่มของการเอา AI ไปต่อเป็น workflow เต็มรูปแบบ อ่านภาพรวมต่อได้ใน AI Workflow Automation และถ้าคุณอยากพัฒนาทักษะสายนี้อย่างเป็นระบบ ดูคอร์สที่เกี่ยวข้องได้ใน Plants.work Learn