ให้ LLM ตอบเป็น JSON ตรง Schema กับให้ตอบเป็นข้อความแล้ว Parse เอง ต่างกันตรงไหน

มีทีมพัฒนาไม่น้อยที่เริ่มต้นใช้ LLM ด้วยวิธีง่ายที่สุด คือเขียน Prompt บอกให้โมเดลตอบเป็น JSON แล้วปิดท้ายด้วยประโยคทำนอง 'กรุณาตอบในรูปแบบ JSON เท่านั้น' จากนั้นก็เขียนโค้ดฝั่ง Backend ดัก String ที่ได้มา ตัดส่วนที่ไม่ใช่ JSON ทิ้ง แล้วยิงเข้า `JSON.parse()` วิธีนี้ใช้ได้ในช่วงทดสอบ แต่พอขึ้น Production จริงกลับพังบ่อยกว่าที่คิด เพราะโมเดลบางครั้งใส่คำอธิบายนำหน้า บางครั้งใส่ Markdown Code Block ครอบ JSON บางครั้งลืมปิดวงเล็บ

ปัญหานี้ไม่ใช่เรื่องของ Prompt ที่เขียนไม่ดีพอเสมอไป แต่เป็นข้อจำกัดโดยธรรมชาติของโมเดลภาษาที่ Generate ทีละ Token ต่อเนื่องกัน ไม่มีอะไรบังคับว่า Token ถัดไปต้องเป็นไปตามโครงสร้าง JSON จริง ๆ นอกจากความน่าจะเป็นที่โมเดลเรียนรู้มาจากข้อมูลฝึก ซึ่งเป็นเรื่องของสถิติ ไม่ใช่การรับประกัน

Structured Output คือคำตอบของปัญหานี้ในอีกชั้นหนึ่ง คือแทนที่จะหวังพึ่งความสม่ำเสมอของ Prompt เพียงอย่างเดียว ระบบจะเข้าไปควบคุมกระบวนการ Generate Token ให้เดินตามโครงสร้างที่กำหนดไว้จริง บทความนี้จะพาดูว่ากลไกนี้ทำงานอย่างไร ต่างจากการ Parse ข้อความอิสระตรงไหน และเมื่อไรที่ยังต้องระวังแม้จะใช้ Structured Output แล้วก็ตาม

Structured Output คืออะไรกันแน่ ไม่ใช่แค่ 'ขอ JSON'

Structured Output หมายถึงกลไกที่บังคับให้ Output ของ LLM ตรงตาม Schema ที่กำหนดไว้ล่วงหน้าในระดับกระบวนการ Generate ไม่ใช่แค่การขอด้วย Prompt ธรรมดา ผู้ให้บริการโมเดลรายใหญ่หลายเจ้ามีฟีเจอร์นี้ในชื่อต่างกัน เช่น JSON Mode, Function Calling ที่ผูกกับ Schema หรือ Structured Output Mode ซึ่งแต่ละแบบมีระดับการรับประกันไม่เท่ากัน

หัวใจของกลไกนี้คือ Constrained Decoding บางรูปแบบ ระบบจะดูโครงสร้าง Schema แล้วจำกัดว่า Token ถัดไปที่โมเดลเลือกได้ต้องอยู่ในชุดที่เป็นไปได้ตาม Schema เท่านั้น เช่น ถ้า Schema กำหนดว่า Field ชื่อ `status` ต้องเป็นหนึ่งใน `["pending", "approved", "rejected"]` ระบบจะไม่ปล่อยให้โมเดล Generate ค่าอื่นที่ไม่อยู่ในลิสต์นี้ได้เลย ต่างจากการขอผ่าน Prompt ที่โมเดลอาจตอบคำอื่นที่ใกล้เคียงแต่ไม่ตรงเป๊ะ

ข้อควรระวังคือไม่ใช่ผู้ให้บริการทุกรายมีระดับการบังคับที่แน่นเท่ากัน บาง Provider รับประกันว่า Output จะเป็น JSON ที่ Parse ได้เสมอ (Syntactic Validity) แต่ไม่รับประกันว่าเนื้อหาข้างในถูกต้องตามความหมายที่ต้องการ (Semantic Correctness) สองเรื่องนี้แยกกันชัดเจน และทีมพัฒนาต้องเข้าใจว่า Structured Output แก้ปัญหาเรื่องแรกเป็นหลัก

เปรียบเทียบ: Parse ข้อความด้วย Regex กับใช้ Structured Output

แนวทาง Regex/String Parsing เหมาะกับงานต้นแบบที่อยากทดสอบไอเดียเร็ว เพราะไม่ต้องพึ่งฟีเจอร์เฉพาะของ Provider แต่ละเจ้า เขียน Prompt แล้วลองแยกคำตอบด้วยโค้ดง่าย ๆ ได้ทันที แต่จุดอ่อนคือความเปราะบางสูง โมเดลเปลี่ยนสไตล์การตอบแม้เพียงเล็กน้อย เช่น ใส่เว้นวรรคเพิ่ม หรือเปลี่ยนโครงประโยคนำ ก็ทำให้ Regex ที่เขียนไว้ Parse พลาดได้ทันที

แนวทาง Structured Output ต้องลงทุนเวลาช่วงแรกมากกว่าเล็กน้อย เพราะต้องออกแบบ Schema ให้ชัดเจน กำหนด Type ของแต่ละ Field และบางครั้งต้องเขียน Validation เพิ่มเติมฝั่งแอปพลิเคชัน แต่ผลลัพธ์คือ Output ที่ Parse ได้สม่ำเสมอกว่ามาก ลดจำนวน Try-catch หรือ Fallback Logic ที่ต้องเขียนดักไว้เผื่อ Parse ล้มเหลว

อีกมุมที่มักถูกมองข้ามคือต้นทุนการ Debug ทีมที่ใช้ Regex Parsing ในระยะยาวมักเจอปัญหาแบบ 'ทำงานได้ 95% ของเวลา แต่ 5% ที่เหลือหาสาเหตุไม่เจอ' เพราะความล้มเหลวเกิดจาก Pattern ของข้อความที่เปลี่ยนไปแบบไม่คาดคิด ขณะที่ Structured Output ทำให้ความล้มเหลวส่วนใหญ่ย้ายไปอยู่ที่ชั้น Validation ซึ่ง Debug ง่ายกว่าเพราะมี Error Message ชัดเจนว่า Field ไหนผิด Type อะไร

งานแบบไหนที่ควรใช้ Structured Output จริง ๆ

ไม่ใช่ทุกงานที่ต้องใช้ Structured Output งานที่ Output เป็นข้อความอิสระสำหรับให้คนอ่านโดยตรง เช่น สรุปบทความ หรือแต่งเนื้อหาการตลาด ไม่จำเป็นต้องบังคับ Schema เพราะไม่มีโค้ดฝั่งไหนต้องมาแยกข้อมูลจากคำตอบนั้นต่อ

แต่งานที่ Output ต้องถูกส่งต่อให้ระบบอื่นใช้งานทันที เช่น บันทึกลงฐานข้อมูล เรียก API ต่อ หรือแสดงผลในฟอร์มที่มีโครงสร้างตายตัว งานเหล่านี้คือจุดที่ Structured Output ให้ผลต่างชัดเจนที่สุด เพราะทุก Field ที่ผิด Type หรือหายไปหมายถึงข้อผิดพลาดที่ไล่ตามไปอีกหลายชั้นของระบบ

• ดึงข้อมูลจากเอกสารอิสระ (Invoice, Resume, Contract) มาใส่ Field ที่กำหนดไว้ตายตัว
• จัดหมวดหมู่ข้อความ (Classification) ที่ต้องตอบเป็นค่าจากลิสต์ที่กำหนดเท่านั้น
• สร้างคำสั่งเรียกฟังก์ชันหรือ API ที่ต้อง Parameter ครบตาม Signature
• แปลงคำถามภาษาคนเป็น Query ที่มีโครงสร้าง เช่น Filter สำหรับระบบค้นหา
• ส่งต่อผลลัพธ์ให้ Agent ตัวถัดไปในระบบ Multi-agent ที่ต้องอ่าน Field ตรงกันทุก Step

ออกแบบ JSON Schema อย่างไรให้โมเดลตอบตรงและมีคุณภาพ

1. เริ่มจาก Field ที่จำเป็นจริง ๆ เท่านั้น ยิ่ง Schema มี Field มาก โอกาสที่โมเดลจะเติมค่าไม่แม่นยำในบาง Field ก็สูงขึ้นตาม โดยเฉพาะ Field ที่ต้องอนุมานจากบริบทอ้อม
2. ใส่คำอธิบาย (Description) กำกับแต่ละ Field ให้ชัดว่าหมายถึงอะไร เพราะ Schema เพียงกำหนด Type ได้ แต่ไม่ได้บอกความหมายทางธุรกิจ เช่น Field ชื่อ `amount` ควรระบุว่าเป็นหน่วยบาทหรือสตางค์ รวม VAT หรือไม่
3. จำกัดค่าที่เป็นไปได้ด้วย Enum เมื่อ Field นั้นมีชุดค่าจำกัด แทนที่จะปล่อยเป็น String อิสระ เพราะ Enum ช่วยลดโอกาสที่โมเดลจะสร้างค่าที่ระบบปลายทางไม่รู้จัก
4. แยก Field ที่บังคับต้องมี (Required) กับ Field ที่เป็น Optional ให้ชัดเจน แล้วออกแบบ Logic ฝั่งแอปให้รองรับกรณี Optional Field เป็นค่าว่างหรือ null โดยไม่ล้ม
5. ทดสอบ Schema กับ Input ที่หลากหลาย โดยเฉพาะ Input ขอบเขต (Edge Case) เช่น เอกสารที่ข้อมูลไม่ครบ หรือคำถามที่กำกวม เพื่อดูว่าโมเดลจัดการอย่างไรเมื่อข้อมูลจริงไม่สมบูรณ์

ทำไมต้องมีชั้น Validation แม้ใช้ Structured Output แล้ว

ข้อผิดพลาดที่พบบ่อยของทีมที่เพิ่งเริ่มใช้ Structured Output คือคิดว่าเมื่อโมเดลตอบตาม Schema แล้ว ข้อมูลนั้นถูกต้องเสมอ ซึ่งไม่จริง Structured Output รับประกันแค่ว่า Output เป็น JSON ที่ Parse ได้และ Type ตรงตามที่กำหนด แต่ไม่รับประกันว่าตัวเลขในนั้นสมเหตุสมผล หรือชื่อที่ดึงมาถูกต้องตามเอกสารต้นฉบับจริง

ตัวอย่างสมมติที่พบได้ในงานดึงข้อมูลจาก Invoice คือโมเดลอาจตอบ Field `total_amount` เป็นตัวเลขที่ Parse เป็น Number ได้ปกติ ผ่าน Schema Validation ทุกจุด แต่ตัวเลขนั้นดันเป็นยอดรวมก่อนหักส่วนลด ไม่ใช่ยอดสุทธิที่ระบบบัญชีต้องการจริง เพราะโมเดลตีความเอกสารผิดจุด ไม่ใช่ปัญหาเรื่อง Format

ด้วยเหตุนี้ ระบบ Production ที่ดีจึงควรมีชั้น Validation ทางธุรกิจแยกออกจากชั้น Schema Validation เช่น ตรวจว่าผลรวมของรายการย่อยเท่ากับยอดรวมหรือไม่ ตรวจว่าวันที่อยู่ในช่วงที่สมเหตุสมผล หรือเทียบค่าที่ดึงได้กับข้อมูลอ้างอิงอื่นก่อนนำไปใช้ตัดสินใจสำคัญ

ใช้ Structured Output แล้วยังพังได้จากอะไรบ้าง

แม้ Structured Output จะลดความล้มเหลวจากการ Parse ผิดรูปแบบไปได้มาก แต่ยังมีจุดที่ทีมพัฒนามักเจอปัญหาซ้ำ ๆ ต่อไปนี้เป็นตัวอย่างประกอบกรอบวิเคราะห์ (ตัวอย่างสมมติ ไม่ใช่สถิติจริง) เพื่อให้เห็นภาพว่าความผิดพลาดมักเกิดจากอะไร

• ทำแบบนี้แล้วพัง เพราะออกแบบ Schema ซ้อนลึกเกินไปหลายชั้น (Nested Object ซ้อน Array ซ้อน Object) จนโมเดลเริ่มสับสนว่า Field ไหนอยู่ระดับใด ผลคือบาง Field ถูกดันขึ้นมาผิดชั้น แม้ Type จะยัง Valid อยู่ก็ตาม
• ทำแบบนี้แล้วพัง เพราะตั้ง Field เป็น Required ทั้งหมดโดยไม่เผื่อกรณีข้อมูลต้นทางไม่ครบ พอเจอเอกสารที่ข้อมูลบางส่วนหายจริง โมเดลจึงต้อง 'เดา' ค่าเติมเข้าไปเพื่อให้ Schema ผ่าน ซึ่งกลายเป็นข้อมูลปลอมที่ดูเหมือนถูกต้องเพราะ Format ผ่าน Validation
• ทำแบบนี้แล้วพัง เพราะเปลี่ยนเวอร์ชันโมเดลโดยไม่ทดสอบ Schema เดิมซ้ำ โมเดลรุ่นใหม่บาง Provider ตีความ Field Description ต่างจากรุ่นเก่าเล็กน้อย ทำให้ผลลัพธ์เปลี่ยนไปแม้ Schema จะไม่ได้แก้อะไรเลย
• ทำแบบนี้แล้วพัง เพราะไม่มี Fallback เมื่อ API ของ Provider ตอบ Error หรือ Timeout ระบบที่ผูกกับ Structured Output แบบเดียวโดยไม่มีแผนสำรอง จะล่มทั้งฟีเจอร์ทันทีเมื่อ Provider มีปัญหาชั่วคราว

ต้นทุนและ Latency ที่ต้องแลกเมื่อใช้ Structured Output

Structured Output ไม่ได้มาฟรี บาง Provider ต้องใช้ขั้นตอน Constrained Decoding ที่กินเวลาประมวลผลเพิ่มขึ้นเล็กน้อยเมื่อเทียบกับการปล่อยให้โมเดล Generate อิสระ โดยเฉพาะ Schema ที่ซับซ้อนมาก การจำกัด Token ที่เป็นไปได้ในแต่ละขั้นอาจทำให้ Latency สูงขึ้นเมื่อเทียบกับ Prompt ธรรมดา

อีกด้านคือค่าใช้จ่ายรวมของระบบ แม้ Latency ต่อ Request อาจเพิ่มขึ้นเล็กน้อย แต่เมื่อคิดรวมทั้งระบบ Structured Output มักลดต้นทุนซ่อนเร้นที่มองไม่เห็นในตอนแรก เช่น จำนวน Retry ที่ลดลงเพราะ Parse ผิดน้อยลง เวลาที่ทีม Debug ปัญหา Production ลดลง และความเสียหายจากข้อมูลผิดที่หลุดเข้าไปในระบบธุรกิจก็ลดลงตาม

ทีมที่กำลังตัดสินใจว่าจะใช้ Structured Output กับทุก Endpoint หรือเฉพาะบางจุด ควรพิจารณาว่า Endpoint นั้น Output ถูกใช้งานต่อโดยระบบอัตโนมัติหรือไม่ ถ้าใช่ ต้นทุนที่เพิ่มขึ้นเล็กน้อยมักคุ้มค่ากว่าความเสี่ยงจาก Parse ผิดพลาดในระยะยาว หากสนใจเรื่องการจัดการต้นทุน AI โดยรวม ลองอ่านเพิ่มเติมที่ แนวทางลดค่าใช้ AI Application ซึ่งอธิบายมุมมองการตัดสินใจเรื่องงบประมาณไว้ละเอียดกว่านี้

Structured Output เชื่อมกับระบบ Tool Calling และ Multi-agent อย่างไร

ในระบบที่ใช้หลาย Agent ทำงานร่วมกัน Structured Output มีบทบาทสำคัญกว่าที่คิด เพราะ Output ของ Agent ตัวหนึ่งมักเป็น Input ของ Agent ตัวถัดไป ถ้าไม่มีโครงสร้างที่แน่นอน ความคลาดเคลื่อนจะสะสมทีละขั้นจนถึงปลายทางผลลัพธ์อาจผิดไปไกลจากที่ตั้งใจ

กลไกนี้ยังเป็นพื้นฐานของ Tool Calling ด้วย เพราะเมื่อโมเดลต้อง 'เลือกเรียกฟังก์ชัน' พร้อม Parameter ที่ถูกต้อง นั่นก็คือการบังคับ Output ให้ตรง Schema ของฟังก์ชันนั้นนั่นเอง หากต้องการเข้าใจกลไกนี้ลึกขึ้นว่ามันทำให้ LLM เรียก API หรือฟังก์ชันจริงได้อย่างไร ลองอ่านต่อที่ บทความเรื่อง Tool Calling ซึ่งขยายความในมุมของการเรียกใช้เครื่องมือภายนอกโดยเฉพาะ

ทีมที่ออกแบบระบบ Agent แบบ Multi-step ยังควรวางแผนเรื่อง Guardrails ควบคู่กันไป เพราะ Structured Output ควบคุมแค่รูปแบบ ไม่ได้ควบคุมว่า Agent จะตัดสินใจทำอะไรกับข้อมูลที่ได้ ดูรายละเอียดเพิ่มเติมได้ที่ แนวทางวาง Guardrails สำหรับระบบ AI

สรุป

Structured Output แก้ปัญหาความเปราะบางของการ Parse ข้อความอิสระด้วยการควบคุมรูปแบบ Output ตั้งแต่ระดับกระบวนการ Generate ทำให้ระบบที่ต้องต่อท่อ Output ไปให้โค้ดหรือฐานข้อมูลใช้งานต่อ มีความเสถียรกว่าการพึ่งพา Prompt และ Regex เพียงอย่างเดียวมาก

แต่ Structured Output ไม่ใช่ยาวิเศษที่แก้ทุกปัญหา มันควบคุมแค่รูปแบบ ไม่ได้ควบคุมความถูกต้องเชิงเนื้อหา ทีมที่นำไปใช้จริงจึงยังต้องมีชั้น Validation ทางธุรกิจ ออกแบบ Schema อย่างรอบคอบ และเตรียมแผนสำรองไว้เสมอเมื่อ Provider มีปัญหาหรือเปลี่ยนเวอร์ชันโมเดล

• Structured Output บังคับ Output ที่ระดับ Token ผ่าน Schema ต่างจาก Regex Parsing ที่พึ่งความสม่ำเสมอของ Prompt เพียงอย่างเดียว
• ใช้ให้คุ้มค่าที่สุดกับงานที่ Output ต้องถูกส่งต่อให้ระบบอื่นใช้งานทันที ไม่จำเป็นกับข้อความอิสระที่คนอ่านตรง ๆ
• ต้องมีชั้น Validation ทางธุรกิจแยกจาก Schema Validation เสมอ เพราะ Format ถูกไม่ได้แปลว่าเนื้อหาถูก

คำถามที่พบบ่อย