Google ชี้ behavioral eval เสริม benchmark ไม่ใช่ตัวแทน

โดย Nokka (นก-กา) | 15 กันยายน 2026

บทความนี้เขียนโดย AI (โมเดล deepseek-v4.1-flash ของผู้ให้บริการ ollama-cloud) ผ่าน Hermes Agent จาก Nous Research ตรวจสอบและเรียบเรียงโดย Nokka

มีปัญหาหนึ่งที่ทุกคนที่สร้าง AI agent เจอ และผมคิดว่า Google อธิบายได้ตรงที่สุด

"เมื่อนักพัฒนาทำงาน harness engineering กับระบบ agentic coding ครั้งแรก พวกเขามักตกหลุมพรางเดียวกัน คือรัน benchmark แบบ end-to-end ที่ใช้กันทั่วไปอย่าง Terminal-Bench และ DeepSWE เห็นคะแนนรวมขยับไม่กี่เปอร์เซ็นต์ *และไม่รู้เลยว่าทำไมมันถึงเปลี่ยน*" [1]

Taylor Mullen และ Chris Gunderman เขียนบทความนี้บน Google Cloud Tech เมื่อ 15 กันยายน 2026 [1][2]

ปัญหาของการวัดแบบ "ให้คะแนนเหมือนสอบ"

Google เปรียบเทียบไว้ตรงไปตรงมา [1]

"ทีมส่วนใหญ่ประเมิน AI agent เหมือนประเมินนักเรียนที่เข้าสอบ พวกเขายื่นโค้ดเบสก้อนใหญ่ให้ agent กำหนดเวลาจำกัด แล้ววัดความสำเร็จจากจำนวนเทสต์ที่ผ่านหรือไม่ผ่าน"

และปัญหาคือ เมื่อคะแนนตกลง คุณตอบไม่ได้ว่าอะไรผิด [1]

คำถามที่ Google ยกมา ซึ่งผมคิดว่าตรงกับประสบการณ์จริง [1]

• โมเดลมั่นใจเกินไปกับ prompt ที่กำกวมหรือเปล่า
• มันลืมตรวจ test suite ก่อนส่งงานไหม
• มัน hallucinate CLI flag ขึ้นมาไหม

บริบทที่ควรรู้ Terminal-Bench คือ benchmark ที่ให้ agent ทำงานในสภาพแวดล้อมเทอร์มินัลจริง และเป็นหนึ่งในชุดทดสอบที่ Google ยกมาเป็นตัวอย่าง [4]

"benchmark แบบ end-to-end *โดยทั่วไปไม่ตอบคำถามเหล่านี้โดยตรง*" [1]

ทางออก: behavioral evaluation

แนวคิดคือ เปลี่ยนจากการวัด "ผลลัพธ์สุดท้าย" มาวัด "การกระทำที่สังเกตได้เป็นขั้น ๆ" [1]

Google ให้นิยามไว้สั้นและคม

"การประเมินเชิงพฤติกรรมทำหน้าที่เหมือน **integration tests สำหรับปรับปรุงการทำงานของ agent harness" [1]

และตารางเทียบที่ผมคิดว่าเข้าใจง่ายที่สุด [1]

คำถาม	สิ่งที่วัด
ได้รับ prompt ที่กำกวม มันถามกลับหรือเดา	การกระทำ
จะแก้ไฟล์ build มันรัน validator ท้องถิ่นก่อนบอกว่าเสร็จไหม	การกระทำ
จะเขียนเอกสาร มันให้ลิงก์ repo ที่เป็นทางการไหม	การกระทำ

⇒ สังเกตว่าทั้งสามข้อวัด "พฤติกรรมที่คาดหวัง" ไม่ได้วัด "คำตอบถูกไหม" [1]

จุดที่ผมคิดว่าสำคัญที่สุด: เมื่อไหร่ควรเริ่มทำ eval

Google ให้คำตอบที่ขัดกับสัญชาตญาณของคนทำงานส่วนใหญ่ [1]

"แทนที่จะตั้ง evaluation harness ที่ซับซ้อนตั้งแต่วันแรก ให้ใช้เวลานั้นทำตามสัญชาตญาณนักพัฒนาและ dogfooding" [1]

และเหตุผลที่เขาให้ [1]

"จนกว่าคุณจะสร้าง agent ที่สามารถ dogfood โค้ดเบสของตัวเองได้ จัดการงานซ้ำ ๆ เขียน markdown renderer ของตัวเอง และทำงานนักพัฒนาประจำวันได้ *มันไม่สมเหตุสมผลที่จะรัน evaluation*"

⇒ eval ไม่ใช่ขั้นแรก แต่เป็นขั้นที่สอง [1]

และประโยคที่ผมคิดว่าควรติดไว้ที่ผนัง

"จุดประสงค์หลักของ eval suite ไม่ใช่เพื่อฉลองเมื่อคุณทำ agent เก่งขึ้น 2% แต่เพื่อให้ความมั่นใจแบบสั่นคลอนไม่ได้ว่า การปรับ prompt การเปลี่ยน schema เครื่องมือ หรือการอัปเกรดโมเดล ไม่ได้ทำให้ agent แย่ลงโดยรวม" [1]

ผมอ่านประโยคนี้แล้วคิดว่ามันเปลี่ยนวิธีคิดเรื่อง eval ทั้งหมด eval ไม่ใช่เครื่องมือวัดความก้าวหน้า แต่เป็นตาข่ายกันตก [1]

ตัวอย่างโค้ดที่ Google ให้มา

เขาใช้ Antigravity SDK เป็นตัวอย่าง และหลักการสำคัญคือ assert ที่ขั้นกลาง ไม่ใช่ที่ข้อความสุดท้าย [1]

import pytest
from google.antigravity import Agent, LocalAgentConfig, types

@pytest.mark.asyncio
async def test_agent_uses_web_search_for_live_weather():
  """Assert that the agent consults ground truth rather than guessing."""
  config = LocalAgentConfig()

  async with Agent(config) as agent:
    response = await agent.chat("What's the weather like in Mountain View, California?")
    tools = [call.name async for call in response.tool_calls]

  # Assert behavior, not output prose
  assert types.BuiltinTools.SEARCH_WEB in tools, (
      "Agent answered from memory without consulting live search."
  )

จุดที่ผมคิดว่าฉลาดมากคือ บรรทัด assertion มันไม่ได้ตรวจว่าคำตอบเรื่องอากาศถูกไหม แต่มันตรวจว่ามันเรียก web search หรือเปล่า [1]

"การประเมินเชิงพฤติกรรม assert ที่ขั้นตอนการทำงานระหว่างทาง เช่น การเรียกเครื่องมือเฉพาะหรือการแก้ไฟล์ *แทนที่จะเทียบข้อความสุดท้ายแบบตรงตัว*" [1]

⇒ เพราะคำตอบเรื่องอากาศเปลี่ยนทุกวัน แต่ "ต้องค้นข้อมูลจริง" เป็นพฤติกรรมที่ต้องคงที่ [1]

และทั้งชุดรันได้ในเวลาสั้น [1]

# Run local behavioral suite in under 5 seconds
pytest evals/behavioral/ -v

ลูปที่ Google แนะนำ

Google แนะนำ สามขั้นตอน และผมจะยกมาแบบตรง ๆ เพราะคิดว่าใช้ได้จริง [1]

ขั้นที่ 1: เลือกความล้มเหลวมาหนึ่งอย่าง

"หาความผิดพลาดที่ agent เพิ่งทำ เช่นลืมรัน unit test ก่อนทำเครื่องหมายว่างานเสร็จ หาการกระทำเดียวที่ชัดเจนที่หลุดไป แล้วตั้งมันเป็นเป้า" [1]

ขั้นที่ 2: เขียน assertion ตามความซับซ้อนของงาน

นี่คือส่วนที่ผมคิดว่าฉลาดที่สุด เพราะมันแยกสองสถานการณ์ [1]

• งานง่ายที่มีคำตอบดีที่สุดอันเดียว ⇒ ใช้ assertion แบบเข้มงวด ตรวจว่าถึง milestone เฉพาะหรือไม่
• งานซับซ้อนที่โมเดลอาจเดินเส้นทางไม่คาดคิดแต่ถูกต้อง ⇒ อย่าบังคับลำดับเครื่องมือตายตัว ใช้การตรวจแบบประเมินผลลัพธ์ เช่น LLM-as-a-judge

⇒ ถ้าคุณบังคับลำดับเครื่องมือตายตัวในงานซับซ้อน คุณจะทำ eval ที่ "ผ่านยากเกินจริง" และทีมจะเลิกเชื่อมัน [1]

ขั้นที่ 3: ทำ batch evaluation ไม่ใช่บล็อก PR ด้วยการรันครั้งเดียว [1]

"แทนที่จะบล็อก PR ด้วยการรัน eval ครั้งเดียวซึ่งมีสัญญาณรบกวนสูงเนื่องจากความไม่แน่นอนของโมเดล ให้ทำอัตโนมัติเป็น batch evaluation เพื่อดึงข้อมูลปริมาณมากขึ้น *การติดตามอัตราผ่านแบบรวมเมื่อเวลาผ่านไป ทำให้มั่นใจว่าพฤติกรรมของโมเดลมีแนวโน้มไปทางที่ถูก*"

⇒ นี่คือข้อที่ผมคิดว่าต่างจากวิธีที่ทีมส่วนใหญ่ทำ เพราะมันยอมรับว่า eval ของ AI ไม่ deterministic จึงไม่ควรใช้ตัดสินเป็นรายครั้ง [1]

และลูปที่ผมคิดว่าน่าสนใจที่สุด

Google ยกตัวอย่างการใช้ behavioral eval เพื่อ automate prompt engineering [1]

"คุณตั้งลูปที่ LLM ปรับ system prompt ของตัวเอง วนไปจนกว่าเทสต์ที่ล้มเหลวจะผ่าน ในขณะที่เทสต์ที่เหลือทำหน้าที่เหมือน **CI/CD guardrail"

⇒ นี่คือแนวคิดที่ผมคิดว่านำไปใช้ได้ทันที ถ้าคุณมี behavioral eval ที่ดี มันกลายเป็น "สัญญาณความสำเร็จ" ให้ agent ปรับ prompt ของตัวเองได้ โดยมี suite ที่เหลือคอยกันไม่ให้ทำอย่างอื่นพัง [1]

ข้อจำกัดที่ Google เปิดเอง

บทความนี้ไม่ได้บอกว่า behavioral eval แทน benchmark ได้ และผมคิดว่านี่คือส่วนที่ทำให้บทความน่าเชื่อถือ [1]

"แม้ว่า behavioral evaluation จะเป็นเสาหลักของการทำ harness engineering *มันไม่ได้แทนที่ชุดทดสอบแบบ end-to-end ที่ใหญ่กว่า แต่จริง ๆ แล้วมันเสริมกัน** macro benchmark ตรวจสอบปลายทางสุดท้าย ส่วน micro behavioral eval ทำหน้าที่เป็นคู่หูที่ทำให้เกิดการปรับตัวอย่างรวดเร็วและปลอดภัย"*

และประโยคปิดของ Google [1]

"agent ของคุณไม่จำเป็นต้องมีคะแนน benchmark ที่สูงขึ้นเพื่อเริ่มต้น มันต้องการ evaluation harness ที่คอยทำให้มันซื่อสัตย์" [1]

SDK ที่ใช้ในตัวอย่าง

โค้ดตัวอย่างเขียนสำหรับ Antigravity SDK ซึ่งเป็นไลบรารี Python จากทีม Google Antigravity [1][3]

รายการ	ข้อมูล
repo	google-antigravity/antigravity-sdk-python
ดาว	3,406
Forks	1,347
สัญญาอนุญาต	Apache-2.0
สร้างเมื่อ	29 เมษายน 2026
อัปเดตล่าสุด	2 กันยายน 2026

และมีข้อควรรู้ที่ README ระบุไว้ชัด [3]

"SDK ของ Google Antigravity ต้องใช้ไบนารี runtime ที่คอมไพล์แล้ว ซึ่งรวมอยู่ใน wheel ที่เผยแพร่บน PyPI *การโคลน repo นี้อย่างเดียวไม่เพียงพอที่จะรัน SDK** ให้ติดตั้งจาก PyPI ด้วย pip install google-antigravity [5]"*

เริ่มจากอะไรได้พรุ่งนี้

ผมแนะนำให้ลองแบบนี้ครับ เลือก agent ที่คุณมีอยู่ แล้วย้อนดูความผิดพลาดล่าสุดหนึ่งครั้ง

จากนั้นเขียนเทสต์เดียวที่ตรวจ "การกระทำ" ที่หายไป ไม่ใช่ "คำตอบ" ที่ผิด [1]

ตัวอย่างที่จับต้องได้ ถ้า agent ลืมรันเทสต์ก่อนบอกว่าเสร็จ เขียนเทสต์ที่ตรวจว่ามันเรียก test runner แล้วรันใน CI

วิธีนี้ใช้เวลาไม่ถึงชั่วโมง และถ้ามันจับ regression ได้แม้แต่ครั้งเดียว มันก็คืนทุนแล้ว [1]

ข้อควรระวัง

หนึ่ง บทความนี้สรุปจากบทความของ Google Cloud Tech ซึ่งเป็นบริษัทที่พัฒนา Antigravity SDK และ Gemini [1]

สอง ผมไม่ได้ทดสอบ Antigravity SDK หรือเขียน behavioral eval เอง ทั้งหมดเป็นการรายงานจากบล็อกและ README [1][3]

สาม โค้ดตัวอย่างในบทความนี้เป็นของ Google ผมยกมาทั้งบล็อกโดยไม่แก้ไข [1]

สี่ ตัวเลขดาวและ forks ของ repo เปลี่ยนทุกวัน ตัวเลขที่ผมเขียนดึงจาก GitHub API ณ วันที่เขียน [3]

ห้า บทความต้นทางไม่ได้ให้ตัวเลขผลลัพธ์ว่า behavioral eval ช่วยได้กี่เปอร์เซ็นต์ ⇒ ประโยชน์ที่ผมอธิบายเป็นหลักการ ไม่ใช่ผลการวัด [1]

หก ผมทำงานบนระบบที่ใช้โมเดล AI และเขียนบทความนี้ด้วยความช่วยเหลือของ AI [6]

บทความที่เกี่ยวข้อง

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

แหล่งอ้างอิง

[1] Mullen, T. และ Gunderman, C., "The Anatomy of Harness Engineering: How to Evaluate, Iterate, and Guard AI Coding Agents", Google Cloud Tech (15 ก.ย. 2026), https://x.com/i/article/2099944987588698112

[2] Google Cloud Tech, โพสต์ลิงก์บทความบน X (15 ก.ย. 2026), https://x.com/GoogleCloudTech/status/2099946653134229721

[3] "Google Antigravity SDK" ไลบรารี Python สำหรับสร้าง AI agent, GitHub (สร้าง 29 เม.ย. 2026 · อัปเดต 2 ก.ย. 2026), https://github.com/google-antigravity/antigravity-sdk-python

[4] "Terminal-Bench" benchmark สำหรับประเมิน agent ในสภาพแวดล้อมเทอร์มินัล, Stanford/Laude Institute (เข้าถึง ก.ย. 2026), https://www.tbench.ai/

[5] "Antigravity SDK บน PyPI" แพ็กเกจไลบรารี Python, PyPI (เข้าถึง ก.ย. 2026), https://pypi.org/project/google-antigravity/

[6] การเปิดเผยของผู้เขียน: บทความนี้เขียนโดยใช้โมเดล AI