ToolFailBench: งานวิจัยชี้ 'คะแนนรวม' ปิดบังว่าเอเจนต์ล้มเหลวเรื่อง tool use อย่างไร — แยกโหมดพัง 4 แบบ โมเดลเก่งสุดยังทำ Clean Tool-Use ได้แค่ 86%

งานวิจัยใหม่บน arXiv (ส่งเมื่อ 6 ก.ค. 2026) ชื่อ “ToolFailBench: Diagnosing Tool-Use Failures in LLM Agents” โดย Harsh Soni ชี้ประเด็นที่ทีมสร้างเอเจนต์ทุกทีมควรอ่าน: คะแนนรวมของเบนช์มาร์ก tool use ปิดบังไม่ให้เห็นว่าโมเดลล้มเหลว “อย่างไร” — สองโมเดลที่คะแนนใกล้เคียงกันอาจพังคนละแบบสิ้นเชิง และถ้าคุณเลือกโมเดลจากตัวเลขรวมเพียงอย่างเดียว คุณอาจได้พฤติกรรมที่ไม่เหมาะกับงานของคุณเลย

เบนช์มาร์กส่วนใหญ่ในปัจจุบันให้คะแนน tool use เป็นก้อนเดียว — เรียกเครื่องมือถูกได้กี่เปอร์เซ็นต์ ToolFailBench เสนอมุมมองที่ วินิจฉัยได้ แทน โดยแยกความล้มเหลวออกเป็นประเภท เพื่อให้เห็นว่าจุดอ่อนอยู่ตรงไหนจริง ๆ

4 โหมดความล้มเหลวของ tool use

ToolFailBench จำแนกความผิดพลาดออกเป็นสี่ประเภทที่ชัดเจน:

• Tool-Skip — ควรเรียกเครื่องมือแต่ไม่เรียก (เดาคำตอบเองทั้งที่ควรไปค้น/คำนวณ)
• Result-Ignore — เรียกเครื่องมือแล้ว แต่ไม่เอาผลลัพธ์ที่ได้มาใช้จริง
• Output-Fabrication — กุผลลัพธ์ของเครื่องมือขึ้นมาเอง แทนที่จะใช้ค่าที่ได้กลับมา
• Unnecessary-Tool-Use — เรียกเครื่องมือทั้งที่ไม่จำเป็น (งานที่ตอบได้เองก็ไปเรียก)

สองโหมดแรกคือ “ควรเรียกแต่พลาด” ส่วนสองโหมดหลังคือ “ไม่ควรเรียก/ไม่ควรมั่ว แต่ทำ” — การแยกแบบนี้ทำให้เห็นว่าโมเดลมีนิสัยเอนไปทาง “ขี้เรียก” หรือ “ขี้เกียจเรียก”

ตัวเลขที่นักพัฒนาต้องจำ

ชุดข้อมูลมี 1,000 งาน ครอบคลุม 5 โดเมน — การเงิน การแพทย์ กฎหมาย ความมั่นคงไซเบอร์ และอสังหาริมทรัพย์ — ประเมินด้วย rule classifier บวก LLM judge สองตัว (ตัดสินด้วยเสียงข้างมาก) ทดสอบกับ 19 โมเดลแถวหน้า

ผลที่คมที่สุด:

• โมเดลเก่งสุดทำ Clean Tool-Use Rate ได้เพียง 86.33% — แปลว่า “การใช้เครื่องมืออย่างซื่อตรง” ยัง ไม่ saturate ยังมีช่องพังเหลืออยู่ราว 1 ใน 7 ครั้ง
• โมเดลที่คะแนนรวมใกล้กัน กลับพังคนละแบบ งานวิจัยระบุว่าส่วนใหญ่ “มีวินัย” กับงานควบคุมที่ไม่ต้องใช้เครื่องมือ แต่ ตระกูล Llama-3.1 แสดงนิสัย ‘Always-Call’ — เรียกเครื่องมือแทบตลอด แม้ในงานที่ไม่จำเป็น
• ในงานควบคุม (control tasks) ที่ ไม่ควร เรียกเครื่องมือ ช่องว่างระหว่าง Llama-3.1-70B กับ Qwen2.5-72B ห่างกันถึง 89 จุดเปอร์เซ็นต์ — ขนาดพารามิเตอร์ใกล้กัน คะแนนรวมใกล้กัน แต่โปรไฟล์ความล้มเหลวตรงข้ามกันโดยสิ้นเชิง

มุมมอง AI Curator

นี่คืองานประเภท “เปลี่ยนวิธีที่คุณเลือกโมเดล” ไม่ใช่แค่ leaderboard อีกอัน บทเรียนใช้ได้ทันทีคือ: อย่าเลือกโมเดลสำหรับเอเจนต์จากคะแนน tool use รวมก้อนเดียว เพราะมันซ่อนว่าโมเดลนั้นเป็นสาย “ขี้เรียก” (Always-Call) หรือสาย “ขี้เดา” (Tool-Skip) — และสองนิสัยนี้เหมาะกับงานคนละแบบ ระบบที่การเรียกเครื่องมือมีต้นทุนหรือความเสี่ยง (เช่น สั่งฐานข้อมูล เรียก API ที่คิดเงิน หรือทำธุรกรรม) ต้องการโมเดลที่ ไม่เรียกพร่ำเพรื่อ ส่วนงานที่พลาดข้อมูลจริงแล้วเสียหาย ต้องการโมเดลที่ ไม่ขี้เกียจเรียก

สำหรับทีมไทยที่กำลังต่อเอเจนต์เข้ากับระบบภายใน (ERP, ฐานข้อมูลลูกค้า, ระบบชำระเงิน) โหมด Output-Fabrication คือจุดอันตรายที่สุดที่ควรเทสต์ให้หนัก — โมเดลที่ “กุผลลัพธ์เครื่องมือ” แทนที่จะใช้ค่าจริง คือหายนะเงียบ ๆ เพราะคำตอบดูสมเหตุสมผลแต่ตัวเลขผิด และการที่แม้แต่โมเดลระดับท็อปยังทำ Clean Tool-Use ได้แค่ ~86% เป็นเครื่องเตือนว่า การวางกลไกตรวจสอบ (validation, guardrail, การบังคับ schema ของผลลัพธ์เครื่องมือ) ยังเป็นงานของเรา ไม่ใช่สิ่งที่โมเดลรับประกันให้ วิธีที่ได้ผลคือเอากรอบ 4 โหมดนี้ไปสร้างชุดเทสต์ของตัวเอง แล้ววัดโมเดลผู้สมัครด้วย “โปรไฟล์ความล้มเหลว” ไม่ใช่แค่คะแนนเดียว

แหล่งข่าว

• ToolFailBench: Diagnosing Tool-Use Failures in LLM Agents — arXiv:2607.04686
• ToolFailBench — ฉบับ HTML เต็ม (arXiv)