วิธีประเมินเอเจนต์ AI: ชุดทดสอบ ตัวให้คะแนน และการตรวจสอบรีเกรสชัน

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

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

การประเมินเอเจนต์ AI หมายถึงอะไร?

การประเมินเอเจนต์ AI หมายถึงการประเมินประสิทธิภาพในการทำงานให้สำเร็จอย่างถูกต้อง และพิจารณาว่าการตัดสินใจของเอเจนต์เป็นไปตามข้อกำหนดขององค์กรหรือไม่ ในทางปฏิบัติ การประเมินเอเจนต์ AI หรือ evals คือตัวชี้วัดเฉพาะที่ช่วยให้องค์กรตัดสินได้ว่าเอเจนต์ทำงานได้น่าเชื่อถือเพียงพอสำหรับบทบาทที่กำหนดไว้หรือไม่

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

และหากคุณเปลี่ยนพรอมต์ระบบของเอเจนต์เพื่อแก้ปัญหานั้น คุณจะรู้ได้อย่างไรว่าไม่ได้ทำให้เกิดปัญหาใหม่ขึ้นมาอีก?

หากไม่มีการประเมิน ผู้จัดการผลิตภัณฑ์ก็แทบจะต้องคาดเดาเอาเอง ดังนั้น evals จึงเป็นสัญญาณป้อนกลับสำหรับวัดประสิทธิภาพ ระบุปัญหาที่เกิดซ้ำ และทดสอบการเปลี่ยนแปลงได้อย่างมั่นใจมากขึ้น

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

• คุณภาพของผลลัพธ์สุดท้าย
• ข้อมูลที่เอเจนต์ใช้
• เครื่องมือที่เอเจนต์เรียกใช้
• เอเจนต์ปฏิบัติตามกฎที่กำกับพฤติกรรมของตนหรือไม่

ตัวชี้วัดทั่วไปในการประเมินเอเจนต์ AI

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

ต่อไปนี้คือรายการตัวชี้วัดพื้นฐานในการประเมินเอเจนต์ AI:

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

ขึ้นอยู่กับสิ่งที่คุณต้องการวัด evals สามารถประเมินประสิทธิภาพของเอเจนต์แบบครบวงจร (end-to-end) เส้นทางการดำเนินการ (trajectory) หรือองค์ประกอบแต่ละส่วน เช่น การเรียกใช้เครื่องมือและขั้นตอนการดึงข้อมูล

ขั้นตอนที่ 1: กำหนดว่าการรันเอเจนต์ที่ประสบความสำเร็จมีลักษณะอย่างไร

ก่อนอื่น ให้อธิบายอย่างชัดเจนว่าเอเจนต์ควรทำอะไรให้สำเร็จ ซึ่งก็คือข้อกำหนดของผลิตภัณฑ์ ฟังดูเป็นเรื่องที่ชัดเจนอยู่แล้ว แต่กลับทำได้ยากอย่างน่าประหลาดใจ ถึงขั้นมีชื่อเรียกเฉพาะว่า ช่องว่างของข้อกำหนด (specification gap)

ต่อไปนี้คือแนวทางตามคำแนะนำของ Andrey Khomutov นักวิทยาศาสตร์ข้อมูลอาวุโสของเรา:

“เริ่มต้นด้วยคำถามสองข้อ: “อะไรบ้างที่นับว่าทำงานสำเร็จ?” และ “อะไรที่ทำให้การรันที่ดูเหมือนสำเร็จกลายเป็นสิ่งที่ยอมรับไม่ได้?”

ในทางเทคนิค สำหรับเอเจนต์ นั่นหมายถึงการตรวจสอบทั้งผลลัพธ์และวิธีที่เอเจนต์ไปถึงผลลัพธ์นั้น”

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

“ผมคาดว่าการตรวจสอบเส้นทางการดำเนินการ (trajectory inspection)จะกลายเป็นส่วนมาตรฐานของชุด eval สำหรับเอเจนต์ แทนที่จะเป็นสิ่งที่เราทำเฉพาะเมื่อผลลัพธ์ดูน่าสงสัยเท่านั้น” เขากล่าวเสริม

จากนั้น ให้ผู้เชี่ยวชาญเฉพาะด้านเข้ามาช่วยตรวจสอบเกณฑ์ความสำเร็จของคุณ ผู้ที่มีความรู้จากประสบการณ์ตรงในสาขานั้นสามารถบอกได้ว่าเงื่อนไขที่เรากำหนดให้เอเจนต์ AI สะท้อนถึงผลลัพธ์ที่ประสบความสำเร็จจริงหรือไม่

ขั้นตอนที่ 2. สร้างชุดทดสอบจากงานและความล้มเหลวที่เกิดขึ้นจริง

ตรวจสอบพฤติกรรมจริงของเอเจนต์เพื่อทำความเข้าใจว่าประสิทธิภาพที่ดีและไม่ดีมีลักษณะอย่างไร อย่าเพิ่งเริ่มต้นด้วยการสร้างการทดสอบหลายสิบรายการโดยอิงเพียงสิ่งที่คุณคิดว่าอาจผิดพลาด

Hamel Husain วิศวกร ML ที่ Parlance Lab และ Shreya Shankar นักวิจัยด้านระบบ ML และ evals สำหรับ AI ประยุกต์ แนะนำให้เริ่มต้นด้วยการวิเคราะห์ข้อผิดพลาด (error analysis) ซึ่งเป็นเทคนิคที่ยืมมาจากแมชชีนเลิร์นนิงและวิทยาการข้อมูล กระบวนการนี้เริ่มจากการวิเคราะห์เชิงคุณภาพของเทรซการดำเนินการ (execution trace)ของเอเจนต์ ซึ่งเป็นบันทึกที่แสดงอินพุตของผู้ใช้ การเรียกใช้เครื่องมือ ข้อมูลที่ดึงมา และเอาต์พุตของเอเจนต์

1. ตรวจสอบเทรซทีละรายการและบันทึกข้อผิดพลาด (open coding) ให้ผู้เชี่ยวชาญเฉพาะด้านตรวจสอบการรันของเอเจนต์ และเขียนข้อสังเกตสั้นๆ ว่าเกิดอะไรผิดพลาด โดยมุ่งไปที่ข้อผิดพลาดสำคัญจุดแรก
2. จัดกลุ่มข้อสังเกตเป็นรูปแบบความล้มเหลว (axial coding) เมื่อมีบันทึกเพียงพอแล้ว ให้ใช้ LLM ช่วยเสนอหมวดหมู่สำหรับข้อผิดพลาดที่คล้ายกัน ซึ่งอาจรวมถึงการแนะนำอะไหล่ที่เข้ากันไม่ได้ การดึงข้อมูลสินค้าคงคลังที่ไม่ถูกต้อง และการส่งต่องานให้มนุษย์ที่ล้มเหลว
3. นับจำนวนครั้งที่เกิดขึ้น จัดข้อสังเกตแต่ละข้อเข้าหมวดหมู่ จากนั้นใช้สเปรดชีตหรือตาราง Pivot เพื่อคำนวณว่ารูปแบบความล้มเหลวแต่ละแบบเกิดขึ้นบ่อยเพียงใด
4. จัดลำดับความสำคัญของสิ่งที่ต้องแก้ไข โดยพิจารณาทั้งความถี่และความรุนแรง
5. เปลี่ยนความล้มเหลวที่สำคัญให้เป็นกรณีทดสอบ บันทึกอินพุตที่เกี่ยวข้อง เงื่อนไขเริ่มต้น ผลลัพธ์ที่คาดหวัง และเกณฑ์การให้คะแนน เพื่อให้สามารถทดสอบเอเจนต์กับสถานการณ์เดิมได้อีกครั้ง

ควรตรวจสอบเทรซกี่รายการ? ประมาณ 100 รายการ แต่ไม่มีตัวเลขตายตัว ให้หยุดก่อนได้เมื่อถึงจุดอิ่มตัวเชิงทฤษฎี (theoretical saturation) ซึ่งเป็นจุดที่การตรวจสอบเทรซเพิ่มเติมไม่เผยให้เห็นรูปแบบความล้มเหลวใหม่ที่มีนัยสำคัญอีกต่อไป

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

การใช้เบนช์มาร์กในการประเมินเอเจนต์ AI

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

แต่เบนช์มาร์กก็ไม่ได้ไร้ข้อผิดพลาด การตรวจสอบ SWE-bench การทบทวนเบนช์มาร์กของ Epoch AI และคำตอบที่ถูกต้องซึ่งถูกปฏิเสธในตอนแรกใน TheoPhysEval แสดงให้เห็นว่างานหรือคำตอบที่คาดหวังซึ่งมีข้อบกพร่องสามารถบิดเบือนผลการประเมินได้อย่างไร

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

ขั้นตอนที่ 3. รันเอเจนต์ในสภาพแวดล้อมการทดสอบที่ทำซ้ำได้

สภาพแวดล้อมการทดสอบที่ทำซ้ำได้คือการตั้งค่าแบบควบคุม ซึ่งคุณสามารถรันเอเจนต์ AI กับกรณีทดสอบชุดเดิมภายใต้เงื่อนไขเริ่มต้นเดียวกัน แล้วเปรียบเทียบผลลัพธ์ได้ ซึ่งรวมถึงโฟลเดอร์ของกรณีทดสอบ สคริปต์ Python ที่ใช้รันเอเจนต์ หรือชุดการตรวจสอบที่ใช้ประเมินผลลัพธ์

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

ขยาย

ทำตามขั้นตอนต่อไปนี้เพื่อตั้งค่าสภาพแวดล้อมการทดสอบที่ทำซ้ำได้:

1. บันทึกอินพุตที่เป็นตัวแทน จัดเก็บเหตุการณ์จริงหรือกรณีทดสอบในโครงสร้างเดียวกับที่แอปพลิเคชันของคุณได้รับในระบบใช้งานจริง ในสถานการณ์ของเรา คุณจะบันทึกคำขอซ่อมบำรุงที่มีรหัสเครื่องจักร อะไหล่ที่ต้องใช้ และวันที่ซ่อมบำรุงเป็นไฟล์ JSON พร้อมกับสแนปช็อตของข้อมูลสินค้าคงคลังและข้อมูลอะไหล่ที่ได้รับอนุมัติ
2. ดำเนินการเวิร์กโฟลว์ รันอินพุตแต่ละรายการผ่านเอเจนต์ ซึ่งรวมถึงขั้นตอนการดึงข้อมูล การเรียกใช้เครื่องมือ และการสร้างคำตอบ
3. บันทึกผลลัพธ์และเทรซ เก็บเอาต์พุตสุดท้ายและการดำเนินการระหว่างทางที่เกี่ยวข้อง (เช่น การค้นหาข้อมูลสินค้าคงคลัง) เพื่อให้คุณเห็นไม่เพียงแค่ว่าเอเจนต์ล้มเหลวหรือไม่ แต่ยังเห็นว่าล้มเหลวที่จุดใด
4. รันกรณีทดสอบซ้ำตามความรุนแรงของความล้มเหลว ความถี่ และความยากในการแก้ไขปัญหา แอปพลิเคชัน LLM มีลักษณะไม่เป็นเชิงกำหนด (nondeterministic) กล่าวคือ อาจให้ผลลัพธ์ต่างกันจากอินพุตที่เหมือนกัน ดังนั้นการรันที่สำเร็จหนึ่งครั้งจึงไม่ได้รับประกันว่าครั้งต่อไปจะสำเร็จด้วย ให้รายงานสัดส่วนของการทดลองที่สำเร็จและตรวจสอบกรณีที่ล้มเหลว

สำหรับกรณีหลัง Khomutov แนะนำให้วัด pass@1 (ความถี่ที่เอเจนต์ทำสำเร็จในการพยายามครั้งเดียว) และ pass@k (ความน่าจะเป็นที่จะสำเร็จอย่างน้อยหนึ่งครั้งจากจำนวนครั้งที่กำหนด) หากรายงาน pass@k ให้ระบุจำนวนครั้งที่พยายามด้วย เนื่องจากการได้คำตอบที่ถูกต้องหนึ่งคำตอบจากหลายคำตอบไม่ได้หมายความว่าเอเจนต์รู้ว่าควรเลือกคำตอบใด

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

ขั้นตอนที่ 4. เลือกตัวให้คะแนนที่เหมาะสมสำหรับการตรวจสอบแต่ละรายการ

ตัวให้คะแนน (grader) หรือที่มักเรียกว่าตัวประเมิน (evaluator) คือกลไกที่อยู่ในรูปของโค้ด LLM ที่ทำงานตามเกณฑ์การให้คะแนน (grading rubric) หรือผู้ตรวจสอบที่เป็นมนุษย์ ซึ่งจะตรวจสอบเอาต์พุตหรือการดำเนินการของเอเจนต์เทียบกับเกณฑ์ที่กำหนดไว้ ตัวให้คะแนนจะส่งคืนผลการตัดสินแบบผ่าน/ไม่ผ่าน พร้อมคำอธิบายที่ระบุหลักฐานที่เกี่ยวข้อง

ข้อมูลเพิ่มเติม: เกณฑ์การให้คะแนนคือชุดหลักเกณฑ์และคำแนะนำที่กำหนดว่าผลลัพธ์แบบใดถือว่าถูกต้องหรือยอมรับได้

ประเภทของตัวให้คะแนนที่เหมาะสมขึ้นอยู่กับสิ่งที่คุณต้องการตรวจสอบ ต่อไปนี้คือการเปรียบเทียบทั้งสามแนวทาง:

บางครั้งแง่มุมต่างๆ ของการรันเดียวกันอาจต้องใช้วิธีการประเมินที่แตกต่างกัน คุณจึงอาจต้องใช้ตัวให้คะแนนหลายแบบร่วมกัน

จะใช้ตัวให้คะแนนหลายแบบร่วมกันได้อย่างไร?

ให้ถามว่า “ผลลัพธ์สามารถตรวจสอบเทียบกับกฎที่ทราบหรือค่าที่คาดหวังได้หรือไม่ หรือต้องอาศัยวิจารณญาณแบบมนุษย์?”

• หากคุณตรวจสอบผลลัพธ์ได้อย่างแม่นยำ ให้เริ่มต้นด้วยตัวให้คะแนนแบบใช้โค้ด ตัวให้คะแนนแบบใช้โค้ดยังสามารถตรวจสอบเอาต์พุตที่มีโครงสร้าง ค่าฟิลด์ที่ถูกต้อง อาร์กิวเมนต์ของเครื่องมือ หรือสถานะสุดท้ายของฐานข้อมูลได้ด้วย
• หากการตรวจสอบต้องอาศัยการตีความบริบท ให้ใช้ LLM-as-a-judge
• ใช้ผู้ตรวจสอบที่เป็นมนุษย์สำหรับการตัดสินใจเฉพาะด้านหรือที่มีข้อโต้แย้ง

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

ปรับเทียบตัวให้คะแนนที่เป็น LLM กับการตัดสินของมนุษย์

โดยพื้นฐานแล้ว การปรับเทียบต้องอาศัยผู้เชี่ยวชาญเฉพาะด้านในการประเมินการรันจริงของเอเจนต์ จากนั้นผู้เชี่ยวชาญจะเปรียบเทียบการตัดสินของตนกับของ LLM และปรับปรุงเกณฑ์การให้คะแนนตามจุดที่เห็นไม่ตรงกัน

ต่อไปนี้คือกระบวนการปรับเทียบตัวให้คะแนนห้าขั้นตอน:

1. รวบรวมตัวอย่างอินพุต เอาต์พุต และเทรซที่เกี่ยวข้องของเอเจนต์
2. ให้ผู้เชี่ยวชาญเฉพาะด้านประเมินอย่างอิสระว่าแต่ละตัวอย่างเป็นไปตามเกณฑ์การประเมินหรือไม่
3. รันตัวให้คะแนนที่เป็น LLM กับตัวอย่างเหล่านั้น
4. เปรียบเทียบการตัดสินของมนุษย์และของโมเดล
5. ตรวจสอบจุดที่เห็นไม่ตรงกันและปรับปรุงเกณฑ์การให้คะแนนของตัวให้คะแนนก่อนนำไปทดสอบกับตัวอย่างใหม่

Khomutov ยังเน้นย้ำถึงความสำคัญของการทดสอบความสม่ำเสมอของตัวให้คะแนนที่เป็น LLM แยกต่างหาก:

“ให้ป้อนการรันที่บันทึกไว้และไฟล์ชุดเดียวกันทุกประการให้ตัวให้คะแนนซ้ำหลายครั้ง โดยไม่ต้องรันเอเจนต์ใหม่ วิธีนี้ช่วยให้คุณแยกความแปรปรวนในการทำงานของเอเจนต์ออกจากความแปรปรวนในการให้คะแนนได้”

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

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

ขั้นตอนที่ 5. เปรียบเทียบเวอร์ชันและรันการตรวจสอบการถดถอย

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

นี่คือจุดที่การทดสอบการถดถอยเข้ามามีบทบาท

การทดสอบการถดถอย (regression testing) หมายถึงการรันกรณีทดสอบที่เคยผ่านมาแล้วซ้ำอีกครั้งหลังจากเปลี่ยนพรอมต์ โมเดล หรือเวิร์กโฟลว์ของเอเจนต์ เพื่อให้มั่นใจว่าการเปลี่ยนแปลงนั้นไม่ได้ทำให้เกิดความล้มเหลวใหม่

1. ทำให้ความล้มเหลวเดิมเกิดซ้ำโดยใช้อินพุตที่บันทึกไว้จากชุดทดสอบ
2. ทำการเปลี่ยนแปลงแบบเจาะจงกับพรอมต์ โมเดล หรือเวิร์กโฟลว์
3. รันการทดสอบที่ล้มเหลวซ้ำเพื่อตรวจสอบว่าปัญหาได้รับการแก้ไขแล้วหรือไม่
4. เรียกใช้การทดสอบอื่นๆ เพื่อยืนยันว่าการเปลี่ยนแปลงนั้นไม่ได้ทำให้การทำงานที่เคยทำได้สำเร็จก่อนหน้านี้เสียหาย
5. ตรวจสอบผลลัพธ์ และสืบหาสาเหตุของความล้มเหลวใหม่ๆ ที่เกิดขึ้น

เปรียบเทียบเอเจนต์เวอร์ชันพื้นฐานกับเวอร์ชันที่อัปเดตแล้ว โดยใช้กรณีทดสอบและเกณฑ์การให้คะแนนชุดเดียวกันเพื่อให้ได้ผลลัพธ์ที่แม่นยำ

ขั้นตอนที่ 6: ติดตามประสิทธิภาพของเอเจนต์ AI ในโปรดักชัน

การประเมินเอเจนต์ไม่ได้สิ้นสุดลงเมื่อคุณนำแอปพลิเคชันไปใช้งานจริงแล้ว ดังที่ Husain และ Shankar อธิบายไว้ ตัวประเมินชุดเดียวกับที่คุณใช้ระหว่างการพัฒนายังสามารถนำมาใช้กับข้อมูลจริงในโปรดักชันได้ด้วย เพื่อวัดว่าเอเจนต์ของคุณทำงานได้ดีเพียงใดเมื่อเวลาผ่านไป

สิ่งนี้เรียกว่า การประเมินแบบออนไลน์ ซึ่งเป็นส่วนหนึ่งของกระบวนการติดตามโปรดักชันในภาพรวมที่ช่วยเผยให้เห็นความล้มเหลวที่เกิดซ้ำและความล้มเหลวที่ไม่เคยพบมาก่อน

กระบวนการนี้เป็นแบบวนซ้ำ และประกอบด้วยกิจกรรม 4 อย่างที่ส่งเสริมกันและกัน:

• ใช้ LLM ผู้ตัดสิน (LLM judge) ที่ผ่านการปรับเทียบแล้วกับเทรซในโปรดักชัน สุ่มตัวอย่างการโต้ตอบจริงของเอเจนต์ แล้วนำตัวประเมินที่คุณได้ตรวจสอบความถูกต้องเทียบกับการตัดสินของมนุษย์แล้วมาใช้
• ติดตามอัตราความล้มเหลวเมื่อเวลาผ่านไป ใช้หมวดหมู่ความล้มเหลวที่กำหนดไว้ระหว่างการวิเคราะห์ข้อผิดพลาดเพื่อวัดปริมาณปัญหาที่เกิดซ้ำ
• ตรวจทานเทรซด้วยตนเองอย่างต่อเนื่อง ตัวให้คะแนนอัตโนมัติจะตรวจพบได้เฉพาะปัญหาที่ถูกออกแบบมาให้ระบุเท่านั้น ควรสุ่มตรวจตัวอย่างการโต้ตอบจริงของเอเจนต์ด้วยตนเอง เพื่อค้นหาข้อผิดพลาดใหม่ๆ หรือคำขอที่ผิดปกติจากผู้ใช้
• ใช้การทดสอบ A/B เพื่อวัดผลลัพธ์ทางธุรกิจ (เฉพาะเมื่อเหมาะสม) เปรียบเทียบพรอมต์ โมเดล หรือเวิร์กโฟลว์ที่แตกต่างกัน โดยใช้เมตริกต่างๆ เช่น อัตราการทำงานสำเร็จ ความพึงพอใจของผู้ใช้ และระยะเวลาในการแก้ไขปัญหา กระบวนการนี้ช่วยตัดสินว่าการเปลี่ยนแปลงหนึ่งๆ ช่วยปรับปรุงประสบการณ์การใช้งานผลิตภัณฑ์จริงได้หรือไม่ นอกเหนือไปจากการผ่านการทดสอบแต่ละรายการ

ข้อควรทราบที่สำคัญ: การประเมินไม่จำเป็นต้องสมบูรณ์แบบไร้ที่ติ เพียงแค่ต้องดีพอที่จะช่วยปรับปรุงผลิตภัณฑ์ของคุณได้

ความเข้าใจผิดที่พบบ่อยในการประเมินเอเจนต์ AI

• การประเมินก็เป็นแค่ unit test ไม่ใช่เลย unit test คือการตรวจสอบอัตโนมัติขนาดเล็กซึ่งเป็นเพียงส่วนหนึ่งของการประเมิน การประเมินยังครอบคลุมถึงการวิเคราะห์ข้อผิดพลาดเชิงคุณภาพ การตัดสินโดยมนุษย์ การติดตามโปรดักชัน และการทดลองเพื่อวัดคุณภาพของแอปพลิเคชัน
• แพลตฟอร์มการประเมินสามารถทำทุกอย่างแทนคุณได้ เครื่องมือสำเร็จรูปสามารถทำการตรวจสอบบางอย่างโดยอัตโนมัติได้ แต่ไม่สามารถระบุได้ว่ารูปแบบความล้มเหลว (ประเภทของข้อผิดพลาดหรือพฤติกรรมที่ไม่พึงประสงค์ของเอเจนต์) แบบใดที่มีความสำคัญต่อผลิตภัณฑ์ของคุณ
• คุณสามารถให้ LLM ประเมินทุกอย่างได้ นี่เป็นความเข้าใจผิดครั้งใหญ่ การวิเคราะห์ข้อผิดพลาดที่นำโดยมนุษย์และการปรับเทียบตัวให้คะแนนยังคงเป็นสิ่งจำเป็น เนื่องจาก LLM ขาดบริบททางธุรกิจที่จำเป็นต่อการค้นพบปัญหาทุกอย่าง
• การทดสอบ A/B หรือแค่การใช้งานเอเจนต์ก็ใช้แทนการประเมินได้ ไม่ถูกต้อง การทดสอบ A/B แสดงให้เห็นได้ว่าเวอร์ชันใดทำงานได้ดีกว่าตามเมตริกที่เลือกไว้ แต่ไม่สามารถอธิบายปัญหาที่แท้จริงเบื้องหลังได้ด้วยตัวเอง

คำถามที่พบบ่อยเกี่ยวกับการประเมินเอเจนต์ AI

1. การประเมินเอเจนต์ AI กับการประเมิน LLM แตกต่างกันอย่างไร

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

การประเมินเอเจนต์แตกต่างจากการประเมิน LLM ทั่วไปตรงที่จะตรวจสอบทั้งผลลัพธ์สุดท้ายและลำดับการดำเนินการที่ใช้เพื่อให้ได้ผลลัพธ์นั้น ซึ่งรวมถึงการเรียกใช้เครื่องมือ การตัดสินใจ และการปฏิบัติตามกฎที่กำหนดไว้ล่วงหน้า

2. เมตริกสำคัญสำหรับการประเมินเอเจนต์ AI

เมตริกสำหรับการประเมินเอเจนต์ AI แบ่งออกเป็นสองประเภทหลัก:

• เมตริกประสิทธิภาพทางเทคนิค: อัตราความสำเร็จของงาน ความถูกต้องของการดำเนินการ คุณภาพของคำตอบ ความน่าเชื่อถือ (pass@1 และ pass@k) เวลาแฝง การใช้โทเค็น และต้นทุนต่องานที่สำเร็จ
• เมตริกด้านธุรกิจและประสบการณ์ผู้ใช้: ความพึงพอใจของลูกค้า (CSAT) อัตราการแก้ไขปัญหา อัตราการส่งต่อเรื่อง อัตราคอนเวอร์ชัน ระยะเวลาในการทำงานให้เสร็จ และผลลัพธ์อื่นๆ ที่เฉพาะเจาะจงกับบทบาทของเอเจนต์

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

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

3. เครื่องมือที่ดีที่สุดสำหรับการประเมินเอเจนต์ AI มีอะไรบ้าง

ตัวเลือกที่นิยมใช้ ได้แก่:

• เฟรมเวิร์กการทดสอบ: assertion ของ Python และ pytest มีประโยชน์สำหรับการรันกรณีทดสอบที่ทำซ้ำได้และการตรวจสอบเงื่อนไขที่แน่นอน เช่น เอเจนต์เลือกเครื่องมือที่ถูกต้องหรือส่งคืน ID ชิ้นส่วนที่ถูกต้องหรือไม่
• เฟรมเวิร์กการประเมินเอเจนต์ AI: DeepEval และ agent-eval toolkit ของ Google รองรับการประเมินที่ซับซ้อนมากขึ้น ซึ่งรวมถึงเทรซการดำเนินการ ตัวให้คะแนนที่ใช้ LLM และการทดสอบรีเกรสชันแบบอัตโนมัติ
• แพลตฟอร์มการประเมินและการสังเกตการณ์ระบบ (Observability): LangSmith, Arize Phoenix และ MLflow ช่วยให้ทีมตรวจสอบพฤติกรรมของเอเจนต์ จัดการชุดข้อมูลการประเมิน เปรียบเทียบเอเจนต์เวอร์ชันต่างๆ และติดตามประสิทธิภาพในโปรดักชัน

4. จะทำให้การประเมินเอเจนต์ AI เป็นแบบอัตโนมัติได้อย่างไร

คุณสามารถทำให้การประเมินเอเจนต์ AI เป็นแบบอัตโนมัติได้ด้วยการสร้างการทดสอบที่ทำซ้ำได้ ใช้ตัวให้คะแนนอัตโนมัติ และผสานการตรวจสอบเหล่านั้นเข้ากับเวิร์กโฟลว์การพัฒนาและโปรดักชัน:

1. สร้างชุดข้อมูลการประเมิน: รวบรวมงานของผู้ใช้ที่เป็นตัวแทนได้ดี ผลลัพธ์ที่คาดหวัง ความล้มเหลวที่ทราบอยู่แล้ว และเทรซการดำเนินการของเอเจนต์ รวมถึงกรณีขอบ (edge case) เช่น การเรียกใช้เครื่องมือที่ล้มเหลว ข้อมูลที่ขาดหายไป และการดำเนินการที่ไม่ได้รับอนุญาต
2. ทำให้การรันการทดสอบและการให้คะแนนเป็นแบบอัตโนมัติ: ใช้เฟรมเวิร์กอย่าง pytest หรือ DeepEval เพื่อรันกรณีทดสอบและใช้การตรวจสอบด้วยโค้ดหรือตัวให้คะแนนแบบ LLM ตรวจสอบความถูกต้องของตัวให้คะแนนแบบ LLM เทียบกับการตัดสินของมนุษย์ก่อนที่จะเชื่อถือคะแนนจากตัวให้คะแนนเหล่านั้น
3. ผสานการประเมินเข้ากับ CI/CD: รันการทดสอบรีเกรสชันซ้ำโดยอัตโนมัติเมื่อนักพัฒนาอัปเดตพรอมต์ โมเดล เครื่องมือ หรือเวิร์กโฟลว์ของเอเจนต์ เปรียบเทียบผลลัพธ์กับเวอร์ชันพื้นฐาน และกำหนดเกณฑ์คุณภาพที่จะป้องกันการเผยแพร่เมื่อการตรวจสอบที่สำคัญล้มเหลว
4. ใช้ตัวให้คะแนนที่ผ่านการปรับเทียบแล้วกับเทรซจากโปรดักชันที่สุ่มตัวอย่างมา ติดตามอัตราความล้มเหลวและเมตริกประสิทธิภาพอื่นๆ และสืบหาข้อผิดพลาดใหม่ๆ ผ่านการตรวจทานด้วยตนเอง