Anthropic Engineering: คู่มือเชิงปฏิบัติและวิธีวิทยาสำหรับการประเมิน AI Agent (Evals)

สรุป:

• การใช้เพียง benchmark ของ LLM แบบเดิมยังวัดประสิทธิภาพของ 'AI Agent' ที่ใช้เครื่องมือและทำการให้เหตุผลหลายขั้นตอนได้อย่างแม่นยำได้ยาก
• การประเมิน Agent ควรผสานทั้ง Unit Tests และ Integration Tests คล้ายกับการทดสอบซอฟต์แวร์
• การผสมผสานการให้คะแนนแบบกำหนดแน่นอนด้วยโค้ด (Code-based) และการให้คะแนนแบบอิงโมเดลด้วย LLM (Model-based) มีประสิทธิภาพ
• ควรเปลี่ยนจาก 'Capability Evals' ไปสู่ 'Regression Evals' ให้สอดคล้องกับวงจรชีวิตการพัฒนา Agent

สรุปแบบละเอียด:

1. ทำไมการประเมิน AI Agent จึงยาก
   ต่างจากแชตบอตแบบรอบเดียว (Single-turn) Agent สามารถใช้เครื่องมือ เปลี่ยนสถานะของสภาพแวดล้อม และทำงานต่อเนื่องหลายขั้นตอน (Multi-turn) ได้ ดังนั้นการตรวจเพียงคำตอบสุดท้ายจึงไม่เพียงพอ แต่ต้องประเมินโดยรวมว่า Agent ใช้เครื่องมือได้ถูกต้องหรือไม่ และกระบวนการมีประสิทธิภาพเพียงใด

2. โครงสร้างของการประเมิน Agent (Eval)
   ระบบประเมินที่มีประสิทธิภาพประกอบด้วยองค์ประกอบสำคัญดังต่อไปนี้

• Task: เคสทดสอบเดี่ยวที่มีอินพุตและเกณฑ์ความสำเร็จที่กำหนดไว้
• Grader: ตรรกะสำหรับให้คะแนนผลการทำงานของ Agent
• Transcript: บันทึกการทำงานทั้งหมด รวมถึงกระบวนการคิดของ Agent การเรียกใช้เครื่องมือ และผลลัพธ์ระหว่างทาง
• Outcome: สถานะสุดท้ายของสภาพแวดล้อมหลังการทำงานของ Agent (เช่น มีการสร้างการจองใน DB จริงหรือไม่)

3. เปรียบเทียบประเภทของ Grader
   Anthropic แนะนำให้ใช้ Grader ทั้งสามประเภทต่อไปนี้ร่วมกัน

ประเภท	คำอธิบาย	ข้อดี	ข้อเสีย
Code-based	การจับคู่สตริง, regex, static analysis, การรัน unit test เป็นต้น	เร็ว, ต้นทุนต่ำ, เป็นกลาง, ทำซ้ำได้	อาจพลาดความละเอียดอ่อนที่ซับซ้อน, ยืดหยุ่นน้อย
Model-based	ใช้ LLM เป็นกรรมการ (Judge) เพื่อให้คะแนนตาม rubric	ยืดหยุ่น, จับความละเอียดอ่อนได้, เหมาะกับคำถามปลายเปิด	อาจไม่เป็นแบบกำหนดแน่นอน, มีต้นทุน, ต้องมีมนุษย์ช่วยปรับเทียบ
Human	รีวิวโดยผู้เชี่ยวชาญ, crowdsourcing	เป็น 'gold standard' ด้านคุณภาพ	ช้ามากและมีค่าใช้จ่ายสูง

4. ตัวอย่างการประเมิน Coding Agent (การตั้งค่า YAML)
   เมื่อต้องประเมิน Coding Agent เราไม่ควรดูเพียงว่าโค้ดรันได้หรือไม่ (การทดสอบแบบกำหนดแน่นอน) แต่ควรพิจารณาร่วมด้วยว่ามีการละเมิดรูปแบบการเขียนโค้ดหรือความปลอดภัยหรือไม่ (static analysis/การให้คะแนนด้วย LLM) ต่อไปนี้คือตัวอย่างสมมติของการตั้งค่าการประเมินสำหรับ Task 'แก้ไขช่องโหว่ด้านความปลอดภัย'

task:  
  id: "fix-auth-bypass_1"  
  desc: "แก้ไขช่องโหว่การข้ามการยืนยันตัวตนที่เกิดขึ้นเมื่อฟิลด์รหัสผ่านว่าง"  
  graders:  
    # 1. การทดสอบแบบกำหนดแน่นอน: ตรวจว่าชุดทดสอบจริงผ่านหรือไม่  
    - type: deterministic_tests  
      required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]  
    
    # 2. การให้คะแนนตาม rubric ด้วย LLM: ประเมินคุณภาพและสไตล์ของโค้ด  
    - type: llm_rubric  
      rubric: prompts/code_quality.md  
    
    # 3. static analysis: รัน linter และเครื่องมือด้านความปลอดภัย  
    - type: static_analysis  
      commands: [ruff, mypy, bandit]  
    
    # 4. ตรวจสอบสถานะ: ตรวจว่า security log ถูกบันทึกไว้อย่างถูกต้องหรือไม่  
    - type: state_check  
      expect:  
        security_logs: {event_type: "auth_blocked"}  
    
    # 5. ตรวจการใช้เครื่องมือ: อ่านและแก้ไขไฟล์ที่จำเป็นหรือไม่  
    - type: tool_calls  
      required:  
        - {tool: read_file, params: {path: "src/auth/*"}}  
        - {tool: edit_file}  
        - {tool: run_tests}  
  
  # metrics ที่ใช้ติดตาม  
  tracked_metrics:  
    - type: transcript  
      metrics:  
        - n_turns # จำนวนรอบ  
        - n_toolcalls # จำนวนครั้งที่เรียกใช้เครื่องมือ  
        - n_total_tokens # ปริมาณการใช้โทเคน  
    - type: latency  
      metrics:  
        - time_to_first_token  

5. ตัวชี้วัดการประเมิน (Metrics)
   เพื่อรับมือกับลักษณะที่ไม่เป็นแบบกำหนดแน่นอนของ Agent นอกจากความแม่นยำแบบพื้นฐานแล้ว ยังใช้ตัวชี้วัดต่อไปนี้ด้วย

• pass@k: ความน่าจะเป็นที่จะสำเร็จอย่างน้อย 1 ครั้งจากความพยายาม k ครั้ง (ใช้วัดความสามารถในการสำรวจ)
• pass^k: ความน่าจะเป็นที่ทุกความพยายามทั้ง k ครั้งจะสำเร็จ (ใช้วัดความสม่ำเสมอ/ความน่าเชื่อถือ)

6. เครื่องมือและเฟรมเวิร์ก
   สำหรับการสร้างระบบประเมิน มีข้อเสนอให้ใช้เครื่องมืออย่าง Harbor (รันในสภาพแวดล้อมคอนเทนเนอร์), Promptfoo (การตั้งค่าการทดสอบแบบอิง YAML), Braintrust, LangSmith หรือสร้างเฟรมเวิร์กภายในที่เหมาะกับ workflow ของทีมเอง สิ่งสำคัญไม่ใช่ตัวเฟรมเวิร์ก แต่คือการมีเคสทดสอบคุณภาพสูงเพียงพอ

[darjeeling]

เนื้อหาดีมาก เลยขอเพิ่มฉบับแปลภาษาเกาหลีไว้ด้วย

https://rosettalens.com/s/ko/demystifying-evals-for-ai-agents