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

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

คำถามสำคัญจึงไม่ใช่แค่ “model เก่งขึ้นหรือยัง?” แต่คือ เมื่อ model อยู่ในระบบจริง ระบบนั้นน่าเชื่อถือขึ้นหรือยัง?

Model quality ≠ system reliability

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

Model quality ไม่เท่ากับ system quality

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

System quality ต้องมองเส้นทางทั้งหมดตั้งแต่ input จนถึงผลลัพธ์:

  1. ข้อมูลที่เข้ามาครบและสดพอหรือไม่
  2. retrieval หยิบ context ที่เกี่ยวข้องและผู้ใช้มีสิทธิ์เห็นหรือไม่
  3. tool ทำงานสำเร็จหรือคืนข้อมูลที่ผิดรูปแบบหรือไม่
  4. orchestration ส่งขั้นตอนต่อไปเมื่อเงื่อนไขผ่านจริงหรือไม่
  5. ระบบรู้หรือไม่ว่าคำตอบนี้มีหลักฐานไม่พอ
  6. มี trace และสัญญาณให้คนแกะรอยเมื่อเกิดปัญหาหรือไม่

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

ความน่าเชื่อถือเกิดจากหลายชั้น

ใน workflow หนึ่ง เราอาจแยกชั้นได้ประมาณนี้:

request
  -> validate input
  -> retrieve context
  -> call tool / model
  -> validate output
  -> attach evidence
  -> answer or escalate

แต่ละลูกศรมีโอกาสผิดของตัวเอง ตัวอย่างเช่น retrieval อาจได้เอกสารที่เกี่ยวข้องแต่หมดอายุ หรือ tool อาจคืนข้อมูลสำเร็จด้วย HTTP 200 แต่เป็นผลลัพธ์ว่างเพราะ filter ผิด

การออกแบบที่ดีจึงไม่ให้ model เป็นผู้ตัดสินทุกอย่างเพียงลำพัง ขั้นตอนที่ตรวจได้แน่นอนควรใช้ deterministic code เช่น ตรวจ schema, ตรวจ permission, ตรวจว่ามี source อย่างน้อยหนึ่งรายการ และหยุดเมื่อข้อมูลสำคัญหายไป ส่วน model ควรรับงานที่เหมาะกับความน่าจะเป็น เช่น การสรุป การจัดหมวดหมู่ หรือการเสนอทางเลือก

ตัวอย่างของคำว่า “ผ่าน” ที่ไม่พอ

สมมติระบบมีฟังก์ชันแบบนี้:

const response = await model.generate({ context, question });

return response.text;

โค้ดทำงานและคืน text ได้ แต่ยังตอบไม่ได้ว่า:

  • context มาจากเอกสารฉบับใด
  • context สดถึงวันที่เท่าไร
  • model อ้างข้อมูลเกิน context หรือไม่
  • คำตอบมี uncertainty ที่ควรบอกผู้ใช้หรือไม่
  • ถ้าเรียก tool ไม่สำเร็จ ระบบจะหยุดหรือเดาต่อ

ระบบที่น่าเชื่อถือกว่าจะคืนผลลัพธ์ที่มีหลักฐานและสถานะด้วย:

return {
  answer: validatedAnswer,
  evidence: sources,
  status: sources.length > 0 ? 'grounded' : 'needs-review',
};

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

Human judgment ยังเป็นส่วนของระบบ

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

สำหรับระบบหนึ่ง เราอาจดูทั้ง accuracy, groundedness, retrieval recall, latency, cost, tool failure rate และอัตราที่ต้องส่งต่อให้คน แต่ตัวเลขเหล่านี้ต้องช่วยตัดสินใจ ไม่ใช่กลายเป็น dashboard ที่ไม่มีใครเปิดดู

สรุป

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

สิ่งที่ควรจำมีสามข้อ:

  1. model quality เป็นเพียงส่วนหนึ่งของ system quality
  2. ขั้นตอน deterministic ควรรับงานที่ตรวจได้ ส่วน model ควรอยู่ใน boundary ที่ชัด
  3. คำตอบที่ดีต้องมีวิธีตรวจสอบและวิธีหยุดเมื่อหลักฐานไม่พอ

References