← Harness Engineering Handbook
LEVEL 3 · ขยายระบบ
Evals — รู้ได้ยังไงว่า harness ดีขึ้น
เมื่อวานแก้ system prompt หนึ่งบรรทัด วันนี้เพิ่ม tool ใหม่หนึ่งตัว — agent ดีขึ้นหรือแย่ลง? · ถ้าคำตอบคือ "รู้สึกว่าดีขึ้นนะ" แปลว่าเรากำลังปรับระบบมูลค่าสูงด้วยวิธีเดียวกับการเดาหวย · เล่ม #07 สอน "อย่าวัด prompt ด้วยความรู้สึก" ไว้แล้ว — บทนี้คือหลักเดียวกัน ขยายจากวัดหนึ่ง prompt เป็นวัดทั้งระบบ
11.1 eval ของ harness ≠ eval ของโมเดล
eval ของโมเดล (ที่ lab ใช้จัดอันดับกัน) วัดคำตอบเดี่ยว: ถามหนึ่งข้อ ให้คะแนนหนึ่งคำตอบ · แต่สิ่งที่เราปรับใน harness — เพิ่ม tool, แก้ description, เปลี่ยนกติกา permission — กระทบพฤติกรรมทั้งวงของ loop ไม่ใช่คำตอบใดคำตอบหนึ่ง · eval ของ harness จึงต้องวัด end-to-end task: ให้งานจริงทั้งชิ้น ("แก้บั๊กนี้ให้เทสต์ผ่าน", "อัปเดต dependency แล้ว build ต้องเขียว") แล้ววัดว่างานจบจริงไหม พร้อมต้นทุน — กี่ token กี่นาที กี่รอบ
11.2 หลักปฏิบัติสี่ข้อ
- ชุดงานตัวแทน — งานจริง 10–30 ชิ้นที่ครอบความหลากหลาย: ง่าย กลาง ยาก และเจ้าเล่ห์ (เคสที่เคยหลอก agent ได้) · ไม่ต้องเริ่มหรูหรา — มีสิบงานที่รันซ้ำได้ ก็ชนะ "ความรู้สึก" ขาดลอยแล้ว
- เกณฑ์ตัดสินอัตโนมัติ — จุดที่บทที่ 5 กลับมาทวงบุญคุณ: verifier ที่เชื่อได้คือกรรมการ eval ที่ดีที่สุด (เทสต์ผ่านไหม ไฟล์ถูกต้องไหม build เขียวไหม) · งานที่วัดด้วยกลไกยาก ใช้ AI เป็นกรรมการ (LLM-as-judge) ได้ แต่ต้องรู้ตัวว่าเชื่อได้น้อยกว่า และควรสุ่มตรวจกรรมการด้วยตาคนเป็นระยะ
- รันซ้ำหลายรอบ (pass@k) — agent ไม่ deterministic: งานเดียวรันครั้งเดียวแทบไม่บอกอะไร · รันงานละ 5 รอบแล้วรายงาน "ผ่าน 4/5" — การเทียบสองเวอร์ชันคือเทียบการกระจายของผล ไม่ใช่จับฉลากครั้งเดียวชนกัน
- regression suite จากเคสที่เคยพัง — ทุกครั้งที่ agent พังในงานจริง (transcript จากบทที่ 7 คือวัตถุดิบ) กลั่นเคสนั้นเป็นงาน eval ใหม่ · เหมือน unit test ที่เกิดจากบั๊กจริง — ระบบจะไม่มีวันพังท่าเดิมแบบเงียบ ๆ อีก
ขยายเรื่อง pass@k อีกนิดให้เห็นภาพ — เพราะนี่คือจุดที่คนพลาดบ่อยที่สุด: ทำไม "รันครั้งเดียวแล้วเทียบ" ถึงหลอกเราได้ทั้งที่ตั้งใจวัดแล้ว
11.3 ของแถมที่แพงที่สุดของการมี eval
ไม่ใช่ตัวเลขบนกราฟ แต่คือความกล้า: harness ที่ไม่มี eval จะค่อย ๆ กลายเป็นระบบที่ไม่มีใครกล้าแตะ — แก้อะไรก็ได้แต่ภาวนาว่าไม่ทำของเดิมพัง · พอมี suite ที่รันได้ใน 20 นาที การทดลองไอเดียใหม่กลายเป็นเรื่องปกติ: ลอง รัน เทียบ เก็บหรือทิ้ง — จบ · วัฒนธรรมเดียวกับที่ unit test ให้กับโค้ด แต่คราวนี้ให้กับระบบ AI
✅ สรุปบทที่ 11 — ตอบไม่ได้ว่าดีขึ้นหรือแย่ลง = ปรับมั่ว · eval ของ harness วัด end-to-end task (งานจบจริงไหม + ต้นทุน) ไม่ใช่คำตอบเดี่ยว · สี่หลัก: ชุดงานตัวแทน 10–30 ชิ้น, เกณฑ์อัตโนมัติ (verifier จากบท 5 คือกรรมการที่ดีสุด — LLM-as-judge เชื่อได้น้อยกว่า), รันซ้ำ pass@k เพราะไม่ deterministic, regression จากเคสพังจริง · รางวัลใหญ่สุดคือความกล้าทดลอง