บทที่ 16 · Context · เชื่อถือ · สเกล · Evaluation
Evaluation — มันได้ผลจริงไหม
เราสร้างของที่ดูดีมาตลอด — แต่ มันถูกจริงไหม? การประเมิน agent เป็นวิชาแยกต่างหาก
มีสามระดับ (final / trajectory / step) ชุดทดสอบส่วนตัวจากงานจริงเอาชนะ benchmark สาธารณะ
ตัวอย่างนำ: ฟีดแบ็กงานนักศึกษา — ฟีดแบ็กนั้น “ดี” ไหม (เน้นกระบวนการ ไม่ใช่จับผิด AI)
พูดแบบเข้าใจง่าย
การประเมิน agent คือการถาม สามคำถามที่ต่างกัน ต่อหนึ่ง run ไม่ใช่คำถามเดียว:
- Final-task — ได้ผลตามเป้าหมายไหม?
- Trajectory — เส้นทางสมเหตุสมผลไหม (เรียก tool ถูก ลำดับถูก ตารางถูก ไม่ข้ามขั้นตรวจ)?
- Step — แต่ละการตัดสินใจถูกไหมเมื่อเทียบกับสิ่งที่รู้ตอนนั้น?
run หนึ่งผ่านระดับหนึ่งแต่ตกอีกระดับได้ — นั่นแหละเหตุผลที่ต้องมีครบสาม: คำตอบถูกที่ได้มาจากเส้นทางที่ผิด
คือ failure mode ที่การเทสต์ธรรมดาจับไม่ได้ · เพื่อวัดในสเกล ให้สร้าง ชุดทดสอบส่วนตัว ~50 เคสจากงานจริงของคุณ
(ดีกว่า leaderboard สาธารณะที่วัดงานของคนอื่น) · ถ้าใช้ LLM-as-judge ต้องสอบเทียบกับคำตัดสินของคนก่อน ตัดสินทีละมิติ และอนุญาตให้ตอบ “ไม่แน่ใจ” ได้
เปรียบเทียบ: ตรวจข้อสอบฟิสิกส์
ไม่ได้ดูแค่เลขในกรอบคำตอบ — อ่านวิธีทำ และตรวจพีชคณิตทีละบรรทัด ·
เลขในกรอบ = final-task · วิธีโดยรวมสมเหตุสมผล (ใช้อนุรักษ์พลังงานเมื่อโจทย์ต้องการ ไม่ใช่สูตรมั่ว 3 อัน) = trajectory · เช็คเครื่องหมายทีละบรรทัด = step ·
เคสที่ครูกลัวที่สุด: คำตอบถูกเพราะผิดสองที่หักล้างกัน (final ผ่าน · trajectory/step ตก) — นั่นคือ agent ที่ได้จำนวนถูกจากตารางผิด
ในระบบของเรา — มีเมล็ดพันธุ์แล้ว แต่ยังไม่มี agent eval
เมล็ดพันธุ์regression fixture: input คงที่ → ผลคงที่ (พังเสียงดังเมื่อ drift)
→
แต่…นั่นทดสอบ “ฟังก์ชันบริสุทธิ์” ไม่ใช่ทั้ง agent
→
ช่องว่างไม่มีอะไรให้คะแนนว่า “agent ตอบงานจริงดีขึ้น/แย่ลง”
ระบบเรามี fixture ทดสอบแบบ deterministic (เช่น parser ค่าฝุ่นต้องคืนค่าเดิมจาก HTML ที่แช่แข็งไว้) — นี่คือ
วินัยที่ดีและเป็น “เมล็ดพันธุ์” ของ eval แต่มัน ทดสอบฟังก์ชันบริสุทธิ์ ไม่ใช่ทั้ง agent ·
ทุกการเรียก tool ถูก log ไว้ (ได้ trajectory ฟรี) แต่ ไม่มีบรรทัดไหนบอก “เป้าหมายของ session” หรือ “ผ่าน/ไม่ผ่าน” —
เปลี่ยน prompt หรือสลับโมเดลทีก็เหมือน บินด้วยตาเปล่า สำหรับฟีดแบ็กงานนักศึกษา คำถามคือ “ฟีดแบ็กดีพอไหม” ซึ่งต้องวัดเชิงคุณภาพ
ทำพลาด vs ทำถูก
⚠️ แย่ · “เทสต์เขียว = agent ถูกทดสอบแล้ว”
สับสนสองวิชา
regression ของฟังก์ชันบริสุทธิ์ (input รู้ → output รู้) บอกได้แค่ parser ไม่ drift —
ไม่ได้บอกว่า agent เลือก tool ถูก ค้นตารางถูก และได้คำตอบถูก เมื่อเจอคำถามจริง
⚠️ แย่ · ไม่มี agent eval เลย
จูน prompt แบบไสยศาสตร์
เปลี่ยน system prompt/สลับโมเดลแล้วไม่มีอะไรบอกว่าคำตอบต่อคำถามจริงดีขึ้นหรือแย่ลง
“รู้สึกว่า prompt นี้ดีกว่า” = เดา ไม่ใช่วัด
✅ ดี · ต่อยอด final-task eval บนเมล็ดพันธุ์
~50 เคสจากงานจริง + 3 ระดับ
แช่แข็ง “คำถามจริง → คำตอบที่คาดหวัง + เส้นทาง tool ที่คาดหวัง” สัก ~50 เคส ติด label เป้าหมาย+ผ่าน/ไม่ผ่าน
แล้วการเปลี่ยน prompt/โมเดลครั้งหน้าจะ วัดได้ ไม่ใช่เดา — trajectory มีให้ฟรีจาก log อยู่แล้ว
ลองเอง — ให้คะแนน agent 3 ระดับ
กิจกรรม · เติม scorecard
Grade the Agent: Three Verdicts per Run
ดู 3 run แล้วตั้งคำตัดสิน Final / Trajectory / Step ต่อ run แล้วกด “เฉลย”
ระวัง Run B — คำตอบถูก แต่ได้มาจากเส้นทางที่ผิด (ถูกโดยบังเอิญ)
ตั้ง PASS/FAIL สามระดับต่อ run · แล้วเฉลย
มองไปข้างหน้า — ครบ “เรื่องยาก” แล้ว ถอยมามองภาพรวม
เราปูพื้น สร้าง harness เชื่อมโลก และทำให้ดี/ปลอดภัย/พิสูจน์ได้แล้ว ส่วนที่ 5 คือมุมมองมืออาชีพ:
ผู้ช่วยตัวนี้เป็น 1 ในหลายระบบบน harness ร่วมกัน + cockpit ที่คุมทุก agent โดยไม่ใช้ AI เลย
สรุปบทที่ 16
- ประเมิน agent = สามคำถาม: final · trajectory · step — ผ่านระดับหนึ่งตกอีกระดับได้
- คำตอบถูกจาก เส้นทางผิด = failure ที่เทสต์ธรรมดาจับไม่ได้
- ชุดทดสอบส่วนตัว ~50 เคสจากงานจริง > benchmark สาธารณะ · LLM-as-judge ต้องสอบเทียบ + ตัดสินทีละมิติ
- ระบบเรามี fixture (เมล็ดพันธุ์) แต่ ยังไม่มี agent eval — เปลี่ยน prompt/โมเดล = บินตาเปล่า
Harness Scorecard · มิติ: “มี agent eval ที่วัดงานจริงไหม?”
ระบบเรา: ⚠️ อ่อน — มี regression fixture แต่ยังไม่มี agent eval (จุดอ่อนคู่กับ observability ในบทที่ 9)
📋 build-your-harness checklist · บรรทัดที่ 15
“ชุด eval ส่วนตัว ~50 เคสจากงานจริง · ให้คะแนน 3 ระดับ · สอบเทียบ LLM-as-judge ก่อนใช้”