การประเมิน AI agent: วิธีสร้าง evals และวัดความน่าเชื่อถือแทนความรู้สึก

ทำไมต้องประเมิน AI agent ในเมื่อเห็นอยู่แล้วว่ามันทำงานได้

ที่จริงแล้วการมองด้วยตาเปล่าทำให้เห็นได้ไม่ชัด agent ไม่เคยติดขัดเลยหนึ่งสัปดาห์หลังจากแก้ prompt นั่นเป็นเพราะการแก้ไขหรือเพราะสัปดาห์นั้นมีแต่งานง่าย วิศวกรคนหนึ่งมั่นใจว่าเทมเพลตใหม่เปลี่ยนทุกอย่าง อีกคนดูล็อกเดียวกันแล้วไม่เห็นความต่าง ทั้งคู่ถูกเท่า ๆ กัน เพราะไม่มีใครนับอะไรเลย

การประเมิน AI agent (evals) แทนที่ความรู้สึกด้วยตัวเลข คุณเลือกชุดงานที่ตายตัว รัน agent ตรวจผลลัพธ์อัตโนมัติ และเปรียบเทียบตัวชี้วัดก่อนกับหลังการเปลี่ยนแปลง เมื่อนั้นการถกเถียงว่า "ดีขึ้นหรือยัง" จะถูกตัดสินด้วยตาราง ไม่ใช่ด้วยความเชื่อมั่นของใครคนหนึ่ง

หากไม่มี evals การเปลี่ยนแปลงใด ๆ ของ harness ไม่ว่าจะเป็น prompt, AGENTS.md, ชุดเครื่องมือ หรือโมเดล ล้วนเป็นการเดิมพันโดยไม่รู้ผล แต่ถ้ามี evals มันจะกลายเป็นการทดลองที่มีผลวัดได้

ทำไมความรู้สึกถึงหลอกเรา

ความประทับใจจากการทำงานของ agent มีความผิดพลาดเชิงระบบอยู่สามอย่าง และทุกอย่างผลักเราไปสู่ความมั่นใจที่ผิดที่

• อคติจากผู้รอดชีวิต (survivorship bias) การรันที่สำเร็จถูกจดจำและแสดงให้เพื่อนร่วมทีมดู ส่วนการรันที่ล้มเหลวถูกรันซ้ำและถูกลืม ความน่าเชื่อถือที่คำนวณจากการรันที่สำเร็จไม่บอกอะไรเลยว่า agent พังตรงไหนจริง ๆ
• ตัวอย่างเล็กเกินไป งานที่สำเร็จสามงานติดกันเป็นเรื่องปกติแม้กับ agent ที่สำเร็จเพียงครึ่งเดียว โอกาสเกิดขึ้นคือ 0.5³ = 12.5% หรือราวหนึ่งในแปดของชุดงาน
• น้ำเสียงที่มั่นใจ agent เขียนว่า "เสร็จแล้ว เทสต์ผ่านทั้งหมด" ด้วยความมั่นใจเท่ากันทั้งตอนที่จริงและตอนที่ไม่จริง ความมั่นใจของโมเดลไม่ได้ถูกปรับเทียบ น้ำเสียงของคำตอบจึงไม่ใช่สัญญาณของความถูกต้อง

จากข้อนี้จึงได้กฎว่า สิ่งที่ไม่ได้บันทึกและไม่ได้คำนวณใหม่ ถือว่าไม่ได้วัด

pass@k และ pass^k: สองตัวชี้วัดที่มักสับสน

agent ไม่มีความแน่นอน งานเดียวกันเมื่อรันซ้ำอาจผ่านหรือไม่ผ่านก็ได้ ดังนั้นจึงรันแต่ละงานหลายครั้งแล้วคำนวณตัวชี้วัดหนึ่งในสองตัว

pass@k: อย่างน้อยหนึ่งครั้งจาก k ครั้งสำเร็จ

ตัวชี้วัดนี้มาจากการประเมินการสร้างโค้ด มันตอบคำถามว่า "ระบบนี้สามารถแก้งานได้หรือไม่ หากให้ลองหลายครั้ง" เหมาะสำหรับสถานการณ์ที่มนุษย์เลือกผลลัพธ์ที่ดีที่สุดจากหลายตัวเลือก หรือมีการตรวจอัตโนมัติที่เชื่อถือได้ซึ่งคัดผลที่ไม่ดีออก

pass^k: สำเร็จทั้ง k ครั้ง

ตัวชี้วัดนี้ตอบคำถามอีกข้อ: "agent แก้งานนี้ได้เสถียรแค่ไหน" มันอธิบายการทำงานโดยไม่มีคนดูแล เมื่อ agent ถูกรันหลายครั้งและทุกความล้มเหลวมีต้นทุนเป็นเงินหรือเวลา

ความต่างระหว่างสองตัวนี้ใหญ่มาก สมมติ agent แก้งานได้ 70% ในหนึ่งครั้ง และแต่ละครั้งเป็นอิสระต่อกัน:

จาก pass@5 agent ดูเกือบสมบูรณ์แบบ แต่จาก pass^5 มันดูไม่น่าเชื่อถือ ตัวเลขทั้งสองถูกต้อง เพียงแต่อธิบายสิ่งต่างกัน หากคุณจะปล่อยให้ agent ทำงานอัตโนมัติ ให้ดู pass^k เพราะมันใกล้เคียงกับสิ่งที่คุณจะเห็นในการทำงานจริงมากกว่า

วิธีคำนวณในทางปฏิบัติ

รันแต่ละงาน n ครั้ง (เช่น 5 ครั้ง) และบันทึกจำนวนครั้งที่สำเร็จ c สำหรับ pass^k ค่าประมาณคือสัดส่วนของการรันที่สำเร็จทั้ง k ครั้งติดต่อกัน หรือง่ายกว่านั้นคือประมาณความน่าจะเป็นสำเร็จ p = c / n แล้วยกกำลัง k สำหรับชุดงาน ให้หาค่าเฉลี่ยทั่วทุกงาน

import json
from statistics import mean

# results.jsonl: {"task": "add-pagination", "runs": [true, true, false, true, true]}
rows = [json.loads(line) for line in open("results.jsonl")]

def pass_at_k(runs, k):
    p = sum(runs) / len(runs)
    return 1 - (1 - p) ** k

def pass_pow_k(runs, k):
    p = sum(runs) / len(runs)
    return p ** k

for k in (1, 3, 5):
    print(k,
          round(mean(pass_at_k(r["runs"], k) for r in rows), 3),
          round(mean(pass_pow_k(r["runs"], k) for r in rows), 3))

การประมาณผ่าน p ยกกำลัง k หยาบเมื่อ n น้อย แต่สำหรับการเปรียบเทียบเวอร์ชันของ harness มักเพียงพอ สิ่งที่สำคัญกว่าคือ n และชุดงานต้องไม่เปลี่ยนระหว่างการเปรียบเทียบ

วิธีสร้างชุดงานสำหรับ evals

ชุดงานคือทรัพย์สินหลัก ตัวชี้วัดที่ดีบนงานที่ไม่ดีจะวัดสิ่งที่ผิด

เลือกงานจากสภาพจริงของคุณ

benchmark สาธารณะอย่าง SWE-bench มีประโยชน์สำหรับเปรียบเทียบโมเดล แต่งานเหล่านั้นถูกคัดมาแล้ว มีคำอธิบายชัดเจนและมีเทสต์พร้อมใช้ ในรีโพซิทอรีของคุณ ข้อกำหนดมักคลุมเครือและบางส่วนไม่มีเทสต์ ตัวเลขจาก benchmark จึงแทบจะสูงกว่าที่ agent จะทำได้ในงานของคุณเสมอ แหล่งงานที่ดีที่สุดคือ ticket ที่ปิดแล้วและความล้มเหลวจริงของ agent ที่บันทึกไว้ในล็อก

องค์ประกอบของชุดงาน

• 20–50 งานเพื่อเริ่มต้น น้อยกว่านั้น สัญญาณรบกวนจะกลืนความต่างระหว่างเวอร์ชัน มากกว่านั้น การรันจะแพงและจะไม่มีใครอยากรัน
• หลายประเภท: ฟีเจอร์ใหม่ การแก้บั๊ก การรีแฟกเตอร์ งานในโมดูลของคนอื่น และงานกับดัก (ซึ่งคำตอบที่ถูกต้องคือ "ทำแบบนี้ไม่ได้" หรือ "ต้องขอข้อมูลเพิ่ม")
• งานที่ล้มเหลวในการทำงานจริงทุกงานกลายเป็นเทสต์ ชุดงานจะเติบโตไปพร้อมกับความเข้าใจว่า agent อ่อนตรงไหน และการถดถอยจะไม่หลุดรอดไปโดยไม่มีใครสังเกต
• สถานะเริ่มต้นที่ตายตัว: commit ที่แน่นอน dependency ที่ล็อกไว้ และสภาพแวดล้อมเดียวกัน ไม่เช่นนั้นคุณจะวัดการเปลี่ยนแปลงของสภาพแวดล้อม ไม่ใช่ตัว agent

รูปแบบของงาน

แต่ละงานประกอบด้วยคำอธิบาย สถานะเริ่มต้น และเกณฑ์ความสำเร็จที่ตรวจได้โดยไม่ต้องมีคน

id: add-pagination
repo_ref: 3f2c1ab
prompt: |
  เพิ่มการแบ่งหน้าให้ GET /payments: พารามิเตอร์ limit (ค่าเริ่มต้น 20 สูงสุด 100)
  และ cursor คำตอบต้องมี next_cursor
check:
  - pytest tests/test_payments_pagination.py
  - mypy app/
limits:
  max_changed_files: 6

สังเกตว่าเกณฑ์ความสำเร็จคือ Definition of Done ที่เขียนเป็นคำสั่ง ถ้าคุณเขียนเกณฑ์ของงานไม่ได้ นั่นเป็นสัญญาณว่างานนั้นถูกมอบหมายให้ agent อย่างคลุมเครือเช่นกัน

การตรวจอัตโนมัติ หรือ LLM judge

ผลลัพธ์สามารถตรวจด้วยโค้ดหรือด้วยโมเดลอีกตัวก็ได้ วิธีแต่ละแบบมีขอบเขตของตัวเอง

กฎ: ใช้โค้ดก่อน แล้วค่อยเพิ่ม judge

สิ่งที่ตรวจแบบกำหนดแน่นอนได้ ให้ตรวจแบบกำหนดแน่นอน ใช้ LLM judge เฉพาะกับคุณสมบัติที่โค้ดแสดงไม่ได้ และไม่เคยใช้แทนเทสต์

ทำให้ LLM judge มีประโยชน์ได้อย่างไร

• บริบทที่ต่างจากผู้สร้าง judge ไม่ควรเห็นเหตุผลของ agent มันควรเห็นแค่งาน เกณฑ์ และ diff สุดท้าย มิฉะนั้นมันจะทำซ้ำข้อผิดพลาดเดิม นี่คือ N-version คือมุมมองอิสระสองแบบแทนที่จะเป็นมุมมองเดียว
• rubric แทนการให้คะแนนสิบระดับ ใช้คำถามเจาะจงที่ตอบได้ด้วยใช่หรือไม่ เช่น "มีการตรวจ limit > 100 หรือไม่" หรือ "มีการแก้ไฟล์นอก app/payments หรือไม่"
• ปรับเทียบด้วยการติดป้ายด้วยมือ ติดป้ายผลลัพธ์ด้วยมือ 20–30 รายการแล้วเทียบกับคำตัดสินของ judge ถ้าความสอดคล้องต่ำ ให้แก้ rubric ไม่ใช่เชื่อ judge มากขึ้น
• ความไม่สมมาตรของความผิดพลาด "เสร็จแล้ว" ที่ผิดแพงกว่า "ยังไม่เสร็จ" ที่ผิด ความผิดแรกหลุดไปถึง production ส่วนความผิดหลังเสียแค่การรันใหม่หนึ่งครั้ง ตั้งค่า judge ให้ปฏิเสธเมื่อมีข้อสงสัย

ตัวชี้วัดอื่นนอกจากอัตราความสำเร็จ

อัตราของงานที่แก้ได้เป็นเพียงส่วนบนสุด เพื่อให้เข้าใจว่าควรแก้ตรงไหน ต้องใช้ตัวชี้วัดความน่าเชื่อถือจากวิศวกรรมแบบดั้งเดิม

• MTBF จำนวนขั้นตอนหรืองานที่ agent ทำได้ก่อนจะติดขัด แสดงว่ามันพังไม่บ่อยแค่ไหน
• MTTR เวลาที่ใช้ในการกลับสู่สถานะที่ทำงานได้หลังความล้มเหลว การลด MTTR มักถูกกว่าการเพิ่ม MTBF เสมอ ไฟล์ความคืบหน้าที่ดีและสภาพแวดล้อมที่ทำซ้ำได้ช่วยลดเวลาการกู้คืนลงได้หลายเท่า
• รัศมีความเสียหาย ขั้นตอนที่ล้มเหลวหนึ่งขั้นทำให้โค้ดเสียหายเท่าไร ควบคุมได้ด้วยขีดจำกัดของ diff และการแยกสำเนาของงาน
• สัดส่วนของ "เสร็จ" ที่ผิด งานที่ agent ประกาศว่าสำเร็จแต่การตรวจล้มเหลว เป็นตัวชี้วัดที่อันตรายที่สุด เพราะมันบอกได้ว่าควรเชื่อรายงานของ agent หรือไม่
• ต้นทุนและเวลา โทเคนและนาทีต่องาน harness ที่เพิ่มความสำเร็จ 5% แต่ทำให้ต้นทุนเพิ่มเป็นสองเท่า ไม่ได้ชนะเสมอไป

บันทึกความล้มเหลว: evals จากงานประจำวัน

ไม่ใช่ทุกทีมจะพร้อมสร้างตัวรันการประเมินตั้งแต่แรก เวอร์ชันขั้นต่ำของการประเมินคือบันทึกความล้มเหลวที่มีสามคอลัมน์

| งาน                     | ผลลัพธ์                            | ชั้น          |
|-------------------------|------------------------------------|---------------|
| pagination /payments    | "เสร็จแล้ว" เทสต์แดง 2 ตัว         | การตรวจสอบ    |
| แก้ timeout ของ webhook | เสียเวลา 30 นาทีไปกับ pip install | สภาพแวดล้อม   |
| รีแฟกเตอร์ refunds      | ใช้ไวยากรณ์ ORM แบบเก่า            | บริบท         |

ชั้นคือหนึ่งในห้าจุดที่ agent มักพัง ได้แก่ ข้อกำหนดของงาน บริบท สภาพแวดล้อมการรัน ข้อมูลตอบกลับจากการตรวจ และการจัดการสถานะ หลังจากผ่านไปยี่สิบรายการ จะเห็นคอขวดที่แท้จริง และเกือบทุกครั้งมันไม่ได้อยู่ตรงที่คุณคิด ทุกบรรทัดในบันทึกคือผู้สมัครเป็นงานในชุด evals

ทำไมโมเดลที่แรงกว่าจึงไม่ช่วยเสมอไป

ปฏิกิริยาแรกต่อความล้มเหลวของ agent คือเปลี่ยนไปใช้โมเดลที่แพงขึ้น บางครั้งก็ช่วยได้ แต่บ่อยครั้งช่องว่างระหว่าง benchmark กับความเป็นจริงของคุณถูกปิดด้วยสภาพแวดล้อมรอบ ๆ ไม่ใช่ตัวโมเดล

ถ้า agent ใช้เวลาครึ่งชั่วโมงในการตั้งค่าสภาพแวดล้อม นั่นคือปัญหาที่ชั้นสภาพแวดล้อม และโมเดลระดับเรือธงก็จะใช้เวลาครึ่งชั่วโมงเท่ากัน ถ้า agent บอกว่า "เสร็จแล้ว" ทั้งที่เทสต์แดง นั่นคือชั้นการตรวจสอบ ซึ่งไม่มีคำสั่งใดบอกความจริง ถ้ามันเขียนโค้ดในสไตล์ที่ไม่ใช่ของโปรเจกต์ นั่นเพราะไม่ได้ให้ข้อตกลงของโปรเจกต์กับมัน ไม่มีปัญหาเหล่านี้ที่เกี่ยวกับสติปัญญาของโมเดลเลย

evals ทำให้ตรวจสิ่งนี้ได้อย่างซื่อตรง รันชุดงานด้วยโมเดลปัจจุบันและโมเดลที่แพงกว่า จากนั้นรันด้วยโมเดลปัจจุบันพร้อม AGENTS.md ที่มีคำสั่งตรวจ บ่อยครั้งการเปลี่ยนครั้งที่สองให้ผลมากกว่าการเปลี่ยนครั้งแรกโดยไม่เสียค่าใช้จ่ายอะไรเลย แต่อย่าเชื่อเรื่องนี้เพียงเพราะได้ยินมา การเปรียบเทียบแบบนี้คือเหตุผลที่ต้องมีชุดงาน

แผนทีละขั้น: ประเมิน AI agent ใน 1 สัปดาห์

1. วันที่ 1 เปิดบันทึกความล้มเหลวและจดทุกความล้มเหลวของ agent พร้อมระบุชั้น
2. วันที่ 2 คัดงาน 20 งานจาก ticket ที่ปิดแล้วและจากบันทึก สำหรับแต่ละงาน ล็อก commit และเขียนเกณฑ์ความสำเร็จเป็นคำสั่ง
3. วันที่ 3 เขียนตัวรันการประเมิน: สำเนางานที่สะอาด รัน agent ด้วย prompt ของงาน รันการตรวจ และบันทึกผลเป็น JSONL
4. วันที่ 4 รันแต่ละงาน 3–5 ครั้ง คำนวณ pass@1, pass^3, สัดส่วนของ "เสร็จ" ที่ผิด และต้นทุนเฉลี่ย
5. วันที่ 5 เปลี่ยนหนึ่งสิ่งใน harness แล้วรันใหม่ เปรียบเทียบเฉพาะเมื่อชุดงานและจำนวนการรันซ้ำเหมือนกัน

เปลี่ยนทีละตัวแปร ถ้าในการทดลองเดียวคุณเปลี่ยนทั้งโมเดล prompt และเครื่องมือ คุณจะไม่รู้ว่าอะไรได้ผล

ข้อผิดพลาดที่พบบ่อยในการประเมิน agent

• รันหนึ่งครั้งต่องาน ความไม่แน่นอนของ agent ทำให้ผลลัพธ์เป็นเหมือนการจับสลาก อย่างน้อยรันซ้ำสามครั้ง
• ชุดงานเปลี่ยนระหว่างการเปรียบเทียบ เพิ่มงานใหม่และเปลี่ยน prompt พร้อมกัน ทำให้ตัวเลขเทียบกันไม่ได้
• agent เห็นเทสต์ที่ใช้ตรวจ ถ้าเทสต์อยู่ในรีโพซิทอรี agent อาจปรับโค้ดให้เข้ากับเทสต์ หรือแก้ไขเทสต์ไปเลย เก็บการตรวจที่ซ่อนไว้นอกสำเนางาน และตรวจว่า agent ไม่ได้แตะไฟล์เทสต์
• ใช้รายงานของ agent แทนการตรวจ "เทสต์ทั้งหมดผ่าน" ในคำตอบของโมเดลไม่ใช่ผลลัพธ์ ผลลัพธ์คือรหัสที่คำสั่งซึ่งตัวรันเป็นผู้เรียกคืนค่า
• ดูแค่ pass@k ตัวเลขสวยสำหรับการนำเสนอ แต่เป็นการคาดการณ์ที่แย่สำหรับการทำงานอัตโนมัติ

สรุป

การประเมิน AI agent คือชุดงานจริงที่ตายตัว การตรวจอัตโนมัติ และตัวชี้วัดที่คำนวณใหม่ทุกครั้งที่ harness เปลี่ยน pass@k บอกว่า agent ทำอะไรได้บ้าง ส่วน pass^k บอกว่าไว้ใจให้ทำงานโดยไม่มีคนดูได้หรือไม่ การตรวจอัตโนมัติให้ความจริง ส่วน LLM judge ที่มี rubric และบริบทแยกต่างหากช่วยเติมเต็มในจุดที่โค้ดทำไม่ได้ และบันทึกความล้มเหลวที่แบ่งตามห้าชั้นแสดงว่าควรแก้อะไรก่อน ซึ่งส่วนใหญ่แล้วไม่ใช่โมเดล วงจรการวินิจฉัยและตัวชี้วัดความน่าเชื่อถือถูกอธิบายและนำไปใช้จริงในคอร์สเกี่ยวกับ harness engineering