Google ปล่อย Agent และ Model Evaluations บน Gemini Enterprise Agent Platform เป็น GA — metric สำเร็จรูป 20+ ตัว, adaptive rubric ที่สร้างเกณฑ์เองรายเคส และ user/environment simulator

วันที่ 31 กรกฎาคม 2026 Google ประกาศให้ Agent and Model Evaluations บน Gemini Enterprise Agent Platform เข้าสู่สถานะ GA (generally available) พร้อมกันทั้งชุด — ตั้งแต่ metric สำเร็จรูป การรัน experiment การมอนิเตอร์ traffic จริงบน production ไปจนถึงระบบจำลองผู้ใช้และระบบปลายทาง

Alex Martin และ Dima Melnyk (Product Manager) วางกรอบประกาศนี้ด้วยประโยคที่สรุปปัญหาได้ตรง:

“Agent quality must be measured during development against the cases you wrote, and after launch against the tasks the agent actually performed.”

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

metric: ของสำเร็จรูป 20+ ตัว และ adaptive rubric

metric ที่ให้มาแบ่งเป็นสองสาย

สายคำนวณตรง ๆ (computation-based) — ตัวคลาสสิกที่ deterministic และไม่มีค่าใช้จ่ายเพิ่ม:

• ROUGE สำหรับงานสรุปความ
• BLEU, MetricX, COMET สำหรับงานแปล
• Exact match สำหรับ extractive QA

สาย adaptive rubric — ครอบคลุม Task Success, Tool Use Quality, Safety (นโยบายเนื้อหา เช่น hate speech, harassment, dangerous content, sexually explicit และ PII), Trajectory Quality, Final Response Quality, Hallucination, Grounding และคุณภาพภาพ/วิดีโอ

adaptive rubric คืออะไร — Google อธิบายว่าเป็น “advanced LLM-judge metric workflow” ที่พัฒนาร่วมกับทีมวิจัย Google DeepMind จุดต่างจาก LLM-as-a-judge แบบทั่วไปคือ มันไม่ได้ใช้เกณฑ์ตายตัวชุดเดียวกับทุกเคส แต่ สร้างเกณฑ์ผ่าน/ไม่ผ่านเฉพาะของแต่ละเคสขึ้นมาเอง จากนิยาม evaluation case, คำสั่งที่นักพัฒนาเขียน และ tool declaration ของ agent แล้วจึงเอา trace ไปตรวจกับเกณฑ์นั้นพร้อมให้ verdict และเหตุผลกำกับ

นักพัฒนายังนิยาม metric เองได้สองแบบ: code-based (ฟังก์ชัน Python สำหรับ exact match, ตรวจความถูกต้องของ JSON หรือ logic เฉพาะทาง) และ LLM-as-a-judge ที่กำหนดเกณฑ์ สเกลคะแนน และเลือกโมเดลผู้ตัดสินได้เอง — จุดที่น่าสนใจคือ เลือกโมเดล Anthropic และโมเดลใน Model Garden เป็นผู้ตัดสินได้ ไม่ได้บังคับให้ใช้ Gemini ทุก metric ถูกลงทะเบียนใน registry ที่มีเวอร์ชันและใช้ร่วมกันทั้งองค์กร เพื่อให้การให้คะแนนใน offline experiment กับ online monitor สอดคล้องกัน

experiment, online monitor และ simulator

Experiment คือชุดข้อมูลทดสอบจับคู่กับ metric แล้วรันให้คะแนน รันได้ทั้ง local (สำหรับ iterate เร็ว ๆ) และ server-side ที่เก็บ artifact ลง Cloud Storage แบบตรวจสอบย้อนหลังและทำซ้ำได้

ฟีเจอร์ที่ผมคิดว่ามีประโยชน์เกินคาดคือ issue clustering — แทนที่จะโยนรายการเคสที่ fail มาให้ไล่อ่านทีละอัน ระบบจัดกลุ่มความล้มเหลวตาม taxonomy ของสาเหตุที่นักพัฒนากำหนดเอง และมี taxonomy สำเร็จรูปสำหรับ adaptive rubric ที่ครอบคลุมรูปแบบความล้มเหลวที่พบบ่อยของ agent มาให้แล้ว

Online monitoring ทำงานบน traffic จริง: ให้คะแนน trace ที่มีอยู่ผ่าน Cloud Trace ได้โดยตรง หรือตั้ง online monitor ให้ประเมิน traffic สดอัตโนมัติ พร้อมปรับ sampling และ filter เพื่อคุมค่าใช้จ่าย ผลออกมาเป็น dashboard คะแนนตามเวลาพร้อม drift alert ส่งเข้าอีเมล Slack หรือ channel ที่กำหนดเอง

Simulation มีสามชิ้นที่แก้ปัญหา “ไม่มีข้อมูลทดสอบพอ” โดยตรง:

• Case Generator — สร้าง evaluation case สังเคราะห์จากคำสั่งและ tool ของ agent เพื่อตั้งต้นชุดข้อมูลโดยไม่ต้องเขียนเคสเองทั้งหมด
• User Simulator — สวมบทผู้ใช้ตาม persona ที่กำหนด แล้วคุยกับ agent จนจบบทสนทนา ทำให้ทดสอบ multi-turn ได้โดยไม่ต้องสคริปต์คำตอบผู้ใช้ทีละบรรทัด (ใช้กับ agent ที่สร้างด้วย ADK)
• Environment Simulator — จำลองระบบปลายทางที่ agent เรียก ทำให้ทดสอบได้ว่า agent ทำตัวอย่างไรเมื่อ service ปลายทางล่มหรือช้า โดยไม่ต้องไปยุ่งกับของจริง

เข้าถึงได้ผ่าน Agent Platform SDK, agents-cli, ADK, Evals Worksheet (UI บนเว็บ) และ REST API สำหรับภาษาที่ SDK ไม่รองรับ

ค่าใช้จ่ายและความพร้อมใช้งาน

• metric ที่เป็น code-based และ computation-based ไม่มีค่าใช้จ่ายเพิ่ม
• metric ที่ใช้ LLM คิดตาม อัตราการเรียกโมเดลปกติ
• Cloud Storage คิดตาม artifact ที่ server-side run เก็บไว้
• ข้อมูลและ trace อยู่ในโปรเจกต์ของลูกค้าเอง
• ความพร้อมใช้งานต่างกันตาม region — ต้องเช็กเอกสารประกอบ

มุมมอง AI Curator

ปีที่ผ่านมาเราเห็นเครื่องมือสร้าง agent ผุดขึ้นเป็นสิบ แต่ เครื่องมือวัดว่า agent ทำงานดีหรือเปล่ายังตามหลังอยู่มาก ทีมส่วนใหญ่ที่ผมเห็นยังวัดคุณภาพ agent ด้วยวิธีเดิม คือให้คนในทีมลองใช้แล้วบอกว่า “รู้สึกว่าดีขึ้น” ประกาศนี้จึงสำคัญไม่ใช่เพราะเป็นของใหม่ที่ไม่เคยมี — Langfuse, LangSmith, Braintrust และเจ้าอื่นทำเรื่องนี้มาก่อน — แต่เพราะเป็นสัญญาณว่า eval กำลังกลายเป็นชั้นพื้นฐานของแพลตฟอร์ม ไม่ใช่เครื่องมือเสริมที่ต่อเพิ่มทีหลัง

สองชิ้นที่ผมคิดว่าคิดมาดีจริง

หนึ่ง คือ adaptive rubric LLM-as-a-judge แบบเกณฑ์ตายตัวมีจุดอ่อนที่คนใช้จริงเจอกันหมด คือเกณฑ์ที่เขียนกว้างพอจะใช้กับทุกเคสได้ มักหลวมเกินกว่าจะจับความผิดที่สำคัญของเคสใดเคสหนึ่ง การให้ระบบสร้างเกณฑ์รายเคสจากนิยามงานและ tool declaration แล้วให้เหตุผลกำกับ verdict เป็นทิศทางที่ถูก และการที่มันมาจากงานร่วมกับ DeepMind ก็ทำให้พอเชื่อได้ว่าไม่ใช่แค่ prompt template ที่ห่อใหม่ แต่ยังต้องรอเห็นว่าเกณฑ์ที่มันสร้างเองมีความเสถียรแค่ไหนเมื่อรันซ้ำ — เพราะ judge ที่ให้คำตอบไม่คงที่ระหว่างรัน จะทำลายความหมายของ drift alert ทั้งระบบ ซึ่งประกาศนี้ไม่ได้พูดถึง

สอง คือ environment simulator ในบรรดาฟีเจอร์ทั้งหมด ผมว่านี่คือชิ้นที่ถูกมองข้ามที่สุดแต่มีค่าที่สุดในทางปฏิบัติ เพราะความล้มเหลวของ agent ในโลกจริงจำนวนมาก ไม่ได้เกิดจากโมเดลตอบผิด แต่เกิดจาก tool ปลายทาง timeout, คืน error แปลก ๆ หรือช้ากว่าปกติสิบเท่า แล้ว agent ตัดสินใจต่อผิดทาง เคสพวกนี้ทดสอบยากมากถ้าไม่มีตัวจำลอง และแทบไม่มีใครเขียนเทสไว้ก่อนขึ้น production เลย

ข้อสังเกตที่ควรพูดตรง ๆ: ทั้งหมดนี้เป็นของ enterprise บน Google Cloud ไม่ใช่ของที่นักพัฒนาเดี่ยวหยิบไปใช้ฟรีได้ และการผูกกับ Cloud Trace, Cloud Storage และ registry ระดับองค์กร แปลว่า ต้นทุนการย้ายออกไม่ต่ำ ถ้าคุณสร้างมาตรฐานคุณภาพทั้งหมดไว้บนนี้ จุดที่ช่วยลดความกังวลได้บ้างคือการเลือกโมเดลผู้ตัดสินเป็นของ Anthropic ได้ ซึ่งอย่างน้อยก็แปลว่า Google ไม่ได้ล็อกให้ Gemini เป็นผู้ตัดสินคุณภาพ Gemini เอง — ข้อนี้สำคัญกว่าที่เห็น เพราะ judge ที่มาจากตระกูลเดียวกับ agent ที่ถูกตรวจ มีความเสี่ยงเรื่องอคติเชิงระบบอยู่ในตัว

สำหรับทีมไทยและ SEA ผมเห็นสองอย่างที่เอาไปใช้ได้ทันทีโดยไม่ต้องซื้อแพลตฟอร์มใคร

อย่างแรกคือแนวคิดวัดสองจุด — วัดตอนพัฒนาด้วยเคสที่เราเขียนเอง และวัดหลัง launch ด้วยงานที่ agent ทำจริง ทีมส่วนใหญ่ทำแค่อย่างแรกแล้วหยุด ทั้งที่จุดที่สองคือจุดที่ความจริงอยู่ การเริ่มเก็บ trace ของ production ไว้แล้วสุ่มมาให้คะแนนสัปดาห์ละครั้ง เป็นการลงทุนที่ถูกมากเมื่อเทียบกับสิ่งที่ได้กลับมา

อย่างที่สองคือ multi-turn ซึ่งเกี่ยวกับบริบทไทยโดยตรง — agent ภาษาไทยที่คุยกับลูกค้าจริงมักพังในเทิร์นที่ 3-5 ไม่ใช่เทิร์นแรก เพราะผู้ใช้ไทยเปลี่ยนเรื่องกลางทาง ใช้คำย่อ พิมพ์ผสมไทย-อังกฤษ และตอบสั้นแบบที่ต้องอาศัยบริบทก่อนหน้าอย่างหนัก แนวคิด user simulator ที่สวม persona แล้วคุยยาว ๆ เป็นสิ่งที่ทีมไทยควรทำเองด้วยซ้ำ เพราะ persona ที่สะท้อนพฤติกรรมผู้ใช้ไทยจริง ๆ ไม่มีใครสร้างให้ได้นอกจากเรา และเป็นสินทรัพย์เชิงแข่งขันที่ลอกกันไม่ได้ง่าย ๆ

แหล่งข่าว

• Agent and Model Evaluations in Gemini Enterprise Agent Platform are now GA — Google Developers Blog, 31 ก.ค. 2026
• Google Developers Blog