ประเมิน AI Agent ให้​เป็น — Evals

ความคืบหน้า0 / 8 บทเรียน

เส้น​ทางการ​เรียน

1. ●01ทำไม eval ของ agent ต่างจาก test ปกติเริ่มตรงนี้
   • Evalการวัดผลอย่างเป็นระบบว่า output ของ AI agent (เช่น ops-copilot) ถูกต้องและมีประโยชน์จริงหรือไม่ ด้วยชุดเกณฑ์และกรณีทดสอบที่ชัดเจน แทนการดูจากความรู้สึกว่า 'ตอบดูดี' — จำเป็นเพราะ agent เป็นระบบหลายขั้นตอนที่ความผิดพลาดสะสมทบกันได้ และแต่ละรอบก็ไม่ได้เดินทางเดิมเป๊ะทุกครั้ง
   • Pass^kตัวชี้วัดความน่าเชื่อถือที่นับว่า agent ต้องผ่าน 'ทุกครั้ง' ใน k รอบที่รันซ้ำเคสเดิม ไม่ใช่แค่ผ่านสักครั้งใน k ครั้งแบบ pass@k — มาจากงาน τ-bench ที่ชี้ว่า agent ที่สุ่มถูกบางครั้งยังใช้งานจริงไม่ได้ ต้องวัดความนิ่งข้ามหลายรอบจึงจะเชื่อถือได้
   • Agentic Loopวงจรที่ agent ทำซ้ำจนกว่าจะบรรลุเป้าหมาย: รับ input → วางแผน → เรียก tool → สังเกตผลลัพธ์ → วนกลับไปตัดสินใจใหม่ — ยิ่งวงจรนี้ยาวและมีหลายขั้นตอน ยิ่งมีโอกาสที่ความผิดพลาดต่อขั้นจะสะสมทบกัน (ผิด 5% ต่อขั้น 10 ขั้น อาจเหลือถูกแค่ราว 60%) จึงต้องมี Eval ที่มองทั้ง Trajectory เป็นตาข่ายเสริม ไม่ใช่มองแค่ผลลัพธ์สุดท้ายอย่างเดียว
2. ○02Failure taxonomy — ตั้งชื่อความพลาดก่อนวัด
   • Failure Taxonomyหมวดหมู่ความผิดพลาดที่ได้จากการทำ Open Coding ซ้ำหลายรอบจนเห็นแพทเทิร์นซ้ำ ๆ เช่น วางแผนผิด (Planning Failure), เรียก tool ถูกตัวแต่ได้ผลลัพธ์ผิดเอง (tool-execution failure), หรือแผนถูกแต่ใช้ขั้นตอน/เวลา/ต้นทุนเกินจำเป็น (efficiency failure) — ใช้จัดลำดับว่าจะแก้ปัญหาไหนก่อนเพราะกระทบมากที่สุด
   • Planning Failureความผิดพลาดหมวดหลักที่เกิดตอน agent วางแผนผิดตั้งแต่ต้น เช่น เลือกเรียก tool ที่ไม่มีอยู่จริง เรียก tool ถูกตัวแต่ใส่ parameter ผิดชนิด/ผิดค่า (เช่น คืนเงิน ฿100 ทั้งที่ควรเป็น ฿120) หรือบรรลุเป้าหมายผิดไปเลย — ต่างจาก tool ที่ทำงานถูกคำสั่งแต่คืนผลลัพธ์ผิดเอง ต้องแก้กันคนละจุด
3. ○03ตัดสินที่ผลลัพธ์ ไม่ใช่เส้นทาง
   • Outcome-based Evalการตัดสินจาก 'สถานะสุดท้ายของสภาพแวดล้อมจริง' หลัง agent ทำงานเสร็จ เช่น มีแถวคืนเงินของออเดอร์นั้นในฐานข้อมูลจริงหรือยัง ไม่ใช่จากคำบรรยายว่า agent 'บอกว่าทำเสร็จแล้ว' — เป็นค่าเริ่มต้นที่แนะนำ เพราะ agent หลายเส้นทางไปถึงผลลัพธ์ที่ถูกต้องเหมือนกันได้โดยไม่จำเป็นต้องเดินเหมือนกัน
   • Trajectoryลำดับขั้นตอนจริงที่ agent เดินผ่านระหว่างทำงาน (เรียก tool ไหน คิดอะไร ตัดสินใจอย่างไร) ก่อนถึงผลลัพธ์สุดท้าย — เช็คทีละก้าวยังมีประโยชน์เป็นตาข่ายเสริมด้านความปลอดภัย (เช่น เช็คว่าไม่เคยเรียก tool คืนเงินโดยไม่มีการอนุมัติ) แต่ไม่ควรใช้แทนการเช็ค outcome เป็นหลัก เพราะเข้มเกินไปกับ agent ที่มีหลายเส้นทางที่ถูกต้องพร้อมกัน
   • Ground Truthคำตอบหรือพฤติกรรมที่ 'ถูกต้องจริง' ตามการตรวจสอบของมนุษย์ผู้เชี่ยวชาญ ใช้เป็นหลักอ้างอิงเทียบกับ output ของ agent ใน Golden Dataset — ถ้า ground truth เองยังคลุมเครือ eval ที่เทียบกับมันก็เชื่อถือไม่ได้ตั้งแต่ต้น
4. ○04LLM-as-judge (และเมื่อไร deterministic ดีกว่า)
   • LLM-as-judgeเทคนิคที่ใช้ LLM อีกตัวเป็นผู้ตัดสิน (judge) ว่า output ของ agent ผ่านเกณฑ์หรือไม่ แทนมนุษย์อ่านทุกเคสเอง มักให้คะแนนตามเกณฑ์หลายมิติในคำสั่งเดียว — ใช้ได้จริงเมื่อผ่าน Judge Calibration กับมนุษย์แล้วเท่านั้น เพราะ judge มีอคติแฝง (เอนเอียงตามลำดับที่เห็นก่อน ตามความยาวคำตอบ หรือชอบ output จาก model ตระกูลเดียวกับตัวเอง) ไม่ใช่ผู้ตัดสินที่เป็นกลางโดยอัตโนมัติ
   • Rubricเกณฑ์การให้คะแนนที่เขียนไว้ชัดเจนเป็นข้อ ๆ ก่อนเริ่มตรวจ ให้ทั้งมนุษย์และ LLM-as-judge ใช้ตัดสินแบบเดียวกัน — ยิ่ง rubric คลุมเครือ ยิ่งได้คะแนนที่เชื่อถือไม่ได้ไม่ว่าใครเป็นคนตรวจ และต้องแก้ไขซ้ำได้เมื่อเจอ Criteria Drift ไม่ใช่เขียนทิ้งไว้ตายตัว
   • Judge Calibrationกระบวนการเช็คว่า LLM-as-judge ตัดสินตรงกับป้ายที่มนุษย์ผู้เชี่ยวชาญให้ไว้แค่ไหน ก่อนปล่อยให้ judge ตัดสินเองเต็มรูปแบบ — ต้องดูอัตราที่ judge จับได้ถูกทั้งฝั่ง 'ผ่านจริง' และ 'พังจริง' แยกกัน ไม่ใช่แค่ % ที่ตรงกับมนุษย์รวม ๆ เพราะถ้าเคสพังมีน้อย judge ที่ตอบ 'ผ่าน' มั่ว ๆ ก็ยังได้คะแนนสูงลวงตา และต้อง calibrate ซ้ำทุกครั้งที่เปลี่ยน model judge หรือ rubric
5. ○05เริ่มด้วย eval set เล็กๆ
   • Golden Datasetชุด input พร้อมคำตอบ/พฤติกรรมที่ถูกต้อง (Ground Truth) ซึ่งมนุษย์ตรวจแล้ว ใช้เป็นหลักอ้างอิงตายตัวสำหรับรัน eval ซ้ำก่อนปล่อยแต่ละ version — เริ่มจากเคสจริงหลักสิบเคสที่เคยพังมาก่อนก็พอ ไม่ต้องรอให้มีเป็นร้อยเคสก่อนเริ่ม eval แต่ต้องมาจากความล้มเหลวจริง ไม่ใช่เคสที่จินตนาการขึ้นเอง
6. ○06Error analysis และคนดู (หัวใจของคอร์ส)
   • Error Analysisการนั่งอ่าน trace ที่ agent ทำงานจริงทีละเคสเพื่อหาว่าอะไรพังจากอะไร เน้นจับ 'ความผิดพลาดแรกสุด' ในแต่ละ trace ก่อนเสมอ เพราะความผิดพลาดต้นทางมักลากให้พังต่อเป็นทอด ๆ — เป็นจุดเริ่มต้นของ eval ที่ดี ไม่ใช่การมองแค่ dashboard ตัวเลขรวม และควรทำซ้ำทุก 2-4 สัปดาห์
   • Human-in-the-loopการให้มนุษย์เข้ามาตรวจสอบหรือให้ป้ายในจุดสำคัญของกระบวนการ eval เช่น สุ่มตรวจผลตัดสินของ LLM-as-judge หรืออนุมัติก่อน agent ทำสิ่งที่ย้อนกลับไม่ได้ — มนุษย์ยังจับสิ่งที่ automation มองข้ามได้เสมอ (เช่น agent เลือกแหล่งข้อมูลที่ดู SEO ดีแต่ไม่น่าเชื่อถือ) จึงเป็นสิ่งที่รักษาคุณภาพ eval ไว้ไม่ให้พึ่งพา judge เพียงลำพัง
   • Open Codingเทคนิคจากงานวิจัยเชิงคุณภาพที่ยืมมาทำ Error Analysis — อ่าน trace ทีละเคสแล้วเขียนบรรยาย 'ความผิดพลาดแรกสุด' ที่เห็นด้วยคำพูดของตัวเอง โดยยังไม่ยึดหมวดหมู่ตายตัว จนกว่าจะไล่ดูราวร้อยเคสแล้วเริ่มไม่เจอแพทเทิร์นใหม่ จึงค่อยจัดกลุ่มเป็น Failure Taxonomy
   • Criteria Driftปรากฏการณ์ที่เกณฑ์ 'อะไรคือคำตอบที่ดี' ค่อย ๆ ชัดขึ้นหรือเปลี่ยนไปเองระหว่างมนุษย์ตรวจเคสจริงไปเรื่อย ๆ เพราะคนเรามักรู้ว่า 'ดี' หมายถึงอะไรก็ต่อเมื่อได้เห็น output จริงจำนวนมากแล้วเท่านั้น ไม่ใช่คิดเกณฑ์ครบตั้งแต่วันแรก — เหตุผลที่ Rubric ต้องรักษาความสอดคล้องด้วยการปรับปรุงซ้ำได้เรื่อย ๆ
7. ○07Offline suite + online monitoring — สองด่านที่ปิดเป็นวง
   • Offline Evalการวัดผล agent กับ Golden Dataset ที่คัดไว้ล่วงหน้า (มักมี Ground Truth ประกอบ) ก่อนปล่อยแต่ละ version จริง เหมือนยูนิต test/integration test ของ code ทั่วไป รันซ้ำได้ผลเดิมทุกครั้งและใช้ดักไม่ให้ version ใหม่แย่ลงกว่าเดิม
   • Online Evalการวัดผล agent จากการใช้งานจริงบน production แบบต่อเนื่อง โดยไม่มีคำตอบอ้างอิงตายตัวให้เทียบ เหมือนงาน monitoring หรือ canary testing — จับปัญหาจาก query จริงที่ offline eval ไม่เคยเจอ แต่ข้อเสียคือกว่าจะรู้ปัญหาก็มักมีผู้ใช้เจอไปก่อนแล้ว เคสที่คะแนนต่ำควรถูกป้อนกลับไปเป็นเคสใหม่ใน Golden Dataset
   • Regression Suiteชุด Offline Eval ของเคสที่ agent เคยทำถูกอยู่แล้ว ใช้รักษามาตรฐานเดิมไว้ไม่ให้ version ใหม่ทำพัง รันก่อนปล่อยทุกครั้ง — ควรผ่านเกือบ 100% เสมอ ต่างจากชุด eval เคสใหม่/เคสยากที่ถ้าผ่าน 100% แปลว่ายังท้าทาย agent ไม่พอ
   • Driftอาการที่พฤติกรรมหรือการกระจายของ query จริงค่อย ๆ เปลี่ยนไปจากตอนที่เคย eval ผ่านไว้ เช่น หลังผู้ให้บริการอัปเดต model หรือผู้ใช้เริ่มถามคำถามแบบใหม่ที่ Golden Dataset ไม่เคยครอบคลุม — เหตุผลที่ต้องมี Regression Suite และ Online Eval รันต่อเนื่อง ไม่ใช่ eval ครั้งเดียวจบ
8. ○08Eval-driven development (ข้อถกเถียงจริง)
   • Evalการวัดผลอย่างเป็นระบบว่า output ของ AI agent (เช่น ops-copilot) ถูกต้องและมีประโยชน์จริงหรือไม่ ด้วยชุดเกณฑ์และกรณีทดสอบที่ชัดเจน แทนการดูจากความรู้สึกว่า 'ตอบดูดี' — จำเป็นเพราะ agent เป็นระบบหลายขั้นตอนที่ความผิดพลาดสะสมทบกันได้ และแต่ละรอบก็ไม่ได้เดินทางเดิมเป๊ะทุกครั้ง
   • Error Analysisการนั่งอ่าน trace ที่ agent ทำงานจริงทีละเคสเพื่อหาว่าอะไรพังจากอะไร เน้นจับ 'ความผิดพลาดแรกสุด' ในแต่ละ trace ก่อนเสมอ เพราะความผิดพลาดต้นทางมักลากให้พังต่อเป็นทอด ๆ — เป็นจุดเริ่มต้นของ eval ที่ดี ไม่ใช่การมองแค่ dashboard ตัวเลขรวม และควรทำซ้ำทุก 2-4 สัปดาห์