SWE-Gate: แพตช์ 644 ชิ้นที่ผ่านเทสต์ มี 221 ชิ้นที่รีวิวเวอร์จะตีกลับ — และการบอกกฎให้เอเจนต์รู้ล่วงหน้า ทำให้มันซ่อมบั๊กได้แย่ลง

ทุกคนที่ใช้เอเจนต์เขียนโค้ดในงานจริงเจอสถานการณ์นี้: เอเจนต์แก้บั๊กได้ เทสต์เขียว แล้วรีวิวเวอร์ตีกลับ เพราะมันไปเปลี่ยน public interface, ทิ้ง exception semantics เดิม, หรือไม่ทำตามคอนเวนชันของรีโป เบนช์มาร์กอย่าง SWE-Bench วัดแค่ครึ่งแรกของเรื่องนี้ — patch ผ่าน functional test ก็ถือว่าสำเร็จ

เปเปอร์ arXiv:2609.04167 ที่ส่งเมื่อ 3 ก.ย. 2026 17:53 UTC โดยทีมจาก School of Software Engineering มหาวิทยาลัยซุนยัตเซ็น ร่วมกับ Zhejiang University และ Chongqing University เสนอ SWE-Gate ซึ่งเป็นเบนช์มาร์กระดับรีโปตัวแรกที่แยกวัดสองมิตินี้ออกจากกันด้วยเทสต์ที่รันได้จริงคนละชุด และตัวเลขที่ได้ก็ตรงกับความรู้สึกของคนใช้งานจริงพอดี

221 จาก 644 — “ความล้มเหลวที่ซ่อนอยู่”

SWE-Gate สร้างเงื่อนไข (เรียกว่า review constraint หรือ gate) จากคอมเมนต์รีวิว pull request จริง แล้วสังเคราะห์เคสซ่อมโค้ดรอบเงื่อนไขนั้น ได้ 303 เคสจาก 75 รีโป Python ใน 6 โดเมน แต่ละเคสมาพร้อม เทสต์สองชุดแยกกัน (functional test กับ constraint test), แพตช์ที่ไม่ผ่านเงื่อนไข (ผ่านเทสต์การทำงานแต่ละเมิดเงื่อนไข) และ gold patch ที่ผ่านทั้งคู่

ตัวอย่างที่เปเปอร์ยกมาคือ PR จริงของ Pydantic ที่ขอเพิ่ม conditional serialization ให้ extra fields — implementation แรกทำงานได้ตามที่ขอ แต่รีวิวเวอร์ทักว่าการเปลี่ยน core-schema แบบนั้นคือ breaking change และแนะให้เพิ่มพารามิเตอร์ extras_ser_exclude_if แทน functional test ถามว่า field ที่เข้าเงื่อนไขถูกตัดออกจากผลลัพธ์ไหม ส่วน compatibility test ถามว่า public schema เดิมยังใช้ได้อยู่ไหม — แพตช์ผ่านข้อแรกแต่ตกข้อสองได้สบาย ๆ

ทีมรันสี่โมเดลบนสแคฟโฟลด์เดียวกัน (Mini-SWE-Agent สูงสุด 100 interaction step) โดยยื่นเงื่อนไขเป็นภาษาธรรมชาติให้อ่านด้วย:

โมเดล	ผ่านเทสต์การทำงาน	ผ่านทั้งสองชุด	FSR	CFR	JSR
GPT-5.5	227	160	74.9%	70.5%	52.8%
DeepSeek-V4-Flash	202	130	66.7%	64.4%	42.9%
GPT-5.4-mini	187	120	61.7%	64.2%	39.6%
GPT-4o-mini	28	13	9.2%	46.4%	4.3%

FSR = สัดส่วนเคสที่ซ่อมบั๊กสำเร็จ, CFR = สัดส่วนของแพตช์ที่ซ่อมสำเร็จแล้วยังทำตามเงื่อนไขด้วย, JSR = สัดส่วนเคสที่ผ่านทั้งสองอย่าง

รวมทั้งสี่โมเดล แพตช์ 644 ชิ้นผ่าน functional test แต่ผ่านทั้งสองชุดแค่ 423 ชิ้น เหลือ 221 ชิ้นเป็น hidden failure คิดเป็น 34.3% — คือหนึ่งในสามของ “ความสำเร็จ” ที่เบนช์มาร์กแบบเดิมจะนับให้ เป็นแพตช์ที่รีวิวเวอร์จะไม่รับ อัตรานี้ไล่จาก 29.5% ของ GPT-5.5 ไปถึง 53.6% ของ GPT-4o-mini คือ ยิ่งโมเดลอ่อน สัดส่วนความสำเร็จปลอมยิ่งสูง

ผลที่ควรอ่านซ้ำสองรอบ: บอกกฎแล้วซ่อมบั๊กแย่ลง

ส่วนที่น่าสนใจที่สุดของเปเปอร์ไม่ใช่ตารางข้างบน แต่คือ ablation ที่เปรียบเทียบสองเงื่อนไขการทดลอง: +C คือยื่นเงื่อนไขรีวิวเป็นภาษาธรรมชาติให้เอเจนต์อ่าน -C คือไม่ยื่น (เทสต์ที่ซ่อนไว้เหมือนกันเป๊ะทั้งสองกรณี)

โมเดล	FSR (−C → +C)	CFR (−C → +C)	JSR (−C → +C)
GPT-5.5	75.6 → 74.9 (−0.7)	54.6 → 70.5 (+15.9)	41.3 → 52.8 (+11.5)
GPT-5.4-mini	71.6 → 61.7 (−9.9)	50.7 → 64.2 (+13.5)	36.3 → 39.6 (+3.3)
DeepSeek-V4-Flash	70.0 → 66.7 (−3.3)	54.2 → 64.4 (+10.2)	38.0 → 42.9 (+4.9)
GPT-4o-mini	15.8 → 9.2 (−6.6)	20.8 → 46.4 (+25.6)	3.3 → 4.3 (+1.0)

การยื่นเงื่อนไขให้อ่านทำให้ CFR ดีขึ้นทุกโมเดล (บวก 10.2–25.6 จุด) และ JSR ดีขึ้นทุกโมเดล — แต่ FSR ลดลงทุกโมเดล โดยเฉพาะ GPT-5.4-mini ที่ร่วงเกือบ 10 จุด เปเปอร์อธิบายว่าเงื่อนไขเพิ่มความซับซ้อนของการซ่อม และอาจดึงเอเจนต์ออกจากแพตช์ง่าย ๆ ที่แก้บั๊กได้อยู่แล้ว

พูดเป็นภาษาคนทำงาน: การเขียน CLAUDE.md / AGENTS.md ที่ระบุคอนเวนชันของทีมไว้ครบ ไม่ใช่ของฟรี มันซื้อความเข้ากันได้กับรีวิวมา ด้วยการจ่ายอัตราซ่อมบั๊กสำเร็จออกไป และเปเปอร์ก็ระมัดระวังในจุดนี้ — ระบุเองว่าแต่ละเงื่อนไขรัน หนึ่ง generation ต่อโมเดลต่อเคส จึงควรอ่านเป็น “trade-off ที่สังเกตได้” ไม่ใช่ข้อสรุปเชิงสาเหตุ

เงื่อนไขประเภทไหนที่โมเดลทำไม่ได้

ตารางแยกตามประเภทเงื่อนไข (ซ้อนทับกันได้ ไม่ใช่กลุ่มที่แยกขาด) ชี้กลุ่มที่ยากชัดเจน: Scope generalization (62 เคส) ทำให้ CFR ของสามโมเดลแรกร่วงมาที่ 63.0%, 46.3% และ 53.5% ส่วน Lifecycle cleanup / resource (19 เคส) อยู่ที่ 62.5%, 53.8% และ 57.1% เปเปอร์อธิบายว่าเงื่อนไขสองกลุ่มนี้ต้องการความครอบคลุมเกินจุดที่พังจริง หรือต้องรักษาสภาพตลอดวงจรชีวิตของทรัพยากร — ซึ่งแพตช์ที่ “แก้เฉพาะจุด” ทำไม่ได้ตามนิยาม

กลุ่ม Encoding / escaping / quoting (74 เคส) เป็นอีกจุดอ่อน โดย GPT-5.4-mini และ DeepSeek-V4-Flash ทำได้ 51.1% และ 55.9% เท่านั้น ส่วนกลุ่มที่ใหญ่ที่สุดคือ Error semantics (152 เคส) และ Schema / metadata / typing (143 เคส)

ชุดข้อมูล โค้ด และผลการทดลองทั้งหมดอยู่ที่ github.com/DeepSoftwareAnalytics/SWE-Gate

มุมมอง AI Curator

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

รายชื่อโมเดลก็ควรอ่านด้วยความระวัง — GPT-5.5, GPT-5.4-mini, DeepSeek-V4-Flash และ GPT-4o-mini ไม่มีตัวไหนเป็นแนวหน้าของวันนี้ ไม่มี Opus 5, Fable 5.1 หรือ GPT-6 Astra ในตาราง เปเปอร์นี้จึงอธิบาย สแคฟโฟลด์ ได้ดี แต่อธิบาย สถานะปัจจุบันของโมเดล ไม่ได้ และการที่ GPT-4o-mini ถูกใส่มาเป็นพื้นก็ดันค่าเฉลี่ยรวม 34.3% ให้สูงกว่าที่โมเดลชั้นนำทำจริง (29.5%)

แต่ข้อค้นพบที่ผมคิดว่าอยู่ได้นานที่สุดคือ trade-off ระหว่าง FSR กับ CFR ไม่ใช่ตัวเลข 34.3% เพราะมันขัดกับสัญชาตญาณของทุกทีมที่กำลังเขียนไฟล์กฎยาว ๆ ให้เอเจนต์อ่านอยู่ตอนนี้ สมมติฐานที่ทุกคนถืออยู่คือ “บอกกฎเพิ่ม = ได้ผลลัพธ์ดีขึ้น” แต่ข้อมูลชุดนี้บอกว่ามันคือ การจัดสรรความสนใจใหม่ — เอเจนต์ที่ต้องแบกเงื่อนไขเพิ่มอาจแก้บั๊กไม่จบ ซึ่งเข้ากันได้พอดีกับสิ่งที่เราเขียนถึงเมื่อเช้าว่า OpenAI เองแนะนำให้ ตรวจสอบไฟล์ที่โมเดลเข้าถึงได้ เพราะ GPT-6 Astra ไวต่อ SKILL.md และ AGENTS.md มาก — ความไวนั้นมีสองด้าน และเปเปอร์นี้วัดด้านที่แพงให้เห็นเป็นตัวเลข

สำหรับทีมไทยที่กำลังตั้งกระบวนการรีวิวโค้ดที่มีเอเจนต์อยู่ในลูป ข้อเสนอที่ปฏิบัติได้จากเปเปอร์นี้มีสองข้อ หนึ่ง — แยกเทสต์คอนเวนชันออกจากเทสต์ฟีเจอร์ ให้เป็นสวีตคนละชุดใน CI ถ้าทีมคุณมีกฎว่า “ห้ามเปลี่ยน public schema” หรือ “ต้อง cleanup resource เสมอ” ให้เขียนเป็นเทสต์ที่รันได้ ไม่ใช่ประโยคใน CONTRIBUTING.md เพราะเอเจนต์อ่านประโยคแล้วยังพลาด 29.5% แต่เทสต์ที่แดงมันเห็นทันที สอง — อย่ายัดกฎทั้งหมดเข้าไปในพรอมต์เดียว ผลของ ablation ชี้ว่าเงื่อนไขที่เกี่ยวข้องกับงานตรงหน้าเท่านั้นที่คุ้ม การโหลดคอนเวนชันทั้งองค์กรใส่ทุกคำขอมีต้นทุนเป็นอัตราซ่อมบั๊กที่ลดลง

ท้ายที่สุด SWE-Gate เป็นเบนช์มาร์กที่สมควรถูกเลียนแบบมากกว่าถูกอ้าง — ไอเดียของการมี เทสต์สองชุดที่รันแยกกัน สำหรับ “มันทำงานไหม” กับ “มันยอมรับได้ไหม” ควรอยู่ในไปป์ไลน์ของทุกทีมที่ให้เอเจนต์เปิด PR ได้เอง ไม่ว่าจะอ่านเปเปอร์นี้หรือไม่

แหล่งข่าว

• SWE-Gate: Passing Functional Tests Is Not Enough for Software Engineering Agents — arXiv:2609.04167 (3 ก.ย. 2026)
• ฉบับ HTML เต็ม พร้อมตาราง 2–5
• Replication package: โค้ด ข้อมูล และผลการทดลอง (GitHub)