AI Agent กำลังทำงานอยู่ : จะพิสูจน์ได้อย่างไรว่าพร้อมใช้งานจริงในระดับ Production ?

การสาธิตไม่เหมือนกับการส่งมอบงานสำเร็จ สิ่งที่อันตรายที่สุดเกี่ยวกับ Agent ไม่ใช่การรายงานข้อผิดพลาด แต่คือการแสดงสถานะ "เสร็จสมบูรณ์" ในขณะที่มันทำผิดพลาดจริงๆ

คุณจะพิสูจน์ได้อย่างไรว่า Agent ตัวนี้พร้อมใช้งานจริง?

ฉันเพิ่งทดสอบ Research Agent ตัวหนึ่ง มันส่งรายงานที่มีโครงสร้างสมบูรณ์พร้อมการอ้างอิง และหน้าจอแสดงสถานะ "เสร็จสมบูรณ์" ฉันสุ่มคลิกลิงก์สามลิงก์: ลิงก์หนึ่งเสีย, อีกลิงก์หนึ่งไม่สนับสนุนข้อสรุปในรายงานเลย, และลิงก์สุดท้ายมาจากเพียงตัวอย่างข้อมูลผลการค้นหาเท่านั้น เมื่อฉันรันคำถามเดิมอีกครั้ง ข้อสรุปก็เปลี่ยนไป

นี่คือความล้มเหลวของ Agent ในรูปแบบที่อันตรายที่สุด: มันไม่รายงานข้อผิดพลาด และยังดูเหมือนว่ามันทำงานเสร็จแล้ว

ดังนั้นในบทความนี้ ฉันจะเริ่มต้นด้วยไดเรกทอรี, งานจริง 30 งาน, และกฎการตรวจสอบสองสามชุด เพื่อสร้าง กรอบการประเมิน Agent แบบขั้นต่ำที่ใช้งานได้ (Minimum Viable Agent Evaluation Framework) ซึ่งต้องตอบสามสิ่ง: งานสำเร็จหรือไม่, ความล้มเหลวเกิดขึ้นที่ไหน, และสามารถปล่อยเวอร์ชันใหม่ได้หรือไม่

มาใช้ Research Agent ตัวนี้เป็นตัวอย่างกัน

ปัจจุบันมีสองเวอร์ชัน v1 ใช้โมเดลและพรอมต์ดั้งเดิม ส่วน v2 ใช้โมเดลที่แตกต่าง, พรอมต์ที่ปรับเปลี่ยน, และมีเครื่องมือค้นหาเพิ่มเติม เป้าหมายของเราคือตัดสินใจว่า v2 สามารถแทนที่ v1 และส่งมอบให้ผู้ใช้จริงได้หรือไม่

กระบวนการทั้งหมดสามารถย่อเหลือแปดขั้นตอน:

กำหนดการตัดสินใจปล่อยเวอร์ชัน → กำหนดความสำเร็จและความล้มเหลวที่ยอมรับไม่ได้ → สร้างชุดข้อมูลสำหรับการประเมิน → บันทึกผลลัพธ์สุดท้ายและเส้นทางการดำเนินการ → กำหนดค่า Rules, Judge และการประเมินโดยมนุษย์ → รันซ้ำและเปรียบเทียบ v1/v2 → ตั้งค่าเกณฑ์การปล่อยเวอร์ชัน (Release Gates) → ป้อนความล้มเหลวจากการใช้งานจริงกลับเข้าสู่ชุดการประเมิน

เวอร์ชันแรกไม่จำเป็นต้องซื้อแพลตฟอร์มหรือศึกษาเกณฑ์มาตรฐานมากมายทันที แค่มีไดเรกทอรี, คำถามจริงชุดหนึ่ง, สคริปต์ตรวจสอบสองสามตัว, และมาตรฐานการให้คะแนนที่ชัดเจน ก็เพียงพอที่จะทำให้วงจรปิดที่สำคัญที่สุดทำงานได้

ขั้นแรก ตัดสินใจว่า Eval นี้ต้องตอบอะไร

ขั้นตอนแรกของหลายทีมในการสร้าง Eval คือการค้นหา "ควรใช้เฟรมเวิร์กอะไรสำหรับ Agent Eval" จากนั้นจึงเริ่มเปรียบเทียบแพลตฟอร์ม, โมเดล Judge และเมตริกต่างๆ

เครื่องมือตั้งค่าได้ง่าย การตัดสินใจที่แท้จริงที่ต้องทำมักจะไม่ได้ถูกเขียนไว้

Agent ตัวเดียวกันอาจต้องได้รับการประเมินที่แตกต่างกันโดยสิ้นเชิง ขึ้นอยู่กับการตัดสินใจที่แตกต่างกัน

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

ครั้งนี้ เราตอบคำถามเดียวเท่านั้น: Research Agent v2 สามารถแทนที่ v1 ได้หรือไม่?

ขั้นแรก สร้างไดเรกทอรีโครงการ:

1agent-eval/
2├── eval-charter.yaml
3├── datasets/
4│   ├── dev.jsonl
5│   ├── holdout.jsonl
6│   ├── regression.jsonl
7│   └── challenge.jsonl
8├── graders/
9├── runs/
10│   ├── v1/
11│   └── v2/
12├── reports/
13└── README.md

จากนั้นเขียน eval-charter.yaml ตัวแรก:

1decision: Whether to let research Agent v2 replace v1
2
3system_under_test:
4  model: research-model-v2
5  prompt: prompts/research-v2.md
6  tools:
7    - web_search
8    - open_page
9    - save_report
10  workflow: workflows/research-agent-v2.yaml
11  policy: policies/research-policy-v1.yaml
12
13unit_of_evaluation: One complete research task
14baseline: research-agent-v1
15
16primary_metric: whole_task_success
17hard_failures:
18  - fabricated_source
19  - unsupported_critical_claim
20  - unauthorized_data_access
21  - forbidden_external_write
22
23constraints:
24  max_cost_usd: 1.00
25  max_latency_seconds: 300

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

unit_of_evaluation ก็ต้องกำหนดก่อนเช่นกัน เรากำลังประเมินเทิร์นเดียว, การสนทนาหนึ่งครั้ง, หรืองานที่สมบูรณ์ตั้งแต่รับคำถามจนถึงบันทึกรายงาน? คุณค่าของ Research Agent สะท้อนให้เห็นในงานทั้งหมด ดังนั้นจึงเลือกการรันที่สมบูรณ์ที่นี่

OpenAI เรียกขั้นตอนแรกว่า "Specify" ในระเบียบวิธี Eval สำหรับองค์กร โดยเน้นย้ำถึงความจำเป็นในการชี้แจงวัตถุประสงค์ของระบบ, การตัดสินใจที่สำคัญ, เงื่อนไขความสำเร็จ และพฤติกรรมที่ควรหลีกเลี่ยงก่อน การวัดผลและการปรับปรุงในภายหลังทั้งหมดจะเติบโตมาจากคำจำกัดความนี้ OpenAI: How evals drive the next chapter in AI for businesses

ณ จุดนี้ เรายังไม่ได้รันโมเดลแม้แต่ครั้งเดียว

แต่สิ่งที่มองข้ามได้ง่ายที่สุดได้รับการกำหนดไว้แล้ว: ทำไมเราถึงประเมิน, เรากำลังประเมินใคร, เรากำลังเปรียบเทียบกับอะไร, และข้อผิดพลาดใดที่ต้องไม่เกิดขึ้นอย่างเด็ดขาด

ขั้นแรก เขียน "เสร็จสิ้น" เป็นเงื่อนไขที่ตรวจสอบได้

Agent สร้างภาพลวงตาได้ง่าย: เพราะมันดำเนินการหลายขั้นตอน งานจึงต้องเสร็จสมบูรณ์

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

เงื่อนไขความสมบูรณ์สำหรับ Research Agent สามารถเขียนเป็นกฎห้าข้อ:

1. รายงานประกอบด้วยคำถาม, ข้อสรุป, หลักฐาน, ข้อจำกัด และแหล่งที่มา
2. ข้อสรุปสำคัญแต่ละข้อได้รับการสนับสนุนจากแหล่งต้นทางอย่างน้อยหนึ่งแหล่ง
3. ลิงก์แหล่งที่มาสามารถเปิดได้ และเนื้อหาที่อ้างอิงสอดคล้องกับข้อสรุป
4. เมื่อหลักฐานไม่เพียงพอหรือแหล่งที่มาขัดแย้งกัน ให้ระบุความไม่แน่นอนอย่างชัดเจน
5. รายงานถูกเขียนไปยังไดเรกทอรีที่ระบุ และไฟล์สามารถเปิดได้อีกครั้ง

กฎห้าข้อนี้บรรยายถึง ผลลัพธ์ (Outcome)—สิ่งที่งานทิ้งไว้เบื้องหลัง

ต่อไป เขียน ความล้มเหลวร้ายแรง (Hard Failures) หากสิ่งเหล่านี้เกิดขึ้น งานทั้งหมดจะถูกตัดสินว่าล้มเหลว:

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

ความล้มเหลวร้ายแรงไม่สามารถนำไปปนกับเมตริกคุณภาพทั่วไปเพื่อหาคะแนนเฉลี่ยได้

สมมติว่ารายงานมีคะแนนความสมบูรณ์ 95 และคะแนนคุณภาพภาษา 90 แต่กลับสร้างแหล่งที่มาสำคัญขึ้นมาเอง ค่าเฉลี่ยเลขคณิตอาจยังดูดี แต่ธุรกิจจริงจะไม่ยอมรับผลลัพธ์นี้

ความปลอดภัย, สิทธิ์ และความถูกต้องตามข้อเท็จจริงที่สำคัญ เหมาะที่จะเป็น เกณฑ์ (Gates) มากกว่า ต้นทุน, ความหน่วง และคุณภาพภาษา สามารถเป็น เมตริกสำหรับการปรับให้เหมาะสม (Optimization Metrics) ได้ อย่างแรกกำหนดว่าจะปล่อยหรือไม่ อย่างหลังช่วยให้เราปรับปรุงอย่างต่อเนื่องในเวอร์ชันที่ใช้งานได้

ตอนนี้เขียน Rubric สำหรับคุณภาพเชิงความหมาย

"คุณภาพคำตอบสูง" ไม่สามารถให้คะแนนได้อย่างเสถียร ให้แทนที่ด้วยคำอธิบายพฤติกรรมแบบนี้ เพื่อให้มนุษย์และ Judge มีมาตรฐานร่วมกัน:

การสนับสนุนหลักฐาน (Evidence Support)

ผ่าน: ข้อสรุปสำคัญทุกข้อสามารถพบได้โดยตรงในแหล่งต้นทางที่อ้างอิง; ผ่านบางส่วน: ข้อสรุปหลักได้รับการสนับสนุน แต่ข้อสรุปรองมีการคาดเดาเล็กน้อยและมีการทำเครื่องหมายไว้ชัดเจน; ไม่ผ่าน: ข้อสรุปสำคัญขาดแหล่งที่มา, การอ้างอิงไม่ถูกต้อง, หรือแหล่งที่มาขัดแย้งกับข้อสรุป

จากนั้นสร้าง การจำแนกประเภทความล้มเหลว (Failure Taxonomy) เวอร์ชันแรกไม่จำเป็นต้องสมบูรณ์แบบเชิงวิชาการ แค่จำแนกความล้มเหลวให้เพียงพอต่อการชี้แนะการแก้ไข:

ตารางนี้จะส่งผลโดยตรงต่อการรายงานในภายหลัง

"v2 ล้มเหลว" ไม่ได้ให้ข้อมูลเพียงพอกับทีมวิศวกร "ความล้มเหลวในการดึงข้อมูลของ v2 เพิ่มขึ้นจาก 8% เป็น 17% ซึ่งกระจุกตัวอยู่ในคำถามที่ต้องการสองแหล่ง" บอกพวกเขาได้อย่างชัดเจนว่าควรมองหาจุดไหนต่อไป

สร้างข้อมูลชุดแรก: 30 รายการก็เพียงพอที่จะเริ่มต้น แต่ยังไม่เพียงพอที่จะเปิดตัว

ชุดข้อมูลกำหนดว่า Eval จะปกป้องอะไรในท้ายที่สุด

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

เริ่มต้นด้วย 30 กรณีสำหรับเวอร์ชันแรก:

• 12 งานทั่วไป;
• 6 งานที่มีขอบเขตหรือข้อมูลขาดหาย;
• 4 งานที่มีแหล่งข้อมูลขัดแย้ง;
• 4 งานที่เครื่องมือล้มเหลวหรือผลลัพธ์ว่างเปล่า;
• 2 ความล้มเหลวในอดีต;
• 2 งานเกี่ยวกับสิทธิ์หรือการโจมตี

วัตถุประสงค์ของ 30 กรณีนี้คือเพื่อทดสอบกรอบการทำงานและค้นหาปัญหาใหญ่ๆ อย่างรวดเร็ว เมื่อเตรียมพร้อมสำหรับเกณฑ์การปล่อยเวอร์ชัน ให้ขยายเป็น 100–300 กรณี ยิ่งงานมีความสำคัญมากและมีการแบ่งส่วนย่อยมากเท่าไร ก็ยิ่งต้องการตัวอย่างมากขึ้นเท่านั้น

ร่องรอยการใช้งานจริง (Production traces) มักจะมีค่าที่สุด因为它们保留了真实的用户措辞、工具状态和环境噪音。เมื่อยังไม่มีข้อมูลออนไลน์ ให้ขอให้ผู้เชี่ยวชาญโดเมนเขียนกรณีต่างๆ จากนั้นใช้โมเดลสร้างคำถามเชิงขอบเขตและการโจมตี และสุดท้ายให้มนุษย์ตรวจสอบ ข้อมูลที่สร้างโดยโมเดลไม่สามารถใช้เป็นมาตรฐานทองคำได้โดยตรง มิฉะนั้นผู้ตั้งคำถามและผู้ตอบอาจมีอคติร่วมกัน

สามารถบันทึกกรณีได้ดังนี้:

1{
2  "id": "research-017",
3  "user_goal": "เปรียบเทียบข้อสรุปของเอกสารสองฉบับเกี่ยวกับความน่าเชื่อถือของ Agent และชี้ให้เห็นความแตกต่าง",
4  "initial_state": {
5    "available_sources": ["source-a.pdf", "source-b.pdf"]
6  },
7  "required_tools": ["open_document"],
8  "allowed_tools": ["open_document", "save_report"],
9  "forbidden_actions": ["web_search", "external_write"],
10  "expected_outcome": {
11    "must_cover": ["ข้อสรุปร่วม", "ความแตกต่าง", "ตำแหน่งของแหล่งที่มา"],
12    "must_abstain_when": ["ข้อมูลไม่สามารถสนับสนุนการตัดสินเชิงสาเหตุ"]
13  },
14  "severity": "high",
15  "slices": ["multi_source", "conflict", "closed_corpus"],
16  "graders": ["schema", "citation", "groundedness", "policy"]
17}

คุณไม่จำเป็นต้องบันทึกคำตอบมาตรฐานที่ไม่ซ้ำใครเสมอไป

งานวิจัยแบบปลายเปิดอาจมีรูปแบบการแสดงออกที่สมเหตุสมผลหลายแบบ เราจำเป็นต้องบันทึกข้อเท็จจริงที่ต้องครอบคลุม, ความแปรปรวนที่อนุญาต, แหล่งที่มาที่ต้องอ้างอิง และภายใต้สถานการณ์ใดที่ Agent ควรปฏิเสธที่จะตอบ

ชุดข้อมูลควรแบ่งออกเป็นอย่างน้อยสี่ส่วน:

dev สำหรับการพัฒนาประจำวัน สามารถดูซ้ำได้; holdout จะรันเฉพาะเมื่อเปรียบเทียบอย่างเป็นทางการ เพื่อป้องกันไม่ให้ทีมปรับแต่งพรอมต์สำหรับคำถามเฉพาะเจาะจงอยู่ตลอดเวลา; regression บันทึกเหตุการณ์ในอดีต; challenge บันทึกงานเชิงขอบเขตและการโจมตีที่มีความถี่ต่ำแต่มีความเสี่ยงสูง

ผลลัพธ์ของทั้งสี่ชุดนี้ควรรายงานแยกกัน

หากคุณผสมชุด challenge กับการรับส่งข้อมูลรายวัน อัตราการผ่านโดยรวมจะถูกดึงลงโดยปัญหาที่ยากซึ่งถูกออกแบบมาโดยเจตนา หากคุณดูเฉพาะการรับส่งข้อมูลจริง ความเสี่ยงด้านความปลอดภัยที่เกิดขึ้นน้อยครั้งจะถูกฝังไว้ด้วยงานทั่วไปจำนวนมาก

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

กฎการเติบโตที่ใช้ได้จริงคือ: ทุกเหตุการณ์ที่เกิดขึ้นจริง (online incident) ต้องกลายเป็นกรณีการถดถอย (regression case) ใหม่

การแก้ไขปัญหาแก้ไขได้เพียงวันนี้ การนำเหตุการณ์นั้นใส่ลงในชุดการถดถอยจะป้องกันไม่ให้การเปลี่ยนแปลงในอีกสามเดือนต่อมานำมันกลับมา

ผลลัพธ์ (Outcome) และเส้นทาง (Trajectory) ต้องถูกมองแยกกัน

Eval ของ LLM แบบดั้งเดิมมักเขียนได้ดังนี้:

Input → Model → Output → Score

Agent มีเส้นทางที่เปลี่ยนแปลงเพิ่มเติมอยู่ตรงกลาง:

เป้าหมาย (Goal) → แผน (Plan) → การเรียกใช้เครื่องมือ (Tool Call) → การสังเกต (Observation) → การวางแผนใหม่ (Re-plan) → การเปลี่ยนแปลงสภาพแวดล้อม (Environment Change) → ผลลัพธ์สุดท้าย (Final Output)

รายงานสุดท้ายอาจถูกต้อง แต่ก็ยังอาจมีปัญหาในกระบวนการได้

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

Outcome Eval ตรวจสอบสถานะสุดท้ายของงาน:

• ไฟล์เป้าหมายมีอยู่หรือไม่?
• ฟิลด์ที่จำเป็นครบถ้วนหรือไม่?
• การอ้างอิงใช้ได้หรือไม่?
• มีหลักฐานสำหรับข้อสรุปสำคัญหรือไม่?
• ระบบภายนอกถึงสถานะเป้าหมายจริงหรือไม่?

Trajectory Eval ตรวจสอบกระบวนการดำเนินการ:

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

Anthropic เน้นย้ำในระเบียบวิธี Agent Eval ว่าสถานะ (statefulness), การเรียกใช้เครื่องมือ และเส้นทางหลายเทิร์นของ Agent ทำให้การประเมินซับซ้อนกว่าการตอบสนองของโมเดลเทิร์นเดียวอย่างมาก ผลลัพธ์สุดท้ายและกระบวนการดำเนินการจำเป็นต้องมี grader ที่ออกแบบแยกกัน Anthropic: Demystifying evals for AI agents

ทิ้งหลักฐานไว้สำหรับทุกการรัน:

1{
2  "case_id": "research-017",
3  "system_version": "v2.3.1",
4  "started_at": "2026-09-03T10:01:00Z",
5  "final_output": "runs/v2/research-017/report.md",
6  "tool_calls": [],
7  "environment_state": {},
8  "errors": [],
9  "retry_count": 1,
10  "latency_ms": 84320,
11  "cost_usd": 0.42,
12  "stop_reason": "success_criteria_met"
13}

สำหรับ Agent ที่แก้ไขสถานะ สถานะสุดท้ายของสภาพแวดล้อมน่าเชื่อถือมากกว่าการตอบกลับครั้งสุดท้าย

Code Agent ควรทดสอบการทำงานจริง SQL Agent ควรดำเนินการค้นหาและตรวจสอบผลลัพธ์ Refund Agent ควรตรวจสอบว่ามีบันทึกการคืนเงินปรากฏขึ้นหรือไม่ Research Agent ควรเปิดรายงานอีกครั้งและตรวจสอบลิงก์, ฟิลด์ และความสัมพันธ์ของการอ้างอิง

NVIDIA ยังถือว่าการใช้เครื่องมือเป็นสัญญาณระดับแรกในระเบียบวิธีการประเมิน Agent: เครื่องมือใดที่อนุญาต, เครื่องมือใดที่ต้องเรียกใช้, จำนวนการเรียกใช้สูงสุด และพารามิเตอร์ที่คาดหวัง ล้วนสามารถเข้าสู่คำจำกัดความของงานและการให้คะแนนเส้นทางได้ NVIDIA: AI Agent Evaluation

หากไม่มี Outcome เราสามารถตัดสินได้เพียงว่าคำตอบ ดู ถูกต้องหรือไม่ หากไม่มี Trajectory เราไม่รู้ว่าควรแก้ไขโมเดล, เครื่องมือ หรือกระบวนการหลังจากเกิดความล้มเหลว

Grader สามชั้น: Rules สำหรับความแน่นอน, Judge สำหรับความคลุมเครือ, Human สำหรับความเสี่ยงสูง

เมื่อการประเมินเริ่มต้นขึ้น คำถามก็เกิดขึ้นอย่างรวดเร็ว: ใครเป็นคนให้คะแนน?

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

การผสมผสานที่เสถียรกว่าคือ Rules + Judge + Human

Rules จัดการการตรวจสอบที่แน่นอน (Deterministic Checks)

ในงานวิจัย สิ่งต่อไปนี้สามารถตรวจสอบได้โดยตรงด้วยโค้ด:

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

หากผลลัพธ์สามารถตรวจสอบได้โดยสถานะสภาพแวดล้อม อย่าให้โมเดลอื่นอ่านแล้วบอกว่า "ดูเหมือนเสร็จสมบูรณ์"

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

LLM Judge จัดการการตัดสินเชิงความหมาย (Semantic Judgment)

Judge เหมาะกับคำถามเหล่านี้มากกว่า:

• ข้อสรุปได้รับการสนับสนุนจากเนื้อหาที่อ้างอิงหรือไม่?
• มีการละเว้นข้อจำกัดที่สำคัญหรือไม่?
• ความขัดแย้งของแหล่งที่มาถูกนำเสนออย่างถูกต้องหรือไม่?
• คำตอบสุดท้ายตอบสนองต่อเป้าหมายของผู้ใช้จริงหรือไม่?
• เส้นทางการดำเนินการมีทางอ้อมที่ชัดเจนหรือขั้นตอนที่ไม่สมเหตุสมผลหรือไม่?

การให้ Judge แต่ละตัวประเมินเพียงมิติเดียวที่ชัดเจนนั้นเสถียรกว่าการขอให้มัน "ให้คะแนนรวมสำหรับรายงานนี้"

Groundedness Judge สามารถเขียนได้ดังนี้:

1คุณตัดสินเฉพาะ "ว่าข้อสรุปสำคัญได้รับการสนับสนุนจากหลักฐานที่อ้างอิงหรือไม่"
2
3ข้อมูลนำเข้าประกอบด้วย:
41. ข้อสรุปสำคัญ;
52. ข้อความอ้างอิงที่เกี่ยวข้อง;
63. บริบทของแหล่งต้นทาง
7
8ผลลัพธ์ต้องเป็นเพียง:
9- supported: หลักฐานสนับสนุนข้อสรุปโดยตรง;
10- partially_supported: หลักฐานสนับสนุนบางส่วน แต่มีการคาดเดาอย่างจำกัด;
11- unsupported: หลักฐานไม่สนับสนุน, ขัดแย้ง, หรือไม่สามารถตรวจสอบได้
12
13นอกจากนี้ ให้ระบุตำแหน่งของหลักฐานและเหตุผลไม่เกิน 80 คำ
14อย่าประเมินรูปแบบการเขียน, ความสมบูรณ์, หรือว่าข้อสรุปน่าสนใจหรือไม่

เมื่อเปรียบเทียบ v1 และ v2 Pairwise Judge มักจะตรงไปตรงมามากกว่าคะแนนสัมบูรณ์อิสระสองคะแนน: ให้ผลลัพธ์ A/B สำหรับคำถามเดียวกันแก่ Judge และให้มันเลือกอันที่ดีกว่าหรือตัดสินว่าเสมอกันตาม Rubric

ควรสุ่มลำดับของ A/B และซ่อนชื่อระบบ Judge อาจชอบคำตอบในตำแหน่งใดตำแหน่งหนึ่ง หรือเข้าใจผิดว่าคำตอบที่ยาวกว่าเป็นคำตอบที่ดีกว่า เมื่อใช้โมเดลเดียวกับที่กำลังประเมิน ระวังอคติต่อตัวเอง (self-preference)

งานวิจัยเช่น G-Eval และ MT-Bench ได้พิสูจน์การใช้งานได้ของโมเดลที่แข็งแกร่งในฐานะผู้ประเมิน ในขณะเดียวกันก็เปิดเผยอคติเชิงระบบเหล่านี้ด้วย G-Eval; Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena

มนุษย์จัดการมาตรฐานและข้อพิพาท (Humans handle standards and disputes)

มนุษย์ไม่ควรให้คะแนนทุกเอาต์พุตอย่างเป็นกลไก

ความพยายามของมนุษย์ควรใช้ไปกับ:

• ผู้เชี่ยวชาญทางธุรกิจกำหนด Rubric;
• ผู้ตรวจสอบสองหรือสามคนสร้างชุดป้ายกำกับทองคำ (gold labels) หนึ่งชุด;
• มนุษย์แก้ไขความไม่ลงรอยกันระหว่างผู้ตรวจสอบ;
• ส่งต่อกรณีที่มีความเสี่ยงสูงและความเชื่อมั่นต่ำของ Judge ไปให้มนุษย์;
• ตรวจสอบผลการให้คะแนนอัตโนมัติเป็นระยะ;
• มนุษย์ค้นพบรูปแบบความล้มเหลว (Failure Modes) ใหม่จากบันทึกออนไลน์

การตรวจสอบเป็นระยะ (Spot checks) ไม่สามารถข้ามได้

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

งานวิจัยของ Google เกี่ยวกับการประเมินแพตช์ซอฟต์แวร์ยังชี้ให้เห็นว่าผู้ตรวจสอบที่เป็นมนุษย์เองก็มีความไม่ลงรอยกัน Rubric ที่ใช้ร่วมกันและชัดเจนสามารถปรับปรุงความสอดคล้องของมนุษย์ก่อน จากนั้นจึงสนับสนุน LLM Judge ด้วยมาตรฐานที่มนุษย์แก้ไขแล้ว Google: Human-in-the-Loop Framework for Reliable Patch Evaluation

Judge เองก็ต้องการ Eval

LLM Judge เป็นเครื่องมือวัด ไม่ใช่คำตอบมาตรฐาน

ก่อนใช้งานจริง ให้เตรียมชุดสอบเทียบ (calibration set) จำนวน 100–500 กรณีที่ได้รับการยืนยันโดยผู้เชี่ยวชาญ เปรียบเทียบความสอดคล้องระหว่าง Judge และป้ายกำกับของมนุษย์ พร้อมทั้งตรวจสอบการเรียกคืน (recall) สำหรับข้อผิดพลาดร้ายแรง, ประสิทธิภาพในส่วนงานต่างๆ และความเต็มใจที่จะงดออกเสียงเมื่อหลักฐานไม่เพียงพอ

ความสอดคล้องโดยเฉลี่ยไม่ได้บอกเรื่องราวทั้งหมด

หาก Judge แม่นยำมากในการประเมินรูปแบบการเขียนทั่วไป แต่พลาดการอ้างอิงที่สร้างขึ้นบ่อยครั้ง ก็ยังไม่เหมาะที่จะเป็นเกณฑ์การปล่อยเวอร์ชันสำหรับ Research Agent ข้อผิดพลาดประเภทต่างๆ มีระดับความสำคัญที่แตกต่างกัน และต้องรายงานแยกกัน

ความสำเร็จครั้งเดียวยังไม่ใช่ความน่าเชื่อถือ (Reliability)

เอาต์พุตของ Agent เป็นแบบสุ่ม (stochastic) การสุ่มตัวอย่างโมเดลเปลี่ยนไป, ผลการค้นหาเปลี่ยนไป, ความหน่วงของเครื่องมือและสถานะสภาพแวดล้อมก็เปลี่ยนได้เช่นกัน

การรันงานสำเร็จหนึ่งครั้งพิสูจน์ได้เพียงว่ามันสำเร็จในครั้งนั้น

สมมติว่า Agent มีอัตราความสำเร็จ 80% สำหรับการรันครั้งเดียว ภายใต้เงื่อนไขที่เป็นอิสระโดยประมาณ ความน่าจะเป็นของการรันสำเร็จติดต่อกันห้าครั้งคือ:

0.8⁵ = 32.8%

นี่คือความแตกต่างระหว่าง pass@k และ pass^k

pass@k หมายถึงรันมัน k ครั้ง และนับว่าผ่านหากสำเร็จอย่างน้อยหนึ่งครั้ง เหมาะสำหรับงานที่อนุญาตให้ลองหลายครั้ง เช่น การสำรวจโค้ดหรือค้นหาวิธีแก้ปัญหา

pass^k หมายถึงสำเร็จติดต่อกัน k ครั้ง องค์กรที่สร้างรายงานประจำวัน, ประมวลผลคำสั่งซื้อ หรือแก้ไขสถานะระบบ จะสนใจความเสถียรประเภทนี้มากกว่า

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

ดังนั้น ให้ทำซ้ำกรณีสำคัญอย่างน้อย 3–5 ครั้ง ทดสอบคำพ้องความหมาย, ฟิลด์ที่หายไป, การตอบสนองของเครื่องมือที่ช้า และการเปลี่ยนแปลงลำดับแหล่งที่มา เพื่อดูว่าระบบยังทำงานได้อย่างเสถียรหรือไม่

งานวิจัยด้านความน่าเชื่อถือของ Agent ของ Princeton แบ่งความน่าเชื่อถือออกเป็นความสม่ำเสมอ (consistency), ความทนทาน (robustness), ความสามารถในการคาดเดา (predictability) และความปลอดภัย (safety) โดยชี้ให้เห็นว่าการปรับปรุงความสามารถไม่ได้นำมาซึ่งการปรับปรุงความน่าเชื่อถือที่เท่าเทียมกันโดยอัตโนมัติ Towards a Science of AI Agent Reliability

เมื่อเปรียบเทียบ v1 และ v2 ให้ใช้ชุดกรณีเดียวกันสำหรับการประเมินแบบคู่ (paired evaluation)

รัน v1 สำหรับแต่ละคำถามก่อน จากนั้นรัน v2 ภายใต้สถานะเริ่มต้นเดียวกัน วิธีนี้จะช่วยให้คุณเห็นโดยตรงว่ากรณีใดเปลี่ยนจากความล้มเหลวเป็นความสำเร็จ และกรณีใดเปลี่ยนจากความสำเร็จเป็นความล้มเหลว หากทั้งสองเวอร์ชันต่างก็รับชุดคำถามแบบสุ่ม ความแตกต่างของความยากของงานจะถูกปนเข้ากับความแตกต่างของระบบ

รายงานสุดท้ายควรมีอย่างน้อย:

• อัตราความสำเร็จของงานทั้งหมด;
• pass^k สำหรับงานสำคัญ;
• อัตราความล้มเหลวสำหรับแต่ละโหมดความล้มเหลว (Failure Mode);
• ผลลัพธ์สำหรับแต่ละส่วนของความเสี่ยง, ความยาก และสถานะเครื่องมือ;
• ต้นทุนต่องานที่สำเร็จ;
• ความหน่วง p50 และ p95;
• อัตราข้อผิดพลาดและการกู้คืนของเครื่องมือ;
• อัตราการกระทำที่ไม่ได้รับอนุญาต;
• ช่วงความเชื่อมั่น 95%

อย่าสร้างแค่ "คะแนนคุณภาพโดยรวม 87.4"

ค่าเฉลี่ยรวมซ่อนปัญหาได้ง่าย v2 อาจปรับปรุงงานทั่วไปขึ้น 8 จุดเปอร์เซ็นต์ ในขณะที่ทำให้งานที่มีแหล่งข้อมูลขัดแย้งถดถอยลง 15 จุดเปอร์เซ็นต์ เมื่อรวมกันแล้ว คุณจะเหลือตัวเลขที่ดูเหมือนเพิ่มขึ้นเล็กน้อย

ช่วงความเชื่อมั่นก็ข้ามไม่ได้เช่นกัน

ใน 100 งาน การเพิ่มขึ้นของอัตราความสำเร็จจาก 80% เป็น 83% ไม่ได้หมายความว่า v2 ดีขึ้นโดยอัตโนมัติ อัตราความสำเร็จแบบไบนารีมีความผันผวนตามธรรมชาติหลายจุดเปอร์เซ็นต์ที่ขนาดตัวอย่างนี้ เมื่อตัวอย่างไม่เพียงพอ ข้อสรุปที่ซื่อสัตย์กว่าอาจเป็น "ไม่พบการถดถอยที่สำคัญ" ซึ่งไม่ได้พิสูจน์ว่ามันดีขึ้นอย่างมีนัยสำคัญ

ความล้มเหลวด้านความปลอดภัยต้องใช้ความระมัดระวังเป็นพิเศษ หากคุณรัน 100 ครั้งและไม่มีการเข้าถึงโดยไม่ได้รับอนุญาตเกิดขึ้น ก็หมายความว่าไม่พบในการรัน 100 ครั้งนั้นเท่านั้น การประมาณคร่าวๆ ทั่วไปคือ: หากไม่มีความล้มเหลวเกิดขึ้นในการทดลองอิสระ n ครั้ง ที่ระดับความเชื่อมั่น 95% ขอบเขตบนของอัตราความล้มเหลวจริงจะอยู่ที่ประมาณ 3/n สำหรับการทดลอง 100 ครั้งที่ไม่มีความล้มเหลว ขอบเขตบนยังคงอยู่ที่ประมาณ 3%

ความเสี่ยงที่เกิดขึ้นน้อยครั้งแต่สูญเสียสูงต้องใช้ชุดความท้าทาย (challenge sets) โดยเฉพาะ, การทดลองมากขึ้น และการควบคุมระบบที่เข้มงวด คุณไม่สามารถพึ่งพาเฉพาะการสังเกตเป็นศูนย์ในการรับส่งข้อมูลโดยเฉลี่ยได้

เปลี่ยนเมตริกเป็นเกณฑ์การปล่อยเวอร์ชัน (Release Gates)

หลังจากรัน Eval แล้ว มักเกิดการสูญเสียอีกประเภทหนึ่ง: รายงานมีแผนภูมิมากมาย แต่ทีมก็ยังไม่รู้ว่าจะปล่อยเวอร์ชันหรือไม่

ควรเขียน Release Gates ก่อนการทดลอง หากคุณตัดสินใจมาตรฐานหลังจากเห็นผลลัพธ์ ผู้คนจะหาคำอธิบายสำหรับเวอร์ชันที่พวกเขาชอบโดยธรรมชาติ

Research Agent v2 สามารถใช้ชุดเกณฑ์ดังนี้:

1release_gate:
2  primary:
3    metric: paired_whole_task_success
4    requirement: Actual improvement exists, and confidence intervals support it
5
6  non_inferiority:
7    critical_workflows:
8      max_allowed_drop_percentage_points: 0.5
9
10  safety:
11    critical_unauthorized_actions: 0
12    fabricated_sources: 0
13    high_risk_failure_upper_bound: below_policy_threshold
14
15  reliability:
16    critical_case_pass_power_k: above_target
17
18  efficiency:
19    max_cost_increase_per_success: 5%
20    max_p95_latency_increase_ms: 200
21
22  slices:
23    no_major_regression:
24      - conflicting_sources
25      - insufficient_evidence
26      - tool_failure
27      - high_risk
28
29  operations:
30    trace_completeness: 100%
31    judge_calibrated: true
32    rollback_ready: true

ตัวเลขเหล่านี้เป็นเพียงตัวอย่างเชิงโครงสร้างเท่านั้น เกณฑ์ที่แท้จริงควรกำหนดตามความเสี่ยงทางธุรกิจ ค่าพื้นฐานปัจจุบัน และขนาดกลุ่มตัวอย่าง

Primary Metric ตอบว่าความก้าวหน้าโดยรวมบรรลุเป้าหมายหรือไม่ Non-inferiority ป้องกันไม่ให้เส้นทางสำคัญถูกสังเวย Safety และ permissions เป็นเกณฑ์บังคับ (hard gates) Reliability ดูว่าระบบสามารถทำงานได้อย่างเสถียรและต่อเนื่องหรือไม่ Efficiency มุ่งเน้นที่ต้นทุนต่อความสำเร็จ ไม่ใช่ต้นทุนต่อคำขอ

ทำไมต้องใช้ Cost per Successful Task?

Agent ราคาถูกที่ล้มเหลวบ่อยครั้ง ต้องรันซ้ำสามครั้ง หรือส่งต่อให้มนุษย์แก้ไข อาจมีต้นทุนจริงที่สูงกว่า การดูเฉพาะค่า API ครั้งเดียวอาจทำให้เข้าใจผิดว่าความล้มเหลวราคาถูกคือการเพิ่มประสิทธิภาพ

หลังจากผ่านทุกเกณฑ์แล้ว คุณไม่จำเป็นต้องเปลี่ยนเส้นทางการรับส่งข้อมูลทั้งหมด 100% ทันที

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

จุดสิ้นสุดของ Eval คือการตัดสินใจเผยแพร่ที่สามารถอธิบายได้และย้อนกลับได้

ความล้มเหลวออนไลน์ต้องกลับไปประเมินแบบออฟไลน์

ข้อมูลออฟไลน์ไม่สามารถครอบคลุมโลกแห่งความจริงได้ทั้งหมด

ผู้ใช้จะใช้สำนวนใหม่ เว็บเพจภายนอกจะเปลี่ยนเลย์เอาต์ API จะส่งคืนข้อผิดพลาดที่ไม่เคยเห็นมาก่อน และนโยบายทางธุรกิจจะมีการอัปเดต หลังจาก Agent ใช้งานจริง Evaluation Framework ต้องทำงานต่อไป

วงจรปิดที่สมบูรณ์สามารถเขียนได้ดังนี้:

Production trace → Online Eval → Failure mining → Human review → Golden Set → Offline experiment → Regression → Release

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

จากนั้นแยกตัวอย่างสามประเภทจากสิ่งเหล่านี้:

• งานที่ล้มเหลวอย่างชัดเจนหรือทริกเกอร์การแจ้งเตือน
• งานที่ Judge ไม่แน่ใจหรือ Grader ต่างกันขัดแย้งกัน
• ตัวอย่างสุ่มจากการรับส่งข้อมูลปกติ

สองประเภทแรกช่วยค้นหาปัญหาได้อย่างรวดเร็ว ตัวอย่างสุ่มมีหน้าที่ค้นหาความล้มเหลวใหม่ที่ระบบไม่รู้จัก

หลังจากตรวจสอบโดยมนุษย์ ให้เพิ่มเหตุการณ์ที่เป็นตัวแทนลงใน regression และรูปแบบความเสี่ยงสูงใหม่ลงใน challenge หากปัญหามาจากลูกค้าหรือกลุ่มธุรกิจใหม่ ให้เพิ่มลงในการออกแบบการสุ่มตัวอย่างของชุดทดสอบหลัก

ทุกครั้งที่คุณแก้ไข Prompt, Model, RAG, Skill, Tool หรือ Workflow ให้รันซ้ำกับชุดกรณีเดียวกัน เปลี่ยนตัวแปรหลักทีละตัวเท่านั้น เพื่อให้รู้ว่าอะไรทำให้เกิดการเปลี่ยนแปลงในผลลัพธ์

เมื่อระบบมีความซับซ้อนมากขึ้น คุณยังสามารถวัด Component Lift ได้อีกด้วย

ตัวอย่างเช่น กำหนด task, model, workspace และ scorer ให้คงที่ และเปลี่ยนเฉพาะว่า Skill ใดถูกโหลดหรือไม่:

Skill Lift = Quality(with Skill) - Quality(without Skill)

วิธีเดียวกันนี้สามารถวัด Prompt Lift, RAG Lift, Tool Lift และ Memory Lift ได้ ซึ่งจะทำให้คุณเห็นมูลค่าส่วนเพิ่มของคอมโพเนนต์ ไม่ใช่แค่ "คะแนนรวมของระบบใหม่คือ 85"

ระบบ Multi-Agent ยิ่งต้องการการเปรียบเทียบนี้ การเพิ่ม Planner, Researcher, Critic และ Verifier จะเพิ่มต้นทุน เวลาแฝง การสูญเสียจากการส่งต่อ และจุดบกพร่อง ควรเปรียบเทียบกับ baseline ของ Single-Agent ที่แข็งแกร่งที่สุดในชุดงานเดียวกัน เพื่อพิสูจน์ว่าคุณภาพที่เพิ่มขึ้นนั้นเพียงพอที่จะครอบคลุมความซับซ้อนที่เพิ่มขึ้น

ส่วนนี้สามารถเก็บไว้สำหรับขั้นตอนที่สองได้

Evaluation Framework เวอร์ชันแรกควรมุ่งเน้นให้ Agent เดียว เวิร์กโฟลว์เดียว และการตัดสินใจเผยแพร่ที่ชัดเจนทำงานได้ก่อน เครื่องมือควรเพิ่มขึ้นตามปัญหาที่เพิ่มขึ้น คุณไม่จำเป็นต้องสร้าง Eval OS ระดับองค์กรตั้งแต่วันแรก

เริ่มต้นด้วยไดเรกทอรี

Agent Evaluation อาจมีขนาดเล็กมาก

ในวันแรก คุณเพียงต้องการงานที่ชัดเจน กรณีจริง 30 กรณี การตรวจสอบเชิงกำหนด (deterministic checks) สองสามอย่าง และ Rubric ของมนุษย์ หลังจากรันแล้ว ให้จัดหมวดหมู่ความล้มเหลวอย่างชัดเจนเพื่อดูว่าปัญหามาจาก retrieval, tools, reasoning, verification หรือ stop conditions หรือไม่

เมื่อเตรียมพร้อมสำหรับการเผยแพร่ ให้ขยายข้อมูลเป็น 100–300 กรณี ทิ้ง traces ที่สมบูรณ์ ปรับเทียบ LLM Judge ทำการทดลองซ้ำสำหรับงานสำคัญ และเพิ่มช่วงความเชื่อมั่นและการวิเคราะห์กลุ่ม (slice analysis) ในผลลัพธ์

หลังจากเข้าสู่ระบบการผลิต ให้เชื่อมต่อ shadow, canary, การแจ้งเตือน และการย้อนกลับ ทุกเหตุการณ์จริงจะกลายเป็น Regression Case ที่จะไม่เกิดขึ้นซ้ำในครั้งหน้า

เมื่อมองย้อนกลับไป วิธีการทั้งหมดหมุนรอบสิ่งเดียวกันเสมอ:

ขั้นแรก ให้ชัดเจนว่าต้องตัดสินใจอะไร → เขียนให้ชัดเจนว่า "เสร็จ" หมายถึงอะไร → สร้างชุดข้อมูลด้วยงานจริง → ตรวจสอบทั้งผลลัพธ์และวิถีการทำงาน (trajectories) → ใช้ Rules, Judge และ Human เพื่อให้คะแนนแบบหลายชั้น → รันซ้ำเพื่อดูความน่าเชื่อถือ → ใช้ Release Gates เพื่อตัดสินใจเผยแพร่ → ป้อนความล้มเหลวออนไลน์กลับเข้าสู่ชุดการประเมิน

โมเดลเป็นตัวกำหนดว่างาน สามารถ เสร็จสมบูรณ์ได้หรือไม่

Evaluation Framework มีหน้าที่พิสูจน์ว่างานสามารถส่งคืนได้ อย่างเสถียร ปลอดภัย และสามารถอธิบายได้

อ่านเพิ่มเติม:

https://x.com/ClorisSignal/status/2090852298620801208