𝗦𝗰𝗼𝗿𝗶𝗻𝗴 𝗔𝗜 𝗔𝗴𝗲𝗻𝘁𝘀: 𝗗𝗲𝘁𝗲𝗿𝗺𝗶𝗻𝗶𝘀𝘁𝗶𝗰 𝗠𝗲𝘁𝗿𝗶𝗰𝘀 + 𝗮𝗻 𝗟𝗟𝗠 𝗝𝘂𝗱𝗴𝗲
คุณรัน AI agent ขนาดเล็กจำนวนมาก คุณมี agent สำหรับ backend, frontend, mobile และ devops โดยที่แต่ละ agent จะมีหน้าที่เพียงอย่างเดียว
เมื่อคุณมี agent จำนวนมาก คุณจะพบกับปัญหา คุณไม่รู้ว่าพวกมันทำงานได้ดีหรือไม่ คุณไม่รู้ว่าการแก้ไข prompt จะทำให้พวกมันดีขึ้นหรือแย่ลง การพูดแค่ว่า "มันก็ดูโอเคดีนะ" นั้นไม่สามารถใช้ได้เมื่อต้องจัดการในสเกลใหญ่
ผมได้สร้าง framework ขึ้นมาเพื่อแก้ปัญหานี้ โดยใช้ตัวเลขในการวัดประสิทธิภาพและปรับปรุง prompt โดยอัตโนมัติ
กลยุทธ์
เริ่มจากการวัดสิ่งที่คุณสามารถวัดได้ด้วยคณิตศาสตร์ก่อน ใช้ LLM judge เฉพาะเมื่อจำเป็นเท่านั้น ตัวชี้วัดแบบ Deterministic นั้นรวดเร็วและไม่มีค่าใช้จ่าย ส่วน LLM judge นั้นช้าและมีค่าใช้จ่าย
ระบบทำงานอย่างไร:
• harness จะรันแต่ละ agent แยกเป็นคนละ process • มันจะส่ง task ให้กับ agent • มันจะดักจับ output ที่ได้ • มันจะให้คะแนนผลลัพธ์โดยเทียบกับข้อมูลที่คาดหวัง
agent เพียงแค่ต้องอ่านจาก stdin และเขียนลง stdout เท่านั้น จะเป็น Python หรือ shell script ก็ได้ โดยที่ harness ไม่สนใจ
5 ตัวชี้วัดหลักที่ต้องติดตาม:
- Accuracy: ผลลัพธ์ตรงตามเป้าหมายหรือไม่?
- Fuzzy score: ข้อความมีความคล้ายคลึงกับเป้าหมายเพียงใด?
- Timeout rate: agent ทำงานไม่เสร็จบ่อยแค่ไหน?
- Safety violations: ผลลัพธ์ตรงกับรูปแบบที่ไม่ปลอดภัยหรือไม่?
- Reproducibility variance: agent ให้คำตอบเดิมทุกครั้งหรือไม่?
หาก agent ให้คำตอบที่ถูกต้องแต่ไม่สม่ำเสมอ นั่นคือ bug
LLM Judge
บางอย่างยากที่จะวัดด้วยคณิตศาสตร์ คุณจำเป็นต้องรู้ว่า agent ยังคงอยู่ในบทบาทของตนเองหรือปฏิบัติตามข้อจำกัดที่กำหนดไว้หรือไม่
สำหรับกรณีเหล่านี้ LLM judge จะเป็นผู้ตรวจสอบงาน โดยจะได้รับ rubric และ output จาก agent จากนั้นจะส่งคำตัดสินที่มีโครงสร้างชัดเจนกลับมา ผมทำการตรวจสอบคำตัดสินนี้ด้วย JSON schema เพื่อไม่ให้ทำให้รายงานเสียหาย
judge ทำหน้าที่มากกว่าแค่การให้คะแนน แต่มันต้องแนะนำวิธีแก้ไขด้วย คำวิจารณ์อย่าง "อันนี้ยังไม่ดีพอ" นั้นไร้ประโยชน์ แต่คำวิจารณ์อย่าง "ให้เพิ่ม JSON block ลงใน prompt" นั้นสามารถนำไปปฏิบัติได้จริง
วงจรการปรับปรุง (Improvement Loop)
ความล้มเหลวจะถูกบันทึกลงในไฟล์ ซึ่งไฟล์นี้จะถูกนำไปใช้ในวงจรการทำงานอัตโนมัติ ระบบจะมองหาจุดที่อ่อนที่สุดของ prompt และพยายามแก้ไขมัน โดยจะเก็บรวบรวมตัวเลือกที่ดีเอาไว้ และเขียนเวอร์ชันที่ดีที่สุดกลับลงไปในโค้ด
คะแนนเพียงค่าเดียวเป็นเพียงภาพถ่าย ณ ช่วงเวลาหนึ่งเท่านั้น จงใช้ประวัติการทำงานเพื่อติดตามแนวโน้ม ซึ่งจะบอกคุณได้ว่าคุณกำลังพัฒนาขึ้นตามกาลเวลาหรือไม่
สร้างรากฐานของคุณบนตัวชี้วัดแบบ deterministic และใช้ judge เป็นเหมือนมีดผ่าตัด ไม่ใช่ค้อน
การให้คะแนน AI Agents: ตัวชี้วัดแบบ Deterministic เทียบกับ LLM Judge
การประเมินประสิทธิภาพของ AI agents เป็นหนึ่งในความท้าทายที่ยิ่งใหญ่ที่สุดในวงการ AI ปัจจุบัน เนื่องจากเอเจนต์เหล่านี้ไม่ได้ทำงานแบบเส้นตรงเหมือนซอฟต์แวร์ทั่วไป แต่มีความสามารถในการใช้เหตุผล (reasoning) และการตัดสินใจที่ซับซ้อน ซึ่งทำให้การวัดผลด้วยวิธีเดิมๆ ทำได้ยาก
ในบทความนี้ เราจะมาเจาะลึกความแตกต่างระหว่างการใช้ ตัวชี้วัดแบบ Deterministic (Deterministic Metrics) และการใช้ LLM เป็นผู้ตัดสิน (LLM-as-a-Judge) เพื่อดูว่าวิธีใดเหมาะกับสถานการณ์ไหน
ความท้าทายในการประเมิน AI Agents
เมื่อเราสร้าง AI agent เราไม่ได้ต้องการแค่ให้มันตอบคำถามได้ถูกต้อง แต่เราต้องการให้มัน:
- ใช้เครื่องมือ (Tool Use) ได้อย่างถูกต้อง: เรียกใช้ฟังก์ชันหรือ API ด้วยพารามิเตอร์ที่เหมาะสม
- มีกระบวนการคิดที่สมเหตุสมผล: วางแผนขั้นตอนการทำงานได้อย่างเป็นระบบ
- บรรลุเป้าหมาย: ทำงานจนสำเร็จตามที่ได้รับมอบหมาย
ปัญหาคือ AI agents มีความไม่แน่นอน (non-deterministic) คำตอบเดียวกันอาจได้ผลลัพธ์ที่แตกต่างกันเล็กน้อยในแต่ละครั้ง ทำให้การใช้การเปรียบเทียบคำต่อคำ (Exact Match) นั้นใช้ไม่ได้ผลเสมอไป
1. ตัวชี้วัดแบบ Deterministic (Deterministic Metrics)
ตัวชี้วัดแบบ Deterministic คือการวัดผลที่อิงตามกฎเกณฑ์ที่ชัดเจนและให้ผลลัพธ์ที่แน่นอน ไม่ว่าคุณจะรันการทดสอบกี่ครั้ง ผลลัพธ์ก็จะยังคงเดิม
ตัวอย่างการใช้งาน:
- Exact Match (การจับคู่ที่แม่นยำ): ตรวจสอบว่าคำตอบตรงกับ
ground truthหรือไม่ (เหมาะสำหรับคำตอบสั้นๆ หรือรหัสผ่าน) - Code Execution (การรันโค้ด): หาก agent เขียนโค้ด Python โค้ดนั้นสามารถรันได้สำเร็จและให้ผลลัพธ์ที่ถูกต้องหรือไม่?
- Tool Call Accuracy (ความแม่นยำในการเรียกใช้เครื่องมือ): ตรวจสอบว่า JSON schema ที่ agent ส่งมาสำหรับการเรียกใช้ API นั้นถูกต้องตามโครงสร้างที่กำหนดหรือไม่
- Regex Matching: ใช้ Regular Expressions เพื่อตรวจสอบรูปแบบของคำตอบ เช่น รูปแบบวันที่ หรือรูปแบบอีเมล
ข้อดี:
- รวดเร็วและราคาถูก: ใช้ทรัพยากรคำนวณน้อยมาก
- ทำซ้ำได้ (Reproducible): ให้ผลลัพธ์ที่คงเส้นคงวา ไม่มีความลำเอียง
- ชัดเจน: เมื่อผิดพลาด คุณจะรู้ทันทีว่าผิดที่จุดไหน (เช่น พารามิเตอร์ผิด หรือรูปแบบ JSON ผิด)
ข้อเสีย:
- ขาดความยืดหยุ่น: ไม่สามารถเข้าใจความหมายที่เปลี่ยนไปแต่ยังคงความถูกต้องได้ (เช่น "ใช่" กับ "ถูกต้อง" อาจถูกมองว่าต่างกัน)
- ไม่สามารถวัดความซับซ้อนได้: ไม่สามารถประเมินคุณภาพของเหตุผลหรือความลื่นไหลของภาษาได้
2. การใช้ LLM เป็นผู้ตัดสิน (LLM-as-a-Judge)
แนวทางนี้คือการใช้โมเดลภาษาขนาดใหญ่ที่มีความสามารถสูง (เช่น GPT-4o หรือ Claude 3.5 Sonnet) มาทำหน้าที่เป็น "กรรมการ" เพื่อประเมินคำตอบของโมเดลที่เรากำลังทดสอบ
วิธีการทำงาน:
เราจะส่ง Prompt ไปยัง LLM Judge ซึ่งประกอบด้วย:
- คำสั่ง (Instruction): บอกเกณฑ์การให้คะแนนอย่างละเอียด
- บริบท (Context): ข้อมูลที่เกี่ยวข้องหรือคำถามต้นฉบับ
- คำตอบของ Agent (Agent's Response): สิ่งที่เราต้องการประเมิน
- คำตอบที่ถูกต้อง (Ground Truth - ถ้ามี): เพื่อใช้เป็นแนวทาง
ข้อดี:
- เข้าใจบริบทและความหมาย: สามารถประเมินความถูกต้องเชิงคุณภาพ (Qualitative) เช่น ความสุภาพ, ความลื่นไหล, หรือความสมเหตุสมผล
- ยืดหยุ่นสูง: สามารถประเมินคำตอบที่หลากหลายรูปแบบได้โดยไม่ต้องเขียนกฎที่ตายตัว
ข้อเสีย:
- ค่าใช้จ่ายสูงและช้ากว่า: ต้องใช้การเรียก API ของโมเดลระดับสูง ซึ่งมีราคาแพงและใช้เวลานานกว่า
- อคติ (Bias): LLM Judge อาจมีอคติ เช่น:
- Self-preference bias: ชอบคำตอบที่มีสไตล์การเขียนคล้ายกับตัวเอง
- Position bias: ให้คะแนนคำตอบที่ปรากฏลำดับแรกๆ สูงกว่าความเป็นจริง
- Verbosity bias: ให้คะแนนคำตอบที่ยาวกว่า แม้ว่าเนื้อหาจะน้ำเยอะก็ตาม
ตารางเปรียบเทียบ: Deterministic vs. LLM Judge
| คุณสมบัติ | Deterministic Metrics | LLM-as-a-Judge |
|---|---|---|
| ความเร็ว | สูงมาก (Instant) | ต่ำ (ต้องรอการประมวลผล) |
| ต้นทุน | ต่ำมาก | สูง |
| ความแม่นยำเชิงโครงสร้าง | ดีเยี่ยม (เช่น JSON, Code) | ปานกลาง |
| ความเข้าใจเชิงความหมาย | ต่ำ | สูงมาก |
| ความสามารถในการทำซ้ำ | สูง (ผลลัพธ์คงที่) | ต่ำ (อาจมีความแปรปรวน) |
| ความซับซ้อนในการตั้งค่า | ต้องเขียนกฎ/Regex/Unit Test | ต้องเขียน Prompt ที่ดี |
แนวทางแบบผสมผสาน (The Hybrid Approach)
ในการสร้างระบบประเมินที่มีประสิทธิภาพสูงสุดสำหรับ AI Agents เราไม่ควรเลือกอย่างใดอย่างหนึ่ง แต่ควรใช้ แนวทางแบบผสมผสาน
สูตรสำเร็จที่แนะนำ:
- ใช้ Deterministic Metrics เป็นด่านแรก: ตรวจสอบความถูกต้องของโครงสร้าง (Format), การเรียกใช้เครื่องมือ (Tool calls), และการรันโค้ด (Code execution) หากผ่านด่านนี้ไม่ได้ ก็ไม่จำเป็นต้องส่งไปให้ LLM Judge ประเมินต่อ
- ใช้ LLM Judge สำหรับการประเมินเชิงคุณภาพ: เมื่อโครงสร้างถูกต้องแล้ว จึงใช้ LLM Judge ประเมินความสมเหตุสมผลของเหตุผล (Reasoning) และความพึงพอใจของผู้ใช้ (User satisfaction)
การทำเช่นนี้จะช่วยให้คุณได้ระบบการประเมินที่ทั้ง รวดเร็ว ประหยัด และมีความละเอียดอ่อน ในเวลาเดียวกัน