Agent ผ่าน Test Case ที่เตรียมไว้ครบทุกข้อ แล้วจะเอาไปใช้กับลูกค้าจริงได้เลยไหม
สรุปสั้น ๆ
AI Agent Evaluation คือการประเมินคุณภาพของ Agent ที่ตัดสินใจเลือกและเรียกใช้เครื่องมือเองหลายขั้นตอนกว่าจะได้คำตอบสุดท้าย ต่างจาก LLM Evaluation ทั่วไปตรงที่ต้องวัดทั้งเส้นทางการตัดสินใจ ความแม่นยำในการเลือกเครื่องมือ จำนวนรอบที่ใช้ และความปลอดภัยเมื่อเรียกใช้เครื่องมือที่มีผลกระทบจริง การผ่าน Test Case จำนวนหนึ่งที่เตรียมไว้ล่วงหน้าไม่ได้แปลว่า Agent จะรับมือกับความหลากหลายของผู้ใช้จริงได้ เพราะสถานการณ์จริงมักมีรูปแบบคำถามและเงื่อนไขที่ Test Case ไม่ครอบคลุมเสมอไป
ทีมพัฒนาแห่งหนึ่งสร้าง Agent สำหรับช่วยลูกค้าตรวจสอบสถานะคำสั่งซื้อและแก้ไขที่อยู่จัดส่ง โดยเขียน Test Case ไว้ 40 เคสครอบคลุมทั้งกรณีปกติและกรณีขอบที่คิดออก Agent ผ่านทุกเคสก่อนปล่อยใช้งานจริง ทีมมั่นใจว่าพร้อมแล้ว แต่พอเปิดให้ลูกค้าจริงใช้งาน กลับพบว่า Agent สับสนเมื่อลูกค้าถามหลายเรื่องในข้อความเดียว เช่น ถามสถานะพัสดุพร้อมขอเปลี่ยนที่อยู่ในประโยคเดียวกัน ซึ่งไม่มีใน Test Case ที่เตรียมไว้เลยสักเคส
ปัญหานี้ชี้ให้เห็นความต่างสำคัญระหว่างการทดสอบ Agent กับการทดสอบ Chatbot หรือ LLM ทั่วไปที่ตอบคำถามเดียวจบ Agent ต้องตัดสินใจเองว่าจะเรียกใช้เครื่องมือไหน กี่ครั้ง ตามลำดับใด และต้องรับมือกับสถานการณ์ที่ไม่ตรงกับที่วางแผนไว้ล่วงหน้า การผ่าน Test Case จำนวนหนึ่งจึงเป็นเพียงจุดเริ่มต้น ไม่ใช่หลักประกันว่าจะรับมือความหลากหลายของโลกจริงได้ครบ
บทความนี้จะพาดูว่า AI Agent Evaluation ควรวัดอะไรบ้างที่ต่างจาก LLM Evaluation ทั่วไป ออกแบบสถานการณ์ทดสอบอย่างไรให้ใกล้เคียงโลกจริง และจุดที่ทีมส่วนใหญ่มักมองข้ามจนปล่อย Agent ที่ยังไม่พร้อมออกไปใช้งานจริง
AI Agent Evaluation คืออะไร ต่างจากการวัด Chatbot ทั่วไปตรงไหน
AI Agent Evaluation คือการประเมินคุณภาพของ Agent ที่มีความสามารถตัดสินใจเองว่าจะเรียกใช้เครื่องมือใด เมื่อไร และตามลำดับใด กว่าจะได้คำตอบสุดท้ายส่งกลับผู้ใช้ ต่างจาก LLM Evaluation ทั่วไปที่มักวัดคำตอบเดียวจากคำถามเดียว โดยไม่มีขั้นตอนตัดสินใจระหว่างทางที่ต้องตรวจสอบ
ความซับซ้อนของ Agent อยู่ที่มันไม่ได้เดินตามเส้นทางตายตัวเหมือนโค้ดที่เขียนไว้ล่วงหน้า แต่เลือกขั้นตอนเองตามบริบทของคำขอในแต่ละครั้ง คำขอเดียวกันอาจได้เส้นทางการทำงานต่างกันเล็กน้อยในแต่ละรอบ การประเมินจึงต้องดูทั้งผลลัพธ์สุดท้ายและเส้นทางที่ Agent เลือกเดินไปด้วย ไม่ใช่ดูแค่ว่าคำตอบท้ายสุดถูกหรือผิด
อีกจุดที่ต่างชัดเจนคือความเสี่ยง Agent ที่เรียกใช้เครื่องมือที่มีผลกระทบจริง เช่น ส่งอีเมล แก้ไขข้อมูลในระบบ หรือดำเนินการชำระเงิน มีความเสี่ยงสูงกว่าการตอบข้อความธรรมดามาก การประเมินจึงต้องรวมมิติด้านความปลอดภัยและการควบคุมความเสี่ยงเข้าไปด้วย ซึ่งเป็นมิติที่แทบไม่มีในการประเมิน Chatbot ที่ตอบคำถามเดียวจบทั่วไป
ทำไมผ่าน Test Case ที่เตรียมไว้ครบทุกข้อยังไม่พอสำหรับลูกค้าจริง
Test Case ที่ทีมเตรียมไว้ล่วงหน้ามักถูกออกแบบตามสิ่งที่ทีมคิดว่าผู้ใช้จะถาม ซึ่งเป็นการคาดเดาที่จำกัดด้วยประสบการณ์ของคนออกแบบเอง ผู้ใช้จริงมักถามในรูปแบบที่ไม่มีใครในทีมคาดคิดมาก่อน เช่น ถามหลายเรื่องปนกันในข้อความเดียว ใช้คำที่กำกวม หรือให้ข้อมูลไม่ครบแล้วคาดหวังให้ Agent ถามกลับอย่างฉลาด
อีกสาเหตุคือ Test Case ส่วนใหญ่มักทดสอบแบบแยกเคส คือแต่ละเคสเริ่มต้นใหม่จากศูนย์ ไม่ได้จำลองบทสนทนาต่อเนื่องหลายรอบที่ผู้ใช้จริงมักทำ เช่น ถามคำถามหนึ่ง แล้วเปลี่ยนใจถามคำถามใหม่กลางบทสนทนา หรือย้อนกลับไปถามเรื่องเดิมที่คิดว่าคุยจบไปแล้ว Agent ที่ผ่านทุกเคสแบบแยกเดี่ยวอาจยังสับสนเมื่อต้องรักษาบริบทข้ามหลายรอบการโต้ตอบ
ความจริงที่ทีมต้องยอมรับคือ ไม่มีชุด Test Case ใดที่ครอบคลุมความหลากหลายของโลกจริงได้ทั้งหมด สิ่งที่ทำได้คือขยายชุดทดสอบอย่างต่อเนื่องจากปัญหาจริงที่พบหลังปล่อยใช้งาน และออกแบบให้ Agent มีกลไกรับมือกับสถานการณ์ที่ไม่คุ้นเคยอย่างปลอดภัย เช่น ถามกลับเพื่อความชัดเจนแทนที่จะเดาแล้วดำเนินการเลย
มิติที่ต้องวัดเพิ่มจากการประเมิน LLM ทั่วไป
การประเมิน Agent ต้องขยายจากการวัดว่า 'คำตอบถูกไหม' ไปสู่การวัดหลายมิติที่สะท้อนพฤติกรรมระหว่างทาง ตารางด้านล่างสรุปมิติหลักที่ควรมีในชุดประเมิน Agent
| มิติที่วัด | คำถามที่ต้องตอบ | ทำไมสำคัญ |
|---|---|---|
| Task Success Rate | งานที่มอบหมายเสร็จสมบูรณ์ตามเป้าหมายกี่เปอร์เซ็นต์ | ตัวชี้วัดหลักว่า Agent ทำงานได้จริงหรือไม่ |
| Tool Selection Accuracy | Agent เลือกเครื่องมือที่ถูกต้องสำหรับแต่ละสถานการณ์หรือไม่ | เลือกผิดเครื่องมือทำให้งานล้มเหลวแม้เหตุผลจะดูสมเหตุสมผล |
| Step Efficiency | ใช้จำนวนรอบและเวลาเท่าไรกว่าจะเสร็จงาน | รอบมากเกินจำเป็นหมายถึงต้นทุนและเวลาแฝงที่สูงขึ้น |
| Safety and Guardrail Compliance | Agent หยุดหรือถามกลับก่อนดำเนินการที่มีความเสี่ยงสูงหรือไม่ | ป้องกันความเสียหายจริงเมื่อ Agent เข้าถึงระบบที่มีผลกระทบ |
| Recovery from Failure | เมื่อเครื่องมือที่เรียกใช้ล้มเหลว Agent จัดการต่ออย่างไร | โลกจริงมี API ล่มหรือข้อมูลไม่ครบเสมอ ต้องรับมือได้ |
ออกแบบสถานการณ์ทดสอบให้ใกล้เคียงลูกค้าจริงมากขึ้น
- รวบรวมบทสนทนาจริงจากช่องทาง Support เดิมหรือระบบทดลองใช้งานก่อนหน้า เพื่อดูรูปแบบคำถามที่หลากหลายและซับซ้อนกว่าที่ทีมคิดเอง แทนที่จะแต่งสถานการณ์ขึ้นเองล้วน ๆ
- ออกแบบสถานการณ์แบบหลายรอบต่อเนื่อง ไม่ใช่แค่คำถามเดี่ยวจบในตัว เช่น ให้ผู้ทดสอบสวมบทบาทลูกค้าที่เปลี่ยนใจกลางบทสนทนา หรือให้ข้อมูลเพิ่มทีละน้อยแทนที่จะให้ครบตั้งแต่ต้น
- จำลองความล้มเหลวของเครื่องมือที่ Agent เรียกใช้โดยตั้งใจ เช่น ให้ API ตอบช้าผิดปกติ ส่งข้อมูลกลับมาไม่ครบ หรือคืนค่า Error เพื่อดูว่า Agent จัดการต่ออย่างไรเมื่อสิ่งที่คาดไว้ไม่เป็นไปตามแผน
- เพิ่มสถานการณ์เชิงรุกที่พยายามหลอกให้ Agent ทำสิ่งที่ไม่ควรทำ เช่น ขอให้ดำเนินการที่มีผลกระทบสูงโดยไม่ยืนยันตัวตน เพื่อทดสอบว่ากลไกความปลอดภัยที่ตั้งไว้ทำงานจริงหรือไม่
- ให้คนที่ไม่เคยเกี่ยวข้องกับการพัฒนา Agent ทดลองใช้งานแบบไม่มีสคริปต์กำกับ เพื่อจับพฤติกรรมที่ผิดคาดซึ่งทีมพัฒนาเองมองข้ามเพราะคุ้นเคยกับวิธีใช้งานที่ตั้งใจไว้อยู่แล้ว
ประเมินเส้นทางการตัดสินใจ ไม่ใช่แค่ดูคำตอบสุดท้าย
การดูแค่ว่าคำตอบสุดท้ายถูกหรือผิดอาจพลาดปัญหาสำคัญที่ซ่อนอยู่ระหว่างทาง เช่น Agent อาจได้คำตอบถูกต้องในที่สุด แต่ใช้วิธีที่ไม่ควรทำระหว่างทาง เช่น เข้าถึงข้อมูลที่ไม่จำเป็น หรือใช้จำนวนรอบมากเกินสมควรจนต้นทุนสูงเกินคุ้ม การประเมินที่ดีจึงต้องตรวจสอบเส้นทาง (Trajectory) ที่ Agent เดินไป ไม่ใช่แค่ปลายทาง
วิธีหนึ่งที่ใช้ได้จริงคือกำหนดเส้นทางที่ยอมรับได้ไว้ล่วงหน้าสำหรับสถานการณ์สำคัญ เช่น งานประเภทนี้ควรเรียกใช้เครื่องมือ A ก่อนเสมอเพื่อยืนยันข้อมูล แล้วค่อยเรียกเครื่องมือ B เพื่อดำเนินการ ถ้า Agent ข้ามขั้นตอนยืนยันไปเลย แม้ผลลัพธ์สุดท้ายจะถูกต้องในเคสทดสอบนั้น ก็ควรถือว่าไม่ผ่าน เพราะพฤติกรรมแบบนี้เสี่ยงจะทำผิดในสถานการณ์อื่นที่ข้อมูลไม่ตรงกับที่คาดไว้
การเชื่อมข้อมูลจากระบบ AI Agent Observability ที่บันทึกเส้นทางการทำงานจริงในระบบ Production เข้ากับกระบวนการ Evaluation ช่วยให้ทีมเห็นรูปแบบเส้นทางที่ผิดปกติซึ่งเคยเกิดขึ้นจริง แล้วนำมาสร้างเป็นเกณฑ์ตรวจสอบเพิ่มเติมในรอบทดสอบถัดไป แทนที่จะกำหนดเส้นทางที่ยอมรับได้จากการคาดเดาเพียงอย่างเดียว
ข้อผิดพลาดที่ทีมมักเจอเมื่อประเมิน Agent
- ทำแบบนี้แล้วพัง เพราะทดสอบแต่ละเคสแบบแยกเดี่ยว ไม่เคยจำลองบทสนทนาต่อเนื่องหลายรอบ ทำให้ไม่รู้ว่า Agent รักษาบริบทข้ามรอบการโต้ตอบได้ดีแค่ไหน
- ทำแบบนี้แล้วพัง เพราะวัดแค่ Task Success Rate อย่างเดียว โดยไม่ดูว่า Agent ใช้เส้นทางที่ปลอดภัยและมีประสิทธิภาพหรือไม่ ทำให้ Agent ที่ 'สำเร็จแบบเสี่ยง' ผ่านการทดสอบไปได้
- ทำแบบนี้แล้วพัง เพราะไม่เคยจำลองสถานการณ์ที่เครื่องมือที่ Agent เรียกใช้ล้มเหลว ทำให้เมื่อ API จริงล่มในภายหลัง Agent ไม่รู้ว่าต้องทำอย่างไรและอาจตอบผิดหรือค้างอยู่ในสภาวะวนซ้ำ
- ทำแบบนี้แล้วพัง เพราะให้ทีมพัฒนาเองเป็นคนทดสอบทั้งหมด โดยไม่เคยให้คนนอกทีมลองใช้งานแบบไม่มีสคริปต์กำกับ ทำให้พฤติกรรมผิดปกติที่คนนอกสังเกตเห็นได้ง่ายกลับหลุดรอดไปจนถึงลูกค้าจริง
เมื่อไรถือว่า Agent ดีพอจะปล่อยให้ลูกค้าจริงใช้งาน
ไม่มีเกณฑ์ตายตัวว่า Agent ต้อง 'สมบูรณ์แบบ' ก่อนปล่อยใช้งาน แต่ทีมควรกำหนดเกณฑ์ขั้นต่ำที่ชัดเจนตามระดับความเสี่ยงของงาน เช่น Agent ที่แค่ตอบคำถามข้อมูลทั่วไปอาจยอมรับอัตราความสำเร็จที่ต่ำกว่า Agent ที่เข้าถึงข้อมูลลูกค้าหรือดำเนินการที่มีผลกระทบทางการเงิน ซึ่งควรมีเกณฑ์ด้านความปลอดภัยที่เข้มงวดกว่ามาก
แนวทางที่ปลอดภัยกว่าคือเริ่มปล่อยใช้งานแบบจำกัดขอบเขตก่อน เช่น ให้ Agent ทำงานเฉพาะบางประเภทที่ทดสอบมาอย่างละเอียด หรือให้มีจุดตรวจสอบโดยคนก่อนดำเนินการที่มีความเสี่ยงสูง แล้วค่อยขยายขอบเขตเมื่อเห็นข้อมูลจริงจากการใช้งานว่า Agent รับมือกับความหลากหลายได้ดีตามที่คาด ไม่ใช่เปิดให้ Agent ทำงานเต็มขอบเขตทันทีเพียงเพราะผ่านชุดทดสอบภายในทีม
หากทีมมี AI Gateway เป็นชั้นกลางที่คำขอทั้งหมดผ่านอยู่แล้ว จุดนี้เป็นตำแหน่งที่เหมาะจะตั้งเพดานความเสี่ยงชั่วคราวระหว่างช่วงทดลองขยายขอบเขต เช่น จำกัดจำนวนครั้งที่ Agent เรียกใช้เครื่องมือที่มีผลกระทบสูงต่อวัน เพื่อจำกัดความเสียหายสูงสุดที่จะเกิดขึ้นได้หากมีเคสที่หลุดรอดจากการทดสอบไปจริง
สรุป
AI Agent Evaluation ต้องวัดมากกว่าคำตอบสุดท้ายที่ถูกหรือผิด เพราะ Agent ตัดสินใจเรียกใช้เครื่องมือเองหลายขั้นตอนกว่าจะจบงาน มิติสำคัญที่ต้องเพิ่มคือความแม่นยำในการเลือกเครื่องมือ ประสิทธิภาพของจำนวนรอบที่ใช้ ความปลอดภัยเมื่อเรียกใช้เครื่องมือที่มีผลกระทบจริง และความสามารถในการฟื้นตัวเมื่อเครื่องมือล้มเหลว
การผ่าน Test Case ที่เตรียมไว้ล่วงหน้าเป็นเพียงจุดเริ่มต้น ไม่ใช่หลักประกันว่าจะรับมือความหลากหลายของลูกค้าจริงได้ครบ ทีมที่จริงจังต้องขยายชุดทดสอบอย่างต่อเนื่องจากปัญหาจริงที่พบ จำลองความล้มเหลวของเครื่องมือ และเริ่มเปิดใช้งานแบบจำกัดขอบเขตก่อนขยายเต็มรูปแบบ
- Agent Evaluation ต้องดูเส้นทางการตัดสินใจทั้งหมด ไม่ใช่แค่คำตอบสุดท้าย ต่างจาก LLM Evaluation ทั่วไป
- มิติสำคัญเพิ่มเติมคือ Tool Selection Accuracy, Step Efficiency, Safety Compliance และ Recovery from Failure
- ผ่าน Test Case ที่เตรียมไว้ไม่ได้แปลว่าใช้กับลูกค้าจริงได้ทันที ต้องขยายชุดทดสอบจากปัญหาจริงต่อเนื่อง
- ควรเริ่มเปิดใช้งานแบบจำกัดขอบเขตก่อน แล้วขยายเมื่อเห็นข้อมูลจริงยืนยันว่า Agent รับมือความหลากหลายได้ดี
คำถามที่พบบ่อย
AI Agent Evaluation ต่างจาก LLM Evaluation ทั่วไปอย่างไร
LLM Evaluation ทั่วไปมักวัดคำตอบเดียวจากคำถามเดียว ส่วน Agent Evaluation ต้องวัดทั้งเส้นทางการตัดสินใจหลายขั้นตอน ความแม่นยำในการเลือกเครื่องมือ จำนวนรอบที่ใช้ และความปลอดภัยเมื่อเรียกใช้เครื่องมือที่มีผลกระทบจริง ซึ่งเป็นมิติที่แทบไม่มีในการประเมิน LLM ที่ตอบคำถามเดียวจบ
Test Case กี่เคสถึงจะเพียงพอสำหรับทดสอบ Agent
ไม่มีจำนวนตายตัว เพราะความหลากหลายของโลกจริงไม่มีวันครอบคลุมได้หมดด้วยชุดทดสอบคงที่ สิ่งสำคัญกว่าจำนวนคือความหลากหลายของสถานการณ์ ทั้งบทสนทนาต่อเนื่องหลายรอบ ความล้มเหลวของเครื่องมือ และการขยายชุดทดสอบอย่างต่อเนื่องจากปัญหาจริงที่พบหลังปล่อยใช้งาน
จะรู้ได้อย่างไรว่า Agent ใช้เส้นทางที่ปลอดภัยหรือไม่ ไม่ใช่แค่คำตอบถูก
ต้องกำหนดเส้นทางที่ยอมรับได้ไว้ล่วงหน้าสำหรับงานสำคัญ เช่น ต้องยืนยันข้อมูลก่อนดำเนินการ แล้วตรวจสอบว่า Agent ทำตามลำดับนั้นจริงหรือไม่ในแต่ละเคสทดสอบ ไม่ใช่ดูแค่ว่าผลลัพธ์สุดท้ายถูกต้อง เพราะเส้นทางที่ข้ามขั้นตอนสำคัญไปอาจถูกในเคสทดสอบแต่เสี่ยงผิดในสถานการณ์อื่น
ควรจำลองความล้มเหลวของเครื่องมือในการทดสอบด้วยหรือไม่
ควรอย่างยิ่ง เพราะในระบบจริง API ล่มหรือข้อมูลไม่ครบเป็นเรื่องที่เกิดขึ้นได้เสมอ การจำลองสถานการณ์นี้ตั้งแต่ตอนทดสอบช่วยให้เห็นว่า Agent จัดการต่ออย่างไร แทนที่จะไปเจอปัญหานี้ครั้งแรกตอนใช้งานจริงกับลูกค้า ซึ่งอาจสายเกินไปที่จะแก้ทัน
ทีมเล็กที่มี Agent เดียวทำงานไม่ซับซ้อน ต้องทำ Evaluation ระดับนี้เลยหรือไม่
ไม่จำเป็นต้องทำครบทุกมิติตั้งแต่วันแรก ทีมเล็กสามารถเริ่มจากมิติที่สำคัญที่สุดตามความเสี่ยงของงานก่อน เช่น ถ้า Agent ไม่ได้เข้าถึงข้อมูลที่มีผลกระทบสูง อาจเน้นวัด Task Success Rate และ Tool Selection Accuracy ก่อน แล้วค่อยเพิ่มมิติด้านความปลอดภัยเมื่อ Agent เริ่มทำงานที่มีความเสี่ยงมากขึ้น
ผ่านการทดสอบภายในทีมแล้ว ควรเปิดให้ลูกค้าจริงใช้งานเต็มขอบเขตเลยหรือไม่
แนะนำให้เริ่มแบบจำกัดขอบเขตก่อน เช่น จำกัดประเภทงานหรือจำนวนผู้ใช้ในช่วงแรก พร้อมมีจุดตรวจสอบโดยคนก่อนดำเนินการที่มีความเสี่ยงสูง แล้วค่อยขยายขอบเขตเมื่อเห็นข้อมูลจริงยืนยันว่า Agent รับมือกับความหลากหลายของผู้ใช้ได้ดีตามที่คาดไว้ ไม่ใช่เปิดเต็มขอบเขตทันทีเพียงเพราะผ่านชุดทดสอบภายใน
อ่านต่อแบบเจาะลึก
ทดลองวัดผลโฆษณาเข้า LINE ฟรี 14 วัน
สมัครแล้วสร้างโปรเจกต์ เชื่อม LINE ติดตั้ง Tracking แล้วเริ่มเห็น Funnel จาก Click ถึง Purchase ได้ทันที ไม่ต้องใช้บัตรเครดิต
เริ่มทดลองใช้ฟรี 14 วันบทความที่เกี่ยวข้อง
ทีมขนาดเล็กที่มี Agent เดียวทำงานง่าย ๆ จำเป็นต้องลงทุนกับ Observability เพิ่มไหม
ให้ LLM ตอบเป็น JSON ตรง Schema กับให้ตอบเป็นข้อความแล้ว Parse เอง ต่างกันตรงไหน
