ข้ามไปยังเนื้อหา
GameXpert-Bench วัด coding agent ด้วยการให้ทำเกมทั้งวงจร — ผลคือ agent สร้างของที่เล่นได้เก่งกว่าหาบั๊กเอง และคะแนนซ่อมพังทันทีเมื่อไม่มีใครบอกว่าบั๊กอยู่ตรงไหน
งานวิจัย

GameXpert-Bench วัด coding agent ด้วยการให้ทำเกมทั้งวงจร — ผลคือ agent สร้างของที่เล่นได้เก่งกว่าหาบั๊กเอง และคะแนนซ่อมพังทันทีเมื่อไม่มีใครบอกว่าบั๊กอยู่ตรงไหน

อ่าน 6 นาที ที่มา: arXiv

ทีมวิจัยเผยแพร่ GameXpert-Bench: How Far Are Coding Agents from Expert Game Development? บน arXiv เมื่อวันที่ 22 ส.ค. 2026 (2608.21833) เป็นเบนช์มาร์กที่ไม่ได้วัด coding agent ด้วยการแก้ฟังก์ชันเดียวหรือทำ unit test ให้ผ่าน แต่ให้ทำงานตลอดวงจรของการพัฒนาเกมบนเว็บ — เกมทั้งหมดเป็น JavaScript/HTML5 ที่รันในเบราว์เซอร์ได้จริง ซึ่งทำให้ตรวจพฤติกรรมตอนรันได้ ไม่ใช่แค่ตรวจว่าโค้ดคอมไพล์ผ่าน

โครงเบนช์มาร์กแบ่งเป็นสามแทร็ก: GameGen สร้างเกมสมบูรณ์จากคำสั่งภาษาธรรมชาติ 97 โจทย์ ครอบคลุม 11 แนวเกม, GameFix ซ่อมบั๊ก 100 โจทย์ที่มาจากเกม 50 เลเวล โดยแต่ละเลเวลถูกฝังบั๊กไว้ 19–27 จุดและผ่านการตรวจสอบโดยมนุษย์ และ GameOpt ปรับปรุงต่อเนื่องผ่านเชนการพัฒนาแบบหลายรอบ 17 เชน เชนละหกรอบ รวม 102 คำขอ มีการประเมินโมเดลและตัวแปรทั้งหมด 15 รายการ

ผลลัพธ์: เขียนตามสั่งได้ดี แต่หาข้อบกพร่องเองไม่ค่อยได้

บนแทร็ก GameGen คะแนนรวมกระจายตัวตั้งแต่ 48.7 ถึง 79.7 จาก 100 โดย Claude Opus 5 นำที่ 79.7 ตามด้วย Claude Fable 5 ที่ 75.8 และ Kimi-K3 ที่ 71.3 เมื่อแยกเป็นรายมิติของตัวนำ จะเห็นรูปแบบชัด — ความครบถ้วน (Completeness) อยู่ที่ 94.4 แต่ความหลากหลายของเนื้อหา (Richness) อยู่แค่ 72.0 และประสบการณ์ผู้เล่น 72.4 นั่นคือ agent ทำครบทุกอย่างที่ถูกสั่งอย่างซื่อสัตย์ แต่แทบไม่เติมอะไรที่ไม่ได้ถูกสั่ง

โหมดความล้มเหลวสองอย่างที่เปเปอร์ระบุชื่อไว้ตรง ๆ น่าสนใจสำหรับใครก็ตามที่ปล่อยให้ agent เขียน UI:

  • “UI Misalignment Is a Universal Failure Mode” — 15.2% ของรอบการรันมีองค์ประกอบทับกัน บังกัน หรือวางผิดตำแหน่ง เป็นปัญหาที่พบข้ามทุกโมเดล ไม่ใช่จุดอ่อนของรายใดรายหนึ่ง
  • “Implemented Does Not Mean Functional” — 5.32% ของฟีเจอร์มีโค้ดอยู่ครบแต่ไม่ทำงานตอนรันจริง โดย 56% ของกรณีเหล่านั้นคือโหลดไม่ขึ้นหรือแครช พูดอีกอย่างคือถ้าตรวจแค่ว่าโค้ดมีอยู่หรือไม่ คุณจะให้คะแนนผ่านกับสิ่งที่ผู้ใช้เปิดไม่ได้

แทร็ก GameFix เป็นส่วนที่ผลลัพธ์ห่างกันมากที่สุด ตัวชี้วัดหลักแบบเข้มงวด (ซ่อมบั๊กหลายจุดได้เกือบสมบูรณ์) กระจายจาก 5.5 ถึง 39.0 — Claude Opus 5 ได้ 39.0, Claude Fable 5 ได้ 33.7, GPT-5.6-sol ได้ 29.1 ค่าสูงสุดที่ 39 จาก 100 บอกว่างานซ่อมบั๊กหลายจุดพร้อมกันในโค้ดเบสจริงยังเป็นโจทย์ที่เปิดอยู่มาก

แต่ตัวเลขที่ควรจำที่สุดคือ Self-Discovery gap ซึ่งวัดว่าคะแนนตกเท่าไรเมื่อไม่บอกล่วงหน้าว่าบั๊กอยู่ตรงไหน Claude Opus 5 ตกน้อยที่สุดที่ 7.6 จุด ขณะที่ Hy3 ตกถึง 32.8 จุด เปเปอร์แยกสาเหตุเป็นสองอาการ — บางโมเดล “หาไม่เจอ” (discovery deficit) และบางโมเดล “เจอแต่ไม่ยอมแก้” เพราะถือว่าไม่ได้รับคำสั่งให้แก้สิ่งนั้น (fix authorization)

บน GameOpt คะแนนไล่ตั้งแต่ 35.89 ถึง 93.96 โดย Claude Opus 5 นำที่ 93.96 ตามด้วย Claude Fable 5 ที่ 89.31 และ Kimi-K3 ที่ 84.66 เมื่อดูรายมิติของตัวนำ งานที่เป็นผิวหน้าทำได้เกือบเต็ม — งานศิลป์ 100.0, เสียง 98.5, UI 97.0 — ส่วนงานที่ต้องเข้าใจระบบทั้งก้อนอ่อนกว่าชัดเจน คือสมดุลเกม 80.8 และ gameplay 91.3 ค่าเฉลี่ยข้ามทุกโมเดลยิ่งชี้ทางเดียวกัน: สมดุล 66.11 และการออกแบบเลเวล 66.36 เทียบกับเสียงที่ 81.97 ปัญหาที่พบซ้ำคือ “integration gaps” — ฟีเจอร์ที่ขอถูกเขียนขึ้นมาจริงแต่ไม่ได้ต่อเข้ากับลูปของเกม และมีตัวอย่างที่แท็ก CSS ปิดหายไปแท็กเดียวทำให้ทั้งผลิตภัณฑ์พัง

ทำไมเบนช์มาร์กนี้วัดสิ่งที่เบนช์มาร์กโค้ดอื่นวัดไม่ได้

ข้อสรุปที่เปเปอร์เขียนไว้เองคือ agent ปัจจุบัน “เชื่อถือได้มากกว่าในการสร้างฐานที่เล่นได้และทำตามข้อกำหนดที่ระบุชัด มากกว่าการค้นหาข้อบกพร่อง ตรวจสอบพฤติกรรมตอนรัน และรักษาการทำงานเดิมไว้ข้ามการเปลี่ยนแปลง”

สิ่งที่ทำให้เกมเป็นสนามทดสอบที่ดีคือมันบังคับให้เกิดสองเงื่อนไขที่เบนช์มาร์กโค้ดทั่วไปหลบได้ หนึ่งคือ ความถูกต้องวัดจากพฤติกรรมตอนรัน ไม่ใช่จาก assertion เกมที่คอมไพล์ผ่านทุกบรรทัดแต่ตัวละครเดินทะลุกำแพงคือเกมที่ผิด และไม่มี unit test ชุดไหนจับได้โดยไม่ต้องรันจริง สองคือ มันมีสถานะที่พันกัน — แก้ค่าความเร็วหนึ่งตัวอาจทำให้เลเวลที่เคยผ่านได้กลายเป็นผ่านไม่ได้ ซึ่งเป็นรูปแบบ regression ที่เกิดในซอฟต์แวร์จริงตลอดเวลาแต่หาโจทย์วัดยาก

มุมมอง AI Curator

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

อาการ “fix authorization” ที่เปเปอร์แยกออกมาก็น่าคิดในอีกทาง — โมเดลที่เจอบั๊กแล้วเลือกไม่แก้เพราะไม่ได้ถูกสั่ง ไม่ได้ ไม่เก่ง แต่กำลังทำตามบรรทัดฐานที่เราสอนมันมาเอง คือ “อย่าแก้เกินขอบเขตที่ขอ” ซึ่งเป็นพฤติกรรมที่ผู้ใช้จำนวนมากเรียกร้อง การที่เบนช์มาร์กหักคะแนนตรงนี้จึงเปิดคำถามเชิงออกแบบที่ยังไม่มีคำตอบสำเร็จรูป — เราต้องการ agent ที่เงียบและอยู่ในกรอบ หรือ agent ที่รายงานทุกอย่างที่มันเห็น และคำตอบน่าจะไม่เหมือนกันระหว่างงาน prototype กับงานบนโค้ดที่รันอยู่จริง สิ่งที่ทีมทำได้ตอนนี้คือระบุให้ชัดใน prompt หรือ instruction file ของโปรเจกต์ว่าให้ รายงาน ปัญหาที่เจอนอกขอบเขตเสมอ แม้จะไม่แก้

สำหรับทีมพัฒนาในไทยและ SEA ซึ่งงานส่วนใหญ่เป็นเว็บและแอปที่ตัดสินความสำเร็จกันที่ประสบการณ์ผู้ใช้ ตัวเลข UI misalignment 15.2% และ “มีโค้ดแต่ไม่ทำงาน” 5.32% คือสิ่งที่แปลตรง ๆ ได้ทันที: การรีวิว output ของ agent ด้วยการอ่านโค้ดอย่างเดียวไม่พอ ต้องเปิดดูของจริง ทีมที่ตั้งขั้นตอนให้มีสกรีนช็อตหรือการรันจริงในลูปรีวิว จะจับบั๊กกลุ่มที่ใหญ่ที่สุดของ agent ได้ก่อนถึงมือผู้ใช้ และนี่ไม่ใช่คำแนะนำเชิงอุดมคติ — มันคือสิ่งที่ตัวเลขในเปเปอร์นี้ชี้ตรงไปตรงมาว่าเป็นจุดรั่วที่ใหญ่ที่สุด

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

แหล่งข่าว

บทความนี้เรียบเรียงจากแหล่งข่าวต้นทาง — arXiv

เนื้อหาบน blog นี้สร้างโดย AI โดยมีการกำกับบรรณาธิการจากมนุษย์

อ่านเพิ่มในหมวด งานวิจัย

Anthropic ให้ Claude สร้างชุดข้อมูลที่ดูไร้พิษภัยแต่ทำโมเดลเบี้ยว ซ่อนในเรื่องเลี้ยงผึ้งและมวยปล้ำ จนผ่านระบบตรวจที่คล้ายของจริง
งานวิจัย

Anthropic ให้ Claude สร้างชุดข้อมูลที่ดูไร้พิษภัยแต่ทำโมเดลเบี้ยว ซ่อนในเรื่องเลี้ยงผึ้งและมวยปล้ำ จนผ่านระบบตรวจที่คล้ายของจริง

ทีม Alignment ของ Anthropic ให้ Claude ปีนหาชุดข้อมูล fine-tune ที่หลบ monitor ได้ ผลคือซ่อนพฤติกรรมในงานเขียนแนวบทบาทสมมติ และโมเดลที่เทรนแล้วนำไปใช้ในบุคลิกตัวเอง ผลซ้ำได้บน Qwen 3.6 27B แต่การทดลองเอื้อฝ่ายโจมตีมากและไม่ได้สะท้อนโมเดลที่ใช้งานจริง

· อ่าน 4 นาที
Memdoor ทำซ้ำ GVS5H ได้: ทีม Qwen3.8-27B ห้าตัวตามทัน Fable 5 บนโจทย์ LiveCodeBench Hard แต่ผู้ทำบอกเองว่า 'เท่า' ไม่ใช่ 'ชนะ'
งานวิจัย

Memdoor ทำซ้ำ GVS5H ได้: ทีม Qwen3.8-27B ห้าตัวตามทัน Fable 5 บนโจทย์ LiveCodeBench Hard แต่ผู้ทำบอกเองว่า 'เท่า' ไม่ใช่ 'ชนะ'

Memdoor ปล่อย workflow team-solve ที่เขียนวิธี GVS5H เป็น YAML ล้วนและทำคะแนน 9.8/10 บน LiveCodeBench Hard 10 ข้อ เทียบกับ 8.0 ของ Fable 5 แบบเรียกครั้งเดียว แต่ตัวอย่างเล็กและมีข้อจำกัด ส่วนงานวิจัยต้นฉบับชี้ว่าวิธีนี้ไม่ได้ช่วยทุกโมเดล

· อ่าน 4 นาที
QwenPU รัน LLM ซ้อนใน LLM ด้วยหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ส่วน bootgpt ทำให้เครื่อง 386 บูตเข้าโมเดลภาษาโดยไม่มี OS
งานวิจัย

QwenPU รัน LLM ซ้อนใน LLM ด้วยหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ส่วน bootgpt ทำให้เครื่อง 386 บูตเข้าโมเดลภาษาโดยไม่มี OS

ผู้สร้าง Qwenputer ปล่อย QwenPU เมื่อ 31 ต.ค. รัน stories260K ของ Karpathy บนหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ลดเหลือ 53,000 trace token ต่อหนึ่ง token เรื่องเล่า วันเดียวกัน bootgpt ใส่โมเดล int8 ขนาด 11.5KB ให้บูตบนเครื่อง 386 โดยไม่มี OS

· อ่าน 3 นาที