เจ้าหน้าที่สนับสนุนตอบคำถามผู้ใช้เรื่องการรีเซ็ตการยืนยันตัวตนแบบสองขั้นตอน (two-factor authentication) ด้วยขั้นตอนที่ไม่มีอยู่จริง คำตอบดูมีความมั่นใจ HTTP request ส่งกลับมาเป็น 200 OK ค่า latency อยู่ในระดับปกติ และกราฟการตรวจสอบทุกตัวยังคงเป็นสีเขียว
เอเจนต์สนับสนุนที่ขับเคลื่อนด้วย AI เกิดอาการ "หลอน" (hallucinated) เนื่องจากระบบตรวจสอบภายในที่ควรจะตรวจพบข้อผิดพลาดนั้นไม่ได้ทำงานเลย แดชบอร์ดที่วิศวกรใช้รายงานว่าทุกอย่างทำงานได้อย่างสมบูรณ์แบบ ในขณะที่เอเจนต์แอบสร้างคำตอบปลอมขึ้นมาเงียบๆ
ทำไมแดชบอร์ดแบบดั้งเดิมถึงตรวจไม่พบอาการ AI hallucination
สแต็กการตรวจสอบ (observability stacks) ส่วนใหญ่ปฏิบัติกับ AI agent เหมือนกับ microservice อื่นๆ นั่นคือมองแค่การส่งคำขอขาเข้า (inbound request) หนึ่งครั้ง และการตอบกลับขาออก (outbound response) หนึ่งครั้ง พวกเขาบันทึก HTTP status, เวลาในการตอบสนอง (response time) และจำนวนข้อผิดพลาด แต่พวกเขา ไม่ได้ บันทึกขั้นตอนที่ซ่อนอยู่ภายในคำขอนั้น เช่น การดึงข้อมูลจากเอกสารภายนอก (retrieval), การเรียกใช้งาน large language models, การใช้เครื่องมือเสริม (auxiliary tools) และตรรกะ guard-rail ใดๆ ที่ใช้ตรวจสอบความถูกต้องของผลลัพธ์
เมื่อขั้นตอนการดึงข้อมูล (retrieval step) ส่งผลลัพธ์ว่างเปล่า โมเดลมักจะ "เติมช่องว่าง" ด้วยข้อความที่ฟังดูสมเหตุสมผล ในมุมมองของระบบตรวจสอบ การเรียกใช้งานนั้นถือว่าสำเร็จ เพราะไม่มีอะไรพังและสถานะ (status code) ยังคงเป็น 200 อาการ hallucination จึงไม่ถูกตรวจพบ และอาการเพียงอย่างเดียวที่เห็นคือผู้ใช้ได้รับคำตอบที่ผิดพลาด
เปลี่ยนกล่องดำให้กลายเป็นโครงสร้างต้นไม้ที่อ่านง่าย
ขั้นตอนแรกของการดีบั๊ก (debugging) ที่เชื่อถือได้คือ เลิกปฏิบัติกับเอเจนต์เหมือนเป็นการเรียกใช้งานแบบก้อนเดียว (monolithic call) และเริ่มทำให้การทำงานภายในแต่ละขั้นตอนมองเห็นได้ในรูปแบบของแถวในตาราง trace การทำงานปกติจะแบ่งออกเป็น:
- การเรียกใช้งานเอเจนต์ในระดับบนสุด (top-level agent invocation)
- ขั้นตอนการดึงข้อมูล (retrieval step) ที่ดึงเอกสารที่เกี่ยวข้องมา
- ทุกการประมวลผลของโมเดลภาษา (language-model inference) ที่จัดการกับข้อมูลที่ดึงมา
- การเรียกใช้เครื่องมือแต่ละอย่าง (เช่น การค้นหาในฐานข้อมูล, การเรียก API)
- การตรวจสอบด้วย guard-rail เพื่อบังคับใช้ความถูกต้องของข้อเท็จจริงหรือการปฏิบัติตามนโยบาย
แต่ละแถวจะบันทึกเวลา (timestamp), สถานะความสำเร็จ (success flag) และข้อมูล (payload) ที่ส่งผ่านขั้นตอนนั้นๆ ด้วยโครงสร้างนี้ การทำงานจะกลายเป็นโครงสร้างต้นไม้ที่สามารถตรวจสอบได้ทีละบรรทัด แทนที่จะต้องมานั่งเดาจากผลลัพธ์สุดท้าย
บั๊กที่หลุดรอดไปได้
ในการโต้ตอบของฝ่ายสนับสนุนที่ผิดพลาดนั้น trace มีลักษณะดังนี้:
- Retrieval ทำงานแล้วแต่ไม่พบเอกสารใดๆ
- ขั้นตอนถัดไปยังคง ดำเนินต่อไป โดยส่ง context ที่ว่างเปล่าไปยังโมเดล
- โมเดลสร้างคำตอบที่เติมข้อมูลที่ขาดหายไปด้วยขั้นตอนที่กุขึ้นมาเอง
- ระบบส่งกลับมาเป็น 200 เพราะ pipeline ไม่พบข้อผิดพลาด (exception)
อาการ hallucination ไม่ใช่ข้อบกพร่องของตัวโมเดลภาษาเอง แต่มันคือการขาด guard-rail ระหว่างขั้นตอนการดึงข้อมูล (retrieval) และขั้นตอนการสร้างคำตอบ (generation) เอเจนต์ตอบคำถามทั้งที่ไม่มีข้อมูลพื้นฐาน (grounding) มาสนับสนุนคำตอบเลย
Guard-rail ง่ายๆ ที่ช่วยหยุดอาการ hallucination
การเปลี่ยนแปลงที่เป็นรูปธรรมสองอย่างสามารถกำจัดปัญหานี้ได้:
- หยุดทำงานเมื่อการดึงข้อมูลว่างเปล่า (Abort on empty retrieval) – หากคลังเอกสารไม่ส่งข้อมูลใดๆ กลับมา เอเจนต์ต้องตอบว่า “ฉันไม่พบข้อมูลที่คุณต้องการ” แทนที่จะดำเนินการสร้างคำตอบต่อไป
- การตรวจสอบความสอดคล้อง (Grounding check) – หลังจากโมเดลสร้างคำตอบแล้ว ให้ตรวจสอบว่าทุกข้อเท็จจริงที่กล่าวอ้างปรากฏอยู่ในเนื้อหาที่ดึงมาหรือไม่ หากการตรวจสอบล้มเหลว ให้ปฏิเสธคำตอบนั้นและเปลี่ยนไปใช้การตอบกลับแบบ “ไม่สามารถตอบได้” แทน
เวิร์กโฟลว์ที่ใช้งานได้จริงเพื่อการดีบั๊กที่รวดเร็วขึ้น
- ติดตาม (Trace) ทุกการเรียกใช้งานภายใน – ติดตั้งเครื่องมือวัดผล (instrument) ให้กับเอเจนต์ เพื่อให้ทุกการดึงข้อมูล, การประมวลผลโมเดล และการใช้เครื่องมือ เขียนข้อมูลลงใน log ที่จัดเก็บถาวร
- เก็บรักษาการทำงานที่ล้มเหลวไว้ – จัดเก็บ trace ฉบับเต็มของการโต้ตอบใดๆ ที่ผู้ใช้รายงานว่าผิดพลาด การลบข้อมูลเหล่านี้เพื่อประหยัดพื้นที่จัดเก็บจะทำให้คุณสูญเสียข้อมูลที่จำเป็นในการหาจุดที่เกิดการถดถอย (regressions)
- ติดแท็กการทำงานด้วยข้อมูลเวอร์ชัน – ระบุรหัสเวอร์ชัน (release identifier) และสถานะของ feature-flag ในแต่ละแถวของ trace วิธีนี้จะช่วยให้คุณเชื่อมโยงบั๊กใหม่เข้ากับการเปลี่ยนแปลงโค้ดที่เพิ่งเกิดขึ้นได้
- วัดคุณภาพ ไม่ใช่แค่ความเร็ว – เพิ่มตัวชี้วัด (metrics) ที่วัดว่าคำตอบปฏิบัติตามคำสั่งได้ดีเพียงใดและมีความสอดคล้องกับเนื้อหาที่ดึงมาหรือไม่ การมี throughput สูงจะไม่มีความหมายเลยหากคำตอบนั้นผิด
- ตรวจสอบความล้มเหลวทุกวัน – การตรวจสอบความล้มเหลวที่จัดเก็บไว้เป็นประจำสั้นๆ มักจะช่วยให้เห็นรูปแบบบางอย่าง (เช่น คำถามประเภทหนึ่งมักจะดึงข้อมูลไม่พบเสมอ) ก่อนที่มันจะส่งผลกระทบต่อผู้ใช้จำนวนมาก
การเปลี่ยนจากสถานะ “สีเขียว” (ผ่าน) เป็น “ได้รับการตรวจสอบแล้ว” (verified) จะช่วยให้ทีมสามารถตรวจพบอาการ hallucination ได้ตั้งแต่เนิ่นๆ และรักษาประสบการณ์การใช้งานที่น่าเชื่อถือไว้ได้
ราคาที่ต้องจ่ายจากการละเลยความล้มเหลวภายใน
เมื่อแดชบอร์ดรายงานเพียงความสำเร็จในระดับ HTTP องค์กรจะนำเอเจนต์ที่ดูเหมือนจะเชื่อถือได้ไปใช้งาน แต่กลับให้คำแนะนำที่ผิดพลาดอยู่เป็นประจำ
สิ่งที่ควรติดตามต่อไป
จนกว่าสิ่งเหล่านั้นจะกลายเป็นเรื่องปกติ แนวทางที่ปลอดภัยที่สุดคือการปฏิบัติกับการทำงานภายในทุกขั้นตอนให้สามารถตรวจสอบได้ และให้ระบบหยุดทำงานทันทีเมื่อขาดหลักฐานที่จำเป็น
ประเด็นสำคัญ: แดชบอร์ดที่เป็นสีเขียวบอกให้คุณรู้ว่าระบบการทำงานเบื้องหลังทำงานได้ แต่มันไม่ได้การันตีว่าคำตอบนั้นถูกต้อง การติดตามทุกขั้นตอน ทั้งการดึงข้อมูล การเรียกใช้โมเดล และการตรวจสอบเกราะป้องกัน จะช่วยเปลี่ยนอาการหลอนที่ซ่อนอยู่ ให้กลายเป็นความล้มเหลวที่มองเห็นได้ ซึ่งสามารถแก้ไขได้ก่อนที่จะส่งไปถึงผู้ใช้