คู่มือการออกแบบการประเมิน AI Agent — การเรียกใช้เครื่องมือ, รอยทางการทำงาน และการตรวจจับการถดถอย

การประเมิน AI Agent คือกระบวนการตรวจสอบแบบหลายระดับ (multi-layered) ซึ่งไม่ได้ดูเพียงแค่คุณภาพของคำตอบสุดท้ายเท่านั้น แต่ยังรวมถึงความถูกต้องของการเรียกใช้เครื่องมือ (tool calling) และความสมเหตุสมผลของเส้นทางการทำงาน (trajectory) อีกด้วย

ในการประเมิน LLM ทั่วไป การให้คะแนนความสัมพันธ์แบบหนึ่งต่อหนึ่งระหว่าง "อินพุต→เอาต์พุต" นั้นเพียงพอแล้ว แต่เนื่องจาก Agent ต้องบรรลุเป้าหมายผ่านการเรียกใช้เครื่องมือภายนอกหลายขั้นตอน จึงอาจเกิดกรณีที่ผลลัพธ์สุดท้ายดูถูกต้องแม้ว่าการตัดสินใจระหว่างทางจะผิดพลาดก็ตาม หากมองข้าม "ความถูกต้องที่ดูเหมือนจริง" (apparent correctness) นี้ไป อาจมีความเสี่ยงที่จะเกิดการถดถอย (regression) อย่างรุนแรงในสภาพแวดล้อมการใช้งานจริง

บทความนี้จะอธิบายขั้นตอนทั้งหมดของการประเมิน Agent อย่างเป็นระบบ ตั้งแต่การออกแบบ Golden Dataset ไปจนถึงการตรวจสอบการเรียกใช้เครื่องมือ, การให้คะแนนเส้นทางการทำงาน, การตรวจจับการถดถอยภายใต้สภาวะที่ไม่แน่นอน (non-determinism) และการเชื่อมต่อกับ CI โดยเนื้อหาจะช่วยให้วิศวกรและผู้รับผิดชอบด้าน MLOps ที่กำลังพิจารณาสร้างโครงสร้างพื้นฐานสำหรับการประเมิน ได้รับขั้นตอนที่ชัดเจนและสามารถนำไปปฏิบัติได้จริงตั้งแต่วันพรุ่งนี้

บทสรุป: การประเมิน AI Agent จำเป็นต้องตรวจสอบไม่เพียงแค่ความถูกต้องของผลลัพธ์สุดท้ายเท่านั้น แต่ยังรวมถึงความเหมาะสมในการเรียกใช้เครื่องมือ (Tool calling) และความสมเหตุสมผลของขั้นตอนการทำงาน (Execution trajectory) อีกด้วย

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

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

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

ตัวอย่างเช่น Agent ที่เรียกใช้เครื่องมือค้นหาด้วยคำค้นหาที่ไม่จำเป็นซ้ำถึง 5 ครั้งก่อนจะให้คำตอบที่ถูกต้อง กับ Agent ที่ให้คำตอบที่ถูกต้องด้วยการเรียกใช้เพียงครั้งเดียว ทั้งคู่จะมีคะแนนประเมินผลลัพธ์สุดท้ายเท่ากัน แต่แบบแรกนั้นมีปัญหาเรื่องค่าใช้จ่ายที่เกินจำเป็น ความหน่วง (Latency) ที่เพิ่มขึ้น และความเสี่ยงที่จะเกิดผลข้างเคียง (Side effects)

เหตุผลที่ควรประเมินเส้นทางการทำงาน (Trajectory) มีหลักๆ 3 ประการ ดังนี้:

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

ตามที่ได้อธิบายไว้โดยละเอียดใน Harness Engineering คืออะไร? วิธีการออกแบบเพื่อป้องกันความผิดพลาดของ AI Agent ด้วยโครงสร้าง การควบคุมพฤติกรรมของ Agent อย่างเป็นโครงสร้างนั้น จำเป็นต้องมีการมองเห็นภาพรวมในระดับเส้นทางการทำงาน (Trajectory) เป็นพื้นฐานสำคัญ

แม้จะใช้ Prompt เดียวกันรัน 10 ครั้ง แต่ AI Agent อาจสร้างลำดับการเรียกใช้เครื่องมือ (Tool calling) หรือผลลัพธ์ระหว่างทางที่แตกต่างกันออกไปในแต่ละครั้ง นี่คือปัญหาของ "ความไม่แน่นอน" (Non-determinism) หากเป็นการประเมิน LLM ทั่วไป เราสามารถเปรียบเทียบได้ว่า "ตรงกับผลลัพธ์ที่คาดหวังหรือไม่" แต่สำหรับ Agent แล้ว เนื่องจากมีเส้นทางสู่คำตอบที่ถูกต้องได้หลายทาง การใช้การจับคู่สตริง (String matching) แบบง่ายจึงใช้งานไม่ได้ผล

เมื่อมีการใช้การอนุมานแบบหลายขั้นตอน (Multi-step reasoning) ความซับซ้อนจะยิ่งเพิ่มขึ้น:

• การแพร่กระจายของข้อผิดพลาด (Error propagation): หากเรียกใช้เครื่องมือผิดในขั้นตอนที่ 1 ข้อมูลนำเข้าในขั้นตอนที่ 2 เป็นต้นไปจะเกิดการปนเปื้อน ซึ่งอาจทำให้คำตอบสุดท้ายดูเหมือนถูกต้องโดยบังเอิญ
• การระเบิดของการประเมิน (Evaluation explosion): หาก Agent มี 5 ขั้นตอนและแต่ละขั้นตอนมีเส้นทางที่ถูกต้อง 3 รูปแบบ จำนวนชุดค่าผสมที่ต้องตรวจสอบจะเพิ่มขึ้นแบบทวีคูณ
• ความไม่สามารถมองเห็นสถานะระหว่างทาง (Invisibility of intermediate states): ผลกระทบข้างเคียง (Side effects) ต่อ API ภายนอกหรือฐานข้อมูล ไม่สามารถตรวจพบได้จากการดูเพียงผลลัพธ์สุดท้ายเท่านั้น

มุมมองเรื่องการแบ่งเงื่อนไข (Conditional branching) ก็มีความสำคัญเช่นกัน หากเป็น Agent ที่มีจำนวนขั้นตอนน้อยและเส้นทางจำกัด การตรวจสอบเทียบกับเส้นทางที่คาดหวังแบบกำหนดเงื่อนไข (Deterministic expectation trajectory) จะได้ผลดี แต่หากเป็น Agent ที่มีจำนวนขั้นตอนมากและเส้นทางหลากหลาย การใช้ LLM ในการประเมินเส้นทาง (Trajectory evaluation) หรือการออกแบบเกณฑ์การผ่านแบบสถิติจะเป็นทางเลือกที่ใช้งานได้จริงมากกว่า

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

บทสรุป: สิ่งสำคัญในการประเมิน Agent คือการจัดระเบียบว่า "จะวัดอะไร, ที่ระดับความละเอียดเท่าใด และวัดเมื่อใด" ตั้งแต่เริ่มต้น

การแบ่งขอบเขตการประเมินออกเป็นแบบ Offline และ Online พร้อมทั้งออกแบบเลเยอร์ต่างๆ ทั้งในส่วนของคำตอบสุดท้าย (Final Answer), การเรียกใช้เครื่องมือ (Tool Calling), ร่องรอยการทำงาน (Trajectory) และต้นทุน (Cost) จะช่วยให้คุณสร้างระบบการตรวจสอบที่ครอบคลุมและไม่ตกหล่น

การประเมินแบบออฟไลน์ (Offline Evaluation) เปรียบเสมือน "การตรวจสอบคุณภาพก่อนการจัดส่ง" ในขณะที่การประเมินแบบออนไลน์ (Online Evaluation) เปรียบเสมือน "การตรวจสอบสินค้าชำรุดหลังจากโรงงานเริ่มเดินเครื่อง" การใช้ทั้งสองวิธีร่วมกันจะช่วยป้องกันไม่ให้เกิดช่องโหว่ในการประเมิน

การประเมินแบบออฟไลน์ คือการประเมินที่ดำเนินการโดยใช้ชุดข้อมูลมาตรฐาน (Golden Dataset) ที่กำหนดไว้ โดยไม่ใช้ทราฟฟิกจริงจากระบบงาน การประเมินนี้สามารถรวมเข้ากับ CI Pipeline เพื่อให้ทำงานโดยอัตโนมัติทุกครั้งที่มีการเปลี่ยนแปลงโค้ดหรือ Prompt จึงเหมาะสำหรับการตรวจพบปัญหาการถดถอย (Regression) ได้ตั้งแต่เนิ่นๆ โดยมีเป้าหมายหลักดังนี้:

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

ในทางกลับกัน การประเมินแบบออนไลน์ จะมุ่งเน้นไปที่คำขอจากผู้ใช้งานจริง โดยจะวิเคราะห์บันทึก (Log) และร่องรอยการทำงาน (Trace) ในสภาพแวดล้อมการใช้งานจริงอย่างต่อเนื่อง บทบาทหลักคือการตรวจจับกรณีขอบเขต (Edge Cases) ที่จำลองได้ยากในแบบออฟไลน์ รวมถึงการเปลี่ยนแปลงของการกระจายตัวของข้อมูล (Concept Drift)

สรุปการแบ่งบทบาทของทั้งสองวิธีได้ดังนี้:

สิ่งสำคัญคือ แม้แต่ Agent ที่ผ่านการประเมินแบบออฟไลน์มาแล้ว ก็อาจเกิดการเชื่อมโยงของเครื่องมือที่ไม่คาดคิดขึ้นได้ในการใช้งานจริง

ในตอนแรก เรามักจะคิดว่า "การดูความถูกต้องของคำตอบสุดท้ายก็เพียงพอแล้ว" แต่ในความเป็นจริง การประเมินแบบหลายชั้นที่รวมถึงความเหมาะสมของการเรียกใช้เครื่องมือ (Tool calling) และเส้นทางการทำงาน (Execution trajectory) จะช่วยให้ค้นพบปัญหาได้รวดเร็วกว่า

การออกแบบการประเมิน AI Agent ให้มีประสิทธิภาพ ควรแบ่งออกเป็น 4 เลเยอร์ ดังนี้:

• เลเยอร์คำตอบสุดท้าย (Final Answer Layer): ตรวจสอบว่าผลลัพธ์ที่ส่งให้ผู้ใช้มีความถูกต้องและไม่มีอาการหลอน (Hallucination) หรือไม่ สามารถใช้วิธีเดียวกับการประเมิน LLM แบบเดิมได้ (เช่น การตรวจสอบความถูกต้องของคำตอบ หรือการใช้ LLM-as-Judge) แต่เพียงเท่านี้ยังไม่เพียงพอ
• เลเยอร์การเรียกใช้เครื่องมือ (Tool Calling Layer): ตรวจสอบว่ามีการเรียกใช้เครื่องมือใด ด้วยอาร์กิวเมนต์อะไร และเรียกกี่ครั้ง ตัวอย่างเช่น รูปแบบที่ไม่มีประสิทธิภาพอย่าง "การเรียกใช้เครื่องมือค้นหา 5 ครั้งด้วยคำค้นหาเดิมซ้ำๆ" ถือเป็นปัญหา แม้ว่าคำตอบสุดท้ายจะถูกต้องก็ตาม
• เลเยอร์เส้นทางการทำงาน (Trajectory Layer): ให้คะแนนว่าลำดับขั้นตอน การตัดสินใจแยกสาขา และการหยุดทำงาน เป็นไปตามที่คาดหวังหรือไม่ โดยการเปรียบเทียบกับชุดข้อมูลมาตรฐาน (Golden set) และบันทึกการทำงาน (Execution log) เพื่อให้คะแนนในระดับขั้นตอน
• เลเยอร์ต้นทุนและทรัพยากร (Cost & Resource Layer): วัดปริมาณการใช้โทเค็น จำนวนครั้งที่เรียกใช้ API และค่าความหน่วง (Latency) เนื่องจาก Agent ที่มีต้นทุนเกินงบประมาณไม่สามารถนำไปใช้งานจริงได้ จึงจำเป็นต้องเฝ้าระวังควบคู่ไปกับการจัดการการบริโภคที่แนะนำในบทความ Token Trap คืออะไร? แนวทางการจัดการเพื่อป้องกันค่าใช้จ่ายที่พุ่งสูงขึ้นอย่างคาดไม่ถึงของ AI Agent

เหตุผลที่ต้องประเมินทั้ง 4 เลเยอร์ไปพร้อมกัน เป็นเพราะแต่ละเลเยอร์สามารถเสื่อมประสิทธิภาพลงได้อย่างอิสระจากกัน

บทสรุป: คุณภาพของการประเมินขึ้นอยู่กับการออกแบบชุดข้อมูลทองคำ (Golden Dataset) จุดเริ่มต้นคือการเตรียมชุดข้อมูลสามส่วน ได้แก่ อินพุต, ลำดับเครื่องมือที่คาดหวัง และผลลัพธ์ที่คาดหวัง

ในการประเมินเอเจนต์ (Agent Evaluation) ต่างจากการทำ QA ทั่วไปตรงที่จำเป็นต้องมีกรณีตัวอย่างที่กำหนดไว้ด้วยว่า "ต้องเรียกใช้เครื่องมือใดและตามลำดับอย่างไร" ในหัวข้อ H3 ถัดไป จะอธิบายรายละเอียดเกี่ยวกับวิธีการออกแบบและการอัปเดตอย่างต่อเนื่องจากบันทึกการใช้งาน (Operation Logs)

ทีมที่อยู่ในขั้นตอน PoC มักจะเจอกับกำแพงที่ว่า "อยากสร้าง Golden Dataset แต่ไม่รู้ว่าต้องกำหนดอะไรและแค่ไหนถึงจะพอ"

กรณีของการประเมิน Agent นั้น แตกต่างจากการทดสอบ LLM ทั่วไป โดยจำเป็นต้อง กำหนด 3 องค์ประกอบควบคู่กัน ดังนี้:

• Input (อินพุต): คำพูดของผู้ใช้, บริบท (Context) และรายการเครื่องมือที่สามารถใช้งานได้
• Expected Tool Sequence (ลำดับเครื่องมือที่คาดหวัง): ชื่อเครื่องมือและลำดับที่ควรเรียกใช้ รวมถึง Schema ของอาร์กิวเมนต์ในแต่ละขั้นตอน
• Expected Output (ผลลัพธ์ที่คาดหวัง): ข้อกำหนดของคำตอบสุดท้าย (มักกำหนดเป็น "ข้อมูลที่ควรมี" แทนที่จะเป็นการจับคู่แบบตรงตัวทุกประการ)

ความละเอียดของลำดับเครื่องมือที่คาดหวังคือกุญแจสำคัญ หากกำหนดให้ลำดับ "ค้นหา → สรุปผล → สร้างคำตอบ" เป็นคำตอบที่ถูกต้อง คุณจำเป็นต้องตัดสินใจไว้ล่วงหน้าว่าจะจัดการกับกรณีที่มีการเรียกใช้ API ที่ไม่จำเป็นแทรกเข้ามา หรือกรณีที่มีการข้ามขั้นตอนการสรุปผลอย่างไร ว่าจะถือว่าเป็น "คำตอบที่ถูกต้องบางส่วน" (Partial Correct) หรือไม่

ตัวอย่างเช่น หากเป็น Agent สำหรับตรวจสอบสินค้าคงคลัง สามารถกำหนดได้ดังนี้:

ชุดข้อมูลทองคำ (Golden Set) ที่ออกแบบด้วยมือเปรียบเสมือน "ภาพนิ่ง" เนื่องจากเส้นทางการทำงานจริงที่เอเจนต์ใช้ในสภาพแวดล้อมการใช้งานจริงมีการเปลี่ยนแปลงอยู่ทุกวัน หากไม่มีการนำบันทึกการใช้งาน (Operational Logs) เข้ามาประมวลผลอย่างต่อเนื่อง กรณีทดสอบก็จะล้าสมัยไปอย่างรวดเร็ว

กระบวนการที่มีประสิทธิภาพในการแปลงบันทึกการใช้งานให้เป็นกรณีทดสอบ มีดังนี้:

• การรวบรวมบันทึก (Log Collection): บันทึกข้อมูลอินพุต, ลำดับการเรียกใช้เครื่องมือ (Tool calls), อาร์กิวเมนต์ และผลลัพธ์สุดท้ายที่เกิดขึ้นจริงในแต่ละคำขอไว้เป็นชุดข้อมูล
• การกรอง (Filtering): จัดลำดับความสำคัญในการคัดเลือกกรณีที่ผู้ใช้ให้ผลตอบรับเชิงลบอย่างชัดเจน, กรณีที่เกิดข้อผิดพลาดในการเรียกใช้เครื่องมือ และกรณีที่มีจำนวนขั้นตอนการทำงานสูงผิดปกติ
• การติดป้ายกำกับ (Labeling): ทำการระบุลำดับเครื่องมือที่คาดหวังและผลลัพธ์ที่คาดหวังให้กับบันทึกที่คัดเลือกมา โดยใช้แรงงานคนหรือใช้ LLM ช่วยในการทำ Annotation แล้วจึงเพิ่มเข้าไปในชุดข้อมูลทองคำ

สำหรับความถี่ในการอัปเดตนั้น แนวทางที่เหมาะสมคือการพิจารณาจาก 2 ปัจจัย ได้แก่ ช่วงเวลาที่มีการเปลี่ยนแปลงโมเดลหรือ Prompt และช่วงเวลาที่มีปริมาณการใช้งานจริงสะสมถึงระดับหนึ่ง เนื่องจากการทำ Annotation ใหม่ทั้งหมดทุกครั้งที่มีการเปลี่ยนแปลงต้องใช้ทรัพยากรสูง จึงแนะนำให้ใช้วิธี "การอัปเดตแบบเพิ่มขยาย" (Incremental Update) โดยเพิ่มเฉพาะกรณีที่เป็นส่วนต่างเท่านั้น

ข้อควรระวังในการนำบันทึกการใช้งานมาใช้ มีดังนี้:

บทสรุป: การประเมินการเรียกใช้เครื่องมือ (Tool Calling) มีพื้นฐานการประกันคุณภาพอยู่ที่การตรวจสอบ 3 แกนหลัก ได้แก่ การเลือกเครื่องมือ (Selection), อาร์กิวเมนต์ (Arguments) และลำดับการเรียกใช้ (Order)

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

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

การตรวจสอบการเลือกเครื่องมือ (Tool Selection) จะเปรียบเทียบชื่อเครื่องมือที่คาดหวังกับชื่อเครื่องมือที่เรียกใช้จริง โดยใช้การจับคู่แบบตรงตัว (Exact Match) หรือการจับคู่แบบมาตรฐาน (Normalized Match)

• คาดหวัง: search_db → จริง: search_db ✓
• คาดหวัง: search_db → จริง: search_web (เลือกเครื่องมือทดแทน) ✗

ในกรณีที่มีเครื่องมือหลายตัว หากเลือกเครื่องมือทดแทนที่มีความหมายใกล้เคียงกัน จะถือว่าเป็น "คำตอบที่ถูกต้อง" หรือไม่นั้น จำเป็นต้องกำหนดไว้ล่วงหน้าในนโยบายการประเมิน (Evaluation Policy)

การตรวจสอบอาร์กิวเมนต์ (Argument Validation) ต้องการการประเมินที่ละเอียดกว่าการเลือกเครื่องมือ หากอาร์กิวเมนต์เป็นข้อมูลที่มีโครงสร้าง (JSON) วิธีการตรวจสอบประเภทและช่วงของค่าในคีย์แทนการจับคู่แบบตรงตัวจะได้ผลดีกว่า สำหรับอาร์กิวเมนต์ที่เป็นรูปแบบข้อความอิสระ (เช่น คำค้นหา) ให้ใช้คะแนนความคล้ายคลึงทางความหมาย (Semantic Similarity Score) แทนการจับคู่แบบตรงตัว โดยกำหนดเกณฑ์ (Threshold) เพื่อตัดสินผ่านหรือไม่ผ่าน

การตรวจสอบลำดับการเรียกใช้ (Call Sequence Validation) คือการตรวจสอบว่าขั้นตอนที่มีความสัมพันธ์แบบพึ่งพากันนั้นเรียงลำดับอย่างถูกต้องหรือไม่ ตัวอย่างเช่น หากลำดับ "ดึงข้อมูลผู้ใช้ก่อนแล้วจึงค้นหาประวัติการสั่งซื้อ" สลับกัน อาจมีความเสี่ยงที่ขั้นตอนถัดไปจะอ้างอิงถึง ID ผู้ใช้ที่ไม่มีอยู่จริง ความถูกต้องของลำดับสามารถวัดเชิงปริมาณได้ด้วยระยะการแก้ไข (Levenshtein Distance) หรือการจับคู่ลำดับย่อย (Subsequence Matching)

ความเข้มงวดในการประเมินควรปรับใช้ให้เหมาะสมตามแต่ละกรณี

หลังจากตรวจสอบความถูกต้องของการเลือกเครื่องมือและอาร์กิวเมนต์แล้ว สิ่งที่มักถูกมองข้ามในหน้างานจริงคือปัญหาเรื่อง "การเรียกใช้งานที่เกินความจำเป็น" และ "การวนซ้ำไม่รู้จบ" (Infinite Loop) คุณได้ตรวจสอบผ่านการทดสอบแล้วหรือไม่ว่าเอเจนต์มีการเรียกใช้เครื่องมือเดิมซ้ำๆ หรือทำการค้นหาที่ไม่จำเป็นหลายครั้งหรือไม่?

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

การตรวจจับให้ใช้ตัวชี้วัดดังต่อไปนี้:

• การตรวจสอบขีดจำกัดจำนวนครั้งการเรียก: แจ้งเตือนหากจำนวนการเรียกใช้งานจริงเกินสัดส่วนที่กำหนดเมื่อเทียบกับจำนวนการเรียกที่คาดหวังในชุดข้อมูลมาตรฐาน (Golden Set)
• การตรวจจับการเรียกซ้ำ: ตรวจจับการเรียกใช้เครื่องมือเดิมด้วยอาร์กิวเมนต์เดิมติดต่อกันจากบันทึกการทำงาน (Log)
• การตรวจจับการเปลี่ยนผ่านที่ไม่ถูกต้อง: ระบุรูปแบบการวนลูป เช่น เครื่องมือ A → เครื่องมือ B → เครื่องมือ A โดยใช้กราฟวิถี (Trajectory Graph)

การตรวจจับการวนซ้ำ (Loop Detection) มีความสำคัญเป็นพิเศษ "สแต็กลูป" (Stack Loop) ที่เอเจนต์พยายามเรียกใช้งานเดิมซ้ำๆ หลังจากได้รับข้อความแสดงข้อผิดพลาด เป็นรูปแบบความล้มเหลวทั่วไปที่ทำให้สิ้นเปลือง Context Window และไม่สามารถไปถึงคำตอบสุดท้ายได้

จุดสำคัญในการนำไปใช้งานมี 2 ประการ:

• ตั้งค่าจำนวนขั้นตอนสูงสุด (เช่น 20 ขั้นตอน) ใน Evaluation Harness และให้ถือว่ากรณีที่เกินจำนวนนี้เป็นความล้มเหลวโดยอัตโนมัติ
• รวมตรรกะการตัดสินการวนซ้ำเข้าเป็นส่วนหนึ่งของ Assertion ในชุดข้อมูลมาตรฐาน (Golden Set) อย่างชัดเจน

[Token Trap คืออะไร?

บทสรุป: การให้คะแนนเส้นทางการทำงาน (Execution Trajectory) โดยพื้นฐานแล้วเป็นการผสมผสานระหว่างแนวทางการวัดระดับความสอดคล้องกับเส้นทางที่ถูกต้อง (Ground Truth) ในแต่ละขั้นตอน กับการใช้ LLM เป็นผู้ตัดสินเพื่อความยืดหยุ่นในการประเมิน

บทบาทของการให้คะแนนเส้นทางคือการประเมิน "ความเชื่อมโยงระหว่างขั้นตอน" ซึ่งไม่สามารถตรวจจับได้ด้วยการตรวจสอบการเรียกใช้เครื่องมือ (Tool Calling) เพียงอย่างเดียว โดยจะอธิบายรายละเอียดเกี่ยวกับการเลือกใช้ระหว่างการจับคู่เส้นทาง (Trajectory Matching) และการใช้ LLM เป็นผู้ตัดสินในหัวข้อ H3 ถัดไป

ในตอนแรก เรามักจะคิดว่าการประเมินเพียงแค่ว่า "ตรงกับวิถี (Golden Trajectory) หรือไม่" นั้นเพียงพอแล้ว แต่ในความเป็นจริง การให้คะแนนแบบรายขั้นตอนเพื่อดูว่าจุดไหนที่ถูกต้องและจุดไหนที่ผิดพลาด จะช่วยให้วงจรการปรับปรุงทำงานได้รวดเร็วกว่า

การจับคู่วิถี (Trajectory Matching) คือวิธีการตรวจสอบลำดับขั้นตอนที่เอเจนต์ได้ดำเนินการจริง เทียบกับลำดับขั้นตอนที่คาดหวังในชุดข้อมูล Golden Dataset โดยความละเอียดในการเปรียบเทียบแบ่งออกเป็น 2 ระดับหลัก ดังนี้:

การจับคู่แบบสมบูรณ์ (Exact Match)

• ตัดสินแบบ Binary ว่าชื่อเครื่องมือ อาร์กิวเมนต์ และลำดับการเรียกใช้งานตรงกันทั้งหมดหรือไม่
• มีต้นทุนในการติดตั้งต่ำ เหมาะสำหรับการตรวจจับการถดถอย (Regression) เทียบเท่ากับการทำ Unit Test
• เกิดผลบวกปลอม (False Positive) ได้ง่ายจากความแตกต่างเล็กน้อยในการแสดงผลของอาร์กิวเมนต์ (เช่น ความแตกต่างของการทำให้สตริงเป็นมาตรฐาน)

การให้คะแนนรายขั้นตอน (Step-Level Scoring)

• ให้คะแนนแต่ละขั้นตอนแยกจากกัน แล้วนำมารวมเป็นคะแนนของวิถีทั้งหมด
• ตัวอย่างเกณฑ์การให้คะแนน: ความถูกต้องของการเลือกเครื่องมือ (0/1), ความสอดคล้องเชิงความหมายของอาร์กิวเมนต์ (0-1), ความเหมาะสมของจังหวะเวลาในการเรียกใช้งาน (0/1)
• คะแนนสุดท้ายมักออกแบบโดยใช้สูตร "จำนวนขั้นตอนที่ถูกต้อง ÷ จำนวนขั้นตอนที่คาดหวัง" และเพิ่มบทลงโทษสำหรับขั้นตอนส่วนเกินที่ไม่จำเป็น

การนำการให้คะแนนรายขั้นตอนมาใช้ จะช่วยให้เห็นภาพความสำเร็จบางส่วนได้ เช่น "ภาพรวมล้มเหลว แต่ 3 ขั้นตอนแรกทำได้ถูกต้อง" ซึ่งจะช่วยจำกัดขอบเขตในการดีบั๊ก และทำให้ชัดเจนว่าควรแก้ไขที่จุดใดใน Prompt หรือคำจำกัดความของเครื่องมือ

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

การจับคู่เส้นทาง (Trajectory matching) แบบใช้กฎเกณฑ์ (Rule-based) อาจไม่สามารถรองรับได้ในบางกรณี ตัวอย่างเช่น หากมีลำดับการเรียกใช้เครื่องมือหลายรูปแบบเพื่อบรรลุวัตถุประสงค์เดียวกัน ทุกรูปแบบจะต้องถือว่าเป็น "คำตอบที่ถูกต้อง" ในสถานการณ์ที่ต้องการการให้คะแนนที่ยืดหยุ่นเช่นนี้ การประเมินเส้นทางโดยใช้ LLM จะแสดงศักยภาพออกมาได้ดี

สถานการณ์ที่ควรใช้และไม่ควรใช้การประเมินด้วย LLM นั้นสามารถแบ่งแยกได้อย่างชัดเจน หากต้องการตัดสินความสมเหตุสมผลของเส้นทางใน "ระดับความหมาย" การประเมินด้วย LLM จะมีประสิทธิภาพ แต่หากต้องการเพียงตรวจสอบความถูกต้องของชื่อเครื่องมือหรืออาร์กิวเมนต์แบบตรงตัว (Exact match) การใช้กฎเกณฑ์จะรวดเร็วและเสถียรกว่า

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

ข้อควรระวังในการนำไปใช้งานคือ การระบุเกณฑ์การให้คะแนนไว้อย่างชัดเจนใน System Prompt สำหรับ LLM ที่ใช้ประเมิน การส่งผ่านเกณฑ์การประเมินที่เฉพาะเจาะจง เช่น "แต่ละขั้นตอนจำเป็นต่อการบรรลุวัตถุประสงค์หรือไม่" หรือ "มีการเรียกใช้เครื่องมือที่ไม่จำเป็นหรือไม่" จะช่วยลดความคลาดเคลื่อนในการให้คะแนนได้ง่ายขึ้น นอกจากนี้ เนื่องจากตัวการประเมินด้วย LLM เองมีความไม่แน่นอน (Non-deterministic) จึงแนะนำให้ทำการประเมินเส้นทางเดิมซ้ำหลายครั้งและบันทึกการกระจายตัวของคะแนนไว้ด้วย

แม้จะใช้ Prompt เดียวกันรัน 10 ครั้ง แต่คำตอบที่ได้กลับแตกต่างกันทุกครั้ง นี่คือความยากลำบากที่เป็นหัวใจสำคัญของการประเมินผล AI Agent

ในการทดสอบซอฟต์แวร์แบบดั้งเดิม จะมีข้อสันนิษฐานว่า "Input เดียวกัน → Output เดียวกัน" แต่สำหรับ Agent ที่ใช้ LLM ข้อสันนิษฐานนี้กลับใช้ไม่ได้ผล แม้รันครั้งแรกจะ "ผ่าน" แต่ในการรันครั้งถัดไป Agent อาจเลือกเส้นทางอื่นจนนำไปสู่ความล้มเหลวได้ หากเราตัดสินผลผ่าน/ไม่ผ่านจากการรันเพียงครั้งเดียวเพื่อดู Regression เราก็จะมองข้ามความเสื่อมถอยที่ไม่เสถียรเหล่านี้ไปอย่างน่าเสียดาย

แล้วจะตรวจจับได้อย่างไร? แนวทางพื้นฐานคือการใช้ "การทดลองหลายครั้ง + เกณฑ์ทางสถิติ" ร่วมกัน โดยรันเคสเดิมซ้ำหลายๆ ครั้ง และตัดสินว่า "เกิด Regression" ก็ต่อเมื่ออัตราความสำเร็จลดลงต่ำกว่าเกณฑ์ที่กำหนดไว้เท่านั้น ตัวอย่างเช่น การตั้งเกณฑ์ว่า "หากไม่สำเร็จอย่างน้อย 8 ใน 10 ครั้ง ถือว่าไม่ผ่าน (NG)" โดยระดับของเกณฑ์สามารถปรับเปลี่ยนได้ตามความสำคัญของงาน หากเป็นการเรียกใช้เครื่องมือ (Tool calling) ที่สำคัญมากอาจต้องกำหนดไว้ที่ 90% ขึ้นไป แต่หากเป็นงานสรุปความทั่วไป อาจยอมรับได้ที่ 70%

สำหรับการนำไปรวมใน CI การรันชุดทดสอบเต็มรูปแบบทุกครั้งจะทำให้สิ้นเปลืองทั้งค่าใช้จ่ายและเวลา ดังนั้นการกำหนด Subset สำหรับตรวจจับ Regression แยกต่างหากจึงเป็นวิธีที่สมเหตุสมผลกว่า โดยให้จัดลำดับความสำคัญของเคสที่เคยล้มเหลวมาก่อน, เคสขอบเขต (Edge case) ที่พฤติกรรมเปลี่ยนแปลงง่าย และ Flow ที่มีผลกระทบต่อธุรกิจสูง การใช้กลยุทธ์สองขั้นตอนโดยรัน Subset นี้แบบเบาๆ ก่อน แล้วค่อยสลับไปรันชุดเต็มเฉพาะเมื่อพบผลลัพธ์ที่น่าสงสัย จะช่วยให้รักษาสมดุลระหว่างความเร็วและความครอบคลุม (Coverage) ได้ง่ายขึ้น

การตัดสิน "ผ่าน/ไม่ผ่าน" โดยการรันเอเจนต์ที่มีความไม่แน่นอนสูงเพียง "ครั้งเดียว" ก็เปรียบเสมือนการทอยลูกเต๋าเพียงครั้งเดียวเพื่อตัดสินคุณภาพ แม้จะเป็น Prompt เดิม แต่ในแต่ละครั้งที่รันอาจเกิดลำดับการเรียกใช้เครื่องมือ (Tool calling) หรือผลลัพธ์ระหว่างทางที่แตกต่างกัน ทำให้ไม่สามารถแยกแยะได้จากผลลัพธ์ของการทดลองเพียงครั้งเดียวว่า "ระบบพังจริงหรือแค่บังเอิญพลาด"

การรับประกันความเสถียรด้วยการทดลองหลายครั้ง

วิธีที่มีประสิทธิภาพคือการรัน Test case เดิมซ้ำหลายครั้งแล้วนำอัตราความสำเร็จมาคำนวณเป็นคะแนน

• เกณฑ์จำนวนครั้งในการทดลอง: สำหรับการทดสอบที่เทียบเท่ากับ Unit test แบบเบา ให้ทดลองจำนวนน้อยครั้ง ส่วนสถานการณ์สำคัญ (Critical scenario) ให้เพิ่มจำนวนครั้งให้มากขึ้น
• การออกแบบเกณฑ์อัตราความสำเร็จ (Threshold): กำหนดเกณฑ์ตามความสำคัญของเคส เช่น "ถือว่า PASS หากสำเร็จในสัดส่วนที่สูงจากจำนวนครั้งที่กำหนด"
• การตัดสินว่าเป็น Flaky: เคสที่มีอัตราความสำเร็จก้ำกึ่ง ให้ติดธงแยกไว้ว่าเป็น "Flaky" โดยไม่ต้องตัดสินว่าล้มเหลวในทันที แต่ให้ส่งเข้าคิวเพื่อตรวจสอบ

แนวทางการออกแบบเกณฑ์การตัดสิน (Pass/Fail Threshold)

ควรเลือกใช้เกณฑ์ที่แตกต่างกันตามประเภทของเคส

การออกแบบแบบไม่สมมาตร (Asymmetric design) ที่กำหนดให้เคสด้านความปลอดภัยต้องผ่าน 100% โดยไม่มีข้อยกเว้น ในขณะที่งานสร้างสรรค์ยอมรับความผันผวนได้นั้นเป็นแนวทางที่สมเหตุสมผล ทั้งนี้ ขอแนะนำให้กำหนดเกณฑ์ที่ชัดเจนโดยผ่านการตรวจสอบภายในบริษัทเอง ตามระดับความเสี่ยงที่ยอมรับได้และความสำคัญของเคสนั้นๆ

ในตอนแรก เรามักจะคิดว่า "การรันสคริปต์ประเมินผลด้วยตนเองในเครื่อง (Local) ก็เพียงพอแล้ว" แต่ในความเป็นจริง การนำไปรวมไว้ในไปป์ไลน์ CI (Continuous Integration) และรันโดยอัตโนมัติในทุก Pull Request จะช่วยตรวจพบการถดถอย (Regression) ได้รวดเร็วกว่า

ประเด็นสำคัญที่ควรคำนึงถึงในการนำไปรวมกับ CI มีดังนี้:

• การแยก Fast Lane/Slow Lane: หากรันทุกเคสในทุกครั้ง จะทำให้ต้นทุนและเวลาเพิ่มสูงขึ้น การรันเฉพาะ "Smoke Test" ที่ครอบคลุมเพียงสถานการณ์หลัก (Core Scenarios) ในช่วง Pull Request และรันชุดทดสอบเต็มรูปแบบ (Full Suite) ในช่วง Nightly Build จึงเป็นแนวทางที่สมเหตุสมผลกว่า
• การฝังเกณฑ์ตัดสินความไม่เสถียร (Flaky) ไว้ในการตั้งค่า CI: ระบุเกณฑ์ "ผ่าน M ครั้ง จาก N ครั้ง" ที่ออกแบบไว้ในส่วนก่อนหน้าให้เป็นเงื่อนไขการผ่าน/ไม่ผ่านของ CI อย่างชัดเจน การกำหนดให้บิลด์ล้มเหลวเฉพาะเมื่อไม่ผ่านเกณฑ์เท่านั้น จะช่วยลดการแจ้งเตือนที่ผิดพลาดจากสัญญาณรบกวน (Noise) ได้
• การตั้งค่า Regression Budget: กำหนดขีดจำกัดของการใช้โทเค็น, จำนวนการเรียกใช้ API และเวลาที่ใช้ต่อการรัน CI หนึ่งครั้งให้เป็น "Regression Budget" หากมีเคสที่ใช้ทรัพยากรเกินงบประมาณที่ตั้งไว้ ให้ถือว่าเป็นสัญญาณเตือนว่าถึงเวลาต้องทบทวน Golden Set แล้ว

เหตุผลที่ต้องมีการกำหนด Regression Budget ก็เพื่อป้องกันไม่ให้ต้นทุนในการประเมินผลเพิ่มขึ้นอย่างไม่มีขีดจำกัด การประเมินผลด้วยการเรียกใช้เครื่องมือ (Tool Use) หรือการให้คะแนนตามรอย (Trajectory Scoring) อาจมีการใช้ LLM เป็นตัวประเมิน ซึ่งทำให้เฟสการประเมินผลเองก็มีความเสี่ยงที่จะเกิดต้นทุนพุ่งสูงขึ้น ดังที่ได้อธิบายไว้ในบทความ Token Trap คืออะไร? แนวทางการจัดการการใช้งานเพื่อป้องกันต้นทุนแฝงที่พุ่งสูงขึ้นของ AI Agent

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

แม้จะมีการจัดเตรียมกรอบการประเมิน (Evaluation Framework) ไว้แล้ว แต่ในบางกรณีอาจเกิดการมองข้ามเนื่องจากความสดใหม่ของข้อมูลหรือความไม่สอดคล้องของขอบเขต (Scope) ในแต่ละหัวข้อ H3 ต่อไปนี้ จะอธิบายถึงตัวอย่างความล้มเหลวที่เป็นตัวแทนและวิธีการรับมืออย่างเป็นรูปธรรม

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

สาเหตุรากเหง้าของความคลาดเคลื่อนนี้ส่วนใหญ่มาจากการที่ข้อมูลที่ใช้ประเมินไม่ได้สะท้อนถึงพฤติกรรมของผู้ใช้งานจริงในสภาพแวดล้อมการใช้งานจริง หากยังคงใช้ Golden Set ที่สร้างขึ้นด้วยมือในช่วง PoC ต่อไปเรื่อยๆ ช่องว่างระหว่างข้อมูลนั้นกับรูปแบบอินพุตใหม่ๆ ที่สะสมอยู่ใน Log การใช้งานจริงก็จะยิ่งกว้างขึ้นเรื่อยๆ

สาเหตุของการเสื่อมถอยสามารถแบ่งออกได้เป็น 3 ประการหลัก ประการแรกคือ การเปลี่ยนแปลงของรูปแบบอินพุต (Input Distribution) ในช่วงแรกอาจเน้นไปที่รูปแบบคำถามที่คาดการณ์ไว้ แต่เมื่อการใช้งานดำเนินไป รูปแบบคำย่อ ภาษาพูด และงานที่ซับซ้อนจะเพิ่มมากขึ้น ประการที่สองคือ การเปลี่ยนแปลงของสเปกเครื่องมือ (Tool Specification) ซึ่งในบางกรณีเมื่อรูปแบบการตอบกลับของ External API เปลี่ยนไป แต่ค่าที่คาดหวัง (Expected Value) ในเคสการประเมินกลับไม่ได้รับการอัปเดตและถูกปล่อยทิ้งไว้ ประการสุดท้ายคือ การไม่สะท้อนฟีเจอร์ใหม่ๆ กล่าวคือ เป็นสถานการณ์ที่ยังคงรัน Regression Test ด้วย Golden Set ชุดเดิมแม้ว่าจะมีการเพิ่มเครื่องมือใหม่ให้กับ Agent แล้วก็ตาม

หากจะสรุปมาตรการรับมือกับปัญหาเหล่านี้ในคำเดียว ก็คือ 「การปฏิบัติกับข้อมูลประเมินเสมือนสิ่งมีชีวิต」 โดยรายละเอียดการดำเนินงานมีดังนี้

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

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

แล้วจะตรวจพบได้อย่างไร? วิธีที่มีประสิทธิภาพคือการเพิ่มขั้นตอนการตรวจสอบ Log การเรียกใช้เครื่องมือเข้าไปใน Evaluation Harness โดยการตรวจสอบสามประการนี้แบบอัตโนมัติ ได้แก่ ความสอดคล้องของลำดับเครื่องมือที่คาดหวังกับที่เรียกใช้จริง, ความเหมาะสมของ Schema ของอาร์กิวเมนต์ในแต่ละการเรียกใช้ และการเกินขีดจำกัดจำนวนครั้งในการเรียกใช้ เพียงเท่านี้ก็สามารถป้องกันการมองข้ามข้อผิดพลาดส่วนใหญ่ได้แล้ว

ดังที่ได้อธิบายไว้ใน Harness Engineering คืออะไร? วิธีการออกแบบเพื่อป้องกันความผิดพลาดของ AI Agent ด้วยโครงสร้าง การสร้างโครงสร้างให้กับ Evaluation Harness จะช่วยให้สามารถตรวจจับการใช้เครื่องมือผิดประเภทได้โดยอัตโนมัติ การออกแบบการประเมินที่ติดตามเพียงแค่ความถูกต้องของคำตอบสุดท้ายนั้น แม้จะทำให้คุณภาพดูสูงในระดับผิวเผิน แต่กลับเป็นการสะสมความเสี่ยงในการดำเนินงานไว้อย่างเงียบๆ

Q1. ควรเริ่มต้น Golden Dataset ด้วยขนาดเท่าใด?

ในเบื้องต้น การเริ่มต้นที่ประมาณ 20–50 เคสถือเป็นจุดที่เหมาะสมและทำได้จริง โดยให้เริ่มจากการรวบรวม "รูปแบบที่มักเกิดความล้มเหลว" จากบันทึกการใช้งานจริง (Production logs) หรือผลลัพธ์จาก PoC เป็นลำดับแรก เพื่อเตรียม Pipeline การประเมินในชุดข้อมูลขนาดเล็ก จากนั้นจึงค่อยๆ ขยายขนาดขึ้นเรื่อยๆ พร้อมกับการนำบันทึกการใช้งานจริงเข้ามาประมวลผลอย่างต่อเนื่อง ซึ่งวิธีนี้จะช่วยให้รักษาสมดุลระหว่างคุณภาพและปริมาณงานได้ดีที่สุด

---

Q2. จะตัดสิน "ผ่าน/ไม่ผ่าน" (Pass/Fail) สำหรับ Agent ที่มีความไม่แน่นอนสูงได้อย่างไร?

วิธีที่นิยมใช้กันทั่วไปคือการรันเคสเดิมซ้ำหลายๆ ครั้ง แล้วตัดสินจากอัตราความสำเร็จว่าเกินเกณฑ์ที่กำหนดหรือไม่ (เช่น สำเร็จ 4 ใน 5 ครั้ง) โดยควรตั้งค่าเกณฑ์ตามความเสี่ยงของธุรกิจ และหากตั้งค่า Regression budget แบบเป็นลำดับขั้นบน CI เช่น "แจ้งเตือนหากต่ำกว่าเกณฑ์ และถือว่าล้มเหลวหากต่ำกว่าเกณฑ์ติดต่อกัน 2 ครั้ง" จะช่วยลดการตรวจพบที่ผิดพลาดจากความไม่เสถียร (Flaky tests) ได้

---

Q3. ควรใช้ LLM ในการประเมินการเรียกใช้เครื่องมือ (Tool calling) หรือไม่? และแตกต่างจาก Rule-based อย่างไร?

สำหรับการตรวจสอบประเภทของอาร์กิวเมนต์ (Argument type check) หรือลำดับการเรียกใช้งาน วิธีแบบ Rule-based จะมีความรวดเร็วและเสถียรกว่า อีกทั้งยังนำไปรวมใน CI ได้ง่ายกว่า ในขณะที่ "ความสมเหตุสมผลเชิงความหมายของอาร์กิวเมนต์" หรือ "ความเหมาะสมในการตัดสินใจเรียกใช้ตามสถานการณ์" นั้นเป็นสิ่งที่ครอบคลุมด้วยกฎได้ยาก การใช้ LLM ให้คะแนนจึงเข้ามาทำหน้าที่เสริมในส่วนนี้ได้ดี ดังนั้น การผสมผสานทั้งสองวิธีเข้าด้วยกัน โดยใช้ Rule-based เป็นตัวกรองชั้นแรก และใช้ LLM เป็นตัวตรวจสอบชั้นที่สอง จึงเป็นแนวทางที่ใช้งานได้จริงที่สุด

---

Q4. มีมาตรฐานหรือข้อบังคับที่เกี่ยวข้องกับการออกแบบการประเมินหรือไม่?

NIST AI RMF 1.

บทสรุป: การประเมิน AI Agent จำเป็นต้องมีการออกแบบที่ตรวจสอบแบบหลายชั้น ไม่ใช่แค่คุณภาพของคำตอบสุดท้ายเท่านั้น แต่ยังรวมถึงความถูกต้องของการเรียกใช้เครื่องมือ (Tool calling) และเส้นทางการทำงาน (Execution trajectory) อีกด้วย

ในบทความนี้ เราได้สรุปภาพรวมของการประเมิน AI Agent เป็นขั้นตอนต่างๆ โดยมีประเด็นสำคัญดังนี้:

• Golden Dataset: ออกแบบโดยใช้ชุดข้อมูลสามส่วน ได้แก่ อินพุต, ลำดับเครื่องมือที่คาดหวัง และผลลัพธ์ที่คาดหวัง พร้อมทั้งอัปเดตอย่างต่อเนื่องจากบันทึกการใช้งานจริง (Operation logs)
• การประเมินการเรียกใช้เครื่องมือ: ตรวจสอบความถูกต้องของการเลือกเครื่องมือ, อาร์กิวเมนต์ และลำดับการทำงาน รวมถึงตรวจจับการเรียกใช้ที่ไม่จำเป็นหรือการวนลูป
• การให้คะแนนเส้นทางการทำงาน (Trajectory scoring): ผสมผสานการให้คะแนนรายขั้นตอนเข้ากับการประเมินเชิงความหมายโดย LLM
• การตรวจจับการถดถอย (Regression detection): ควบคุมผลกระทบจากความไม่แน่นอน (Non-determinism) ด้วยมาตรการป้องกันความผิดพลาดแบบสุ่ม (Flaky tests) ผ่านการทดลองหลายครั้งและการกำหนดเกณฑ์ผ่าน/ไม่ผ่าน
• การเชื่อมต่อกับ CI: กำหนดงบประมาณการถดถอย (Regression budget) เพื่อทำให้การตัดสินใจในการปล่อยซอฟต์แวร์เป็นไปโดยอัตโนมัติ และรับประกันคุณภาพด้วยแนวทาง Shift-left

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

ในมุมมองของการบริหารจัดการความเสี่ยงตามมาตรฐาน NIST AI RMF และ EU AI Act กลไกการตรวจสอบพฤติกรรมของ Agent อย่างต่อเนื่องจะยิ่งมีความสำคัญมากขึ้นในอนาคต เราขอแนะนำให้เริ่มจากการจัดเตรียม Golden Dataset ขนาดเล็กและ CI Pipeline จากนั้นจึงค่อยๆ ยกระดับความแม่นยำของการประเมินไปพร้อมกับการสะสมข้อมูลการใช้งานจริง