ได้คำตอบจาก AI แล้ว จะให้ระบบเอาไปทำงานต่อได้เลยไหม

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

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

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

ให้ AI ส่งข้อเสนอก่อน

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

เมื่อกำหนดหน้าที่ไว้แคบ ข้อมูลที่รับกลับมาก็กำหนดให้แคบตามได้ เช่น มีเพียง category, summary และ decision ส่วนรหัสคำขอที่ต้นทางรับมาแล้วควรผูกจากบริบทที่ระบบเชื่อถือได้ ไม่ต้องให้โมเดลสร้างหรือยืนยันใหม่จากข้อความในเอกสาร

ตัวอย่าง schema ด้านล่างเป็นรูปแบบสำหรับข้อเสนอสมมติ โดยใช้ JSON Schema Draft 2020-12 และไม่ได้หมายความว่า AI ตอบแบบนี้แล้วจะได้รับสิทธิ์สร้างใบงานทันที

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "category": {
      "type": "string",
      "enum": ["software", "device", "unknown"]
    },
    "summary": {
      "type": "string",
      "minLength": 1,
      "maxLength": 600
    },
    "decision": {
      "type": "string",
      "enum": ["draft", "needs_review"]
    }
  },
  "required": ["category", "summary", "decision"],
  "additionalProperties": false
}

properties บอกว่าถ้ามี field นั้นแล้วต้องมีรูปแบบใด ส่วน required ระบุ field ที่ต้องมี จึงต้องกำหนดทั้งสองส่วนให้ตรงความต้องการ ขณะที่ enum ช่วยจำกัดค่าที่ระบบรองรับ และ additionalProperties ที่เป็น false ใช้ปฏิเสธ field อื่นใน object ตัวอย่างนี้

แยกการอ่าน JSON ออกจากการตรวจ schema

คำตอบอาจหน้าตาเหมือน JSON แต่มีข้อความอธิบายแทรก มีวงเล็บไม่ครบ หรือไม่ได้อยู่ในรูปที่ parser รับได้ ขั้นแรกจึงต้องอ่านข้อมูลให้ได้ตามรูปแบบก่อน แล้วจึงนำค่าที่อ่านได้ไปตรวจ schema ที่กำหนดไว้

แม้ parse ผ่าน ก็ยังอาจได้ค่าผิดชนิด เช่น summary เป็น array หรือ decision เป็นค่าที่ระบบไม่รองรับ หากข้ามการตรวจแล้วใช้โค้ดแปลงให้ผ่านแบบเงียบๆ เราอาจเปลี่ยนความหมายของคำตอบโดยไม่รู้ตัว จึงควรกำหนดให้ชัดว่ารับรูปแบบใด และกรณีใดถือว่าผลใช้ต่อไม่ได้

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

สำหรับผลที่ไม่ครบ ถูกปฏิเสธ หรือการเรียกโมเดลไม่สำเร็จ ควรมีสถานะรองรับแยกไว้ แทนการแทนค่าที่หายเป็นข้อมูลเริ่มต้นแล้วส่งต่อทั้งหมด ค่าเริ่มต้นบางอย่างอาจดูสะดวก แต่ถ้าทำให้ unknown กลายเป็นหมวดที่มีผู้รับผิดชอบจริง ก็มีโอกาสส่งงานผิดทีมโดยไม่มีใครเห็นว่าระบบเดามา

ผ่านรูปแบบแล้ว ยังต้องตรวจความหมาย

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

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

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

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

จุดลงมือทำต้องยึดสิทธิ์เดิมของงาน

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

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

ในงานที่อนุญาตให้ทำอัตโนมัติอยู่แล้ว ก็สามารถเดินต่อภายในขอบเขตนั้นได้หลังตรวจครบ โดยไม่ต้องให้คนกดยืนยันทุกการอ่านหรือทุกร่าง แต่ถ้าผลมีความเสี่ยงสูงหรือข้อมูลไม่พอ ควรมีจุดพักพร้อมรายละเอียดที่คนตัดสินใจต่อได้ ไม่ให้โมเดลเติมความแน่นอนแทนข้อมูลที่ขาด

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

ตรวจกรณีผิดให้เห็นทางออก

ชุดข้อมูลทดสอบควรมีทั้ง JSON ที่อ่านไม่ได้ field ขาด ชนิดผิด ค่า enum ที่ไม่รองรับ และข้อมูลที่ผ่าน schema แต่ขัดกับต้นฉบับ จากนั้นดูว่าแต่ละกรณีหยุดอยู่ตรงขั้นไหน มีการสร้างรายการจริงหรือไม่ และคนดูแลเข้าใจเหตุผลที่หยุดได้แค่ไหน

ควรเพิ่มกรณีที่ข้อความต้นฉบับขอให้เปลี่ยนสิทธิ์หรือเปลี่ยนปลายทางด้วย เพราะแม้ field นั้นถูก schema ปฏิเสธ ระบบส่วนอื่นก็อาจยังเผลออ่านจากข้อความดิบอยู่ การตรวจจึงต้องตามเส้นทางข้อมูลจนถึงขั้นลงมือทำ ไม่จบแค่ว่า validator คืนค่าผ่านหรือไม่ผ่าน

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