ทำไม eval ของ agent ต่างจาก test ปกติ

ในคอร์ส Testing in Practice เราตอบคำถามเดียว — “รู้ได้ยังไงว่า code ทำงานถูก” — ด้วยการไล่ test ทุกชั้นของ domain Order ระบบที่ input เดิมให้ผลเดิมทุกครั้ง แต่พอเอา Order ตัวเดิมนั้นมาห่อด้วย agent — ops-copilot ที่รับคำสั่ง “คืนเงินออเดอร์นี้” แล้ววางแผน เรียก tool คืนเงิน และลงมือแก้สถานะจริงในฐานข้อมูล — สมมติฐาน “input เดิมให้ผลเดิม” ก็พังทันที คอร์สนี้ถามคำถามเดิมกับระบบแบบใหม่: รู้ได้ยังไงว่า agent ทำงานได้จริง คำตอบคือ Eval

คอร์สนี้ไม่ใช่คอร์ส Testing version เขียนใหม่ test แบบเดิมตั้งอยู่บนสมมติฐานว่าระบบเป็น deterministic — เรียก method เดิมด้วย input เดิม ต้องได้ผลเดิมเป๊ะ agent ละเมิดสมมติฐานนี้ด้วยคุณสมบัติสามข้อ: มันเป็นระบบหลายขั้นตอน ความผิดพลาดต่อขั้นจึงทบกัน, มันไม่ deterministic รอบเดียวกันเดินคนละเส้นทางที่ถูกต้องได้, และมันลงมือกับสภาพแวดล้อมจริง เราจึงต้องตัดสินจากสิ่งที่มันทำให้เกิดขึ้น ไม่ใช่จากคำพูดของมันเอง สามข้อนี้คือรากของทุกบทที่เหลือ — บทนี้อธิบายว่าทำไมมันถึงเปลี่ยนเกม แล้วบท 2–8 จะสร้างวินัย eval ทีละชิ้นบนรากสามข้อนี้

📦 code ตัวอย่าง

คอร์สนี้ใช้ ops-copilot agent ที่คืนเงินออเดอร์ใน domain Order เดิมจาก repo kaen-food-ordering (กำลังจัดทำ) เป็นตัวอย่างเดินเรื่องตลอดคอร์ส — บทนี้เป็นบทวางแนวคิด สเก็ตช์ code ที่เห็นเป็นภาพร่างของ eval เพื่อสื่อไอเดีย ไม่ใช่ eval harness ที่รันได้ทันที

agent เป็นระบบหลายขั้นตอน ความผิดพลาดจึงทบกัน

test domain Order วัดการเรียก method ครั้งเดียว: Place(...) เข้า Order ออก จบในก้าวเดียว แต่ agent ไม่ได้ทำงานในก้าวเดียว มันวนอยู่ใน loop: รับ input → วางแผน → เรียก tool → สังเกตผล → วนกลับไปตัดสินใจใหม่ จนกว่าจะบรรลุเป้าหมาย ยิ่งงานซับซ้อน loop นี้ยิ่งยาว และความผิดพลาดเล็กๆ ต่อขั้นก็ยิ่งมีที่ให้สะสม

Chip Huyen ยกตัวเลขไว้ให้เห็นภาพว่า ถ้าความแม่นยำต่อขั้นอยู่ที่ 95% เดิน 10 ขั้นความแม่นยำจะเหลือราว 60% และเดิน 100 ขั้นจะเหลือเพียง 0.6% (ดู Chip Huyen, “Agents”)

ย้ำให้ชัดก่อนเข้าใจผิด: ตัวเลขชุดนี้ ไม่ใช่อัตราพังที่วัดได้จริง จาก agent ตัวใดตัวหนึ่ง มันคือการคำนวณแบบสมมติว่าความผิดพลาดแต่ละขั้น “เป็นอิสระต่อกัน” ล้วนๆ (0.95 ยกกำลัง 10 ≈ 0.60 และยกกำลัง 100 ≈ 0.006) agent จริงไม่ได้เป็นแบบนั้นเป๊ะ — มันกู้คืนจากความผิดพลาดบางอย่างได้เอง และในบางกรณีก็พลาดพร้อมกันเป็นชุดเพราะสาเหตุเดียวกัน ตัวเลข 95%→60%→0.6% จึงมีค่าในฐานะ สัญชาตญาณ ว่า “ยิ่งจำนวนขั้นเยอะ ระบบยิ่งเปราะ” เท่านั้น ห้ามหยิบไปอ้างเป็นผลวัดของ agent จริง บทเรียนที่ได้คือ: จำนวนขั้นเป็นตัวคูณความเสี่ยง test ที่วัดแค่ก้าวเดียวจึงมองไม่เห็นความเปราะที่โผล่มาตอนหลายก้าวต่อกัน

รันผ่านรอบเดียว ไม่ได้แปลว่าเชื่อถือได้

ต่อให้ agent ทำงานถูกในรอบที่เราลอง ก็ยังสรุปไม่ได้ว่ามันเชื่อถือได้ เพราะมันไม่ deterministic Anthropic เขียนไว้ตรงๆ ว่า “Even with identical starting points, agents might take completely different valid paths to reach their goal.” — แม้เริ่มจากจุดตั้งต้นเดียวกัน agent ก็อาจเดินไปตามเส้นทางที่ถูกต้องคนละเส้นจนถึงเป้าหมายได้ (ดู Anthropic, “How we built our multi-agent research system”) นั่นแปลว่ารอบที่ผ่านกับรอบที่พังอาจมาจาก input เดียวกันเป๊ะ การผ่านหนึ่งครั้งจึงเป็นแค่ตัวอย่างหนึ่งจากการแจกแจง ไม่ใช่ข้อสรุปเรื่องความน่าเชื่อถือ

ความน่าเชื่อถือต้องวัดจากการรันซ้ำหลายรอบ ไม่ใช่รอบเดียว งาน τ-bench เสนอ metric ใหม่ชื่อ Pass^k มา “evaluate the reliability of agent behavior over multiple trials” — วัดว่า agent ผ่าน ทุกครั้ง ใน k รอบที่รันเคสเดิมซ้ำหรือไม่ (ดู τ-bench (arXiv 2406.12045)) จุดที่ต้องแยกให้ขาด: pass^k ต่างจาก pass@k — pass@k แค่ผ่าน “อย่างน้อยหนึ่งครั้ง” ใน k รอบก็นับผ่าน (เหมาะกับงานที่ลองหลายคำตอบแล้วเลือกอันดีได้) แต่ ops-copilot ที่ไปแก้เงินจริงในฐานข้อมูลไม่มีสิทธิ์พลาดแม้รอบเดียว เราจึงวัดด้วย pass^k ที่โหดกว่า: พลาดรอบใดรอบหนึ่งคือตก

flowchart TB
  Q["เคสเดียวกัน: คืนเงินออเดอร์ 123 เป็นเงิน 120 บาท"]
  Q --> ONE["รันครั้งเดียว<br/>รอบนั้นผ่าน จึงสรุปว่า agent ใช้ได้"]
  Q --> MANY["รันซ้ำ 5 รอบ วัดแบบ Pass^k"]
  ONE --> V1["สรุปว่าเชื่อถือได้ — แต่เป็นภาพลวงตา"]
  MANY --> R["ผ่าน 3 รอบ พลาด 2 รอบ<br/>รอบ 3 เรียก tool ผิดตัว รอบ 5 คืนเงินผิดจำนวน"]
  R --> V2["Pass^k ไม่ผ่าน — สรุปตามจริงว่ายังเชื่อถือไม่ได้"]
  classDef bad fill:#dc2626,stroke:#7f1d1d,color:#f8fafc;
  classDef good fill:#16a34a,stroke:#065f46,color:#f8fafc;
  class V1 bad;
  class V2 good;

คำบรรยายภาพ: เคสเดียวกันสองวิธีสรุป เส้นซ้าย (แดง) รันรอบเดียวเห็นผ่านก็ปักใจว่า agent เชื่อถือได้ — เป็นภาพลวงตาเพราะรอบถัดไปอาจเดินคนละเส้น เส้นขวา (เขียว) รันเคสเดิมซ้ำ 5 รอบแล้ววัดด้วย pass^k เจอว่าผ่านแค่ 3 จาก 5 (รอบหนึ่งเรียก tool ผิดตัว อีกรอบคืนเงินผิดจำนวน) pass^k จึงไม่ผ่าน และสรุปตามจริงว่ายังปล่อยขึ้นโปรดักชันไม่ได้ ความน่าเชื่อถืออยู่ที่ความนิ่งข้ามหลายรอบ ไม่ใช่ผลของรอบที่โชคดี

eval คือวิธีรู้ว่า agent ทำงานได้จริง — วัดที่ผลลัพธ์

รวมสองข้อข้างบนเข้าด้วยกัน — หลายขั้นตอนจนเปราะ และไม่นิ่งข้ามรอบ — จะเห็นว่า “ลองแล้วดูเหมือนทำงาน” ไม่ใช่หลักฐานเลย eval คือการแทนความรู้สึกนั้นด้วยการวัดที่เป็นระบบ: เกณฑ์ชัดเจน เคสทดสอบที่มาจากงานจริง และรันซ้ำได้ มันคือเครื่องมือที่ช่วยรักษาความน่าเชื่อถือของ agent เอาไว้ระหว่างที่เราแก้ prompt เปลี่ยน model หรือเพิ่ม tool ไปเรื่อยๆ

คุณสมบัติข้อที่สาม — agent ลงมือกับสภาพแวดล้อมจริง — เป็นตัวชี้ว่า eval ควรวัด “อะไร” คำตอบคือวัดที่ ผลลัพธ์ที่เกิดขึ้นจริงต่อสภาพแวดล้อม ไม่ใช่คำบรรยายของ agent เอง ลองดูสองวิธีเช็คผลเดียวกันสำหรับคำสั่ง “คืนเงินออเดอร์ #123 จำนวน ฿120”:

// สเก็ตช์เพื่อสื่อไอเดีย ไม่ใช่ code ที่รันได้จริง — เทียบสองวิธีเช็คผลเดียวกัน

// version ดิบ: เชื่อคำบรรยายของ agent เอง
if (agentReply.includes("คืนเงินเรียบร้อย")) markPass();
// ❌ agent "พูด" ว่าทำ ไม่ได้แปลว่าฐานข้อมูลเปลี่ยนจริง — ผ่านลวงตา

// version ที่วัด outcome: ดูสถานะจริงของฐานข้อมูลหลัง agent ทำงานเสร็จ
const row = db.refunds.findOne({ orderId: 123 });
markPass(row != null && row.amount === 120);
// ✅ มีแถวคืนเงินของออเดอร์นั้นจริง และจำนวนถูกต้อง จึงนับว่าผ่าน

version ดิบผ่านได้ทั้งที่ agent อาจไม่ได้คืนเงินเลย ขอแค่มันพิมพ์ประโยคที่ถูก ส่วน version ที่วัด outcome ถามคำถามที่ตรวจสอบได้: “มีแถวคืนเงินของออเดอร์ #123 ในฐานข้อมูลจริง จำนวน ฿120 หรือยัง” — นี่คือหัวใจที่คอร์สนี้จะกลับมาย้ำตลอด และเป็นเหตุผลว่าทำไมการตัดสินจากผลลัพธ์ถึงเป็นค่าเริ่มต้น ส่วนการไล่เช็คเส้นทาง (trajectory) ทีละก้าวจะกลายเป็นตาข่ายเสริมด้านความปลอดภัย ไม่ใช่เกณฑ์หลัก — บทที่ 3 จะเจาะเรื่องนี้เต็มๆ

สิ่งที่จะทำต่อ

บทนี้วางแค่ราก — ทำไม agent ต้องการ eval ที่ต่างจาก test ปกติ เพราะมันหลายขั้นตอน ไม่นิ่งข้ามรอบ และตัดสินกันที่ผลลัพธ์จริง จากนี้เราจะสร้างวินัย eval ทีละชิ้น:

หมวดหมู่ความล้มเหลวของ agent (บทที่ 2) — planning / tool-execution / efficiency แต่ละแบบแก้กันคนละจุด
ตัดสินจากผลลัพธ์ ไม่ใช่เส้นทาง (บทที่ 3) — ทำไม outcome เป็นเกณฑ์หลัก และเมื่อไรการเช็ค trajectory ยังมีประโยชน์
LLM-as-judge (บทที่ 4) — เมื่อไรใช้ตัวตัดสินที่เป็น LLM และเมื่อไรตัวเช็คแบบ deterministic ดีกว่า
เริ่มจาก eval set เล็กๆ (บทที่ 5) — 20–50 เคสจากความล้มเหลวจริง ก่อนขยายเป็นชุดใหญ่
Human-in-the-loop กับ error analysis (บทที่ 6) — หัวใจของคอร์ส: อ่าน trace จริงเพื่อหาว่าอะไรพังจากอะไร
offline eval กับ online eval (บทที่ 7) — วัดก่อนปล่อย กับวัดต่อเนื่องบนโปรดักชัน
eval-driven development (บทที่ 8) — ข้อถกเถียงที่ยังไม่จบระหว่าง Anthropic กับ Hamel

ทุกบทกลับมาที่ ops-copilot ตัวเดิมเสมอ — ไม่มี agent ใหม่ ไม่มี domain ใหม่ มีแต่การไล่วัดให้แน่ใจว่ามันทำงานได้จริง

🔗 อ้างอิงต้นทางของบทนี้

บทนี้สังเคราะห์จากสามแหล่งหลัก อ่านต่อได้ที่ต้นทางโดยตรง:

Chip Huyen, “Agents” — สัญชาตญาณเรื่องความผิดพลาดที่ทบกันตามจำนวนขั้น (ตัวเลข 95%→60%→0.6% เป็นการคำนวณเชิงสมมติ ไม่ใช่ผลวัดจริง)
Anthropic, “How we built our multi-agent research system” — agent เดินได้หลายเส้นทางที่ถูกต้อง จึงต้องวัดกันที่ผลลัพธ์
τ-bench (arXiv 2406.12045) — metric pass^k สำหรับวัดความน่าเชื่อถือข้ามหลายรอบ
คอร์ส Testing in Practice บทที่ 1 — คู่หูของคอร์สนี้ วินัยพิสูจน์ว่า code ทำงานถูก ก่อนขยับมาพิสูจน์ agent

เช็กความเข้าใจ — บทที่ 1

ข้อ 1 / 3

ตัวเลข 95% ต่อขั้น → ~60% ที่ 10 ขั้น → 0.6% ที่ 100 ขั้น ของ Chip Huyen ควรเข้าใจว่าเป็นอะไร?

ทำไม eval ของ agent ต่าง​จาก test ปกติ

agent เป็น​ระบบ​หลาย​ขั้นตอน ความ​ผิดพลาด​จึง​ทบ​กัน

รัน​ผ่าน​รอบ​เดียว ไม่​ได้​แปล​ว่า​เชื่อถือ​ได้

eval คือ​วิธี​รู้​ว่า agent ทำงาน​ได้​จริง — วัด​ที่​ผลลัพธ์

สิ่ง​ที่​จะ​ทำ​ต่อ