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

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

ในบทความนี้ เราจะอธิบายเนื้อหาต่อไปนี้สำหรับผู้รับผิดชอบงานด้าน AI BPO และการทำระบบอัตโนมัติในองค์กร:

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

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

การประเมิน AI แบบดั้งเดิมมักถูกออกแบบโดยเน้นที่ความแม่นยำเป็นหลักว่า "สามารถตอบคำถามเดียวได้อย่างถูกต้องหรือไม่" ซึ่งตัวอย่างที่เห็นได้ชัดคือการตรวจสอบข้อความผลลัพธ์ด้วย BLEU score หรือ F1 score หรือการวัดค่าความแม่นยำ (Accuracy) ในงานด้านการจำแนกประเภท (Classification tasks)

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

ความแตกต่างหลักระหว่างการประเมินแบบดั้งเดิมกับการประเมินเอเจนต์ มีดังนี้:

• หน่วยการประเมิน: แบบดั้งเดิมคือ "1 อินพุต → 1 เอาต์พุต" ในเทิร์นเดียว ส่วนเอเจนต์จะครอบคลุมทั้งเส้นทาง (Trajectory) ของหลายเทิร์น ได้แก่ "การวางแผน → การเรียกใช้เครื่องมือ (Tool call) → การอัปเดตสถานะ → การดำเนินการถัดไป"
• นิยามของความสำเร็จ: แบบดั้งเดิมคือความถูกต้องของข้อความผลลัพธ์ ส่วนเอเจนต์จำเป็นต้องพิจารณาทั้งสองด้าน คือ ความสำเร็จในการบรรลุเป้าหมายสุดท้าย (Agent Goal Accuracy) และความถูกต้องในการเลือกใช้เครื่องมือในแต่ละขั้นตอน (Tool Call Accuracy)
• ลักษณะของข้อผิดพลาด: แบบดั้งเดิมคือข้อผิดพลาดในเอาต์พุตเพียงอย่างเดียว ส่วนเอเจนต์จะเกิดการแพร่กระจายของข้อผิดพลาด (Error propagation) ที่ความผิดพลาดระหว่างขั้นตอนส่งผลกระทบต่อกระบวนการถัดไป จึงจำเป็นต้องมีการออกแบบการประเมินที่สามารถติดตามได้ว่าข้อผิดพลาดเกิดขึ้นที่ขั้นตอนใดและเกิดจากอะไร
• บทบาทของผู้ประเมิน: แบบดั้งเดิมมักจบลงด้วยการตรวจสอบโดยมนุษย์หรือการเทียบกับข้อความอ้างอิง ส่วนเอเจนต์นั้น การใช้ LLM-as-a-Judge (ซึ่ง NVIDIA แนะนำว่าควรใช้โมเดลที่มีขนาด 70B พารามิเตอร์ขึ้นไป) ร่วมกับการประเมินอัตโนมัติได้กลายเป็นทางเลือกที่ใช้งานได้จริง

ด้วยเหตุนี้ "ระดับความละเอียด" (Granularity) และ "แกนเวลา" (Time axis) ของการประเมินจึงมีความแตกต่างกันโดยพื้นฐาน

AI แบบงานเดี่ยว (Single-task AI) แบบดั้งเดิม เช่น การแปล การจำแนกประเภท หรือการสรุปความ จะจบลงในขั้นตอนเดียวคือ "อินพุต → เอาต์พุต" ด้วยเหตุนี้ จึงสามารถประเมินได้อย่างเพียงพอด้วยตัวชี้วัดแบบคงที่ เช่น ความแม่นยำ (Accuracy) หรือ F1 Score อย่างไรก็ตาม ในเวิร์กโฟลว์แบบอัตโนมัติ (Autonomous Workflow) เอเจนต์จะเรียกใช้เครื่องมือหลายอย่างพร้อมกับตัดสินใจจากผลลัพธ์ระหว่างทาง และกำหนดขั้นตอนถัดไปด้วยตนเอง "การตัดสินใจแบบต่อเนื่อง" (Chain-of-thought decision making) นี้คือเหตุผลพื้นฐานที่ตัวชี้วัดที่มีอยู่ไม่สามารถรองรับได้

ตัวอย่างเช่น ลองพิจารณาการแพร่กระจายของข้อผิดพลาด หากการตัดสินใจที่ผิดพลาดในขั้นตอนที่ 2 ส่งผลให้เอาต์พุตในขั้นตอนที่ 5 เสียหายอย่างเงียบๆ การมองเพียงแค่เอาต์พุตสุดท้ายจะไม่สามารถระบุสาเหตุที่แท้จริงได้ นอกจากนี้ แม้จะทำถูกต้อง 9 จาก 10 ขั้นตอน แต่หากล้มเหลวในขั้นตอนสุดท้าย การประเมินแบบทวิภาค (Binary evaluation) ก็จะบันทึกเพียงแค่ "ล้มเหลว" เท่านั้น การประเมินที่ไม่สะท้อนถึงความพยายามที่สะสมมาตลอดทางแทบจะไม่ให้เบาะแสในการปรับปรุงเลย ยิ่งไปกว่านั้น จำเป็นต้องตรวจสอบว่ามีการเรียกใช้เครื่องมือที่ถูกต้องด้วยอาร์กิวเมนต์ที่ถูกต้องหรือไม่ โดยแยกจากความถูกต้องของคำตอบสุดท้าย นอกจากนี้ เนื่องจากมีความไม่แน่นอน (Non-determinism) ที่เส้นทางการทำงานอาจเปลี่ยนไปแม้จะใช้พรอมต์เดิม จึงจำเป็นต้องมีการประเมินทางสถิติหลายครั้งแทนที่จะสรุปผลจากการประเมินเพียงครั้งเดียว

ทิศทางการออกแบบการประเมินจะเปลี่ยนไปตามลักษณะของงาน หากเป็นแบบอัตโนมัติเต็มรูปแบบ (Fully autonomous) ที่เอเจนต์ตัดสินใจตั้งแต่ต้นจนจบ การใช้ Goal Accuracy หรือ Task Completion Rate เป็นหลักถือว่าเหมาะสม ในทางกลับกัน หากเป็นแบบทำงานร่วมกับมนุษย์ (Human-in-the-Loop) การออกแบบที่ให้ความสำคัญกับจังหวะเวลาในการส่งต่องาน (Handoff) และคุณภาพของการส่งต่องานมากกว่าความแม่นยำสุดท้ายจะเป็นวิธีที่มีประสิทธิภาพมากกว่า

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

ประเภทของเอเจนต์ที่เป็นตัวแทนมีดังนี้:

• เอเจนต์แบบจบในเทิร์นเดียว (Single-turn completion agent): มีโครงสร้างเรียบง่ายโดยการตอบกลับ 1 ครั้งต่อการป้อนข้อมูล 1 ครั้ง ตัวอย่างทั่วไปคือ RAG Chatbot หรือบอทตอบคำถาม FAQ ซึ่งมี Answer Accuracy และ Topic Adherence เป็นแกนหลักในการประเมิน
• เอเจนต์แบบใช้เครื่องมือหลายขั้นตอน (Multi-step tool-use agent): เป็นประเภทที่ทำงานให้สำเร็จโดยการเรียกใช้ API ภายนอกหรือฐานข้อมูลหลายครั้ง ซึ่ง Tool Call Accuracy และ Trajectory Evaluation จะมีความสำคัญ นอกจากนี้ Policy Adherence Rate ที่ IBM ระบุไว้ก็มีความหมายอย่างยิ่งสำหรับเอเจนต์ประเภทนี้
• เอเจนต์แบบทำงานร่วมกันหลายตัว (Multi-agent collaboration): เป็นโครงสร้างที่ Orchestrator ทำงานร่วมกับ Sub-agent หลายตัว เนื่องจากคุณภาพของการส่งต่องานระหว่างเอเจนต์ (Handoff) ส่งผลต่อคุณภาพโดยรวม จึงจำเป็นต้องใช้ตัวชี้วัดอย่าง Agent Handoff F1-Score (HF1)
• เอเจนต์แบบมีมนุษย์เข้ามาเกี่ยวข้อง (Human-in-the-loop): เป็นการออกแบบที่มอบหมายการตัดสินใจบางส่วนให้กับมนุษย์ ซึ่งมักใช้ในหน้างาน AI BPO โดยจำเป็นต้องรวมอัตราความเหมาะสมในการยกระดับปัญหา (Escalation appropriateness) และความล่าช้าในการตอบกลับ ซึ่งไม่สามารถวัดได้ด้วยการประเมินอัตโนมัติเพียงอย่างเดียว เข้าเป็นส่วนหนึ่งของการประเมินด้วย

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

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

หลายคนมักคิดว่า "ลองประเมินทุกฟังก์ชันไปเลยดีกว่า" แต่ในความเป็นจริง การจำกัดขอบเขต (Scope) และเริ่มจากเวิร์กโฟลว์ที่มีความสำคัญสูงจะช่วยให้วงจรการปรับปรุงทำงานได้รวดเร็วกว่า

ก่อนเริ่มการประเมิน สิ่งที่ต้องถามก่อนคือการกำหนดวัตถุประสงค์ให้ชัดเจนว่า "ประเมินเอเจนต์ไปเพื่ออะไร" เพราะตัวชี้วัดที่ต้องวัดและความถี่ในการประเมินจะเปลี่ยนไปตามจุดประสงค์ ไม่ว่าจะเป็นการประกันคุณภาพ (Quality Assurance), การตัดสินใจปล่อยใช้งาน (Release decision) หรือการตรวจสอบประสิทธิภาพอย่างต่อเนื่อง

มุมมองที่ควรตรวจสอบในการกำหนดขอบเขต (Scope)

• ขอบเขตของเวิร์กโฟลว์เป้าหมาย: ระบุให้ชัดเจนว่าเป็นเพียงการเรียกใช้เครื่องมือเดียว หรือเป็นแบบหลายขั้นตอน (Multi-step) ที่เอเจนต์หลายตัวทำงานร่วมกัน
• ผลกระทบต่อผู้ใช้งานและธุรกิจ: กำหนดให้งานที่มีความเสี่ยงสูงหากเกิดความล้มเหลว (เช่น การประมวลผลการเรียกเก็บเงิน, การบริการลูกค้า) เป็นเป้าหมายในการประเมินลำดับแรก
• ความละเอียดของการประเมิน: แยกแยะให้ชัดเจนว่าจะดูความสำเร็จของงานแบบ End-to-end หรือดูความแม่นยำในการเรียกใช้เครื่องมือแต่ละตัว

สิ่งที่ต้องตัดสินใจในการกำหนดเป้าหมาย (Goal)

• เกณฑ์ตัดสินผ่าน/ไม่ผ่าน (เช่น อ้างอิงมาตรฐานอุตสาหกรรมในการกำหนดเกณฑ์ของบริษัท โดยนิยามของ ServiceNow เช่น Overall task completeness ที่ 90-100% คือ Excellent และ 70-89% คือ Good)
• ความถี่ของวงจรการประเมิน (ทุกครั้งที่ Deploy, รายสัปดาห์ หรือรายเดือน)
• ผู้รับผิดชอบผลการประเมินและขั้นตอนการตัดสินใจ

หากเริ่มการประเมินโดยที่ขอบเขตและเป้าหมายยังคลุมเครือ แม้จะรวบรวมบันทึก (Log) ได้มหาศาล ก็จะมองเห็นได้ยากว่า "ควรแก้ไขตรงไหน" การเลือกเวิร์กโฟลว์ที่เป็นตัวแทน 1-2 รายการมาทดลองกระบวนการประเมินทั้งหมดก่อน จะช่วยให้การขยายผลไปยังเวิร์กโฟลว์อื่นๆ เป็นไปอย่างราบรื่น

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

ในการออกแบบข้อมูลทดสอบ ขอแนะนำให้เตรียมข้อมูล 3 ประเภทดังนี้:

• Happy Path: สถานการณ์ที่เอเจนต์ทำงานได้ตามที่คาดหวังด้วยอินพุตที่เป็นปกติ
• Edge Case: อินพุตที่เป็นข้อยกเว้น เช่น คำสั่งที่คลุมเครือ ข้อมูลที่ไม่สมบูรณ์ หรือความล้มเหลวในการเรียกใช้เครื่องมือ
• Regression Case: สถานการณ์ที่จำลองข้อผิดพลาดหรือการทำงานที่ผิดปกติที่เคยเกิดขึ้นในอดีต

การรวมข้อมูลทั้ง 3 ประเภทนี้ไว้อย่างสมดุลจะช่วยป้องกันการประเมินอัตราความสำเร็จสูงเกินจริง

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

ในส่วนของปริมาณข้อมูล ควรมีตัวอย่างอย่างน้อยหลายสิบรายการขึ้นไปสำหรับงานแต่ละประเภท หากมีตัวอย่างน้อยเกินไป คะแนนแบบทวิภาค (Binary score) เช่น Agent Goal Accuracy จะมีความแปรปรวนทางสถิติสูง ทำให้ยากต่อการตัดสินใจว่าการปรับปรุงนั้นได้ผลจริงหรือไม่

นอกจากนี้ สิ่งสำคัญคือข้อมูลทดสอบควรมีการกระจายตัวที่ใกล้เคียงกับข้อมูลที่ใช้ในการทำงานจริง (Production data)

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

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

องค์ประกอบหลักที่ควรจัดเตรียมมีดังนี้:

• Distributed Tracing: กำหนด Trace ID ที่ไม่ซ้ำกันให้กับแต่ละขั้นตอนของ Agent และบันทึกความสัมพันธ์แบบพ่อแม่-ลูกระหว่างขั้นตอน
• Tool Call Logs: จัดเก็บชื่อเครื่องมือ พารามิเตอร์อินพุต ค่าที่ส่งกลับ และสถานะความสำเร็จ/ล้มเหลวในรูปแบบ Structured Log
• LLM Inference Logs: บันทึกข้อความ Prompt ทั้งหมด ผลลัพธ์จากโมเดล จำนวน Token และ Latency เพื่อให้สามารถนำกลับมาทำซ้ำได้ในภายหลัง
• Error Classification Tags: จัดหมวดหมู่ประเภทของข้อผิดพลาดด้วย Tag เช่น Timeout, Tool Failure, หรือ Invalid Output เพื่อให้ง่ายต่อการรวบรวมข้อมูล

ความละเอียดของล็อกเป็นสิ่งที่ต้องแลกเปลี่ยนกับต้นทุน ในสภาพแวดล้อมการใช้งานจริง แนวทางที่เหมาะสมคือการปรับอัตราการสุ่มตัวอย่าง (Sampling Rate) ในขณะที่ยังคงจัดเก็บ Trace ของความล้มเหลวไว้ทั้งหมด

บทสรุป: การวัดอัตราความสำเร็จของเอเจนต์จำเป็นต้องใช้ตัวชี้วัดหลายประการร่วมกัน เช่น อัตราการทำภารกิจสำเร็จ (Task Completion Rate), ความแม่นยำของขั้นตอน (Step Accuracy) และความคุ้มค่าของต้นทุน (Cost Efficiency)

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

ในการประเมิน Agent ครั้งแรก ทีมงานมักจะพยายามตัดสินว่า "งานเสร็จสมบูรณ์หรือไม่" ด้วยค่าแบบทวิภาค (สำเร็จ/ล้มเหลว) แต่ในความเป็นจริง หากเราเหมารวมกรณีที่ดำเนินการได้ถูกต้องจนถึงขั้นตอนกลางทางว่าเป็น "ความล้มเหลว" ทั้งหมด เราจะสูญเสียเบาะแสในการปรับปรุงไป การวัดค่าอัตราความสำเร็จบางส่วน (Partial Completion Rate) ควบคู่ไปด้วยจะช่วยให้ระบุคอขวดได้ง่ายขึ้น

อัตราความสำเร็จของงาน (Task Success Rate / TSR) หมายถึงสัดส่วนของสถานการณ์ที่ Agent สามารถบรรลุเป้าหมายสุดท้ายได้ ในระบบการประเมินของ ServiceNow คะแนน Overall task completeness จะถูกบันทึกเป็น 3 ระดับ คือ "3: Successful / 2: Partially successful / 1: Unsuccessful" และจัดการด้วยป้ายกำกับตั้งแต่ Excellent (90–100%) ไปจนถึง Poor (0–49%)

อัตราความสำเร็จบางส่วน (Partial Completion Rate) คือสัดส่วนของกรณีที่จัดอยู่ในกลุ่ม "Partially successful" โดยมีจุดวัดผลหลักดังนี้:

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

เมื่อนำตัวชี้วัดทั้งสองมาใช้ร่วมกัน จะทำให้เห็นสถานะที่ว่า "อัตราความสำเร็จต่ำ แต่อัตราความสำเร็จบางส่วนสูง" ได้ชัดเจนขึ้น

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

ความแม่นยำของขั้นตอน หมายถึง สัดส่วนของขั้นตอนที่ดำเนินการเสร็จสิ้นตามที่คาดหวัง จากการกระทำทั้งหมดที่เอเจนต์ได้ดำเนินการ (เช่น การเรียกใช้เครื่องมือ, การตัดสินใจแยกสาขา, การดึงข้อมูล เป็นต้น) โดย Trajectory Evaluation และ Tool Call Accuracy ของ NVIDIA NeMo ได้ใช้แนวคิดนี้เป็นพื้นฐานในการบันทึกความถูกต้องของแต่ละขั้นตอนด้วยคะแนนตั้งแต่ 0 ถึง 1

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

เกณฑ์ในการพิจารณาสามารถสรุปได้ดังนี้:

• กรณีที่มีจำนวนขั้นตอนน้อย (ภายใน 3-5 ขั้นตอน): มักจะสามารถวัดคุณภาพได้จากอัตราความสำเร็จของงานเพียงอย่างเดียว
• กรณีที่มีจำนวนขั้นตอนมากหรือมีการแยกสาขาที่ซับซ้อน: ควรวัดความแม่นยำของขั้นตอนและอัตราการแพร่กระจายของข้อผิดพลาดแยกต่างหาก เพื่อระบุให้ชัดเจนว่าข้อผิดพลาดมักเกิดขึ้นที่ขั้นตอนใด

ในวงจรการปรับปรุง เราจะกำหนดให้ขั้นตอนที่มีอัตราการแพร่กระจายของข้อผิดพลาดสูงเป็น "โหนดวิกฤต (Critical Node)" เพื่อจัดเก็บข้อมูลบันทึก (Log) เป็นลำดับความสำคัญแรก และนำไปใช้ในการปรับปรุง Prompt หรือทบทวนการออกแบบเครื่องมือต่อไป

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

จุดวัดค่า Latency ที่สำคัญ

• End-to-End Latency: ระยะเวลารวมตั้งแต่ได้รับคำขอจากผู้ใช้จนถึงการส่งการตอบกลับขั้นสุดท้าย
• Step-by-Step Latency: การแยกบันทึกเวลาของแต่ละขั้นตอน เช่น การอนุมานของ LLM (LLM Inference), การเรียกใช้เครื่องมือ (Tool Calling) และการรอ API ภายนอก
• P95 / P99 Percentile: การดูค่าเฉลี่ยเพียงอย่างเดียวไม่พอ การวัดค่า Percentile จะช่วยให้เข้าใจความถี่ของอาการหน่วงที่เกิดขึ้นผิดปกติ (Latency Spikes) ได้

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

จุดวัดค่าความคุ้มค่าของต้นทุน (Cost Efficiency)

• Token Cost per Task: การรวบรวมจำนวน Token ขาเข้าและขาออกที่ใช้จนจบหนึ่งงานจากบันทึก (Log)
• Tool Call Count: การตรวจสอบว่ามีการวนซ้ำที่ไม่จำเป็นหรือการเรียกใช้ซ้ำซ้อนหรือไม่
• Cost per Successful Task: การนำต้นทุน (Cost) ซึ่งเป็นหนึ่งในดัชนีหลักที่ IBM ระบุไว้ มาหารด้วยจำนวนงานที่สำเร็จ เพื่อให้สามารถวัดความคุ้มค่าเชิงปริมาณได้

แนวทางการปฏิบัติในการวัดผล

เราสามารถบริหารจัดการ Latency และต้นทุนแบบรวมศูนย์ได้ โดยการบันทึก Timestamp และปริมาณการใช้ Token ในระดับ Span ลงในระบบ Tracing

บทสรุป: การประเมินคุณภาพสามารถจัดระบบได้ด้วย 3 ขั้นตอน คือ "การทดสอบตามสถานการณ์ (Scenario Test) → การประเมินโดยมนุษย์และ LLM-as-a-Judge → การติดตามผลอย่างต่อเนื่อง (Continuous Monitoring)"

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

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

ในการทดสอบแบบสถานการณ์จำลอง (Scenario Testing) เราจะแบ่งขั้นตอนการทำงานที่เอเจนต์ต้องรับผิดชอบจริงออกเป็น 3 ประเภท ได้แก่ "Happy Path", "Error Path" และ "Boundary Case"

• Happy Path (กรณีปกติ): งานสามารถดำเนินการจนเสร็จสิ้นได้ด้วยอินพุตตามที่คาดหวังหรือไม่
• Error Path (กรณีผิดปกติ): สามารถจัดการได้อย่างเหมาะสมภายใต้เงื่อนไขที่เกิดข้อผิดพลาด เช่น ขาดพารามิเตอร์ที่จำเป็น หรือการเรียกใช้เครื่องมือล้มเหลวหรือไม่
• Boundary Case (กรณีขอบเขต): สามารถเลือกเครื่องมือได้ถูกต้องโดยไม่ผิดพลาดในกรณีที่เป็นขอบเขต (Edge case) เช่น อินพุตมีความคลุมเครือ หรือมีเป้าหมายที่ขัดแย้งกันหรือไม่

สิ่งสำคัญคือต้องกำหนดทั้ง "ลำดับการเรียกใช้เครื่องมือที่คาดหวัง" และ "ผลลัพธ์สุดท้าย" ไว้ในแต่ละสถานการณ์จำลอง ในบรรดาตัวชี้วัดหลักที่ IBM ระบุไว้ Success rate / task completion และ Error rate สามารถวัดผลได้โดยตรงในขั้นตอนนี้

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

1. ผลการผ่าน/ไม่ผ่าน (Pass / Fail) ของแต่ละสถานการณ์จำลอง
2. ความแม่นยำในการเรียกใช้เครื่องมือ (เรียกใช้เครื่องมือที่ถูกต้องตามลำดับที่ถูกต้องหรือไม่)
3. การมีอยู่ของการดำเนินการกู้คืนเมื่อเกิดข้อผิดพลาด

Tool Call Accuracy และ Trajectory Evaluation ของ NVIDIA NeMo สอดคล้องกับการรวบรวมข้อมูลนี้ ซึ่งสามารถเปรียบเทียบเชิงปริมาณได้ในช่วงคะแนน 0.0 ถึง 1.0

เมื่อตรวจสอบความถูกต้องด้านฟังก์ชันการทำงานผ่าน Scenario Test เรียบร้อยแล้ว ขั้นตอนถัดไปคือการประเมินด้านคุณภาพว่า "การตอบสนองหรือการกระทำนั้นมีความเป็นธรรมชาติและแม่นยำเพียงใด" ซึ่งปัญหาที่หน้างานมักต้องเผชิญคือภาวะกลืนไม่เข้าคายไม่ออกที่ว่า "ต้องการทำระบบอัตโนมัติแต่ก็กังวลเรื่องความแม่นยำ" เพื่อสร้างสมดุลในจุดนี้ แนวทางที่ใช้กันอย่างแพร่หลายคือการผสมผสานระหว่างการประเมินโดยมนุษย์ (Human Evaluation) และ LLM-as-a-Judge

แนวคิดพื้นฐานในการเลือกใช้คือความเรียบง่าย โดยตัดสินจากว่าสามารถนิยามความถูกผิดของผลลัพธ์ได้อย่างชัดเจนหรือไม่ สำหรับสิ่งที่คำตอบมีความตายตัว เช่น ความถูกต้องของการเรียกใช้เครื่องมือ (Tool Call Accuracy) หรือการตัดสินแบบสองสถานะ (Binary Classification) ว่างานสำเร็จหรือไม่ ให้ใช้ LLM-as-a-Judge ในการให้คะแนนอัตโนมัติ ส่วนเกณฑ์การตัดสินที่มีความคลุมเครือ เช่น ความเป็นธรรมชาติของคำตอบ ความเหมาะสมทางจริยธรรม และความสอดคล้องกับบริบททางธุรกิจ ให้ความสำคัญกับการประเมินโดยมนุษย์เป็นอันดับแรก

ในการใช้ LLM-as-a-Judge ต้องระวังว่าขนาดของโมเดล Judge LLM ส่งผลโดยตรงต่อความแม่นยำในการประเมิน จากข้อมูล Agent Goal Accuracy ของ NVIDIA NeMo พบว่าการใช้โมเดลที่มีพารามิเตอร์ 70B ขึ้นไป หรือแนะนำที่มากกว่า 405B จะช่วยเพิ่มความแม่นยำได้ เมทริกซ์ที่ให้คะแนนเป็นช่วง 0.0 ถึง 1.0 เช่น Tool Call Accuracy หรือ Topic Adherence นั้นเหมาะสมกับการให้คะแนนอัตโนมัติ และการระบุเกณฑ์การให้คะแนน (Rubric) ไว้ใน Prompt สำหรับการประเมินจะช่วยให้มั่นใจได้ถึงความสามารถในการทำซ้ำของคะแนน

ในทางกลับกัน การให้มนุษย์ประเมินข้อมูลทั้งหมดมักไม่สมเหตุสมผลในแง่ของต้นทุน ดังนั้นในการปฏิบัติงานจริง จึงนิยมใช้แนวทางที่ให้ความสำคัญกับการนำตัวอย่างที่ LLM-as-a-Judge ให้คะแนนต่ำหรือตัวอย่างที่อยู่ใกล้ค่าขอบเขต (Boundary values) ส่งต่อให้มนุษย์ตรวจสอบเป็นอันดับแรก การแชร์เกณฑ์การประเมินและตัวอย่างที่เป็นรูปธรรมให้กับผู้ตรวจสอบล่วงหน้า จะช่วยลดความคลาดเคลื่อนระหว่างผู้ประเมินได้ง่ายขึ้น

ด้วยระบบสองขั้นตอน (Two-tiered approach) นี้ จะช่วยให้สามารถสร้างสมดุลระหว่างความสามารถในการขยายระบบ (Scalability) และความแม่นยำในการประเมินได้

「ผ่านการทดสอบตามสถานการณ์จำลอง (Scenario Test) แล้ว แต่กลับไม่มีใครสังเกตเห็นความผิดปกติหลังจากเริ่มใช้งานจริง」——การป้องกันสถานการณ์เช่นนี้คือบทบาทของการติดตามผลอย่างต่อเนื่อง (Continuous Monitoring)

การประเมินเพียงครั้งเดียวไม่สามารถตรวจจับความเสื่อมสภาพที่เกิดขึ้นตามช่วงเวลาได้ เช่น การเบี่ยงเบนของพฤติกรรมโมเดล (Model Behavior Drift) หรือการเปลี่ยนแปลงข้อกำหนดของ API ภายนอก การสร้างระบบสังเกตการณ์แบบเรียลไทม์ในสภาพแวดล้อมการใช้งานจริงจึงเป็นสิ่งจำเป็นสำหรับการรักษาคุณภาพของเอเจนต์

ตัวชี้วัดหลักที่ควรติดตามในการมอนิเตอร์

• แนวโน้มอัตราความสำเร็จของงาน (Task Completion Rate): อ้างอิงจากเกณฑ์ของ ServiceNow โดยตรวจสอบเป็นรายสัปดาห์ว่าสามารถรักษาเกณฑ์ Excellent (90% ขึ้นไป) ได้หรือไม่
• อัตราความสำเร็จในการเรียกใช้เครื่องมือ (Tool Call Success Rate): หาก Tool Call Accuracy เริ่มลดลง ให้สงสัยว่ามีการเปลี่ยนแปลงข้อกำหนดของ API ภายนอกหรือเครื่องมือภายใน
• ความหน่วงและต้นทุน (Latency & Cost): ตั้งค่าการแจ้งเตือนเมื่อเวลาตอบสนองเฉลี่ยหรือปริมาณการใช้โทเค็นเกินกว่าค่ามาตรฐานที่กำหนดไว้ในสัดส่วนที่ระบุ
• อัตราข้อผิดพลาด (Error Rate): เฝ้าระวังแบบเรียลไทม์ว่ามีข้อยกเว้นที่ไม่คาดคิดหรือการหยุดชะงักของงานเพิ่มขึ้นอย่างรวดเร็วหรือไม่

แนวคิดในการตั้งค่าการแจ้งเตือน (Alert)

การออกแบบการแจ้งเตือนแบบ 2 ชั้น ประกอบด้วย 「เกณฑ์แบบคงที่ (Static Threshold)」 และ 「เกณฑ์อัตราการเปลี่ยนแปลง (Change Rate Threshold)」 จะให้ผลลัพธ์ที่มีประสิทธิภาพ

• เกณฑ์แบบคงที่: แจ้งเตือนทันทีหากอัตราความสำเร็จของงานต่ำกว่า 70%
• เกณฑ์อัตราการเปลี่ยนแปลง: แจ้งเตือนหากอัตราข้อผิดพลาดแย่ลงกว่าสัปดาห์ก่อนหน้าตั้งแต่ 20% ขึ้นไป

การใช้บริการที่มีการจัดการ (Managed Service) เช่น Amazon Bedrock AgentCore Evaluations จะช่วยให้คุณสามารถสร้างไปป์ไลน์ตั้งแต่การรวบรวมบันทึก (Log) ไปจนถึงการส่งการแจ้งเตือนได้ในระยะเวลาอันสั้น

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

เรามักตัดสินว่า "หากอัตราการทำภารกิจสำเร็จ (Task Completion Rate) สูง แสดงว่าคุณภาพไม่มีปัญหา" แต่ในความเป็นจริง การใช้เพียงตัวชี้วัดเดียวมักทำให้เกิดความเสี่ยงที่มองไม่เห็นสะสมอยู่

ความผิดพลาดที่พบบ่อยในการประเมิน Agent คือการไล่ตามตัวชี้วัดเพียงอย่างใดอย่างหนึ่ง ตัวอย่างเช่น หากกำหนดให้ Task Completion Rate เป็น KPI เพียงตัวเดียว จะเกิดจุดบอดดังต่อไปนี้:

• ไม่เห็นคุณภาพในแต่ละขั้นตอน: แม้ภารกิจจะถูกตัดสินว่า "สำเร็จ" ในท้ายที่สุด แต่อาจมีกรณีที่มีการเรียกใช้เครื่องมือโดยไม่จำเป็นระหว่างทาง หรือมีร่องรอยของการแก้ไขข้อผิดพลาดด้วยตนเองหลงเหลืออยู่
• ละเลยต้นทุนและเวลาแฝง (Latency): ต่อให้อัตราความสำเร็จสูง แต่หากจำนวนครั้งในการเรียกใช้ LLM ต่อหนึ่งภารกิจหรือต้นทุนเกินขอบเขตที่ยอมรับได้ ก็ไม่สามารถนำไปใช้งานจริงได้
• การละเมิดนโยบายถูกปกปิด: เช่นเดียวกับที่ IBM ได้ชี้ให้เห็นถึง Policy adherence rate สถานะการปฏิบัติตามกฎระเบียบภายในบริษัทหรือข้อกฎหมายจะไม่ถูกสะท้อนอยู่ในอัตราความสำเร็จ

ในกรอบการประเมินของ ServiceNow มีการแนะนำให้บันทึก Overall task completeness และ Tool performance record แยกออกจากกัน เพื่อแยกการประเมินระหว่าง "ทำสำเร็จหรือไม่" กับ "ใช้เครื่องมือถูกต้องหรือไม่" ออกจากกัน

สำหรับการปรับปรุง ควรติดตามตัวชี้วัดอย่างน้อย 3 แกนควบคู่กันไป ดังนี้:

1. ตัวชี้วัดผลลัพธ์ (Outcome Metrics): อัตราการทำภารกิจสำเร็จ / อัตราการทำภารกิจสำเร็จบางส่วน
2. ตัวชี้วัดกระบวนการ (Process Metrics): ความแม่นยำในการเรียกใช้เครื่องมือ / จำนวนขั้นตอน

เอเจนต์ที่ทำคะแนนได้สูงในสภาพแวดล้อมทดสอบ (Test Environment) อาจมีประสิทธิภาพลดลงอย่างรวดเร็วหลังจากนำไปใช้งานจริง "ปัญหาช่องว่าง" (Gap Problem) นี้เป็นหนึ่งในหลุมพรางที่มักถูกมองข้ามในขั้นตอนการออกแบบการประเมิน

สาเหตุส่วนใหญ่แบ่งออกเป็นสามระดับ ประการแรกคือความคลาดเคลื่อนของการกระจายตัวของข้อมูลนำเข้า (Input Distribution) เนื่องจากข้อมูลทดสอบมักเน้นไปที่สถานการณ์ที่ถูกจัดรูปแบบไว้แล้ว ทำให้ในหลายกรณีเอเจนต์ไม่สามารถรับมือกับคำสั่งที่คลุมเครือ คำผิด หรือภาษาพูดที่เกิดขึ้นจริงในการใช้งานได้ ประการที่สองคือความแตกต่างของสถานะเครื่องมือและ API ในสภาพแวดล้อมทดสอบมักใช้ Mock ที่ส่งการตอบกลับปกติเสมอ ในขณะที่การใช้งานจริงอาจเกิดเหตุการณ์ API ภายนอกหมดเวลา (Timeout) หรือมีการเปลี่ยนแปลงสเปกอย่างกะทันหัน ประการที่สามคือความแตกต่างของความยาวบริบท (Context Length) ในการใช้งานจริงเมื่อประวัติการสนทนายาวขึ้น ข้อผิดพลาดที่เกิดจากบริบทล้น (Context Overflow) ซึ่งไม่ปรากฏในระหว่างการทดสอบจะเริ่มชัดเจนขึ้น

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

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

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

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

สิ่งแรกที่ควรให้ความสำคัญคือการระบุคอขวด (bottleneck) ว่า "ความล้มเหลวเกิดขึ้นกระจุกตัวอยู่ที่ขั้นตอนใด" แนวทางการแก้ไขจะแตกต่างกันโดยสิ้นเชิงระหว่างกรณีที่อัตราความสำเร็จของงาน (task success rate) ต่ำในภาพรวม กับกรณีที่ความล้มเหลวเกิดขึ้นบ่อยครั้งเฉพาะกับการเรียกใช้เครื่องมือ (tool call) บางตัว กรณีแรกจำเป็นต้องทบทวนการออกแบบคำสั่งใน Prompt ใหม่ทั้งหมด ส่วนกรณีหลังมีแนวโน้มสูงว่าปัญหาอยู่ที่การกำหนดอินเทอร์เฟซของเครื่องมือหรือ Schema ของอินพุต/เอาต์พุต

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

เมื่อดำเนินการปรับปรุงแล้ว ต้องทำการวัดผลซ้ำด้วยชุดข้อมูลประเมิน (evaluation set) ชุดเดิมเสมอ แม้คะแนนจะดีขึ้น แต่สิ่งสำคัญคือต้องตรวจสอบด้วยว่าตัวชี้วัดอื่น ๆ แย่ลงโดยไม่ตั้งใจหรือไม่ ตัวอย่างเช่น การลดจำนวนครั้งในการเรียกใช้เครื่องมือเพื่อหวังจะลด Latency อาจส่งผลให้อัตราความสำเร็จของงานลดลง ซึ่งเป็น Trade-off ที่เกิดขึ้นได้จริง การติดตามตัวชี้วัดหลายตัวควบคู่กันไปแทนที่จะดูเพียงตัวเลขเดียว จะช่วยให้ตรวจพบผลข้างเคียงเหล่านี้ได้ตั้งแต่เนิ่นๆ

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

ขั้นตอนการระบุคอขวด (Bottleneck)

• ตรวจสอบ Trace Log: เรียงลำดับอัตราความสำเร็จ Latency และประเภทของข้อผิดพลาดแยกตามขั้นตอน เพื่อหาจุดที่คะแนนลดลงอย่างรวดเร็ว
• จัดหมวดหมู่ข้อผิดพลาด: รวบรวมจำนวนเหตุการณ์แยกตามประเภทข้อผิดพลาด เช่น การเรียกใช้เครื่องมือล้มเหลว (Tool call failure), อาการประสาทหลอน (Hallucination) หรือการติดอยู่ในลูป (Loop)
• ดำเนินการทดสอบซ้ำ (Reproduction test): จำลองสถานการณ์ที่ล้มเหลวในระดับหน่วยที่เล็กที่สุด เพื่อแยกแยะว่าสาเหตุมาจาก Prompt หรือการออกแบบเครื่องมือ (Tool design)

หากตัดสินได้ว่าสาเหตุของคอขวดอยู่ที่ Prompt แนวทางต่อไปนี้จะมีประสิทธิภาพ:

แนวทางการปรับปรุง Prompt ที่สำคัญ

• ปรับความละเอียดของคำสั่ง (Granularity): การเปลี่ยนคำสั่งที่คลุมเครือให้เป็นคำอธิบายขั้นตอนที่ชัดเจน มักจะช่วยลดข้อผิดพลาดในการเลือกเครื่องมือลงได้
• ทบทวนความยาวของบริบท (Context length): ตัดข้อมูลที่ไม่จำเป็นออกและคัดกรองข้อมูลที่ Agent ควรใช้อ้างอิงให้กระชับขึ้น สำหรับรายละเอียดเพิ่มเติม สามารถดูได้ที่ บทนำสู่ Context Engineering | ก้าวต่อไปของการออกแบบ Prompt
• เพิ่มตัวอย่างแบบ Few-shot: ใส่ตัวอย่างคำตอบที่ถูกต้องสำหรับรูปแบบที่เคยล้มเหลวลงใน Prompt เพื่อเพิ่มความแม่นยำในการตัดสินใจ

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

หากยังมีปัญหาที่การปรับปรุง Prompt ไม่สามารถแก้ไขได้ ขั้นตอนถัดไปคือการทำ Fine-tuning และการทบทวนการออกแบบเครื่องมือ (Tool design) อย่างไรก็ตาม การคิดตั้งแต่ต้นว่า "ถ้าทำ Fine-tuning แล้วความแม่นยำจะเพิ่มขึ้น" นั้นถือว่าด่วนสรุปเกินไป ในความเป็นจริงมักมีสาเหตุมาจากความบกพร่องในการออกแบบเครื่องมือมากกว่า ดังนั้นการตรวจสอบจุดนั้นก่อนจะเป็นวิธีที่มีประสิทธิภาพมากกว่า

การทำ Fine-tuning จะมีประสิทธิภาพเฉพาะในสถานการณ์ที่จำกัด เช่น กรณีที่โมเดลล้มเหลวซ้ำๆ ในเรื่องคำศัพท์หรือรูปแบบภาษาของโดเมนเฉพาะ, กรณีที่รูปแบบผลลัพธ์ (Output format) ไม่เสถียรด้วยการใช้เพียง Prompt หรือกรณีที่คะแนน Tool Call Accuracy ต่ำอย่างต่อเนื่อง

ในทางกลับกัน หากคำจำกัดความของอาร์กิวเมนต์ในการเรียกใช้เครื่องมือมีความคลุมเครือ หรือ Schema ของค่าที่ส่งกลับ (Return value) ไม่เป็นมาตรฐาน ควรปรับปรุงข้อกำหนดของเครื่องมือ (Tool specification) ก่อนการทำ Fine-tuning ก่อนที่จะเริ่มกระบวนการเรียนรู้ที่มีค่าใช้จ่ายสูง เราควรตรวจสอบจุดที่ต้องทบทวนในการออกแบบเครื่องมือไปทีละจุดครับ

Q1. ตัวชี้วัดการประเมิน AI Agent แตกต่างจากการประเมิน Chatbot แบบเดิมอย่างไร?

การประเมิน Chatbot แบบเดิมเน้นไปที่ความถูกต้องของการตอบกลับในแต่ละครั้ง (เช่น ความแม่นยำของคำตอบ หรือคะแนน BLEU) ในขณะที่การประเมิน AI Agent จะประเมินจากห่วงโซ่ของการกระทำที่เป็นอิสระ เช่น อัตราความสำเร็จของงานโดยรวมที่ครอบคลุมหลายขั้นตอน, ความแม่นยำในการเรียกใช้เครื่องมือ (Tool Call Accuracy) และการบรรลุเป้าหมาย (Agent Goal Accuracy) ความแตกต่างที่สำคัญคือการมุ่งเน้นไปที่คุณภาพของกระบวนการทั้งหมด ไม่ใช่แค่การตอบกลับเพียงเทิร์นเดียว

Q2. Agentic Success Rate (ASR) และ Task Success Rate (TSR) แตกต่างกันอย่างไร?

Task Success Rate (TSR) คือตัวชี้วัดที่ตัดสินแบบสองค่า (Binary) ว่า "งานเสร็จสมบูรณ์หรือไม่" ในทางกลับกัน Agentic Success Rate (ASR) จะพิจารณาถึงสถานะการเปลี่ยนผ่าน (State Transition) ที่ Agent ผ่านไประหว่างทาง โดยแบ่งการประเมินออกเป็น Transition Recall และ Transition Precision เนื่องจาก TSR เพียงอย่างเดียวอาจทำให้มองข้ามกรณีที่ "บังเอิญทำสำเร็จ แต่ขั้นตอนระหว่างทางไม่มีประสิทธิภาพ" ได้ การใช้ ASR ควบคู่ไปด้วยจึงช่วยให้เข้าใจถึงคุณภาพของกระบวนการได้ดียิ่งขึ้น

Q3. Judge LLM ที่ใช้ในการประเมินจำเป็นต้องมีขนาดเท่าใด?

ตามเอกสารอย่างเป็นทางการของ NVIDIA NeMo ระบุว่า Judge LLM จำเป็นต้องมีขนาดอย่างน้อย 70B พารามิเตอร์ และแนะนำให้ใช้รุ่นที่มีขนาดมากกว่า 405B พารามิเตอร์ หากใช้โมเดลขนาดเล็กเป็น Judge ความแม่นยำในการตัดสินความแตกต่างเล็กน้อยจะลดลง ส่งผลให้ความน่าเชื่อถือของผลการประเมินลดลงตามไปด้วย หากมีข้อจำกัดด้านต้นทุน การใช้ Judge LLM ขนาดใหญ่เฉพาะในสถานการณ์ที่สำคัญ และใช้การประเมินแบบอิงกฎ (Rule-based) ควบคู่ไปในส่วนอื่นถือเป็นแนวทางที่ใช้งานได้จริง

Q4. ควรตีความคะแนน Overall Task Completeness ของ ServiceNow อย่างไร?

ตามนิยามของ ServiceNow คะแนน Overall Task Completeness จะถูกบันทึกเป็น 3 ระดับ ได้แก่ 3 (Successful), 2 (Partially successful) และ 1 (Unsuccessful) นอกจากนี้ยังมีการกำหนดป้ายกำกับอัตราความสำเร็จไว้เป็น Excellent (90–100%), Good (70–89%), Moderate (50–69%) และ Poor (0–49%) ในการใช้งานจริง มักจะกำหนดให้ระดับ Good ขึ้นไปเป็นเกณฑ์ขั้นต่ำ และให้ความสำคัญกับการปรับปรุงสถานการณ์ที่อยู่ในระดับ Moderate ลงไปก่อน

Q5. หากจัดทำตัวชี้วัดการประเมินแล้วแต่ไม่นำไปสู่การปรับปรุง ควรทบทวนที่จุดใด?

หากวัดผลแล้วแต่การปรับปรุงไม่คืบหน้า ในหลายกรณีมีสาเหตุมาจาก "ความละเอียดของตัวชี้วัดหยาบเกินไปจนไม่สามารถระบุคอขวดได้" ขั้นแรกควรเพิ่มตัวชี้วัดที่มีความละเอียดสูงขึ้น เช่น อัตราการแพร่กระจายของข้อผิดพลาดในแต่ละขั้นตอน หรือความแม่นยำในการเรียกใช้เครื่องมือ แทนที่จะดูเพียงค่าสรุปอย่างอัตราความสำเร็จของงานเพียงอย่างเดียว จากนั้นให้ตรวจสอบ Trace Log ของสถานการณ์ที่ล้มเหลวอย่างละเอียด เพื่อแยกแยะว่าปัญหาอยู่ที่การออกแบบ Prompt, การกำหนดนิยามเครื่องมือ (Tool Definition) หรือคุณภาพการตอบกลับของ External API ท่านสามารถดูข้อมูลเพิ่มเติมเพื่อเป็นแนวทางในการปรับปรุงได้ที่ บทนำสู่ Context Engineering | ก้าวต่อไปของการออกแบบ Prompt