เจาะลึกความล้มเหลว AI Agent: เมื่อข้อผิดพลาดเดียวลุกลามเป็นลูกโซ่
ทำไมความผิดพลาดเพียง 10% ในแต่ละขั้นตอนของ LLM Agent ถึงทวีคูณจนทำให้งานพังทั้งระบบ และวิธีรับมือกับปัญหา Cascade
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ความผิดพลาดของ AI Agent ไม่ใช่เหตุการณ์อิสระ แต่เชื่อมโยงกันผ่านบริบท (Context)
- เมื่อเกิดข้อผิดพลาด ขั้นตอนถัดไปจะมีความน่าจะเป็นที่จะผิดพลาดเพิ่มขึ้น (p_c > p)
- ความเสียหายจาก Cascade จะเติบโตแบบ Super-linear ตามจำนวนขั้นตอนการทำงาน (N)
- การแก้ปัญหาไม่ใช่การทำให้ความผิดพลาดเป็นศูนย์ แต่เป็นการหยุดยั้งไม่ให้ความผิดพลาดขยายวงกว้าง
นักพัฒนาหลายคนมักประเมินความผิดพลาดของ AI Agent แบบสถิติทั่วไป โดยวัดอัตราความผิดพลาดต่อขั้นตอน เช่น มีความผิดพลาด 10% ในแต่ละสเต็ป แล้วสันนิษฐานว่าข้อผิดพลาดเหล่านั้นเป็นอิสระต่อกัน แปลว่าหากสเต็ปไหนผิดพลาดไปแล้ว สเต็ปที่เหลือก็ควรจะดำเนินต่อไปได้ปกติ แต่เมื่อเราเฝ้าดูการทำงานจริง (Trajectory) กลับพบภาพที่ต่างออกไปโดยสิ้นเชิง
ในความเป็นจริง หากสเต็ปที่ 4 ได้ข้อเท็จจริงที่คลาดเคลื่อนเล็กน้อย สเต็ปที่ 5 จะนำข้อมูลที่ผิดพลาดนั้นมาประมวลผลต่อและยึดถือเป็นความจริงที่หนักแน่นขึ้น สเต็ปที่ 6 จะเริ่มดำเนินการต่อโดยอ้างอิงจากฐานที่ผิดทั้งสองส่วน และพอถึงสเต็ปที่ 8 เอเจนต์จะกำลังทำตามแผนงานที่ล่มสลายตั้งแต่สเต็ปที่ 4 ไปด้วยความมั่นใจเต็มร้อย กลายเป็นว่าข้อผิดพลาดเดียวเติบโตกลายเป็นห้าข้อผิดพลาด เพราะความผิดพลาดไม่ได้เป็นอิสระต่อกัน แต่ถูกผูกเข้าไว้ด้วยกันผ่านชุดบริบท (Context)
ปรากฏการณ์นี้เรียกว่า Cascade หรือการลุกลามของความผิดพลาดในแนวตั้ง ซึ่งแตกต่างจากปัญหาในระบบจำหน่าย (Distributed Retry Patterns) ที่ความผิดพลาดกระจายตัวในแนวนอนไปยังหลายเวิร์กเกอร์พร้อมกัน ปัญหา Cascade จะกระจายตัวไปตามกาลเวลาภายในงานรันเดียว เพราะผลลัพธ์ในอดีตของเอเจนต์คืออินพุตในอนาคตของตัวมันเอง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ฟังก์ชันแบบไร้สถานะ (Stateless Function) ทั่วไปเมื่อล้มเหลวก็จะแค่ส่งค่า Error กลับมา แต่เอเจนต์ที่ล้มเหลวจะทำสิ่งที่แย่กว่านั้นคือการบันทึกความล้มเหลวลงในที่ที่มันจะอ่านเจอได้อีก กลไกเดียวกันนี้เองที่ทำให้เอเจนต์ทำงานได้ ทรานสคริปต์จะสะสมและทุกขั้นตอนจะขึ้นอยู่กับข้อมูลก่อนหน้าทั้งหมด ซึ่งเป็นช่องทางเดียวกับที่ความผิดพลาดเดินทางผ่าน
ในมุมมองเชิงสถาปัตยกรรมซอฟต์แวร์ ปัญหา Cascade เกิดจากธรรมชาติของ LLM ที่อิงบริบท (In-context learning) ทำให้บริบทเก่ากลายเป็นความจริงเสมือน (Ground Truth) ของสเต็ปถัดไป การป้องกันจึงต้องอาศัยกลไกการตรวจสอบระหว่างทาง (Interruption points) มากกว่าการหวังพึ่งโมเดลที่สมบูรณ์แบบตั้งแต่ต้น
"One bad step is not one bad step. It's a starting condition, and the agent will faithfully build on it until something makes it stop."
Loop & Retry
ความรุนแรงของ Cascade ยังเพิ่มขึ้นตามความยาวของการรัน (Run length) โดยหากเปรียบเทียบจำนวนขั้นตอน N จะเห็นการขยายตัวที่ชัดเจน:
- N=4: ขยายตัว 1.5 เท่า
- N=8: ขยายตัว 2.0 เท่า
- N=16: ขยายตัว 2.7 เท่า
- N=25: ขยายตัว 3.2 เท่า
ความผิดพลาดแบบอิสระจะเติบโตเป็นเส้นตรงตามค่า N แต่ข้อผิดพลาดแบบลุกลามจะเติบโตแบบ Super-linear เพราะการรันที่ยาวขึ้นเปิดโอกาสให้ข้อผิดพลาดตั้งต้นมีเวลาไปปนเปื้อนขั้นตอนปลายทางได้มากขึ้น ซึ่งมีรูปทรงกราฟเดียวกับ O(N²) token curve นั่นเอง
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น