ทำไมแอป AI จึงต้องใช้ผลลัพธ์ที่มีโครงสร้าง?

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

ลองนึกถึงสตาร์ตอัปโลจิสติกส์สมมติชื่อพาร์เซลไวส์ที่มีพนักงาน 12 คน ซานา นักพัฒนาของบริษัท กำลังสร้างเครื่องมือที่อ่านอีเมลลูกค้าแล้วกรอกแบบฟอร์มเปลี่ยนแปลงการจัดส่ง ได้แก่ เลขอ้างอิงคำสั่งซื้อ วันที่ที่ลูกค้าต้องการ ที่อยู่ใหม่ และลูกค้าขอเงินคืนหรือไม่ อีเมลทั่วไปมีข้อความว่า 'สวัสดีค่ะ คำสั่งซื้อ PW-88213 วันพฤหัสบดีไม่อยู่บ้าน มาส่งวันเสาร์แทนได้ไหมคะ หรือฝากบ้านเลขที่ 14 ก็ได้ ถ้าไม่ได้ก็ยกเลิกแล้วคืนเงินให้ด้วยค่ะ' เวอร์ชันแรกของเธอสั่งโมเดลให้ 'ตอบในรูปแบบ JSON' คำตอบส่วนใหญ่แปลงเป็นข้อมูลได้ แต่บางคำตอบขึ้นต้นด้วย 'ได้เลย นี่คือ JSON' บางคำตอบตั้งชื่อฟิลด์ว่า 'date' แทน 'requested_date' และมีคำตอบหนึ่งส่งค่าวันที่กลับมาเป็น 'วันเสาร์'

สคีมา JSON คืออะไร และช่วยได้อย่างไร?

โครงสร้างข้อมูล JSON คือคำอธิบายอย่างเป็นทางการของข้อมูลที่คุณคาดหวัง ได้แก่ มีฟิลด์ใดบ้าง ฟิลด์ใดจำเป็น แต่ละฟิลด์เป็นข้อมูลชนิดใด และอนุญาตให้มีค่าใดได้บ้าง การให้โครงสร้างข้อมูลแก่โมเดลเปลี่ยนคำขอว่า 'กรุณาตอบเป็น JSON' ให้กลายเป็นข้อกำหนดที่โค้ดของคุณตรวจสอบได้

สำหรับซานา ข้อกำหนดโครงสร้างข้อมูลระบุว่า: order_reference เป็นข้อความที่ต้องมี; requested_date เป็นข้อความในรูปแบบวันที่ที่ต้องมี หรือเป็น null หากไม่ได้ระบุวันที่; new_address เป็นข้อความหรือ null; refund_requested เป็นค่าบูลีนที่ต้องมี; และไม่อนุญาตให้มีฟิลด์อื่น กฎข้อสุดท้ายนี้ป้องกันไม่ให้โมเดลเพิ่มฟิลด์สำหรับความคิดเห็น

API ของโมเดลรองรับผลลัพธ์แบบมีโครงสร้างอย่างไร?

API ของโมเดลหลัก ๆ ให้คุณส่งโครงสร้างข้อมูล JSON ไปพร้อมกับคำขอได้ และจะจำกัดผลลัพธ์ของโมเดลให้ตรงตามโครงสร้างนั้น.

OpenAI

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

Anthropic

API ของ Claude มีตัวเลือกให้สร้างผลลัพธ์ JSON ที่ตรงตามสคีมาที่คุณกำหนด พร้อมตัวเลือกแบบเข้มงวดในการกำหนดเครื่องมือ เพื่อให้ตรวจสอบข้อมูลนำเข้าของเครื่องมือกับสคีมาของเครื่องมือนั้นได้ เอกสารระบุว่ารองรับคุณลักษณะใดของสคีมาบ้าง และคุณลักษณะใดจะทำให้ระบบแจ้งข้อผิดพลาด

Google

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

ทำไมคุณจึงยังต้องตรวจสอบความถูกต้องและลองใหม่?

คุณยังต้องตรวจสอบความถูกต้อง เพราะสคีมาควบคุมรูปแบบของข้อมูล ไม่ใช่ความถูกต้องของค่า คำตอบที่มีรูปแบบถูกต้องสมบูรณ์อาจยังมีวันที่ผิด หมายเลขอ้างอิงคำสั่งซื้อที่แต่งขึ้น หรือสถานะให้คืนเงินทั้งที่ลูกค้าไม่เคยร้องขอ

ตรวจสอบความถูกต้องสองชั้น ขั้นแรก ตรวจสอบโครงสร้างด้วยไลบรารีสคีมา เช่น Pydantic ใน Python หรือ Zod ใน JavaScript ซึ่งเอกสารของ OpenAI, Anthropic และ Google ล้วนมีตัวอย่างให้ดู ขั้นที่สอง ตรวจสอบกฎทางธุรกิจ ได้แก่ เลขอ้างอิงคำสั่งซื้อตรงตามรูปแบบและมีอยู่ในระบบหรือไม่ วันที่เป็นวันในอนาคตและเป็นวันจัดส่งหรือไม่ และที่อยู่อยู่ในพื้นที่จัดส่งหรือไม่ นอกจากนี้ ให้รองรับกรณีที่ผู้ให้บริการระบุไว้ในเอกสารด้วย ได้แก่ การปฏิเสธตอบซึ่งอาจไม่เป็นไปตามสคีมาของคุณ และคำตอบที่ถูกตัดเมื่อถึงขีดจำกัดโทเคนสูงสุด ทำให้ JSON ไม่สมบูรณ์

ลองใหม่อย่างระมัดระวัง หากตรวจสอบไม่ผ่าน ให้ลองใหม่หนึ่งครั้งโดยระบุข้อผิดพลาดให้ชัดเจน เช่น 'requested_date ต้องเป็นวันที่; อีเมลระบุว่าวันเสาร์ และวันที่สั่งซื้อคือ 14 ตุลาคม' จำกัดการลองใหม่ไว้ที่หนึ่งหรือสองครั้ง จากนั้นส่งต่ออีเมลให้คนจัดการ

ผลลัพธ์แบบมีโครงสร้างที่ยังไม่ดีและที่เชื่อถือได้มีลักษณะอย่างไร?

ตัวอย่างที่ไม่รัดกุม: พรอมป์ต์ระบุว่า 'ดึงรายละเอียดและตอบกลับเป็น JSON' แอปอ่านทุกอย่างที่ได้รับกลับมา สำหรับอีเมลข้างต้น แอปได้รับฟิลด์ชื่อ order และ date โดยมีค่าวันที่เป็น 'วันเสาร์' และค่าการคืนเงินเป็น true เพราะโมเดลตีความว่า 'ถ้าไม่ได้ก็ยกเลิกไปเลย' เป็นคำขอที่ชัดเจน แบบฟอร์มจึงกรอกข้อมูลผิด และลูกค้าได้รับเงินคืนทั้งที่ไม่ได้ต้องการ

เวอร์ชันที่รัดกุม: คำขอมีโครงสร้างข้อมูลของซานาพร้อมเปิดโหมดเข้มงวด และพรอมป์ต์อธิบายแต่ละฟิลด์ รวมถึง 'refund_requested เป็น true เฉพาะเมื่อลูกค้าขอคืนเงินโดยไม่มีเงื่อนไขเท่านั้น' โมเดลส่งกลับ order_reference เป็น PW-88213, requested_date เป็นวันที่ของวันเสาร์ถัดไป, new_address เป็น null, refund_requested เป็น false และ conditional_request ซึ่งเป็นฟิลด์ที่ซานาเพิ่มไว้ในโครงสร้างข้อมูลเพื่อรองรับกรณีนี้โดยเฉพาะ มีค่าเป็น 'คืนเงินหากไม่สามารถจัดส่งวันเสาร์หรือฝากเพื่อนบ้านได้' การตรวจสอบยืนยันว่ามีคำสั่งซื้อนี้อยู่จริงและวันเสาร์เป็นวันที่จัดส่งได้ เนื่องจากอีเมลมีคำขอแบบมีเงื่อนไข กฎจึงส่งต่อให้คนเป็นผู้ตัดสินใจขั้นสุดท้าย

ข้อผิดพลาดที่พบบ่อยเกี่ยวกับผลลัพธ์แบบมีโครงสร้างมีอะไรบ้าง?

ข้อผิดพลาดที่พบบ่อยที่สุดคือการเชื่อว่าข้อมูลถูกต้องเพียงเพราะ JSON มีรูปแบบถูกต้อง ข้ออื่น ๆ ได้แก่ การพึ่งคำสั่งเพียงอย่างเดียวทั้งที่ API บังคับใช้โครงสร้างข้อมูลได้ การใช้ชื่อฟิลด์คลุมเครือโดยไม่มีคำอธิบาย การบังคับให้ใส่ค่าเมื่อคำตอบที่ตรงความจริงคือ null การไม่จัดการกรณีปฏิเสธตอบหรือคำตอบถูกตัด และการลองใหม่โดยไม่บอกโมเดลว่าผิดตรงไหน

ผลลัพธ์แบบมีโครงสร้างอยู่ในส่วนใดของรายการหลักสูตร Tosheo.ai?

ผลลัพธ์แบบมีโครงสร้างเป็นบทเรียนเขียนโค้ดในหลักสูตรสร้างแอป AI ในหมวดการสร้างแอป AI ส่วนบทเรียนลงมือทำเต็มรูปแบบพร้อมโค้ด ซึ่งคุณจะกำหนดโครงสร้างข้อมูล เรียก API ตรวจสอบคำตอบ และเพิ่มการลองใหม่ อยู่ในเส้นทางการเรียนเขียนโค้ดหลังสมัคร โดยมีข้อเสนอแนะตามเกณฑ์การให้คะแนนในแต่ละขั้นตอน

แหล่งข้อมูลและขอบเขต

เอกสาร API ของ OpenAI คู่มือการสร้างผลลัพธ์ตามโครงสร้าง การเปรียบเทียบโหมด JSON และการปฏิเสธคำขอ (ตรวจสอบเมื่อ 19 October 2026) ↗

เอกสารประกอบ Anthropic Claude ผลลัพธ์แบบมีโครงสร้างและการใช้เครื่องมือแบบเคร่งครัด (ตรวจสอบเมื่อ 19 October 2026) ↗

เอกสาร API ของ Google Gemini คำแนะนำเกี่ยวกับผลลัพธ์แบบมีโครงสร้างและการตรวจสอบความถูกต้อง (ตรวจสอบเมื่อ 19 October 2026) ↗