Failure attribution

Failure attribution คือการระบุให้ได้ว่าเมื่อ agent ทำงานล้มเหลว ความผิดพลาดเกิดขึ้นตรงไหนของระบบ ปัญหาที่ทีมพัฒนาเจอทุกวันแต่ไม่มีภาษากลางจะพูดถึงคือการประเมินส่วนใหญ่บันทึกแค่ผลลัพธ์ระดับระบบว่าไม่สำเร็จ ซึ่งไม่บอกว่าต้นตออยู่ที่ใด เปเปอร์ที่เสนอกรอบเรื่องนี้เรียกอาการนี้ว่า repair-assignment problem คือปัญหาการมอบหมายว่าใครต้องไปแก้ เพราะความล้มเหลวหน้าตาเดียวกันอาจต้องแก้ด้วยการเทรนโมเดลเพิ่ม แก้ระบบที่ครอบมันอยู่ แก้สภาพแวดล้อม หรือแม้แต่แก้ตัวชุดทดสอบเอง ขึ้นอยู่กับว่าต้นตออยู่ที่ไหน

สิ่งที่งานนี้เสนอคือระบบจัดหมวดที่มองความล้มเหลวเป็นเรื่องของปฏิสัมพันธ์ระหว่างองค์ประกอบ ไม่ใช่คุณสมบัติของตัวใดตัวหนึ่ง เพราะพฤติกรรมของ agent เกิดจากการทำงานร่วมกันของโมเดล ระบบที่ครอบ (ดู harness) ผู้ใช้ เครื่องมือที่ต่ออยู่ หน่วยความจำ และสภาพแวดล้อม กรอบนี้จัด 41 รูปแบบความล้มเหลวลงบนเส้นเชื่อมระหว่างองค์ประกอบสองตัว พร้อมระบุฝั่งที่ต้องแก้ ทำให้จำแนกได้ว่ากรณีไหนควรไปเทรนโมเดลเพิ่ม กรณีไหนควรไปแก้ระบบครอบและการต่อเครื่องมือ และกรณีไหนแปลว่าเงื่อนไขการประเมินเองต้องออกแบบใหม่ก่อนจะเอาไปตัดสินความสามารถของ agent ผู้เขียนวัดความน่าเชื่อถือของระบบจัดหมวดด้วยการให้โมเดลระดับแนวหน้าสี่ตัวมาเป็นผู้ตัดสินอย่างเป็นอิสระแล้วเทียบกับป้ายที่มนุษย์ให้ ตัวที่ทำได้ดีที่สุดได้ค่าความสอดคล้อง Cohen's kappa ที่ 0.76 ซึ่งผู้เขียนตีความว่าหมวดหมู่เหล่านี้จับโครงสร้างร่วมได้จริง ไม่ใช่แค่รสนิยมของคนติดป้าย

คุณค่าที่ใช้ได้ทันทีสำหรับองค์กรคือมันให้ภาษาที่ทำให้เถียงกันบนหลักฐานได้ สถานการณ์ที่เกิดขึ้นบ่อยคือ agent ทำงานพลาดแล้วทีมเถียงกันว่าเป็นเพราะโมเดลไม่เก่งพอหรือเพราะระบบที่เราสร้างครอบมันไม่ดี ซึ่งมักจบด้วยการเปลี่ยนไปใช้โมเดลที่แพงกว่าโดยไม่ได้แก้อะไร คำถามที่หยิบไปใช้ในการประชุมหลังเกิดปัญหาได้เลยคือความผิดพลาดนี้เกิดตรงรอยต่อระหว่างอะไรกับอะไร และฝั่งไหนคือฝั่งที่ควรแก้ ถ้าคำตอบคือเครื่องมือส่งข้อมูลกลับมาในรูปแบบที่โมเดลอ่านไม่ออก การเปลี่ยนโมเดลจะไม่ช่วยอะไรเลย ข้อควรระวังคืองานนี้เสนอกรอบการจัดหมวด ไม่ใช่การวัดว่าความล้มเหลวแบบไหนพบบ่อยที่สุดในงานจริง จึงใช้จำแนกได้แต่ใช้จัดลำดับความสำคัญไม่ได้ และค่าความสอดคล้องที่รายงานมาจากการให้โมเดลติดป้ายเทียบกับคน ไม่ใช่การทดลองในองค์กรจริง

ตัวอย่างจากบทสนทนาจริง

ผู้จัดการฝ่ายปฏิบัติการ: "agent ที่ช่วยตอบลูกค้าตอบผิดสามเคสสัปดาห์นี้ ทีมเสนอให้เปลี่ยนไปใช้โมเดลรุ่นใหญ่กว่า ซึ่งค่าใช้จ่ายขึ้นสามเท่า ควรอนุมัติไหมครับ"

หัวหน้าฝ่ายเทคนิค: "ขอดูก่อนว่าพลาดตรงรอยต่อไหนครับ ผมไล่ trace ของแต่ละเคส แล้วพบว่าสองในสามเคส ระบบค้นข้อมูลส่งสินค้าคนละรุ่นกลับมาให้ตั้งแต่แรก โมเดลก็ตอบตามข้อมูลที่ได้ซึ่งถูกต้องตามหน้าที่มันแล้ว อันนี้เป็นความผิดพลาดฝั่งเครื่องมือ ไม่ใช่ฝั่งโมเดล เปลี่ยนโมเดลไปก็ยังผิดเหมือนเดิม ส่วนเคสที่สามเป็นฝั่งโมเดลจริง ผมเสนอให้แก้ระบบค้นข้อมูลก่อนแล้ววัดใหม่อีกสองสัปดาห์ครับ"

ระวังสับสนกับ

• harness : harness คือระบบที่เราสร้างครอบโมเดลไว้ ทั้งการต่อเครื่องมือ การจัดการบริบท และลำดับการทำงาน ซึ่งเป็นหนึ่งในฝั่งที่ failure attribution ชี้ไปได้ พูดอีกแบบคือ harness เป็นองค์ประกอบ ส่วน failure attribution เป็นวิธีหาว่าองค์ประกอบไหนผิด
• evals : evals คือการวัดว่าโมเดลหรือระบบทำได้ดีแค่ไหน ซึ่งตอบว่าผ่านหรือไม่ผ่าน ส่วน failure attribution ทำงานต่อจากตรงนั้น คือเมื่อไม่ผ่านแล้วต้องตอบว่าไม่ผ่านเพราะอะไรและใครต้องแก้
• non-determinism : non-determinism คือคุณสมบัติที่โมเดลตอบไม่เหมือนเดิมทุกครั้งแม้ป้อนสิ่งเดิม ซึ่งทำให้การไล่หาต้นตอยากขึ้น แต่เป็นคนละเรื่องกับ failure attribution ที่เป็นวิธีจัดหมวดว่าความผิดพลาดเกิดตรงไหน