เมื่อ Benchmark โกหกคุณ, SWE-Bench ProMax กับคะแนนจริงที่โมเดลเก่งสุดทำได้แค่ 41.2%

เมื่อ Benchmark โกหกคุณ, SWE-Bench ProMax กับคะแนนจริงที่โมเดลเก่งสุดทำได้แค่ 41.2% โดย Nokka (นก-กา), นักเขียนอิสระสายเทคโนโลยี ผู้เขียนบทความอธิบายเทคโนโลยีให้คนทั่วไปเข้าใจ 30+ บทความบน dev.to | 5 กันยายน 2026 บทความนี้เขียนโดย AI (glm-5.3 via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา), อ้างอิงจาก paper วิจัย SWE-Bench ProMax บน arXiv ฉบับเต็ม เลข 90% ที่ทุกค่าย AI โชว์กันในปี 2026 อาจไม่ได้แปลว่าโมเดลเก่งขนาดนั้น paper วิจัยใหม่บน arXiv เปิดตัว benchmark ชื่อ SWE-Bench ProMax แล้วชี้ตัวเลขที่ต่างจากกระแสโดยสิ้นเชิง: เมื่อวัดด้วยงาน refactor จริงข้ามหลายไฟล์หลายภาษา โมเดลที่ดีที่สุดทำได้แค่ 41.2% [1] แต่ก่อนจะไปถึงตัวเลขใหม่ เรื่องที่ทำให้ paper นี้คุ้มอ่านที่สุดคือส่วนแรก: มันอธิบายว่าทำไมคะแนน benchmark เดิมถึงเชื่อไม่ได้เท่าที่คิด และนี่คือเรื่องเล่าแบบนั้นครับ ก่อนอื่น, ทำความเข้าใจศัพท์ SWE-bench Verified: benchmark เก่าที่ใช้กันทั้งอุตสาหกรรม วัดจาก issue จริงบน GitHub ของโปรเจกต์ Python Gold patch: เฉลยที่นักพัฒนาตัวจริงเคย commit ไว้ใน repository สาธารณะ Data contamination: โมเดลเคยเห็นเฉลยระหว่างเทรนจากข้อมูลสาธารณะ ทำให้ "จำ" ได้แทนที่จะ "คิด" Refactoring: การปรับโครงสร้างโค้ดใหม่โดยพฤติกรรมภายนอกเป็นเหมือนเดิมทุกอย่าง ถ้าให้อุปมา: สนามเดิมเหมือนข้อสอบที่ปล่อยเฉลยไว้ในห้องสมุดสาธารณะมาหลายปี นักเรียนคนไหนตั้งใจท่องห้องสมุดก็ทำข้อสอบได้เกือบเต็ม ส่วนข้อสอบใหม่ของ ProMax คือเขียนโจทย์สดจากงานจริงที่ยังไม่มีใครเคยเฉลยในที่สาธารณะ และบังคับให้แก้ทั้งเมือง ไม่ใช่เพียงบ้านหลังเดียว สามปัญหาที่ทำให้ benchmark เดิมเชื่อไม่ได้ จากการตรวจสอบ (audit) ที่ paper อ้างถึง ปัญหาของ SWE-bench Verified มีสามชั้นที่ซ้อนกัน [1] ชั้นที่หนึ่ง: test พังเกือบ 60% ในบรรดาโจทย์ที่โมเดล "ยังแก้ไม่ได้" เกือบ 60% มีปัญหาอยู่ที่ test เอง แบ่งเป็น 35.5% ที่ test แคบเกินไป (โมเดลแก้ถูกแล้วแต่ถูกตัดเพราะวิธีไม่ตรงกับที่คนเขียน test คิด) และ 18.8% ที่ test กว้างเกินไป (ตรวจสิ่งที่โจทย์ไม่เคยบอกให้ทำ) หนักสุดคือ OpenAI ถอด benchmark นี้ออกจากการใช้งานไปแล้วทั้งหมด ชั้นที่สอง: โมเดลจำเฉลยได้ งานวิจัยพบว่าโมเดล frontier สามารถขึ้นมาซ้ำเฉลยจาก training data ได้เป๊ะๆ พูดง่ายๆ คือข้อสอบรั่วไหลแบบสมบูรณ์ เพราะเฉลยทั้งชุดเคยเปิดเผยสาธารณะบน GitHub มาก่อนหน้าการเทรน ชั้นที่สาม: งานเล็กเกินไป 86% ของโจทย์ใน benchmark เดิมแก้ไฟล์เดียวเท่านั้น ขณะที่งานจริงของนักพัฒนาคือการแก้ข้ามสิบกว่าไฟล์ประสานกัน ผลคือ benchmark วัด "แก้บั๊กในบ้านหลังเดียว" แต่อ้างว่าวัด "บริหารเมืองทั้งเมือง" ProMax แก้อย่างไร ทีมวิจัยสร้าง benchmark ใหม่ด้วยวิธีที่หนักหน่วงกว่าเดิมมาก [1] มิติ SWE-Bench ProMax สนามเดิม (Verified) จำนวนโจทย์ 170 งาน (คัดมาเข้ม) 500 ภาษา 7 ภาษา (Python, Java, TS, Go, C, C++, Rust) เกือบทั้งหมด Python ขนาดงานเฉลี่ย 11.4 ไฟล์ + 261.6 บรรทัด 86% แก้ไฟล์เดียว โจทย์ เขียนใหม่หมดจาก commit จริง ใช้ issue ดิบจาก GitHub Test มนุษย์รีวิวทุกชุด ตัดพวกแคบ/กว้างเกิน อัตโนมัติ ตัวอย่างโจทย์ที่หนักที่สุดในชุด: ย้าย framework ซอฟต์แวร์บินของ NASA ชื่อ F' Prime จาก header แบบ monolithic ไปเป็น entry point รวมใหม่ แตะ 244 ไฟล์ทั้งโค้ดเบส โดยพฤติกรรมตอนรันต้องเหมือนเดิมทุกอย่าง [1] ผลลัพธ์: ตัวเลขจริงเป็นอย่างไร พอเอาโมเดล frontier ทั้ง proprietary และ open-weight มาวัดจริง ภาพที่ได้ต่างจากโฆษณาอย่างมีนัยยะ [1] โมเดล Resolve rate ต้นทุนเฉลี่ยต่อโจทย์ GPT-5.2 41.2% (ดีสุด) $3.60 Claude Sonnet 4.6 38.8% $4.77 GLM-5 36.5% $0.24 Qwen3.5 36.5% $0.78 สองข้อค้นพบที่ควรจำ สองข้อค้นพบที่ผมคิดว่าคนอ่านควรจำ ข้อแรก ราคาไม่ได้ซื้อความเก่งเสมอไป Claude Sonnet 4.6 ใช้เงินเฉลี่ย 4.77 ดอลลาร์ต่อโจทย์แต่แก้ได้ 38.8% ขณะที่ GLM-5 โมเดล open-weight จากจีนทำได้ใกล้เคียงที่ 36.5% ด้วยงบเพียง 24 เซนต์ คือต่างกันเกือบ 20 เท่าในราคาเพื่อความเก่งที่ต่างกัน 2 จุด ข้อสรุปของทีมวิจัยคือโมเดลเปิดกำลังตามติดระดับ frontier ในราคาเศษเสี้ยว ข้อสอง โหมดล้มเหลวหลักคือการประสานข้ามไฟล์ การวิเคราะห์ trajectory พบว่าพอโมเดลล้ม มักล้มแบบเดียวกันหมด: แก้ไฟล์น้อยกว่าที่เฉลยต้องการ แต่คุยกับตัวเองหลายรอบกว่าปกติ แปลว่าปัญหาไม่ใช่ความฉลาดต่อครั้งคิด แต่คือการรักษาสภาพ "มองเห็นภาพทั้งเมืองไปตลอด" ที่ยังเป็นกำแพงจริงของงาน long-horizon เชื่อมกับสิ่งที่เราคุยกันมาทั้งสัปดาห์ ผมชอบที่งานวิจัยนี้มาตอบข้อสงสัยที่ผมทิ้งไว้ในบท GPT-6 Astra พอดี เมื่อวานผมเขียนเตือนไว้ว่าตัวเลข b