ไขปริศนา! ทำไม Agent อัจฉริยะในองค์กรถึงล้มเหลว? เจาะลึกด้วย IT-Bench และ MAST

ไขปริศนา! ทำไม Agent อัจฉริยะในองค์กรถึงล้มเหลว? เจาะลึกด้วย IT-Bench และ MASTในโลกของการทำงานอัตโนมัติด้วย AI โดยเฉพาะกลุ่ม Agent อัจฉริยะที่ใช้โมเดลภาษาขนาดใหญ่ (LLM) การทำความเข้าใจว่าทำไมระบบเหล่านี้ถึงล้มเหลวในโลกแห่งความเป็นจริง โดยเฉพาะในงานที่ซับซ้อนอย่างการจัดการระบบ IT ถือเป็นเรื่องท้าทายอย่างยิ่ง การทดสอบประสิทธิภาพแบบเดิมๆ มักให้แค่ตัวเลขชี้วัดความสำเร็จ แต่ไม่สามารถบอกได้ว่า "ทำไม" ถึงล้มเหลวIBM Research และ UC Berkeley ได้ร่วมมือกันศึกษาปัญหานี้อย่างจริงจัง โดยใช้เครื่องมือที่ชื่อว่า IT-Bench ซึ่งเป็น Benchmark มาตรฐานสำหรับงานด้าน SRE (Site Reliability Engineering), Security และ FinOps และ MAST (Multi-Agent System Failure Taxonomy) ซึ่งเป็นระเบียบวิธีที่ช่วยวินิจฉัยความล้มเหลวของระบบ Agent อัจฉริยะโดยเฉพาะปัญหา "กล่องดำ" ของ Benchmark AgentBenchmark อย่าง IT-Bench ถูกออกแบบมาเพื่อวัดประสิทธิภาพของ Agent ในงานสำคัญ เช่น การวินิจฉัยปัญหา Kubernetes, การแก้ไขช่องโหว่ความปลอดภัย หรือการจัดการต้นทุนบนคลาวด์ โดยปกติจะใช้ "อัตราความสำเร็จ" เป็นตัวชี้วัดหลัก แต่ตัวเลขนี้เพียงพอหรือไม่? การรู้ว่า Agent ทำงานสำเร็จ 14% ไม่ได้บอกเราว่าสาเหตุที่อีก 86% ล้มเหลวนั้นเกิดจากอะไรกันแน่ ลืมบริบท? สร้างคำสั่งผิด? หรือแค่หยุดทำงานไม่เป็น?หากปราศจากวิธีการวิเคราะห์ความล้มเหลวที่ครอบคลุม นักพัฒนาจะยังคงต้องเดาทาง และมักจะแก้ไขปัญหาด้วยการปรับแต่ง Prompt แบบสุ่ม ซึ่งอาจแก้ปัญหาหนึ่งได้ แต่กลับสร้างปัญหาใหม่ขึ้นมาแทนMAST: กุญแจไขกล่องดำแห่งความล้มเหลวMAST ถูกพัฒนาขึ้นเพื่อเป็นมาตรฐานใหม่ในการวิเคราะห์รูปแบบความล้มเหลวของระบบ Agent ที่ซับซ้อน MAST จะแปลง Log การทำงานที่ดูเหมือนไม่มีโครงสร้าง ให้กลายเป็น "เวกเตอร์ความล้มเหลว" ที่มีโครงสร้าง ชี้ให้เห็นถึง 14 รูปแบบความล้มเหลวที่แตกต่างกัน โดยแบ่งออกเป็น 3 หมวดหมู่หลัก:1. FC1: ปัญหาการออกแบบระบบ (โครงสร้างหลัก)ความล้มเหลวที่เกิดจากสถาปัตยกรรมและนิยามบทบาทของ Agent เช่น:FM-1.3 Step Repetition: การทำงานซ้ำซ้อน (วนลูป)FM-1.4 Loss of Conversation History: การสูญเสียประวัติการสนทนา (Memory Leak)FM-1.5 Unaware of Termination Conditions: ไม่ทราบเงื่อนไขการสิ้นสุดการทำงาน (ไม่ยอมหยุด)2. FC2: การสื่อสารผิดพลาดระหว่าง Agent (การสื่อสาร)ความล้มเหลวที่เกิดขึ้นระหว่างการทำงาน จากวิธีการที่ Agent สื่อสารกันเอง หรือกับสภาพแวดล้อม เช่น:FM-2.2 Fail to Ask for Clarification: ล้มเหลวในการขอคำชี้แจง (ด่วนสรุปแทนที่จะถาม)FM-2.3 Task Derailment: งานหลุดจากเป้าหมาย (ออกนอกประเด็น)3. FC3: การตรวจสอบงาน (การควบคุมคุณภาพ)ความล้มเหลวในกระบวนการประกันคุณภาพของผลลัพธ์ที่ Agent สร้างขึ้น เช่น:FM-3.1 Premature Termination: การยุติงานก่อนเวลาอันควร (ยอมแพ้เร็วเกินไป)FM-3.3 Incorrect Verification: การตรวจสอบไม่ถูกต้อง (สร้างความสำเร็จปลอมขึ้นมา)การทดลอง: วินิจฉัย Agent บน IT-Benchเพื่อทดสอบแนวคิดการใช้ MAST ให้การประเมิน Agent มีประโยชน์และได้ข้อมูลเชิงลึกเกี่ยวกับรูปแบบความล้มเหลว นักวิจัยได้นำ MAST ไปประยุกต์ใช้กับ IT-Bench โดยได้ทำการวิเคราะห์ Log การทำงาน 310 รายการ จาก Agent SRE ที่สร้างขึ้นด้วย Codex ในสภาพแวดล้อมจริง ซึ่งครอบคลุมโมเดล 3 ประเภทที่แตกต่างกัน ได้แก่ Gemini-3-Flash, Kimi-K2 และ GPT-OSS-120B เพื่อให้มองข้ามเมตริกความสำเร็จแบบง่ายๆ และเจาะลึกถึง "ลายเซ็นความล้มเหลว" ที่ขับเคลื่อนผลลัพธ์เหล่านี้ผลการทดสอบพบว่า:Gemini-3-Flash: 100 traces (เฉลี่ย 75.5% Recall)Kimi-K2: 105 traces (เฉลี่ย 28.6% Recall)GPT-OSS-120B: 105 traces (เฉลี่ย 12.4% Recall)การค้นพบที่น่าสนใจจากการวิเคราะห์1. โมเดลที่แข็งแกร่งอย่าง Gemini-3-Flash แสดงรูปแบบความล้มเหลวที่ "แม่นยำ" (แยกส่วน) ในขณะที่ Kimi-K2 และ GPT-OSS-120B แบบ Open Source กลับแสดงรูปแบบความล้มเหลวที่ "ทับซ้อนกัน"เมื่อพิจารณาจาก Traces ที่ล้มเหลว จะเห็นลำดับชั้นของความซับซ้อนที่ชัดเจนระหว่างโมเดลทั้งสาม โดยวัดจากจำนวนรูปแบบความล้มเหลวที่แตกต่างกันในแต่ละครั้งที่ล้มเหลว:Gemini-3-Flash: เฉลี่ย 2.6 รูปแบบความล้มเหลวต่อ Traces ที่ล้มเหลวKimi-K2: เฉลี่ย 4.7 รูปแบบความล้มเหลวต่อ Traces ที่ล้มเหลวGPT-OSS-120B: เฉลี่ย 5.3 รูปแบบความล้มเหลวต่อ Traces ที่ล้มเหลวความแตกต่างนี้เผยให้เห็นถึงวิธีการที่ระบบเหล่านี้ล้มเหลว Gemini-3-Flash แสดงโปรไฟล์ความล้มเหลวที่ "แม่นยำ" แม้ในขณะที่ทำงานไม่สำเร็จ ก็ยังคงรักษาความสอดคล้องภายในไว้ได้สูง และมักจะล้มเหลวเนื่องจากความล้มเหลวที่แยกส่วนได้ เช่น ขั้นตอนการตรวจสอบที่ไม่ถูกต้อง ซึ่งทำให้วินิจฉัยและแก้ไขได้ง่ายกว่าในทางตรงกันข้าม GPT-OSS-120B กลับประสบกับ "การล่มสลายแบบทับซ้อน" ข้อผิดพลาดมีแนวโน้มที่จะสะสมเมื่อเวลาผ่านไป การจับคู่การให้เหตุผลที่ผิดพลาดเล็กน้อยในช่วงต้น อาจนำไปสู่การเบี่ยงเบนไปจากข้อกำหนดของงาน ซึ่งส่งผลให้ Agent ล้มเหลวโดยสิ้นเชิง Kimi-K2 อยู่ตรงกลาง ระหว่างสองโมเดลนี้ โดยมีความล้มเหลวที่บ่อยครั้งและซับซ้อนกว่าโมเดลระดับแนวหน้า แต่ไม่ถึงขั้นความไม่เสถียรของระบบแบบ GPT-OSS-120Bข้อค้นพบนี้มีความสำคัญ เพราะอัตราความสำเร็จที่สูงขึ้น มักมาพร้อมกับความล้มเหลวที่แยกส่วนได้ ระบบที่ล้มเหลวโดยมีปัญหาน้อยกว่า จะสามารถคาดการณ์ได้ง่ายกว่า และง่ายต่อการปรับปรุงผ่านการแทรกแซงทางวิศวกรรมที่ตรงจุด2. ความล้มเหลวแบบ "ไม่ร้ายแรง" (Benign) vs. "ร้ายแรง" (Fatal)สิ่งที่สำคัญที่สุดจาก MAST คือการแยกแยะระหว่างความล้มเหลวที่ระบบสามารถทนทานได้ กับความล้มเหลวที่ส่งผลร้ายแรงต่อความสำเร็จของงาน การเปรียบเทียบการกระจายของรูปแบบความล้มเหลวใน Traces ที่สำเร็จและล้มเหลว ช่วยให้เราจัดประเภทได้ดังนี้:ข้อบกพร่องที่ "ไม่ร้ายแรง" (Benign Flaws)ในโมเดลทั้งสาม รูปแบบความล้มเหลวบางอย่างปรากฏขึ้นบ่อยครั้ง แม้ในขณะที่การทำงานสำเร็จลุล่วง ซึ่งมักจะเป็นข้อขัดข้องเชิงโครงสร้างมากกว่าข้อผิดพลาดร้ายแรง:FM-1.3 Step Repetition: โหมดนี้ปรากฏใน Kimi-K2 ที่สำเร็จมากกว่า 90% ในโดเมน SRE การทำซ้ำมักเป็นสิ่งจำเป็น Agent อาจสอบถาม Metric เดียวกันหลายครั้งเพื่อยืนยันว่า Service กำลังดีขึ้น หรือการแก้ไขได้ผลหรือไม่ น่าสนใจว่า Gemini-3-Flash กลับแสดงการทำซ้ำน้อยลงใน Traces ที่ล้มเหลว ซึ่งบ่งชี้ว่าบางครั้งมันล้มเหลวเพราะ ไม่ทำซ้ำเพียงพอFM-1.1 Disobey Task Specification: Agent มักจะเบี่ยงเบนไปจากรูปแบบเครื่องมือที่เข้มงวด หรือคำแนะนำตามลำดับ แต่ก็ยังสามารถระบุสาเหตุที่ถูกต้องได้นี่คือจุดที่ MAST แสดงคุณค่าของมัน ช่วยให้เราเพิกเฉยต่อความล้มเหลวที่ไม่ร้ายแรง เช่น การทำซ้ำที่มักเกิดขึ้นในการแก้ไขปัญหา และมุ่งเน้นไปที่ความล้มเหลวร้ายแรงที่ทำให้การทำงานล้มเหลวพฤติกรรมที่ "ร้ายแรง" (Fatal Failures)พฤติกรรมบางอย่างแยกความสำเร็จออกจากความล้มเหลวได้อย่างชัดเจน เมื่อโหมดเหล่านี้ปรากฏ ความน่าจะเป็นของผลลัพธ์ที่สำเร็จจะลดลงอย่างมาก ตัวอย่างที่โดดเด่นที่สุดคือ FM-3.3 (Incorrect Verification) โหมดนี้แสดงการเพิ่มขึ้น 52% ใน Gemini-3-Flash ที่ล้มเหลวเมื่อเทียบกับ Traces ที่สำเร็จ โหมดที่โดดเด่นอื่นๆ ได้แก่ FM-1.5 (Unaware of Termination Conditions) และ FM-2.6 (Reasoning Action Mismatch) หากสิ่งเหล่านี้เกิดขึ้น การทำงานมีแนวโน้มที่จะล้มเหลว ซึ่งช่วยแนะนำผู้ปฏิบัติงานในการพัฒนากลยุทธ์การจัดการบริบทที่แข็งแกร่งทั่วทั้ง Agent ในระบบ และการโต้ตอบหลายรอบกรณีศึกษา: Gemini-3-Flash (ตัดสินใจเร็ว แต่อาจมั่นใจเกินไป)Gemini-3-Flash มีประสิทธิภาพสูง แต่ปัญหาคอขวดหลักคือแนวโน้มที่จะ "สันนิษฐานว่าสำเร็จ" โดยไม่มีหลักฐานที่ชัดเจน รูปแบบความล้มเหลวของมันถูกครอบงำด้วยความแตกต่างอย่างมากในข้อผิดพลาดการตรวจสอบ Agent มักจะระบุสัญญาณที่ถูกต้อง แต่จะยุติการทำงานก่อนที่จะตรวจสอบกับ Ground Truth เพื่อแก้ไขปัญหานี้ นักพัฒนาควรใช้ "ประตูการตรวจสอบภายนอก" โดยการกำหนดให้มีหลักฐานจากเครื่องมือ เช่น การแจ้งเตือนที่เคลียร์แล้ว หรือ Threshold ของ Metric ที่ดี ก่อนที่จะอนุญาตให้ Agent สิ้นสุดการทำงาน ซึ่งจะช่วยลดความมั่นใจเกินไปโดยธรรมชาติของโมเดลนี้ได้แนวทางการแก้ไข: การปรับปรุง Gemini-3-Flash บน ITBench ด้วย Prompt Engineering เพียงอย่างเดียวอาจไม่ช่วยมากนัก การทดลองที่แสดงในบทความ NeurIPS 2025 ชี้ให้เห็นว่า การปรับปรุงด้วย Prompt Engineering สำหรับความล้มเหลวที่เกี่ยวกับหน่วยความจำ สามารถเพิ่มประสิทธิภาพได้เพียงประมาณ 15.6% เท่านั้น ในขณะที่การเพิ่ม Agent ใหม่ เช่น Summarizer Agent เพื่อเตือน Agent อื่นๆ หรือกลไกการจัดการบริบท (เช่น State Machine ที่เข้มงวดขึ้นเพื่อบังคับการสิ้นสุด) สามารถเพิ่มประสิทธิภาพได้ถึง 53% เนื่องจากเป็นการจัดการกับปัญหาพื้นฐานของระบบมากกว่ากรณีศึกษา: Kimi-K2 (วิกฤตการสิ้นสุดการทำงาน)แม้ว่าความสับสนเกี่ยวกับการสิ้นสุดการทำงาน (FM-3.1 และ FM-1.5) จะเป็นรูปแบบความล้มเหลวที่แพร่หลายที่สุดสำหรับ Kimi-K2 แต่ Traces ที่ล้มเหลวของมันมักมีลักษณะเด่นคือ FM-2.6 (Action-Reasoning Mismatch) ซึ่งปรากฏใน Traces ที่ล้มเหลวสูงถึง 92%ช่องว่างการดำเนินการ: แม้ว่าส่วนหนึ่งของการให้เหตุผลภายในมักจะถูกต้อง แต่ก็ประสบกับความล้มเหลว 92% ของ FM-2.6 (Action-Reasoning Mismatch) Agent มักจะระบุขั้นตอนต่อไปที่ถูกต้อง แต่กลับดำเนินการคำสั่งที่ซ้ำซ้อนหรือไม่เกี่ยวข้องกับดัก Meta-Loop: ประมาณ 25% ของ Traces ที่ล้มเหลวเกี่ยวข้องกับ FM-2.3 (Task Derailment) เมื่อการเรียกใช้เครื่องมือส่งคืนข้อผิดพลาดเล็กน้อย Agent มักจะละทิ้งเหตุการณ์หลัก และเข้าสู่วงจรการดีบักสคริปต์การตรวจสอบของตนเองKimi-K2 เป็นตัวอย่างที่ดีของ Agent ที่ "คิดมากเกินไป" แต่ดำเนินการผิดพลาดสิ่งที่ได้เรียนรู้ในการสร้าง Agentจากการวิเคราะห์นี้ มีข้อคิดที่สำคัญสำหรับการสร้าง Agent ที่มีประสิทธิภาพในองค์กร:สำหรับ Frontier Models อย่าง Gemini: แยกการตรวจสอบออกไปภายนอก อย่าให้ LLM ตรวจการบ้านของตัวเอง กำหนดให้มีหลักฐานจากเครื่องมือที่ชัดเจนก่อนที่จะสรุปว่างานเสร็จสิ้นควบคุมการสิ้นสุดและลูปการทำงานภายนอกโมเดล: ปัญหาการสิ้นสุดการทำงานเป็นสาเหตุการล้มเหลวที่พบบ่อย (FM-1.5) ควรเพิ่มเงื่อนไขการหยุดที่ชัดเจน และตัวตรวจจับลูปสำหรับการเรียกใช้เครื่องมือ/การดำเนินการซ้ำๆhttps://huggingface.co/blog/ibm-research/itbenchandmast