การประเมิน AI Agent: เกณฑ์มาตรฐาน เมตริก และการทดสอบ

การประเมิน AI Agent คือการวัดอย่างเป็นระบบว่า agent ทำงานได้ถูกต้อง เรียกใช้เครื่องมืออย่างปลอดภัย และอยู่ภายในงบประมาณด้านต้นทุนและ latency ตลอดการ trace การทำงานหลายขั้นตอน ไม่ใช่แค่การเรียก LLM ครั้งเดียว เกณฑ์มาตรฐานแบบ single-turn ที่ออกแบบมาสำหรับ language model ไม่สามารถจับรูปแบบความล้มเหลวสะสมที่เกิดขึ้นในระบบ agentic ได้ อัตราความสำเร็จ 90% ต่อขั้นตอนจะลดลงเหลือประมาณ 59% เมื่อผ่านการเรียกเครื่องมือแบบต่อเนื่อง 5 ครั้ง

การประเมิน AI Agent คือสาขาวิชาการทดสอบซอฟต์แวร์ที่ประเมินระบบ AI อัตโนมัติในมิติต่างๆ ได้แก่ อัตราการทำงานสำเร็จ ความถูกต้องของการเรียกเครื่องมือ ประสิทธิภาพความยาว trajectory การปฏิบัติตาม safety rail และต้นทุนต่องานที่ทำสำเร็จ โดยใช้ชุดเกณฑ์มาตรฐาน การเล่นซ้ำ trace ที่บันทึกไว้ และ LLM-as-judge grader

เหตุใดเกณฑ์มาตรฐาน LLM แบบ single-turn จึงล้มเหลวสำหรับ agent

ข้อผิดพลาดสะสมใน tool chain หลายขั้นตอน

เกณฑ์มาตรฐานแบบ single-turn เช่น MMLU วัดความแม่นยำแบบ one-shot บนคำถามที่แยกกัน Agent ทำงานแตกต่างกัน: การเรียกเครื่องมือแต่ละครั้งขึ้นอยู่กับผลลัพธ์ก่อนหน้า และข้อผิดพลาดจะสะสม ที่ความน่าเชื่อถือ 90% ต่อขั้นตอน tool chain ห้าขั้นตอนจะทำงานสำเร็จโดยไม่มีข้อผิดพลาดเพียง 59% เท่านั้น (0.9⁵ ≈ 0.59) ที่ 80% จะลดลงเหลือ 33%

ไดนามิกสะสมนี้หมายความว่า agent ที่ดูยอมรับได้บนเมตริกระดับขั้นตอนอาจไม่น่าเชื่อถือในการใช้งานจริงแบบ end-to-end การวัดที่มีความหมายเพียงอย่างเดียวคืออัตราการทำงานสำเร็จในระดับ trajectory

การปรับใช้ Task-Pass@k

Pass@k ถูกนำมาใช้ใน HumanEval (2021) เพื่อวัดการสร้างโค้ด สำหรับ agent หลักการเดียวกันนี้ใช้ที่ระดับ trajectory pass@1 ต่ำที่มี pass@3 สูงเป็นสัญญาณความล้มเหลวเฉพาะ: agent สามารถแก้ปัญหาได้แต่ไม่น่าเชื่อถือ

สิ่งที่ MMLU และ HumanEval ขาด

MMLU ทดสอบการจดจำข้อเท็จจริง HumanEval ทดสอบการสร้างโค้ดระดับฟังก์ชันแยก ไม่มีตัวใดทดสอบสิ่งที่ agent จริงๆ ทำ: การใช้เหตุผลหลายขั้นตอนด้วยผลลัพธ์เครื่องมือจริง การกู้คืนจากข้อผิดพลาด และการจัดการต้นทุนตลอด trajectory ที่ยาว

มุมมองของ OpenLegion: สี่มิติการประเมินที่สำคัญ

OWASP LLM08:2025 (Excessive Agency) ระบุการทดสอบพฤติกรรม agent ที่ไม่เพียงพอเป็นสาเหตุหลักของผลข้างเคียงที่ไม่ตั้งใจในระบบ agentic

openai/evals (18,604 GitHub stars, MIT-adjacent) คือ registry เกณฑ์มาตรฐาน LLM แบบ open-source ที่ใหญ่ที่สุด ครอบคลุมการประเมินระดับโมเดล ไม่ใช่การให้คะแนน trajectory ระดับ agent

LLM-as-judge (เป็นที่นิยมโดย MT-Bench 2023) นำเสนอ positivity bias สูงถึง 20% เมื่อโมเดล judge และโมเดลที่ถูกทดสอบมี base weight เดียวกัน ใช้ตระกูลโมเดลที่แตกต่างกันเป็น judge เพื่อผลการประเมินที่น่าเชื่อถือ

ความถูกต้องของการเรียกเครื่องมือและการตรวจสอบผลข้างเคียง

บันทึกการเรียกเครื่องมือทุกครั้งที่ agent ทำระหว่าง eval run: ชื่อเครื่องมือ argument ค่าที่ส่งกลับ และการดำเนินการที่ตามมา เปรียบเทียบกับ golden trajectory

ต้นทุนต่องานและงบประมาณ latency

Agent ที่ทำงานได้ถูกต้องแต่ต้องการ 47 การเรียก LLM เพื่อทำสิ่งที่ agent ที่ออกแบบดียิ่งทำได้ใน 8 ครั้งยังไม่พร้อมสำหรับการใช้งานจริง วัด token ที่ใช้และเวลาจริงต่องานที่เสร็จสิ้น

การประเมินความปลอดภัย: การจัดการ credential และการต้านทาน injection

การประเมินความปลอดภัยสมควรมีชุดทดสอบของตัวเอง ตรวจสอบว่า agent ไม่บันทึก credential ใน argument การเรียกเครื่องมือ ไม่ทำตามคำสั่งที่ฝังอยู่ใน output เครื่องมือที่เป็นภัย และไม่ดำเนินการที่ย้อนกลับไม่ได้นอกขอบเขตงาน

ชุดเกณฑ์มาตรฐานสำหรับ AI Agent

openai/evals: baseline ระดับโมเดล (18,604 stars)

openai/evals (18,604 GitHub stars, MIT-adjacent) คือ registry เกณฑ์มาตรฐานเปิดที่ใหญ่ที่สุดสำหรับการประเมิน LLM มีประโยชน์เป็น baseline คุณภาพโมเดล แต่ไม่ทดสอบการใช้เครื่องมือหลายขั้นตอนหรือการทำงาน agentic สำเร็จ

trycua/cua: เกณฑ์มาตรฐาน computer-use agent (17,633 stars)

trycua/cua (17,633 GitHub stars, MIT) ให้สภาพแวดล้อม sandbox สำหรับประเมิน agent การใช้คอมพิวเตอร์ที่ควบคุม desktop macOS, Linux และ Windows

microsoft/promptflow: โหนดประเมินคุณภาพ LLM app (11,142 stars)

microsoft/promptflow (11,142 GitHub stars, MIT) รวมโหนดประเมินในตัวสำหรับให้คะแนน output ของ LLM application: groundedness, relevance และ fluency

IBM/AssetOpsBench: การประเมิน MCP สถานการณ์อุตสาหกรรม 460+ รายการ (1,704 stars)

IBM/AssetOpsBench (1,704 GitHub stars, Apache-2.0) ให้กรณีการประเมินสถานการณ์อุตสาหกรรมมากกว่า 460 รายการสำหรับ agent ที่ทำงานบน Model Context Protocol

วิธีการประเมิน

การจับคู่แน่นอนและ programmatic grader

Grader การจับคู่แน่นอนเปรียบเทียบ output ของ agent กับค่าที่คาดหวังที่กำหนดไว้ล่วงหน้า มีความแน่นอน รวดเร็ว และปราศจาก bias ของโมเดล judge

LLM-as-judge: ความเสี่ยง bias และการลดผลกระทบ

LLM-as-judge ใช้ language model ให้คะแนน output ของ agent เทียบกับ rubric ความเสี่ยง bias ถูกวัดปริมาณ: positivity bias สูงถึง 20% เพิ่มคะแนนการประเมินเมื่อ judge และวัตถุมี base weight เดียวกัน

การลดผลกระทบ: ใช้โมเดล judge จากผู้ให้บริการหรือสายการฝึกอบรมที่แตกต่างกัน, ให้ rubric การให้คะแนนที่ชัดเจนพร้อมเกณฑ์ผ่าน/ไม่ผ่านที่เป็นรูปธรรม, ปรับเทียบคะแนน judge เทียบกับตัวอย่างที่มนุษย์ติดป้ายกำกับ

การให้คะแนน trajectory และความถูกต้องระดับขั้นตอน

การให้คะแนน trajectory ประเมินลำดับการดำเนินการทั้งหมดที่ agent ทำเพื่อทำงานให้เสร็จ เมตริกระดับขั้นตอน: ความแม่นยำในการเลือกเครื่องมือ ความถูกต้องของ argument ประสิทธิภาพ trajectory การกู้คืนข้อผิดพลาด ความแม่นยำในการสิ้นสุด

harness input ที่เป็นภัย

การประเมินที่เป็นภัยทดสอบพฤติกรรมของ agent ภายใต้ input ที่ออกแบบมาเพื่อกระตุ้นพฤติกรรมที่ไม่ปลอดภัยหรือไม่ถูกต้อง: prompt injection ผ่าน output เครื่องมือ, response เครื่องมือที่ผิดรูปแบบ, การทดสอบขอบเขต scope, การตรวจจับการเปิดเผย credential

การสร้าง pipeline การประเมิน agent

การออกแบบชุดข้อมูลการประเมินสำหรับงาน agentic

ชุดข้อมูลการประเมิน agent ที่ดีประกอบด้วย: input งาน, ลำดับการเรียกเครื่องมือที่คาดหวัง, เกณฑ์ความสำเร็จ และ metadata เริ่มต้นด้วย 50-100 งานที่ครอบคลุม use case หลัก

การเล่นซ้ำ trace และการทดสอบ regression

การเล่นซ้ำ trace รัน eval dataset กับ agent, จับ trace การทำงานทั้งหมด และเปรียบเทียบกับ golden trace การทดสอบ regression แจ้งเตือนเมื่องานที่ผ่านในเวอร์ชันก่อนหน้าล้มเหลวในเวอร์ชันปัจจุบัน

การรวม CI: บล็อกการ deploy เมื่อ eval regression

รวมการประเมิน agent เข้ากับ pipeline CI เพื่อบล็อกการ deploy เมื่อคุณภาพลดลง บล็อกการ deploy หากอัตราการทำงานสำเร็จลดลงมากกว่า 5% โดยสัมบูรณ์หรือหากกรณีทดสอบความปลอดภัยใดๆ กลับไปล้มเหลว

การเปรียบเทียบเครื่องมือประเมิน

มิติ	openai/evals	trycua/cua	promptflow eval	IBM/AssetOpsBench
ขอบเขตการประเมิน	LLM single-turn	Desktop computer-use	คุณภาพ LLM app	Multi-role MCP agent
วิธีให้คะแนน	Exact match, LLM-judge	Environment execution	LLM-judge nodes	Programmatic + LLM-judge
รองรับ agent trajectory	ไม่	ใช่ (full desktop session)	บางส่วน (flow-level)	ใช่ (4-role workflow)
การทดสอบความปลอดภัย	ไม่	ไม่	ไม่	บางส่วน
การรวม CI	ผ่าน CLI	ผ่าน SDK	Native ใน PromptFlow	Manual
ใบอนุญาต	MIT-adjacent	MIT	MIT	Apache-2.0
GitHub stars	18,604	17,633	11,142	1,704

คำถามที่พบบ่อย

การประเมิน AI Agent คืออะไร?

การประเมิน AI Agent วัดว่า agent ทำงานหลายขั้นตอนได้ถูกต้อง เรียกใช้เครื่องมือด้วย argument ที่ถูกต้อง อยู่ภายในงบประมาณด้านต้นทุนและ latency และหลีกเลี่ยงพฤติกรรมที่ไม่ปลอดภัย เช่น การรั่วไหลของ credential หรือ prompt injection หรือไม่

ใช้เกณฑ์มาตรฐานใดในการประเมิน AI Agent?

framework ทั่วไป ได้แก่ openai/evals (18,604 GitHub stars, ระดับโมเดล), trycua/cua (17,633 GitHub stars, MIT, งาน desktop computer-use), โหนดประเมิน microsoft/promptflow (11,142 GitHub stars, MIT, คุณภาพ LLM app) และ IBM/AssetOpsBench (1,704 GitHub stars, Apache-2.0, สถานการณ์ MCP อุตสาหกรรม 460+)

การประเมิน LLM-as-judge คืออะไรและมีความเสี่ยงใดบ้าง?

LLM-as-judge ใช้ language model แยกต่างหากให้คะแนน output ของ agent เทียบกับ rubric ความเสี่ยงหลัก: positivity bias สูงถึง 20% เพิ่มคะแนนเมื่อ judge และวัตถุมี base weight เดียวกัน ใช้ตระกูลโมเดลที่แตกต่างกันเป็น judge เพื่อผลลัพธ์ที่น่าเชื่อถือ

pass@k ทำงานอย่างไรสำหรับการประเมิน agent?

Pass@k วัดความน่าจะเป็นที่อย่างน้อยหนึ่งในการรัน agent k ครั้งที่เป็นอิสระจะทำงานสำเร็จได้อย่างถูกต้อง pass@1 ต่ำที่มี pass@3 สูงบ่งชี้การทำงานที่ไม่ได้กำหนดซึ่งควรตรวจสอบก่อน deploy ใช้งานจริง

จะประเมินความปลอดภัยของ agent และการจัดการ credential อย่างไร?

การประเมินความปลอดภัยทดสอบว่า agent รั่ว credential ใน argument การเรียกเครื่องมือ ตอบสนองต่อ prompt injection ที่เป็นภัยใน output เครื่องมือ หรือสร้างผลข้างเคียงที่ย้อนกลับไม่ได้นอกขอบเขตหรือไม่ OWASP LLM08:2025 (Excessive Agency) บันทึกรูปแบบความล้มเหลวนี้เป็นช่องโหว่ LLM top-10

จะรวมการประเมิน agent เข้ากับ CI/CD อย่างไร?

บันทึก golden eval dataset พร้อม input งาน ลำดับการเรียกเครื่องมือที่คาดหวัง และ output สุดท้าย ในแต่ละ commit เล่นซ้ำชุดข้อมูลกับ agent ที่อัปเดตและเปรียบเทียบคะแนน trajectory กับ baseline ก่อนหน้า บล็อกการ deploy หากอัตราการทำงานสำเร็จลดลงมากกว่า 5% โดยสัมบูรณ์หรือหากการทดสอบความปลอดภัยใดๆ กลับถอยหลัง

OpenLegion รองรับการประเมิน agent อย่างไร?

mesh ของ agent ใน OpenLegion ส่ง trace การเรียกเครื่องมือที่มีโครงสร้างซึ่งสามารถเล่นซ้ำกับ eval harness ได้ credential vault รับรองว่า eval run ใช้ credential ที่แยกกัน agent ประเมินที่ขับเคลื่อนด้วย heartbeat สามารถรัน regression suite ตามกำหนดการได้

ประเมิน agent ของคุณใน mesh ที่ปลอดภัย

agent ที่น่าเชื่อถือต้องการโครงสร้างพื้นฐานการประเมินที่ทดสอบ trajectory การทำงานทั้งหมด ปัญหาข้อผิดพลาดสะสมเป็นเรื่องจริง: อัตราความน่าเชื่อถือต่อขั้นตอน 90% หมายความว่า agent ห้าขั้นตอนล้มเหลวใน 41% ของการรัน

เริ่มสร้าง agent ที่ผ่านการประเมินบน OpenLegion