ข้อผิดพลาดสะสมของ AI agent: ทำไมความแม่นยำ 95% ต่อขั้นตอนถึงยังไม่พอ
ข้อผิดพลาดสะสมของ AI agent (compounding error) คือปรากฏการณ์ที่ความน่าจะเป็นที่งานยาวจะสำเร็จเท่ากับผลคูณของความน่าจะเป็นของแต่ละขั้นตอน ถ้าความแม่นยำต่อขั้นตอนอยู่ที่ 95% ลำดับ 10 ขั้นตอนจะสำเร็จราว 60% และ 20 ขั้นตอนเหลือเพียง 36% harness แก้ปัญหานี้ด้วยการตรวจสอบทุกขั้นตอนและบันทึกสถานะที่ผ่านการตรวจแล้ว เพื่อไม่ให้ข้อผิดพลาดลามไปขั้นต่อไป
ข้อผิดพลาดสะสมคืออะไร
Agent ไม่ได้แก้งานด้วยการกระทำเพียงครั้งเดียว แต่ทำเป็นลำดับ เช่น อ่านไฟล์ แก้ฟังก์ชัน รันเทสต์ แล้วแก้ import ถ้าแต่ละขั้นตอนถูกต้องด้วยความน่าจะเป็น p และขั้นตอนต่าง ๆ เป็นอิสระต่อกัน แต่ข้อผิดพลาดของขั้นตอนเดียวทำให้ขั้นตอนหลังทั้งหมดพัง ความน่าจะเป็นที่งาน n ขั้นตอนจะสำเร็จก็คือ p ยกกำลัง n นี่คือ ข้อผิดพลาดสะสมของ AI agent หรือที่เรียกในภาษาอังกฤษว่า compounding error
สัญชาตญาณมักหลอกเรา: ความแม่นยำ 95% ต่อขั้นตอนฟังดูน่าเชื่อถือ แต่เลขยกกำลังจะกินส่วนเกินนั้นอย่างรวดเร็ว
| จำนวนขั้นตอน | p = 0.95 | p = 0.99 |
|---|---|---|
| 1 | 95% | 99% |
| 10 | ≈ 60% | ≈ 90% |
| 20 | ≈ 36% | ≈ 82% |
| 50 | ≈ 8% | ≈ 61% |
โมเดลนี้เป็นการประมาณคร่าว ๆ เพราะในทางปฏิบัติขั้นตอนไม่ได้เป็นอิสระต่อกันทั้งหมด และข้อผิดพลาดบางส่วนก็ไม่ได้ส่งผลอะไร แต่ทิศทางของมันถูกต้อง: ยิ่ง agent ทำงานอัตโนมัติยาวโดยไม่มีการตรวจ โอกาสที่ผลลัพธ์จะถูกต้องก็ยิ่งน้อยลง
ทำไมลำดับยาวจึงพังลง
ข้อผิดพลาดในขั้นตอนต้น ๆ ไม่หายไปเอง agent จะสร้างการเปลี่ยนแปลงต่อไปบนฐานที่ผิด เมื่อปัญหาเริ่มปรากฏชัด ก็มีโค้ดซ้อนทับอยู่บนบั๊กนั้นหลายชั้นแล้ว ที่แย่กว่านั้นคือเมื่อ agent ประเมินผลงานของตัวเอง การตัดสินของมันมักเอนไปทาง "ทุกอย่างโอเค" ดังนั้นรายงานว่า "เสร็จแล้ว เทสต์ผ่านหมด" อาจมาพร้อมกับโค้ดที่พังไปครึ่งหนึ่งก็ได้
Harness จัดการกับปัญหานี้อย่างไร
การเพิ่ม p ทำได้เพียงบางส่วน โมเดลไม่มีทางไม่ผิดพลาดเลย ตัวงัดสำคัญคือการไม่ปล่อยให้ข้อผิดพลาดไหลไปยังขั้นตอนถัดไป Harness จึงปิดวงจร feedback
- เซนเซอร์หลังทุกขั้นตอน คำสั่งตรวจเพียงคำสั่งเดียว (เช่น
make verifyที่รันเทสต์และ linter) วัดผลลัพธ์อย่างตรงไปตรงมาแทนการประเมินตนเองของ agent - จุดคืนสภาพ ขั้นตอนที่ผ่านการตรวจจะถูก commit ลำดับถัดไปจึงเริ่มจากสถานะที่ตรวจแล้ว และตัวนับข้อผิดพลาดก็เริ่มใหม่ในทางปฏิบัติ
- การแก้ไขขั้นต่ำ เมื่อการตรวจไม่ผ่าน agent แก้เฉพาะสาเหตุที่ระบุได้ แทนที่จะเขียนใหม่ทั้งหมด วิธีนี้ช่วยลดการแกว่งของผลลัพธ์
- งานสั้น ทำทีละงาน ขั้นตอนเล็ก ตรวจบ่อย แทนที่จะปล่อยให้ทำยี่สิบขั้นตอนแบบไม่มีการตรวจ เราจะได้ยี่สิบลำดับสั้นที่ยาวแค่ขั้นเดียว
ใน Claude Code สามารถผูกการตรวจไว้กับ hooks เพื่อให้รันอัตโนมัติ แทนที่จะพึ่งความตั้งใจของโมเดล
สรุป
ข้อผิดพลาดสะสมของ AI agent เป็นเลขคณิตที่เรียบง่าย: 0.95 ยกกำลังสิบมีค่าราว 0.60 และยกกำลังยี่สิบราว 0.36 วิธีแก้ไม่ได้อยู่ที่ "โมเดลที่ฉลาดกว่า" แต่อยู่ที่ harness ด้วยการตรวจทุกขั้นตอน การ commit สถานะที่ผ่านการตรวจ และการแบ่งงานให้สั้น หลักการของวงจรนี้และทฤษฎีเบื้องหลังถูกอธิบายอย่างละเอียดในบทเรียนของคอร์ส
คำถามที่พบบ่อย
หมายความว่า agent จะทำงาน 50 ขั้นตอนไม่สำเร็จเลยหรือ?
ถ้าไม่มีการตรวจระหว่างทาง โอกาสสำเร็จก็น้อยจริง แต่เมื่อมีการตรวจและ commit หลังทุกขั้นตอน งานจะกลายเป็นชุดของลำดับสั้น ๆ และความสำเร็จโดยรวมจะไม่ขึ้นกับผลคูณของทุกขั้นตอนอีกต่อไป
โมเดลที่แรงกว่าช่วยได้ไหม?
ช่วยได้ การเพิ่มความแม่นยำจาก 95% เป็น 99% ทำให้งาน 20 ขั้นตอนสำเร็จจาก 36% เป็น 82% แต่แม้ 99% ในงาน 50 ขั้นตอนก็ให้ผลราว 61% ดังนั้นการตรวจยังจำเป็นอยู่ดี
ทำไม agent ถึงมั่นใจในผลลัพธ์ทั้งที่ผิดพลาด?
ถ้าไม่มีเซนเซอร์ภายนอก agent จะเทียบผลลัพธ์กับความคาดหวังของตัวเอง ไม่ใช่กับความจริง ความมั่นใจของมันจึงเพิ่มขึ้นโดยไม่ขึ้นกับความถูกต้องของโค้ด
ขอให้ agent ตรวจสอบตัวเองได้ไหม?
การเขียนขอไว้ใน prompt ไม่รับประกันว่าจะทำตาม วิธีที่เชื่อถือได้กว่าคือทำให้การตรวจเป็นกลไก เช่น คำสั่งแยกต่างหาก hook หรือการตรวจใน CI
หัวข้อนี้สอนอย่างละเอียดพร้อมฝึกปฏิบัติในคอร์ส “Harness Engineering: инженерия надёжности AI-агентов”
ไปที่คอร์ส