Google เปิด Agent Evaluation แบบ GA: วัด AI Agent จากงานจริง ไม่ใช่แค่ Demo

AI Agent ที่ตอบ Demo ได้สวย อาจยังทำงานจริงพลาดครับ

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

Google เพิ่งเปิด Agent and Model Evaluations ใน Gemini Enterprise Agent Platform แบบ generally available จุดที่ควรสนใจไม่ใช่แค่คำว่า GA แต่คือแนวคิดนี้:

ใช้วิธีวัดเดียวกันตั้งแต่ตอนทดลอง ไปจนถึงตอน Agent ทำงานกับผู้ใช้จริง

สำหรับ founder, operator และทีมเล็ก นี่ช่วยเปลี่ยนคำถามจาก “Agent ดูฉลาดไหม” เป็น “Agent ทำงานสำเร็จสม่ำเสมอแค่ไหน และพลาดตรงไหน”

1) ข่าวนี้คืออะไรในภาษาคนทำงาน

Google รวมเครื่องมือประเมิน Agent ไว้ใน Agent Platform มากขึ้น โดยมีความสามารถหลักที่เกี่ยวกับงานจริงดังนี้

• metrics สำเร็จรูปมากกว่า 20 แบบ ครอบคลุม task success, tool use, trajectory, grounding, hallucination และ safety
• custom metric แบบ code สำหรับเงื่อนไขที่ตรวจได้ตรง ๆ เช่น JSON ต้องครบ field หรือเลขอ้างอิงต้องตรงกับข้อมูลจาก Tool
• LLM-as-a-judge และ adaptive rubric สำหรับงานที่ต้องอ่านบริบทและตัดสินตามเกณฑ์ของแต่ละเคส
• experiment ที่รันได้ทั้ง local และ server-side
• user simulator สำหรับสร้างบทสนทนาหลายรอบ
• environment simulator สำหรับจำลอง Tool ช้า Tool ล้ม หรือข้อมูลหลังบ้านผิดปกติ
• online monitor สำหรับสุ่มประเมิน production traces และแจ้งเมื่อคุณภาพลดลง

Google ระบุว่าเข้าถึงชุด evaluation นี้ได้จาก Agent Platform SDK, agents-cli, Cloud Console และ ADK

ประโยชน์จริงคือทีมไม่ต้องแยกโลก “test ก่อนปล่อย” ออกจากโลก “ดูอาการหลังปล่อย” จนใช้คนละ metric แล้วเทียบกันไม่ได้

2) ทำไมทีมเล็กควรสนใจ

ทีมเล็กมักไม่มีคน QA สำหรับ AI Agent โดยเฉพาะครับ

วิธีที่เกิดขึ้นบ่อยคือ owner ลองถามเอง 5 ถึง 10 ครั้ง ถ้าคำตอบดูดี ก็ปล่อยให้ทีมใช้ แล้วรอจนมีคนร้องเรียนจึงกลับมาแก้ prompt

ปัญหาคือวิธีนี้มี blind spot อย่างน้อย 4 จุด

2.1 เราจำตัวอย่างที่พลาดไม่ได้ครบ

ความผิดพลาดที่เกิดเมื่อสองสัปดาห์ก่อนอาจหายไปจากความจำ พอแก้ prompt รอบใหม่ก็เผลอทำให้ปัญหาเดิมกลับมา

2.2 คะแนนรวมอาจซ่อนความผิดพลาดสำคัญ

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

2.3 Test case ที่ทีมเขียนไม่เหมือนงานจริง

คนจริงเปลี่ยนใจ พิมพ์ไม่ครบ ใช้คำกำกวม และเรียกงานหลายอย่างต่อกัน ถ้า test มีแต่คำสั่งสวย ๆ Agent ก็ผ่านง่ายเกินไป

2.4 คุณภาพเปลี่ยนหลังปล่อยได้

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

ดังนั้นเป้าหมายไม่ใช่ “มี eval เยอะที่สุด” แต่คือมีวงรอบที่เก็บงานจริงกลับมาเป็นเคส วัดด้วยเกณฑ์เดิม และรู้ว่าการแก้แต่ละครั้งดีขึ้นจริงหรือแค่ดูดีขึ้น

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

3) ใช้กับงานของตัวเองยังไง

ไม่ต้องเริ่มจาก 20 metrics พร้อมกันครับ เลือก workflow เดียวก่อน เช่น

• ตอบคำถามจาก Knowledge Base
• สรุป lead และอัปเดต CRM
• ตรวจเอกสารก่อนส่งให้ลูกค้า
• สร้างรายงานประจำวัน
• รับเรื่อง support แล้ว route ให้คนที่ถูก

จากนั้นเลือก 3 ตัววัดที่ตรงกับผลลัพธ์ของงาน

1. Task success: งานที่ผู้ใช้ขอสำเร็จหรือไม่
2. Tool correctness: เรียก Tool ถูกตัว ส่ง argument ถูก และอ่านผลกลับมาถูกหรือไม่
3. Evidence correctness: คำตอบสำคัญตรวจย้อนกลับไปยัง source หรือ Tool output ได้หรือไม่

ถ้างานมีความเสี่ยงเฉพาะ ให้เพิ่ม deterministic check แทนการฝากทุกอย่างไว้กับ LLM judge เช่น

• เลข invoice ต้องตรงกับ Tool output
• ห้ามส่งข้อความถ้ายังไม่มี approval status
• JSON ต้องมี customer_id, action และ evidence_url
• ห้ามบอกว่า “บันทึกแล้ว” ถ้า Tool ไม่คืน success

ตรงนี้สำคัญมาก เพราะ LLM judge มีประโยชน์กับงานที่ต้องอ่านบริบท แต่ไม่ควรแทนเงื่อนไขที่ code ตรวจได้ชัดกว่า

Operator Kit: Agent Quality Loop 5 ขั้น

ใช้ checklist นี้กับ Agent หนึ่ง workflow ได้วันนี้

ขั้นที่ 1: เลือกงานจริงหนึ่งงาน

เขียนให้ชัดว่า Agent รับ input อะไร ต้องส่ง output อะไร เรียก Tool ไหน และจุดไหนที่คนต้อง review

ขั้นที่ 2: เก็บเคส 10 ถึง 20 แบบ

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

ขั้นที่ 3: ตั้ง metric ให้ตรงผลลัพธ์

ใช้ task success เป็นแกน แล้วเพิ่ม Tool correctness กับ deterministic check ที่สำคัญต่อธุรกิจ อย่าตั้ง metric ตามสิ่งที่ dashboard มี ถ้ามันไม่ตอบว่างานสำเร็จหรือไม่

ขั้นที่ 4: อ่าน failure ก่อนแก้ prompt

เปิด trace ดูว่า Agent เข้าใจเป้าหมายผิด เลือก Tool ผิด ส่ง argument ผิด อ่านผลผิด หรือสื่อสารผลผิด จากนั้นแก้สาเหตุทีละเรื่อง

ขั้นที่ 5: วัดซ้ำและติดตามงานจริง

รันชุดเดิมก่อนและหลังแก้ เก็บ baseline ไว้ แล้วสุ่ม production traces เป็นระยะ ถ้าคะแนนลด ให้เอา failure จริงกลับเข้า regression set

Template สั้นสำหรับทีม:

Workflow:
Expected outcome:
Required tools:
Human review point:
Core metric:
Deterministic check:
Known failure cases:
Baseline result:
Change tested:
Result after change:
Production signal to watch:

5) ข้อจำกัดที่ควรรู้

การมี evaluation ไม่ได้แปลว่า Agent จะไม่พลาดครับ

LLM-as-a-judge ยังเป็น model-based signal จึงควรดูแนวโน้มและเปรียบเทียบก่อนกับหลัง มากกว่ายึดคะแนนครั้งเดียวเป็นความจริงเด็ดขาด

การประเมิน production traffic ยังมีต้นทุนจาก model calls และ storage ทีมควรเริ่มจาก sampling เฉพาะ workflow สำคัญ ไม่จำเป็นต้องให้คะแนนทุก request

Synthetic case ช่วยเพิ่ม coverage แต่ไม่แทนงานจริงทั้งหมด เมื่อเริ่มมีผู้ใช้แล้ว production traces ที่คัดและลบข้อมูลอ่อนไหวอย่างเหมาะสมควรกลายเป็นวัตถุดิบหลักของรอบปรับปรุง

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

6) Data-Espresso จะเอาไปใช้ยังไง

มุมที่ Data-Espresso สนใจคือการแปลงข่าว AI ให้เป็น workflow ที่ตรวจผลได้ ไม่ใช่แค่ตามว่า vendor เปิด feature อะไร

ถ้ากำลังทำ AI coworker, support agent, content agent หรือ back-office workflow ลองเริ่มจาก Agent Quality Loop ข้างบนกับงานเดียวก่อนครับ

OPB Stack และทีม Data-Espresso สามารถช่วยจัด workspace, Tool, trace, approval point และชุด test case ให้ AI Agent มีบ้าน มีงานที่ชัด และมีหลักฐานว่าการปรับแต่ละรอบดีขึ้นจริง

ไม่ต้องเริ่มใหญ่ แต่ต้องเริ่มวัดจากงานที่คนใช้จริง

สรุป

ข่าวนี้ไม่ใช่แค่ Google เพิ่มหน้า evaluation ใน Cloud Console

สัญญาณสำคัญคือการทำ AI Agent กำลังขยับจาก “ลองแล้วดูดี” ไปสู่ “มีเคส มี metric มี trace และรู้ว่าหลังปล่อยคุณภาพเปลี่ยนอย่างไร”

สำหรับทีมเล็ก วิธีเริ่มที่คุ้มที่สุดคือเลือก workflow เดียว เก็บ 10 ถึง 20 เคส ตั้ง metric ให้ตรงผลลัพธ์ อ่าน failure จาก trace แล้วนำงานจริงกลับมาเป็น regression test

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