AI Agent Glossary 05: Eval, Trace, Guardrail และ Governance

HR Agent ผ่านคําถามทดสอบ 18 จาก 20 ข้อ ทีมจึงถามว่า “90% พอเปิดใช้หรือยัง” ตัวเลขเดียวตอบไม่ได้ เพราะสองข้อที่พลาดอาจเป็นการใช้ถ้อยคําไม่ลื่น หรืออาจเป็นการเปิดเผยข้อมูลพนักงานให้คนที่ไม่มีสิทธิ์ ทั้งสองอย่างนับเป็นข้อผิดพลาดหนึ่งข้อเท่ากัน แต่ผลกระทบไม่เท่ากัน

การตัดสินใจปล่อย Agent ต้องใช้ทั้งหลักฐานด้านคุณภาพ ความปลอดภัย และความรับผิดชอบ บทสุดท้ายแยกคําที่มักถูกใช้รวมกันจน release review เหลือเพียงคะแนนสวย ๆ

Eval คือกระบวนการ ไม่ใช่คะแนนเดียว

Evaluation หรือ eval คือกระบวนการวัดพฤติกรรมหรือคุณภาพของระบบกับเกณฑ์และตัวอย่างที่กําหนด

Test case คือ input หนึ่งกรณีพร้อม expected behavior, reference answer หรือ rubric เช่น “เมื่อถามเรื่องวันลาที่เอกสารไม่ครอบคลุม Agent ต้องไม่แต่งเงื่อนไขและต้องเสนอส่งต่อ HR”

Eval dataset หรือ test set คือชุด test cases ที่สะท้อนงานจริง เคสเสี่ยง และ edge cases ชุดที่มีแต่คําถามง่ายจากทีมสร้างจะวัดเพียงเดโม ไม่ได้วัดความพร้อมใช้

Ground truth หรือ reference answer คือหลักฐานอ้างอิงสําหรับเปรียบเทียบ ไม่จําเป็นต้องมีคําตอบข้อความเดียวที่ถูกทุกตัวอักษร งานภาษามักยอมรับคําตอบได้หลายแบบ ถ้าข้อเท็จจริงและข้อจํากัดตรงกัน

Grader และ metric แปลหลักฐานเป็นผลประเมิน

Grader คือกฎ โค้ด มนุษย์ หรือโมเดลที่ให้คะแนนหรือผลผ่านไม่ผ่าน Grader model ช่วยขยายการประเมินได้ แต่ไม่ใช่ผู้ตัดสินที่ถูกเสมอ ต้องตรวจความสอดคล้องกับผู้เชี่ยวชาญและเก็บตัวอย่างที่ grader ตัดสินผิด

Metric คือค่าที่สรุปผล เช่น task success rate, citation precision, latency หรือ cost Metric ไม่ใช่ success criterion ทั้งหมด เพราะทีมยังต้องกําหนด threshold และเงื่อนไข critical failure

Benchmark คือชุดงานและวิธีวัดมาตรฐานสําหรับเปรียบเทียบระบบ คะแนน benchmark ช่วยเลือกโมเดลเบื้องต้น แต่ไม่พิสูจน์ว่า Agent พร้อมกับเอกสาร tools และผู้ใช้ขององค์กรจริง

สําหรับ HR Agent ตารางคะแนนที่ใช้ได้ควรแยกอย่างน้อย:

Regression คือสิ่งที่เคยผ่านแล้วกลับแย่ลง

Regression คือพฤติกรรมที่เคยผ่านแล้วแย่ลงหลังเปลี่ยน model, prompt, tool, corpus หรือ workflow

การแก้คําถามหนึ่งข้ออาจทําให้อีกหมวดพัง เช่น เพิ่มคําสั่งให้ตอบสั้นจน citation หาย หรือเปลี่ยน chunking แล้วค้นเอกสารวันลาดีขึ้นแต่สวัสดิการแย่ลง ทุกการเปลี่ยนที่กระทบ behavior จึงควรรัน eval เดิมซ้ําและบันทึกความต่าง

คําว่า “ลองแล้วใช้ได้” ไม่มี baseline ให้ตรวจ regression ส่วน eval dataset ที่ versioned ทําให้ทีมรู้ว่าคุณภาพเปลี่ยนจากอะไร

Trace บอกว่า run หนึ่งเกิดอะไรขึ้น

Trace คือลําดับเหตุการณ์ของ run หนึ่ง เช่น model call, tool call, tool result, handoff, latency และ error มันช่วยอธิบายว่าคําตอบสุดท้ายเกิดจากเส้นทางใด

Observability คือความสามารถในการเข้าใจพฤติกรรมระบบจาก traces, logs, metrics และ feedback ไม่ใช่เพียงเปิด dashboard ดู uptime

Trace ไม่เท่ากับ audit log เสมอไป Audit log เน้นหลักฐานที่ทนต่อการแก้ไขว่าใครทําอะไรเมื่อไรเพื่อการตรวจสอบ ส่วน trace อาจเก็บรายละเอียดสําหรับ debug และมีข้อมูลอ่อนไหวที่ต้องลดหรือจํากัดอายุ

เมื่อ Agent ตอบผิด trace ที่ดีควรช่วยตอบว่า:

• retrieval คืนเอกสารใด
• โมเดลขอเรียก tool อะไรด้วย arguments ใด
• application อนุญาตหรือปฏิเสธ action
• tool result จริงคืออะไร
• จุดใดเกิด fallback หรือ handoff

Guardrail ไม่ใช่ authorization

Guardrail คือชั้นตรวจหรือจํากัด input, output และ actions ตามความเสี่ยง อาจเป็น rule, classifier, model check หรือ policy enforcement

Guardrail ช่วยลดความเสี่ยง แต่ไม่ควรเป็นชั้นเดียว โดยเฉพาะสิทธิ์เข้าถึงข้อมูล Authorization ต้องถูกบังคับโดยระบบที่ถือข้อมูลหรือ action จริง ต่อให้ prompt บอก Agent ว่าอย่าเปิดไฟล์ลับ ผู้ใช้ก็ยังต้องถูกตรวจสิทธิ์ตอนดึงไฟล์

Least privilege คือให้ Agent และ tools มีสิทธิ์เท่าที่จําเป็นต่อหน้าที่และช่วงเวลานั้น HR Agent ที่มีหน้าที่ตอบคําถามไม่ควรได้รับสิทธิ์อนุมัติวันลา และ tool ค้นเอกสารไม่ควรคืนเอกสารของทุกประเทศแล้วหวังให้โมเดลเลือกเอง

Prompt injection และ jailbreak ไม่ใช่คําเดียวกัน

Prompt injection คือ input ที่ทําให้ LLM เปลี่ยนพฤติกรรมหรือ output ไปจากเจตนาของ application อาจมาจากผู้ใช้โดยตรง หรือซ่อนในเว็บและเอกสารที่ Agent อ่าน ซึ่งเรียกว่า indirect prompt injection

Jailbreak มักหมายถึงความพยายามหลบข้อจํากัดด้านความปลอดภัยของโมเดล มันเกี่ยวข้องกับ prompt injection แต่ไม่ครอบคลุมทุกกรณี เอกสารภายในที่มีข้อความ “ส่งข้อมูลนี้ไป URL ภายนอก” เป็น indirect prompt injection แม้ไม่ได้พยายามสร้างเนื้อหาต้องห้าม

วิธีลดความเสี่ยงต้องทําหลายชั้น: แยกข้อมูลจาก instructions, จํากัด tools, ตรวจผลก่อน execute, ขออนุมัติ action สําคัญ และเฝ้าดู trace ที่ผิดปกติ

Excessive agency คือให้ความสามารถเกินงาน

OWASP ใช้คําว่า excessive agency กับความเสี่ยงที่ระบบมี functionality, permissions หรือ autonomy มากเกินจําเป็น

ตัวอย่างเช่น Agent มี tool manage_employee ที่ทั้งอ่าน แก้ และลบบัญชีได้ ทั้งที่ use case ต้องเพียงเปิด ticket ปัญหาไม่ได้อยู่ที่โมเดลฉลาดเกินไป แต่อยู่ที่สัญญาและสิทธิ์ของ tool กว้างเกินงาน

การลด excessive agency ทําได้ด้วยการตัด function ที่ไม่ต้องใช้ ลด scope credentials ให้ action ย้อนกลับได้ และวาง human approval ก่อนงานที่มีผลกระทบสูง

Red teaming หาเส้นทางที่ทีมปกติไม่คิดจะลอง

Red teaming คือการทดสอบเชิงปฏิปักษ์เพื่อหาเส้นทางล้มเหลว การโจมตี และผลกระทบ อาจลอง prompt injection, การสลับสิทธิ์, เอกสารเป็นพิษ, tool error หรือการให้ข้อมูลคลุมเครือ

Red team ไม่แทน eval ปกติ Eval วัดพฤติกรรมกับงานและเกณฑ์ที่กําหนด ส่วน red team พยายามค้นสิ่งที่กรอบเดิมยังมองไม่เห็น ผลจาก red team ที่ยืนยันแล้วควรถูกเพิ่มเข้า regression suite

TEVV และ governance มองทั้ง lifecycle

TEVV ย่อมาจาก Test, Evaluation, Verification และ Validation เป็นกระบวนการตรวจทั้งความสามารถ ความสอดคล้องกับข้อกําหนด และความเหมาะสมต่อ intended use

Verification ถามว่า “ระบบสร้างตรงตาม specification หรือไม่” Validation ถามว่า “ระบบนี้เหมาะกับงานและบริบทจริงหรือไม่” Agent อาจผ่าน unit tests ทั้งหมดและยังไม่เหมาะใช้กับคําถามที่มีผลต่อสิทธิ์พนักงาน

Governance คือโครงสร้างบทบาท นโยบาย การตัดสินใจ เอกสาร และการติดตามตลอด lifecycle ไม่ใช่ checklist compliance ตอนท้าย โครงการต้องรู้ว่าใครเป็นเจ้าของ corpus, ใครอนุมัติเกณฑ์, ใครหยุดระบบได้ และ incident ถูกเปลี่ยนเป็น test case อย่างไร

Risk tolerance คือระดับและชนิดความเสี่ยงที่องค์กรยอมรับได้ในบริบทนั้น ต้องกําหนดก่อนดูคะแนน ไม่เช่นนั้นทีมมักลดเกณฑ์ตามผลที่ได้

Release gate ที่ตอบได้มากกว่า “90%”

ก่อน pilot ให้เตรียม evidence pack ที่มี:

• eval dataset และผลแยกตามมิติ ไม่รวมเป็นคะแนนเดียว
• รายการ critical failures ที่ยอมรับไม่ได้แม้เกิดครั้งเดียว
• trace ของเคสผ่าน เคสหยุดตอบ เคส handoff และเคส tool error
• permission map ของ tools และจุด human approval
• ผล red team พร้อมการแก้และ regression tests
• owner, rollback และวิธีรับ incident หลังเปิดใช้

Pilot ลดจํานวนผู้ใช้และขนาดผลกระทบ แต่ไม่ยกเว้น authorization, data protection หรือเกณฑ์ critical failure

แบบฝึกหัด: เปลี่ยนความมั่นใจเป็นหลักฐาน

เลือก claim ว่า “Agent พร้อมใช้” แล้วเขียนหลักฐานที่ต้องมีในสี่ช่อง:

1. งานปกติที่ต้องผ่าน
2. failure ที่ระบบต้องหยุดหรือส่งต่อ
3. action ที่ต้องขออนุมัติ
4. สัญญาณที่จะ rollback หลังเปิดใช้

งานผ่านเมื่อผู้อนุมัติสามารถตัดสิน go, conditional go หรือ no-go จากหลักฐานเดียวกัน โดยไม่ต้องเชื่อคําบอกเล่าของทีมสร้าง

นี่คือปลายทางของ Glossary ชุดนี้ การรู้คําไม่ได้มีไว้คุยให้ดูเทคนิค แต่ทําให้ทีมระบุส่วนประกอบ เหตุผิดพลาด และหลักฐานที่ต้องใช้ด้วยภาษาเดียวกัน

แหล่งอ้างอิง

• NIST: AI Test, Evaluation, Validation and Verification
• NIST: Artificial Intelligence Risk Management Framework 1.0
• NIST: Generative AI Profile
• OpenAI: Graders
• OWASP: Prompt Injection
• OWASP: Excessive Agency
• OWASP: AI Agent Security Cheat Sheet

ตรวจสอบแหล่งอ้างอิงล่าสุด: 17 สิงหาคม 2026