Supabase เปิด Evals — เบนช์มาร์ก Apache-2.0 ที่ให้ Claude Code, Codex และ OpenCode ลงมือทำงานจริงบนโปรเจกต์ Supabase

เบนช์มาร์กของ coding agent ส่วนใหญ่วัดสิ่งที่วัดง่าย — เขียนฟังก์ชันให้ผ่านเทสต์ แก้ issue ใน repo โอเพนซอร์ส แต่สิ่งที่นักพัฒนาจริงให้ agent ทำทุกวันมักเป็นงานที่ผูกกับ แพลตฟอร์มใดแพลตฟอร์มหนึ่ง: ตั้ง RLS policy ให้ถูก, ไล่ดู log หา Edge Function ที่ 5xx, เขียน migration โดยไม่ทำ history พัง งานพวกนี้ไม่มีอยู่ใน SWE-bench

วันที่ 31 กรกฎาคม 2026 Supabase ปล่อย Supabase Evals — เฟรมเวิร์กเบนช์มาร์กโอเพนซอร์ส (Apache-2.0) ที่เอา coding agent ตัวจริง — Claude Code, Codex, OpenCode — ไปรันกับงาน Supabase จริงในสภาพแวดล้อมจริง แล้วให้คะแนนผลลัพธ์ Matt Rossman ผู้เขียนบล็อกบอกเหตุผลตรงไปตรงมาว่า “agent กำลังกลายเป็นช่องทางหลักที่คนใช้สร้างของบน Supabase” ผ่าน CLI, MCP server, agent skills และเอกสาร — บริษัทจึงต้องรู้ว่าตัวเองทำงานร่วมกับ agent ได้ดีแค่ไหน

งาน 38 สถานการณ์ ที่ไม่ใช่ mock

ใน repo มี eval ทั้งหมด 38 สถานการณ์ แต่ละอันอยู่ใน evals/<id>/ และมีโครงเดียวกัน: PROMPT.md (โจทย์ที่ agent เห็น + metadata), EVAL.ts (ตัวให้คะแนน), และไดเรกทอรี remote/ กับ local/ ที่เป็น สถานะตั้งต้นของสองสภาพแวดล้อม — remote/ คือหน้าตาโปรเจกต์ที่โฮสต์อยู่แล้ว (ฐานข้อมูล, logs.jsonl, Edge Function ที่ deploy ไว้) ส่วน local/ คือไฟล์ในเครื่องนักพัฒนา

ชื่อ eval บอกเนื้องานได้ชัดกว่าคำอธิบายใด ๆ:

• build-rls-003-org-roles-permissions — เขียน RLS ให้ role ในองค์กร
• build-vectors-001-rag-with-permissions — ทำ RAG ที่เคารพสิทธิ์การเข้าถึง
• investigate-functions-001-546-resource-limit — ไล่หาสาเหตุ Edge Function ชน resource limit
• investigate-reliability-003-edge-function-5xx-correlation — หา correlation ของ 5xx
• resolve-security-002-rls-cross-tenant-leak — ปิดรูรั่วข้ามผู้เช่า
• resolve-database-001-migration-history-mismatch — แก้ migration history ที่ไม่ตรงกัน

งานถูกจัดตามสี่ stage (build, deploy, investigate, resolve) ตัดกับ product (database, auth, storage, functions, realtime, vectors, …) และ topic (RLS, security, migrations, SQL, observability)

สำคัญคือมันไม่ได้รันบน mock มีสอง runtime ที่เลือกอัตโนมัติ: tools evals ให้ agent ยิงผ่าน MCP/tool surface จริงแล้วตรวจสถานะโปรเจกต์ที่ได้ ส่วน local-stack evals โยน agent เข้า Docker sandbox ที่มี bash + file tools + Supabase CLI ตัวจริง เพื่อให้มันรัน supabase init/start/db/test กับ local stack ได้เอง เบื้องหลังโปรเจกต์โฮสต์จำลองคือ platform-lite ที่เปิด HTTP surface เข้ากันได้กับ Supabase Management API ทำให้เครื่องมือของจริงอย่าง @supabase/mcp-server-supabase รันใส่ได้ตรง ๆ

การให้คะแนนผสมสองแบบ: deterministic check สำหรับสิ่งที่ตรวจได้ตรง ๆ (ข้อมูลเข้าถึงได้จริงไหม) บวก LLM-as-a-judge เฉพาะส่วนที่ต้องตัดสินเชิงความหมาย และ agent ได้ retry หนึ่งครั้งก่อนตัดเกรด

ตัวเลขที่น่าสนใจไม่ใช่อันดับ แต่คือ “ส่วนต่างจาก skills”

บล็อกรายงานผลเฉพาะขั้น build และตัวเลขบอกอะไรที่ตารางอันดับปกติไม่บอก:

โมเดล / ตัวรัน	ไม่โหลด skill	โหลด skill
Opus 5	100%	—
Kimi K3	100%	—
Sonnet 5	78%	100%
GPT-5.6 Sol	89%	100%
GPT-5.4 mini	78%	89%

Opus 5 กับ Kimi K3 เต็ม 100% ตั้งแต่ยังไม่โหลดอะไรเลย — แปลว่าเพดานของขั้น build นี้ต่ำเกินจะแยกโมเดลระดับบนออกจากกัน (ข้อจำกัดที่ควรพูดตรง ๆ) แต่สิ่งที่มีความหมายกว่าคือ skills ช่วยโมเดลเล็กมากกว่าโมเดลใหญ่: Sonnet 5 กระโดด 22 จุด, GPT-5.6 Sol 11 จุด, GPT-5.4 mini 11 จุด ในขณะที่รุ่นท็อปไม่มีที่ให้ขึ้น

ใน repo มี skill สองตัวคือ supabase และ supabase-postgres-best-practices และทีมงานเล่าว่าตัวหลังตอนแรก agent เรียกใช้เพียง “ราวหนึ่งในสิบ” ของ session — ต้องเขียนคำอธิบายใหม่จน activation ขึ้นไปแตะ 60% ทั่วเบนช์มาร์ก นี่คือรายละเอียดที่คนเขียน Agent Skills ควรอ่าน: skill ที่ดีแต่ agent ไม่หยิบไปใช้ มีค่าเท่ากับไม่มี

อีกตัวเลขที่เผยนิสัยต่างกันของ agent คือการอ่านเอกสาร — Codex/GPT-5.6 อ่านมากที่สุดราว 8 หน้าต่อสถานการณ์ เทียบกับ ราว 2 หน้า ของ Claude Code และ Claude Code เปิดดูเอกสารของ Supabase ใน ไม่ถึง 40% ของสถานการณ์ แม้จะโหลด skill ไว้แล้ว

รันเองได้ และ Supabase ใช้เป็น regression suite ของตัวเอง

ทั้งหมดรันในเครื่องผ่าน pnpm:

git clone --recurse-submodules git@github.com:supabase/evals.git
pnpm install && cp .env.example .env   # ใส่ ANTHROPIC_API_KEY / OPENAI_API_KEY

# รัน eval เดียวกับ experiment เดียว
pnpm eval -- --eval resolve-dataapi-001-empty-results --experiment claude-code-sonnet-5

# รันทั้ง benchmark suite เทียบแบบมี/ไม่มี skills
pnpm eval -- --suite benchmark --experiment-suite benchmark,no-skills

โครงสร้าง experiments/ คือจุดที่ทำให้ repo นี้ต่อยอดง่าย — แต่ละไฟล์คือชุด agent+runtime+model หนึ่งชุด (claude-code-opus-5.ts, codex-gpt-5.6-no-skills.ts, opencode-kimi-k3.ts, …) เพิ่มโมเดลหรือ agent ใหม่ = เพิ่มไฟล์ใหม่ ผลลัพธ์เขียนลง results/ และ export ขึ้นเว็บแอปดูเทียบกันได้

จุดที่ควรอ่านให้ครบ: Supabase บอกเองว่าตัวเลขในบล็อกเป็น snapshot ณ เวลาที่เขียน และให้ไปดูหน้า supabase.com/evals สำหรับผลปัจจุบัน — เพราะเครื่องมือ AI เปลี่ยนเร็วมาก นอกจากนี้ evals ชุดนี้ไม่ได้มีไว้โชว์อย่างเดียว แต่ “ขับทั้งเบนช์มาร์กที่เผยแพร่และ regression suite ภายในที่เราเฝ้าดูทุกวัน”

มุมมอง AI Curator

สิ่งที่ Supabase ทำน่าสนใจกว่าคะแนนที่ได้ — พวกเขาเปลี่ยนคำถามจาก “โมเดลไหนเก่งกว่า” เป็น “แพลตฟอร์มของเราใช้งานง่ายแค่ไหนสำหรับ agent” และนั่นคือเบนช์มาร์กที่บริษัทซอฟต์แวร์ทุกเจ้ากำลังจะต้องมี เมื่อ agent กลายเป็นผู้ใช้หลักของ SDK, CLI และเอกสาร ตัวชี้วัด developer experience ที่แท้จริงก็ไม่ใช่ “นักพัฒนาอ่านเอกสารเราแล้วเข้าใจไหม” อีกต่อไป แต่คือ “agent อ่านแล้วทำถูกไหม”

ตัวเลขที่ควรจำที่สุดในโพสต์นี้คือ 60% — สัดส่วนที่ skill ถูกเรียกใช้จริง หลังจากทีม Supabase ต้องกลับไปเขียนคำอธิบาย skill ใหม่ เพราะของเดิมถูกหยิบแค่หนึ่งในสิบครั้ง นี่คือความจริงที่คนสร้าง Agent Skills และ MCP server ในไทยควรรับไว้ตั้งแต่วันแรก: ปัญหาไม่ได้อยู่ที่เนื้อหาใน skill แต่อยู่ที่ description ที่ทำให้ agent ตัดสินใจว่าจะโหลดมันหรือไม่ เรากำลังเขียนเอกสารให้ผู้อ่านที่ตัดสินใจจาก metadata บรรทัดเดียว

ส่วนช่องว่าง 22 จุดของ Sonnet 5 มีนัยเชิงต้นทุนโดยตรงสำหรับทีมไทยที่งบจำกัด — skill ที่เขียนดีทำให้โมเดลชั้นกลางทำงานเฉพาะทางได้เท่าโมเดลท็อป ในราคาที่ต่ำกว่ามาก การลงแรงเขียน skill/เอกสารให้ agent อ่านรู้เรื่อง จึงเป็นการลงทุนที่คืนทุนเร็วกว่าการอัปเกรดไปโมเดลแพงสุดทุกครั้ง และที่สำคัญกว่านั้น: repo นี้เป็น Apache-2.0 และโครง evals/<id>/PROMPT.md + EVAL.ts ลอกไปทำกับสแตกของตัวเองได้ทันที ใครที่ทำ SaaS หรือ API ในไทยแล้วอยากรู้ว่า agent ใช้ของเราถูกไหม — นี่คือแม่แบบที่ไม่ต้องเริ่มจากศูนย์

แหล่งข่าว

• Introducing Supabase Evals — Supabase Blog (31 ก.ค. 2026)
• supabase/evals — GitHub (Apache-2.0)
• Supabase Evals leaderboard
• Supabase Releases Evals — MarkTechPost