Google ADK เพิ่มการประเมินเอเจนต์เสียงแบบ live — ให้ LLM อีกตัวพูดใส่เอเจนต์ด้วยเสียงจริง แล้วให้คะแนนทั้งเส้นทางสนทนาด้วยเกณฑ์ที่เขียนเป็นภาษาคน

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

24 สิงหาคม 2026 Google Developers Blog เผยแพร่บทความของ Stephen Allen (Solutions Architect) แนะนำความสามารถใหม่ใน Agent Development Kit (ADK): การประเมินแบบ live ในตัว ที่ทดสอบเอเจนต์เสียงด้วย บทสนทนาที่เป็นเสียงจริง ไม่ใช่ทรานสคริปต์

กลไก — LLM อีกตัวสวมบทเป็นผู้ใช้ แล้วพูดใส่

หัวใจของฟีเจอร์อยู่ที่คอนฟิกตัวหนึ่งใน test_config.json คือ user_simulator_config ที่ตั้งชนิดเป็น llm_audio แทนที่จะป้อนข้อความให้เอเจนต์ ตัวจำลองผู้ใช้จะ สังเคราะห์เสียงพูดด้วย Gemini TTS แล้วส่งเสียงนั้นเข้าไปจริง ๆ โดยระบุพารามิเตอร์ของเสียงได้ ทั้งรหัสภาษาและเสียงสำเร็จรูปที่จะใช้

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

ตัวอย่างที่บทความใช้เดินเรื่องเป็น workflow สามขั้นแบบที่คอลเซ็นเตอร์ใช้จริง:

1. เอเจนต์ทักทายที่ยืนยันตัวตนผู้โทร
2. เอเจนต์ตรวจสอบวันเดือนปีเกิด ซึ่งมีการเรียกเครื่องมือ (tool) จริง
3. เอเจนต์จัดการรายละเอียดการนัดหมาย

แต่ละตัวรันแยกกันบนโมเดล live (ตัวอย่างใช้ gemini-live-2.5-flash-native-audio) ขณะที่ยังแชร์บริบทของบทสนทนาร่วมกัน — ซึ่งเป็นรูปแบบที่สะท้อนสถาปัตยกรรมมัลติเอเจนต์จริงมากกว่าเดโมเอเจนต์เดี่ยว

ให้คะแนนด้วยเกณฑ์ที่เขียนเป็นภาษาคน

ส่วนที่สองที่น่าสนใจคือวิธีตัดสินว่า “ผ่าน” การประเมินไม่ได้เทียบสตริงกับคำตอบที่เฉลยไว้ แต่ใช้ การให้คะแนนคุณภาพเส้นทางสนทนาหลายเทิร์นตามเกณฑ์ (rubric-based trajectory scoring) โดยเกณฑ์เขียนเป็นภาษาธรรมชาติ — ตัวอย่างในบทความคือเกณฑ์ชื่อ verifies_identity_first

นักพัฒนากำหนด เกณฑ์ผ่านเป็นตัวเลขได้เอง (ตัวอย่างใช้ 0.7) และประเมินได้ทั้ง รายเทิร์นและแบบ end-to-end ชุดทดสอบเป็นไฟล์ JSON ที่รองรับทั้งแบบกำหนดสถานการณ์ให้ตัวจำลองด้นเอง และแบบบทสนทนาตายตัว ส่วนการเรียกใช้ทำผ่านคลาส AgentEvaluator แบบเขียนโปรแกรมได้ จึงเอาไปแขวนใน CI ได้ตรง ๆ

ข้อกำหนดในการใช้งานคือต้องมีสิทธิ์เข้าถึงทั้ง Live API และ Gemini TTS

มุมมอง AI Curator

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

กับดักนั้นคือ การประเมินทั้งกระบวนการวางอยู่บนโมเดลของ Google ทั้งเส้น: Gemini TTS เป็นคนพูด โมเดล live เป็นคนฟัง และ LLM เป็นคนให้คะแนนตามเกณฑ์ ถ้าเสียงสังเคราะห์ที่ใช้ทดสอบชัดเจนและเป็นระเบียบกว่าเสียงมนุษย์จริงมาก คะแนนที่ได้ก็จะสวยกว่าความเป็นจริงอย่างเป็นระบบ นี่ไม่ใช่ข้อบกพร่องของ ADK โดยเฉพาะ — เป็นข้อจำกัดของแนวคิด “จำลองผู้ใช้ด้วย LLM” ทั้งหมด — แต่เป็นเหตุผลว่าทำไมคะแนนจากชุดนี้ควรถูกใช้เป็น เกณฑ์กันการถดถอย (regression gate) มากกว่าเป็นตัวเลขที่บอกว่าเอเจนต์พร้อมเจอผู้ใช้จริงแล้ว

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

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

แหล่งข่าว

• How to Evaluate Live & Voice Agents in ADK — Google Developers Blog (24 ส.ค. 2026)
• Agent Development Kit — เอกสารทางการ
• google/adk-python — GitHub