ผลการทดสอบมาตรฐาน (benchmark) ใหม่ของ API จากโมเดลภาษาขนาดใหญ่ (LLM) 12 ราย พบว่าเกือบทุกบริการส่งคืน JSON ที่ตรงตาม schema ที่ร้องขอ แต่มีส่วนน้อยจำนวนไม่น้อยที่ให้ค่าที่ผิดพลาดทางข้อเท็จจริงออกมา นอกจากนี้ ค่าใช้จ่ายในรูปแบบ token สำหรับ schema เดียวกันยังมีความผันผวนตั้งแต่ไม่กี่สิบ token ไปจนถึงเกือบห้าพัน token นักพัฒนาที่กำลังสร้าง pipeline การสกัดข้อมูลหรือเอเจนต์ที่ขับเคลื่อนด้วยข้อมูล (data-driven agents) ไม่สามารถใช้ "ความถูกต้องตาม schema" เป็นตัวแทนของ "ความถูกต้องของข้อมูล" ได้อีกต่อไป

ทำไมการทดสอบนี้จึงสำคัญ

ผู้ให้บริการ API ต่างพากันโปรโมต "structured output" ว่าเป็นวิธีในการกำจัดข้อผิดพลาดในการ parse ข้อมูล คำมั่นสัญญานั้นเรียบง่าย: เพียงแค่ส่ง JSON schema ให้กับโมเดล แล้วมันจะเติมข้อมูลลงในฟิลด์ต่างๆ ให้โดยที่คุณไม่ต้องเขียนโค้ด post-processing ที่เปราะบาง ในทางปฏิบัติ ระบบที่ใช้งานจริง (production systems) จำนวนมากอาศัยการรับประกันนี้เพื่อหลีกเลี่ยงการเกิดระบบล่มและเพื่อให้ pipeline การวิเคราะห์ข้อมูลในขั้นตอนถัดไปทำงานได้อย่างราบรื่น แต่เมื่อการรับประกันนั้นเป็นจริงเพียงครึ่งเดียว บั๊กจะแฝงตัวเข้ามาอย่างเงียบเชียบ และการคำนวณต้นทุนตามการใช้งาน token ก็จะคลาดเคลื่อนไปอย่างมหาศาล

ข่าวดี: ปัจจุบันส่วนใหญ่มีการบังคับใช้ schema อย่างเคร่งครัด

  • โมเดลส่วนใหญ่ในชุดทดสอบผลิต JSON ที่ผ่านการตรวจสอบด้วย validator ที่เข้มงวด
  • Constrained decoding – โมเดลที่ล็อกตัวถอดรหัส (decoder) ไว้กับ schema จะไม่สามารถปล่อยตัวอักษรที่นอกเหนือจากที่กำหนดออกมาได้ ดังนั้น payload ที่ผิดรูปแบบจึงแทบจะหมดไป
  • อัตราการเกิด Parse-error – นักพัฒนาไม่จำเป็นต้องครอบทุกการเรียกใช้งานด้วย try-catch block เพื่อดักจับข้อผิดพลาดทางไวยากรณ์ของ JSON อีกต่อไป

ข่าวร้าย: ความถูกต้องของรูปแบบ ≠ ความถูกต้องของข้อมูล

รูปแบบ (shape) ที่ถูกต้องไม่ได้การันตีว่าค่า (value) จะถูกต้อง โมเดล 4 จาก 12 โมเดล ได้แก่ DeepSeek V4, Qwen และ GLM-5.2 (สองโมเดลหลังปรากฏภายใต้ชื่อที่ต่างกันสองชื่อในรายงาน) ผลิต JSON ที่มีรูปแบบสมบูรณ์แบบ แต่กลับมีตัวเลขที่ผิดพลาดเมื่อเปิดโหมด "thinking" (หรือ chain-of-thought)

  • ในโมเดล Qwen การสกัดข้อมูลทางคณิตศาสตร์แบบง่ายๆ มีความแม่นยำจาก คำตอบที่ถูกต้อง 1 จาก 16 เมื่อเปิดการใช้เหตุผล (reasoning) เปลี่ยนเป็น ถูกต้อง 8 จาก 8 เมื่อปิดการใช้เหตุผล
  • DeepSeek V4 Pro แสดงความผันผวนในลักษณะเดียวกัน: ความแม่นยำในการสกัดข้อมูลเพิ่มขึ้นจาก 1/8 เป็น 7/8 เมื่อโมเดลหยุดพยายามอธิบายขั้นตอนของมัน

ขั้นตอนการใช้เหตุผลที่เพิ่มขึ้นเข้ามาแทรกแซงการทำงานของ constrained decoder ทำให้โมเดลหลุดเข้าไปในอาการหลอน (hallucination) ในขณะที่ยังคงรักษาโครงสร้างวงเล็บภายนอกไว้ได้

ด้านที่เลวร้าย: ความประหลาดของต้นทุน token และพารามิเตอร์ที่ถูกละเลย

  • รูปแบบการตอบกลับของ Claude – เมื่อเข้าถึงผ่าน endpoint ที่รองรับ OpenAI, Claude เพิกเฉยต่อ flag response_format โดยสิ้นเชิง และส่งคืนผลลัพธ์ที่ตรงตาม schema เพียง 0% แม้ว่าโมเดลจะรองรับการเรียกใช้งานแบบมีโครงสร้าง แต่ต้องทำผ่านอินเทอร์เฟซ tool-call ของ Anthropic โดยตรงเท่านั้น
  • การเพิ่มขึ้นของ token จาก schema – schema ขนาด 12 KB ที่ดูเหมือนไม่เยอะ กลับใช้เพียง 30 tokens บน DeepSeek แต่ payload เดียวกันกลับกินไปถึง 4,959 tokens บน Claude
  • ความไม่สอดคล้องในการเรียกเก็บเงิน – ผู้ให้บริการบางรายนับ schema เป็นส่วนหนึ่งของ prompt และคิดเงินตามทุก token ที่ใช้ไป ในขณะที่บางรายถือว่าเป็นส่วนเสริมที่ฟรี เมื่อใช้งานในสเกลใหญ่ ค่าใช้จ่ายจาก schema อาจสูงกว่าค่าใช้จ่ายของเนื้อหาที่โมเดลสร้างขึ้นเสียอีก

สิ่งที่นักพัฒนาควรทำในตอนนี้

  1. ตรวจสอบค่าข้อมูล ไม่ใช่แค่รูปแบบ – ตัวตรวจสอบ schema จะไม่ตรวจพบคำตอบที่เป็นตัวเลขที่ผิดพลาด แม้ว่ามันจะตรงตามประเภทข้อมูลที่คาดหวังก็ตาม ควรเพิ่มการตรวจสอบเฉพาะทางตามโดเมน (เช่น ช่วงของตัวเลข, หน่วย, หรือความสอดคล้องระหว่างฟิลด์)
  2. ปิด chain-of-thought สำหรับการสกัดข้อมูล ใน DeepSeek, Qwen และ GLM เมื่อคุณต้องการการเติมข้อมูลในฟิลด์ที่เชื่อถือได้ ขั้นตอนการใช้เหตุผลที่เพิ่มขึ้นนั้นเป็นทางเลือก ไม่ใช่สิ่งจำเป็นสำหรับความถูกต้อง
  3. ตรวจสอบการใช้งาน token – บันทึกจำนวน token ที่แต่ละคำขอใช้ รวมถึงส่วนที่เป็น schema และเปรียบเทียบใบแจ้งหนี้ระหว่างผู้ให้บริการก่อนที่จะตัดสินใจใช้งานในสเกลใหญ่
  4. ทดสอบความสามารถในการใช้งานข้ามแพลตฟอร์ม (portability) – schema ที่ใช้งานได้บน OpenAI อาจถูกละเลยอย่างเงียบๆ บน Gemini หรือ Claude ควรทำการตรวจสอบความถูกต้องเบื้องต้น (sanity check) บนแต่ละแพลตฟอร์มเป้าหมายก่อนที่จะส่งมอบโค้ด

มุมมองโต้แย้งจากผู้ให้บริการ

ผู้ให้บริการบางรายแย้งว่าโหมด "thinking" เป็นทางเลือกของนักพัฒนาที่เหมาะสำหรับงานที่การอธิบายมีความสำคัญมากกว่าความแม่นยำในการสกัดข้อมูลดิบ ส่วนกรณีที่ Claude เพิกเฉยต่อ flag response_format นั้น ผู้ให้บริการแนะนำให้ใช้ Anthropic native tool calls แทน คำอธิบายเหล่านั้นถูกต้องในทางเทคนิค แต่เป็นการผลักภาระให้นักพัฒนาต้องรู้ว่าควรเลือกโหมดใดและต้องเตรียมงบประมาณสำหรับค่าธรรมเนียม token ที่ซ่อนอยู่ไว้อย่างไร

บทสรุป

JSON schema ไม่ใช่ตาข่ายนิรภัยอีกต่อไป แต่มันเป็นเพียงแค่ "รูปแบบ" เท่านั้น จงตรวจสอบให้แน่ใจว่าข้อมูลภายในตรงกับความเป็นจริง คอยจับตาดูต้นทุน token ที่ซ่อนอยู่ และจำไว้ว่าการ "คิด" ของโมเดลสามารถทำให้ผลลัพธ์ที่ดูสะอาดตาที่สุดผิดเพี้ยนไปได้