การประเมินผลของคุณก็ไม่เสถียรเช่นกัน: เลิกเชื่อถืออัตราการผ่านที่คุณไม่สามารถทำซ้ำได้

คนส่วนใหญ่รู้ดีว่า AI agent นั้นมีความไม่แน่นอน (non-deterministic) คุณส่ง prompt เดิม แต่กลับได้ผลลัพธ์ที่แตกต่างกัน

เรายอมรับเรื่องนี้ และเริ่มใช้ LLM มาทำหน้าที่เป็นผู้ตัดสิน (judges) เพื่อให้คะแนน agent เหล่านี้

แต่เราทำผิดพลาดอย่างมหันต์ เราทึกทักเอาเองว่าผู้ตัดสินของเรามีความแน่นอน (deterministic) แต่ความจริงแล้วไม่ใช่เลย

ชุดการประเมินผล (eval suite) ของคุณก็คือระบบที่สุ่มมาเพื่อประเมินอีกระบบหนึ่งที่สุ่มเช่นกัน หากคุณไม่วัดว่าตัวให้คะแนนของคุณมีความแกว่งมากแค่ไหน คุณก็ไม่มีประตูควบคุมคุณภาพ (quality gate) หรอก คุณแค่กำลังโยนเหรียญเสี่ยงทายอยู่ต่างหาก

ผมเคยเห็นเหตุการณ์นี้เกิดขึ้นกับ support agent แดชบอร์ดแสดงสถานะสีเขียวมาหลายสัปดาห์ แต่แล้วข้อร้องเรียนจากลูกค้าก็พุ่งสูงขึ้น ผมจึงลองรันการประเมินเดิมกับคำตอบเก่า 200 รายการ พบว่า 14 รายการมีการเปลี่ยนคำตัดสิน ตัว agent ไม่ได้เปลี่ยนไปเลย แต่ตัวผู้ตัดสินต่างหากที่เปลี่ยนใจ

ประตูควบคุมที่ไม่เสถียรนั้นแย่ยิ่งกว่าการไม่มีประตูควบคุมเสียอีก เพราะมันให้ความมั่นใจที่ผิดพลาดแก่คุณ

มีเหตุผล 3 ประการที่ทำให้การประเมินผลของคุณล้มเหลว:

  • ตัวโมเดลผู้ตัดสิน (The judge model): ผู้ตัดสินที่เป็น LLM ทุกตัวมีความแปรปรวน (variance) แม้จะตั้งค่า temperature เป็น 0 ผู้ให้บริการก็ไม่ได้รับประกันว่าจะได้ผลลัพธ์เดิมเสมอไป การอัปเดตโมเดลแบบเงียบๆ เพียงครั้งเดียวอาจทำลายเกณฑ์มาตรฐาน (baseline) ของคุณได้เพียงชั่วข้ามคืน
  • Harness: หากบริบท (context) หรือผลลัพธ์จากเครื่องมือ (tool outputs) เปลี่ยนไปในแต่ละรอบการรัน ผู้ตัดสินก็จะเห็นคำถามที่ต่างออกไป อินพุตของคุณเกิดการคลาดเคลื่อน (drifted)
  • Rubric: กฎที่คลุมเครืออย่างเช่น "สิ่งนี้ดีหรือไม่?" จะสร้างความแปรปรวน ในขณะที่กฎที่รัดกุมและเฉพาะเจาะจงจะช่วยลดความแปรปรวนนั้นลง

คุณต้องปฏิบัติต่อการประเมินผลที่ไม่เสถียรเหมือนกับซอฟต์แวร์ที่ทดสอบไม่ผ่าน อย่าเพิ่งนำไปใช้งานจริง (ship) ให้กักกัน (quarantine) มันไว้ และวัดอัตราความไม่เสถียร (flake rate) ของมัน

เลิกรายงานแค่อัตราการผ่าน (pass rate) เพียงอย่างเดียว แต่เริ่มรายงานความสอดคล้อง (agreement) แทน

ให้รันการเรียกใช้ผู้ตัดสินแต่ละครั้งหลายๆ รอบ หากผู้ตัดสินไม่สามารถเห็นพ้องกับตัวเองได้ คำตัดสินนั้นก็ไม่ใช่สัญญาณที่มีนัยสำคัญ แต่มันคือความ UNSTABLE (ไม่เสถียร)

ผลลัพธ์ที่ UNSTABLE ควรเป็นผลลัพธ์สำคัญใน CI/CD pipeline ของคุณ และมันควรจะแจ้งเตือนความล้มเหลวอย่างชัดเจน (fail loud)

ในการแก้ไขการประเมินผลที่ไม่เสถียร คุณต้องมีสองสิ่งนี้:

  1. เลเยอร์การให้คะแนน (A scoring layer): ทำหน้าที่คำนวณความเสถียรและเปลี่ยนผลลัพธ์ให้เป็น PASS, FAIL หรือ UNSTABLE
  2. เลเยอร์การติดตาม (A tracing layer): คุณต้องสามารถเห็นข้อมูลดิบ (raw bytes), prompt ที่แม่นยำ และผลลัพธ์จากเครื่องมือ (tool outputs) ในทุกๆ รอบการรัน

หากไม่มีการติดตาม (traces) คุณจะคิดว่าโมเดลแค่สุ่มไปเรื่อยๆ คุณจะลดค่า temperature ลงแล้วคิดว่าคุณแก้ปัญหาได้แล้ว แต่คุณไม่ได้แก้เลย คุณแค่ทำให้บั๊กนั้นเงียบลงเท่านั้นเอง

ปฏิบัติตามกฎเหล่านี้เพื่อสร้างคุณภาพที่แท้จริง:

  • รายงานความสอดคล้อง (agreement) ไม่ใช่แค่ค่าเฉลี่ย
  • กำหนดให้ UNSTABLE เป็นสถานะที่ล้มเหลวใน pipeline ของคุณ
  • ล็อกเวอร์ชันของโมเดลผู้ตัดสิน (Pin your judge model versions)
  • อ่าน traces เมื่อการตรวจสอบล้มเหลว

แดชบอร์ดสีเขียวที่คุณไม่สามารถทำซ้ำได้ไม่ใช่สัญญาณ แต่มันคือเรื่องราวที่คุณสร้างขึ้นมาหลอกตัวเอง

Source: https://dev.to/saurav_bhattacharya/your-evals-are-flaky-too-stop-trusting-a-pass-rate-you-cant-reproduce-6pk

Optional learning community: https://t.me/GyaanSetuAi