Evals: วัดผล AI Agent ก่อนปล่อยใช้งานจริง

เรียนรู้คำศัพท์และกลไกของ Evals, 3 แบบของ grader, ความต่างของ pass@k กับ pass^k และวิธีเริ่มชุดทดสอบแรกจากเคสจริง

ทีมบริการลูกค้าของบริษัทประกันแห่งหนึ่งสร้าง AI Agent คัดแยกเรื่องร้องเรียน ทดลองกับตัวอย่าง 5 เคส ผ่านหมด ทุกคนตื่นเต้น เปิดใช้จริงสัปดาห์แรก เคสเคลมรถถูกส่งไปคิวประกันสุขภาพ ลูกค้ารอเก้อหลายวัน ปัญหาไม่ได้อยู่ที่ Agent อย่างเดียว แต่อยู่ที่ทีมไม่มี Evals ที่ดีพอจะบอกได้ว่ามันพร้อมหรือยัง

Evals คืออะไร

Evals (evaluations) คือชุดทดสอบที่วัดว่า AI Agent ทำงานได้ดีแค่ไหนอย่างเป็นระบบ ทำซ้ำได้ และเปรียบเทียบได้ทุกครั้งที่คุณแก้ prompt เปลี่ยนโมเดล หรือเพิ่มเครื่องมือ ต่างจากการ "ลองเล่นดูแล้วรู้สึกว่าดี" ตรงที่ผลออกมาเป็นตัวเลขและหลักฐาน

บทความ Demystifying evals for AI agents ของ Anthropic (มกราคม 2026) วางคำศัพท์พื้นฐานไว้ดังนี้

• Task: โจทย์ทดสอบหนึ่งข้อ มี input และเกณฑ์ความสำเร็จ
• Trial: การลองทำหนึ่งครั้ง ต้องลองหลายครั้งเพราะผลของ AI ไม่เหมือนเดิมทุกรอบ
• Grader: ตรรกะที่ให้คะแนน
• Transcript: บันทึกทั้งหมดของ trial รวมการเรียก tool และเหตุผลระหว่างทาง
• Outcome: สถานะสุดท้ายของระบบจริง เช่น มีการจองอยู่ในฐานข้อมูลจริงไหม ไม่ใช่แค่ Agent พูดว่าจองแล้ว

3 แบบของ Grader

Code-based

ตรวจด้วยโค้ด เช่น เช็กว่า ticket ถูกย้ายไปคิวที่ถูกต้องในฐานข้อมูล ข้อดีคือเร็ว ถูก และวัดซ้ำได้ตรงกัน ข้อเสียคือเข้มงวดเกินไปกับคำตอบที่ถูกแต่หน้าตาต่าง

Model-based

ให้ LLM อีกตัวให้คะแนนตาม rubric ยืดหยุ่นและรับงานปลายเปิดได้ แต่ผลไม่คงที่และต้องเทียบกับคนตรวจเป็นระยะ ตัวอย่างจริงคือระบบ Research ของ Anthropic ที่ใช้ LLM ให้คะแนนด้านความถูกต้องของข้อเท็จจริง ความถูกต้องของการอ้างอิง ความครบถ้วน คุณภาพแหล่งข้อมูล และประสิทธิภาพการใช้ tool

Human

ผู้เชี่ยวชาญตรวจเอง แม่นที่สุดและใช้ปรับเทียบ grader แบบโมเดล แต่ช้าและแพง

ตัวอย่าง: โจทย์หนึ่งข้อของ Agent ประกัน

Input คือข้อความลูกค้า "รถโดนชนท้ายที่แยกอโศก อยากเคลม" Grader แบบโค้ดเช็กว่า ticket อยู่ในคิวเคลมรถยนต์จริงในระบบ ส่วน Grader แบบโมเดลเช็กว่าข้อความตอบกลับสุภาพและบอกเอกสารที่ต้องเตรียมครบ ใช้สองแบบคู่กันจะได้ทั้งความแม่นและความยืดหยุ่น

pass@k กับ pass^k: ตัวเลขที่หลายทีมมองข้าม

pass@k คือโอกาสที่อย่างน้อยหนึ่งใน k ครั้งทำสำเร็จ ส่วน pass^k คือโอกาสที่ ทุกครั้ง ใน k ครั้งสำเร็จ Anthropic ยกตัวอย่างว่า ถ้าแต่ละครั้งสำเร็จ 75% โอกาสที่ 3 ครั้งติดสำเร็จทั้งหมดจะเหลือประมาณ 42%

ตัววัด pass^k ถูกเสนอในงานวิจัย τ-bench (Yao และคณะ, 2024) ที่จำลองงานบริการลูกค้าซึ่ง Agent ต้องคุยกับผู้ใช้และทำตามนโยบาย งานวิจัยรายงานว่า pass^8 ของ Agent ที่ใช้ gpt-4o ในโดเมนค้าปลีกลดลงต่ำกว่า 25% สำหรับงานที่ลูกค้าเจอทุกวัน ความสม่ำเสมอสำคัญกว่าการทำได้ "บางครั้ง"

Capability evals กับ Regression evals

• Capability: ถามว่า Agent ทำอะไรได้ดี ควรเริ่มจากคะแนนต่ำ เพื่อมีพื้นที่ให้พัฒนา
• Regression: ถามว่ายังทำสิ่งที่เคยทำได้อยู่ไหม ควรอยู่ใกล้ 100% เพื่อจับการถดถอยหลังแก้ระบบ

โจทย์ capability ที่ผ่านสม่ำเสมอแล้วสามารถย้ายไปเป็นชุด regression ได้

ข้อควรระวัง

• ตรวจเส้นทางแทนผลลัพธ์: Anthropic เตือนว่าการบังคับลำดับการเรียก tool แบบตายตัวเปราะเกินไป เพราะ Agent มักหาทางที่ถูกแต่ไม่ตรงกับที่คุณคิด ให้ตรวจสิ่งที่ Agent ทำได้จริง
• เชื่อคะแนนโดยไม่อ่าน transcript: บางครั้ง Agent ไม่ได้ผิด แต่ grader ตัดสินผิด
• ลืมคนจริง: แม้มี eval อัตโนมัติ Anthropic ยังพบว่าการทดสอบโดยคนจำเป็นสำหรับจับกรณีขอบที่ eval มองไม่เห็น

เดโมที่ผ่าน 5 เคสพิสูจน์ว่ามันทำได้ Evals พิสูจน์ว่ามันทำได้ทุกวัน

เริ่มต้นยังไง

1. รวบรวมโจทย์ 20 ถึง 50 ข้อจากเคสจริง โดยเฉพาะเคสที่เคยผิด ตามที่ Anthropic แนะนำ
2. เขียนเกณฑ์ "สำเร็จ" ของแต่ละข้อให้ตรวจได้ ถ้าเป็นไปได้ให้ตรวจที่ outcome ในระบบจริง
3. รันแต่ละข้อหลายครั้ง แล้วดูทั้ง pass@k และ pass^k
4. อ่าน transcript ของเคสที่ตกทุกครั้ง แยกว่า Agent ผิดหรือ grader ผิด
5. รันชุด regression ทุกครั้งก่อนปล่อยเวอร์ชันใหม่

ทักษะออกแบบ Evals ใช้ได้ทั้งในสาย AI, QA และ Product ถ้าคุณอยากรู้ว่าประสบการณ์ที่มีต่อยอดไปตำแหน่งไหนได้ ลองคุยกับ AI Career Assistant หรือทบทวนพื้นฐานใน Agent พังเพราะอะไร เพื่อเอาไปเขียนโจทย์ทดสอบ