เมื่อความซื่อไม่พอ: นิยามปัญหา AI hallucination ใน JSON
AI hallucination JSON คือปรากฏการณ์ที่โมเดลภาษาให้คำตอบในรูปแบบข้อมูลแบบมีโครงสร้างที่ดูถูกต้องตาม schema แต่เนื้อหาถูกสร้างขึ้นโดยไม่มีหลักฐานรองรับจากอินพุต ทำให้ค่าที่อยู่ในช่องต่าง ๆ ของ JSON เป็นการโกหราอย่างเป็นระบบแม้โมเดลจะสามารถยอมรับว่า “ไม่รู้” ได้ในรูปแบบร่างคำตอบทั่วไป และปัญหานี้เกิดเฉพาะเมื่อโมเดลถูกบังคับให้เติมฟอร์มที่ออกแบบไว้ ไม่ใช่เมื่อมันพูดคุยด้วยข้อความอิสระ หัวใจของงานวิจัยใหม่คือคำถามว่า เมื่อคำตอบที่ซื่อคือ “ไม่มีหลักฐาน” แต่ schema ไม่มีช่องสำหรับคำนี้ โมเดลจะเลือกทำอะไร ผลคือโมเดลส่วนใหญ่ “สร้างคำตอบขึ้นมาอย่างสม่ำเสมอ” หรือ language model fabrication ในระดับที่น่ากังวล เพราะมันทำให้ structured data reliability ของระบบที่ใช้ JSON, function calling และ extraction schemas ในงานจริงลดลงอย่างมีนัยสำคัญ
ตัวเลขที่บอกว่า JSON ทำให้โมเดลโกหรามากขึ้นแค่ไหน
การทดลองออกแบบอินพุตให้ “ไม่มีทางมีคำตอบจริงได้” เช่นโพสต์โซเชียลที่มีตัวเลขการมีส่วนร่วมแต่ไม่มีข้อความตอบกลับเลย จากนั้นถามว่า “คนพูดถึงอะไร” หาก JSON มีค่าเชิงรูปธรรมใด ๆ จึงถือว่าเป็นการสร้างข้อมูลขึ้นเองแบบเต็ม ๆ งานนี้ถามโมเดลสามโหมด: ข้อความอิสระ JSON ที่มีช่อง escape และ JSON ที่บังคับให้กรอกทุกช่องโดยไม่มีทางตอบว่าไม่รู้ ตัวเลขชัดเจนมาก: GPT-5.5 เมื่อตอบเป็นข้อความรายงานว่าขาดหลักฐานถูกต้องถึง 98% ของกรณี แต่เมื่อใช้ required-field schema เดียวกัน โมเดลโกหรา 40 จาก 40 ครั้งเต็ม ๆ นี่คือคำพูดที่น่าสะกิดใจว่า “ถ้ามีค่าเชิงรูปธรรมอยู่ในช่อง มันคือข้อมูลที่ถูกแต่งขึ้นแบบไม่ต้องสงสัย” ยิ่งกว่านั้น ในการทดลอง 200 ครั้งกับโมเดลเปิด 5 ตัว ช่อง escape “insufficient_evidence” ถูกใช้ 12 ครั้งในฟิลด์ระดับความขัดแย้ง แต่เป็นศูนย์ในทุกฟิลด์ที่ต้องแต่งเนื้อหา: sentiment, main_themes และ representative_reaction
โครงสร้างบังคับ = อคติทางรูปแบบ: ทำไมโมเดลยอมโกหรามากกว่ายอมเว้นว่าง
ผู้พัฒนาหลายคนเชื่อว่าการเพิ่มค่า escape เช่น "insufficient_evidence" ลงใน enum จะหยุด AI hallucination JSON ได้ แต่งานทดลองพบว่ามันช่วยเฉพาะโมเดลระดับแนวหน้าอย่าง GPT-5.5 ซึ่งใช้ทางออกนี้ทุกครั้ง ขณะที่โมเดลเปิด 9 ตัวที่ทดสอบยังคงสร้างคำตอบปลอมในสัดส่วน 60–100% แม้ escape จะอยู่ใน schema เด่นชัด เมื่อทดลองด้วย grammar-constrained decoding ที่บังคับให้โมเดลสร้างเฉพาะโทเคนที่ schema อนุญาต ค่า escape จึงอยู่ห่างเพียงหนึ่งโทเคนใน enum แต่โมเดลเลือกใช้มันเฉพาะในฟิลด์ที่ “ไม่ต้องเสียคำตอบ” เช่น controversy_level ไม่ใช่ฟิลด์เนื้อหาหลัก นี่เผยสิ่งสำคัญ: schema compliance ถูกฝึกให้เป็นข้อบังคับแข็ง ในขณะที่การเว้นว่างหรือยอมรับว่าไม่รู้เป็นเพียงความชอบแบบอ่อน เมื่อโครงสร้างบังคับให้มีค่า sentiment ที่เป็น enum ปิด หรือ array ที่ต้องมีขั้นต่ำ 3 รายการ และ boolean ที่ห้ามเป็น null โมเดลมีแรงผลักดันทางรูปแบบให้ “เติมฟอร์มให้ครบ” มากกว่ารักษาความซื่อ ทำให้ language model fabrication กลายเป็นพฤติกรรมปกติในโหมดแบบมีโครงสร้าง
ผลสะเทือนต่อระบบจริง: อย่าเชื่อ JSON จากโมเดลโดยไม่ตรวจสอบ
โลกการใช้งานจริงแทบไม่ใช้ร่างข้อความ ระบบใช้งานจริงใช้ JSON mode, function calling, extraction schemas และ structured outputs เป็นหลัก แต่การประเมินความปลอดภัยและความซื่อของโมเดลส่วนใหญ่กลับทำในโหมดข้อความ เพราะ “วัดง่ายกว่า” จากนั้นจึงนำโมเดลไปใช้ในโหมดที่มีพฤติกรรมต่างออกไปโดยแทบไม่มีการวัด นั่นหมายความว่า ตัวเลขการยอมรับว่าไม่รู้ที่เผยแพร่ทั้งหมดเป็นเพียง “เพดานบน” ไม่ใช่ภาพของระบบที่ถูกนำไปใช้จริง เมื่อระบบเริ่มเชื่อ JSON จากโมเดลแล้วต่อด้วยการกระทำผ่าน API แบบมีโครงสร้าง คำถามที่สำคัญที่สุดกลายเป็นว่า “โมเดลพูดว่าไม่รู้ได้ภายในรูปแบบที่เราบังคับมันหรือไม่” ซึ่งไม่ใช่เรื่องเล็กอีกต่อไป ในอีกด้าน งานศึกษาหนึ่งแสดงให้เห็นว่าโมเดลอย่าง GPT-4 สามารถทำนายแนวโน้มคำตอบของคนต่อแบบสอบถามบุคลิกภาพจากภาษาได้โดยยังไม่เก็บคำตอบมนุษย์เลย โดยค่าความสัมพันธ์กับค่าเฉลี่ยจริงของคำถามจาก DSM-5 อยู่ที่ 0.71 และแบบจากตำราโหราศาสตร์สูงถึง 0.85 ความสามารถนี้บอกว่าโมเดลตีความรูปแบบในภาษาและจิตใจคนได้ดี แต่ไม่ได้บอกว่ามันจะซื่อเมื่อต้องกรอกฟอร์ม JSON ในระบบผลิต
บทสรุปและข้อเสนอสำหรับนักพัฒนา: schema คือการตั้งค่าความปลอดภัย
เมื่อความซื่อของโมเดลขึ้นกับว่ามันตอบแบบร่างข้อความหรือกำลังกรอกฟอร์ม JSON หมายความว่า AI output validation ต้องย้ายจากการดูตัวอย่างคำตอบ สู่การวิเคราะห์ schema ที่เราออกแบบให้โมเดลกรอก ผู้เขียนงานวิจัยเสนออย่างตรงไปตรงมาว่า "ให้ใส่ค่า escape ในทุก enum ที่บังคับ" นี่เป็นบรรทัดเดียวที่ช่วยโมเดลระดับแนวหน้า แต่ไม่เพียงพอ เพราะ structured data reliability ไม่ได้ขึ้นกับแนวคิด “ห้ามเดา” ใน prompt เท่านั้น งานทดลองพบว่า anti-hallucination prompt ที่ลดการโกหราในข้อความจาก 39% เหลือ 4% กลับไม่มีผลใด ๆ เมื่อใช้ schema แบบบังคับฟิลด์ในโมเดลส่วนใหญ่ ข้อเสนอที่ตรงสุดคือ: ให้ถือว่า schema design คือการตั้งค่าความปลอดภัย และอย่าปล่อยให้คนเขียนสัญญา API เป็นคนเดียวที่แต่งมันโดยไม่มีคนที่คิดเรื่อง hallucination มาร่วมตรวจ ผู้เขียนได้ปล่อยเครื่องมือ linter ชื่อ phantomfill-lint สำหรับตรวจ schema ว่ามีช่องทาง escape ในฟิลด์ที่เสี่ยงหรือไม่ สามารถรันใน CI และรองรับนิยามเครื่องมือของค่ายโมเดลรายใหญ่ผ่านคำสั่ง pip install phantomfill-lint และ phantomfill-lint 'schemas/**/*.json' สารสำคัญสำหรับนักพัฒนาคือ "วัดโมเดลในรูปแบบที่คุณนำไปใช้" ไม่ใช่บนกระดาษทด โดยเฉพาะเมื่อระบบของคุณตัดสินใจจาก JSON ที่โมเดลมีแรงบังคับให้กรอกให้ครบทุกช่อง
