หน้ากากแห่งเสียงส่วนใหญ่: ทำไมการตรวจสอบ Agent จึงต้องใช้ Fault Injection

AI agent ของคุณอาจกำลังโกหกคุณเกี่ยวกับความแม่นยำของตัวมันเอง

เมื่อไม่นานมานี้ ผมได้เห็นคู่หู AI ล้มเหลวติดต่อกันถึงสามครั้ง มันพลาดปัญหาเรื่องความจริงแบบเดิมซ้ำๆ ในรูปแบบที่ต่างกัน มันเขียนด้วยน้ำเสียงที่ผิดพลาด โมเดลผู้ตรวจสอบ (reviewer model) ให้คะแนนมันสูงขึ้นทุกครั้งที่อ่านเจอข้อผิดพลาดเดิม แม้กระทั่งการนับข้อเท็จจริงเกี่ยวกับ fact drift ก็ยังผิดพลาด

ผมตรวจพบข้อผิดพลาดเหล่านี้ได้เพียงเพราะผมอยู่นอกวงจร (outside the loop)

สิ่งนี้เผยให้เห็นปัญหาขนาดใหญ่ใน agent stack ระบบการตรวจสอบส่วนใหญ่สันนิษฐานถึงความเป็นอิสระต่อกัน พวกเขาใช้การลงคะแนนแบบ multi-agent, รูปแบบ maker/checker หรือ ensemble prompts โดยสันนิษฐานว่าเส้นทางที่ต่างกันจะมองเห็นสิ่งที่ต่างกัน

แต่บ่อยครั้งที่เส้นทางเหล่านี้ใช้แหล่งข้อมูลเดียวกัน

เมื่อผู้ตรวจสอบอ่านจากแหล่งข้อมูลเดียวกับผู้เขียน คุณไม่ได้มีสองมุมมอง แต่คุณมีมุมมองเดียวที่สวมหมวกสองใบที่ต่างกัน นี่คือจุดล้มเหลวเพียงจุดเดียว (single point of failure) ที่สวมหน้ากากแห่งเสียงส่วนใหญ่ (quorum costume) ไว้

หากเส้นทางต่างๆ ใช้แหล่งข้อมูลต้นทาง (upstream) ร่วมกัน พวกมันก็จะเห็นพ้องกับข้อเท็จจริงที่ผิดหรืออาการหลอน (hallucination) แบบเดียวกัน ระบบจะดูเหมือนทำงานได้ดีเพราะผลลัพธ์ดูมีความหลากหลาย แต่ระบบจะล้มเหลวทุกครั้งที่แหล่งข้อมูลโกหก

เพื่อแก้ไขปัญหานี้ คุณต้องใช้ fault injection

อย่าเพียงแค่ตรวจวัดว่า agent เห็นต่างกันหรือไม่ แต่จงตรวจวัดว่าคุณสามารถบังคับให้พวกมันเห็นต่างกันได้หรือไม่ โดยการทำให้ส่วนใดส่วนหนึ่งของระบบเสียหาย

นี่คือวิธีทดสอบ stack ของคุณ:

  • ฉีดหน่วยความจำที่ผิดพลาด (Inject a bad memory): ใส่ข้อเท็จจริงปลอมลงในเส้นทางการดึงข้อมูล (retrieval path) หนึ่ง หากทั้งสองเส้นทางส่งคืนข้อเท็จจริงปลอมนั้น แสดงว่าเส้นทางของคุณมีความเชื่อมโยงกัน (coupled)
  • เปลี่ยนแปลงกฎ (Mutate a rule): เปลี่ยนกฎแบบ offline หากทั้ง maker และ checker ต่างปฏิบัติตามกฎใหม่โดยไม่มีการแจ้งเตือนความไม่สอดคล้อง แสดงว่าพวกมันกำลังใช้ cache ร่วมกัน
  • ใส่ข้อมูล telemetry ที่ผิดพลาด (Plant wrong telemetry): บันทึก model ID ปลอม หากการตรวจสอบผ่าน แสดงว่าตัวตรวจสอบ (verifier) กำลังอ่านบันทึกเดียวกับตัวเขียน (writer)

ระบบแบบกระจายตัว (Distributed systems) แก้ปัญหานี้มาหลายปีแล้ว พวกเขาใช้ chaos engineering และ partition tests พวกเขาไม่ได้เชื่อใจระบบด้วยการเฝ้าดูว่ามันทำงานได้ดี แต่พวกเขาเชื่อใจมันด้วยการจงใจทำให้เกิดความล้มเหลว

สถาปัตยกรรมของ agent ต้องนำวินัยนี้มาใช้

ความเป็นอิสระไม่ใช่คุณสมบัติที่คุณสร้างขึ้นเพียงครั้งเดียว แต่เป็นคุณสมบัติ