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

กระทู้ Hacker News เมื่อ 31 ต.ค. 2026 พาดหัวว่าทีม Qwen3.8-27B ห้าตัว “ชนะ” Claude Fable 5 บน LiveCodeBench Hard ต้นทางคือ workflow ชื่อ team-solve ของ Memdoor เอเจนต์ CLI ใบอนุญาต Apache-2.0 ซึ่งเขียนวิธีจากงานวิจัย GVS5H ใหม่เป็น YAML แปดไฟล์ ไม่มีโค้ดและไม่ระบุชื่อโมเดล

ผลการทำซ้ำน่าสนใจจริง แต่พาดหัวไปไกลกว่าข้อมูล README ของ Memdoor เองเขียนว่าสิ่งที่อ้างคือ “ความเท่าเทียมกับ harness ของผู้วิจัย” ไม่ใช่การเหนือกว่า บล็อกนี้ยังไม่เคยเขียนถึง GVS5H ซึ่งออกตั้งแต่สิงหาคมและขึ้นอันดับหนึ่งบน Hacker News เมื่อ 25 ต.ค. จึงสรุปงานต้นฉบับไว้ด้วย

ผลที่ได้

Memdoor ใช้โจทย์ 10 ข้อแรกของชุด LiveCodeBench Hard ในงานวิจัย ทำ 5 รอบ และตรวจด้วย hidden test ทั้งหมด

รอบ	team-solve	harness ผู้วิจัย	Fable 5 เรียกครั้งเดียว
1	10	9	7
2	10	10	8
3	10	10	10
4	10	9	8
5	9	10	7
เฉลี่ย	9.8	9.6	8.0

ทั้ง 50 รอบใช้เงินรวม $35.79 ค่ากลางอยู่ที่ราว 40 นาทีและ $0.39 ต่อการแก้หนึ่งโจทย์ ทุกคำขอและคำตอบถูกเก็บไว้ใน repo

ข้อจำกัดที่ README ระบุเองมีน้ำหนักมาก ตัวอย่างมีแค่ 10 ข้อ ทำให้ 9.8 กับ 9.6 นับเป็นตัวเลขเดียวกัน คอลัมน์ Fable 5 มาจากไฟล์ของผู้วิจัยแบบเรียกครั้งเดียว ไม่ได้รันใน harness นี้ โจทย์มาจากการแข่งขันช่วงต้นปี 2025 ซึ่งโมเดลอาจเคยเห็นตอนเทรน และโมเดลรันบน OpenRouter ไม่ใช่เครื่อง local

งาน GVS5H ต้นฉบับ

งานวิจัย arXiv 2608.26480 จาก Persis Capital (ส่ง 27 ส.ค. แก้ไข 21 ก.ย.) เสนอให้อินสแตนซ์ใหม่ของโมเดลตัวเดียวกันแบ่งงานกันผ่านไฟล์บนดิสก์ ที่เก็บแผน บันทึก และคำตอบล่าสุด โดยแต่ละตัวเริ่มจาก context ว่างและไม่ต้องเทรนเพิ่ม บนโจทย์ 100 ข้อ ผลหลักคือ

• Qwen3.8-27B ขยับจาก 66.8% เป็น 92.4% เทียบกับ Fable 5 ที่ 90.4% (ความต่าง +2.0 ไม่มีนัยสำคัญ p = 0.88)
• Qwen3.8 Flash Next ได้ 93.0% ด้วยต้นทุนราว 9% ของ Fable 5
• GPT-5.6-Luna ขยับจาก 70.4% เป็น 81.2% แต่ยังต่ำกว่า Fable 5 อยู่ 9.2 จุดอย่างมีนัยสำคัญ

บทคัดย่อยอมรับตรง ๆ ว่าวิธีนี้ไม่ได้ช่วยทุกตัว บางโมเดลเท่าเดิมหรือแย่ลง

จุดที่ทีมยังพลาด

บันทึกของ Memdoor เล่าความล้มเหลวที่มีประโยชน์กว่าตัวเลข ในข้อที่เสียไป manager สร้างตัวอย่างค้านที่ผิดขึ้นมา ทีมเลยเขียนทับโปรแกรมที่ถูกอยู่แล้ว และอีกกรณีโปรแกรมที่ผ่านทุก hidden test ถูกเขียนทับในรอบถัดไปเพราะ manager ไม่ยอมสั่งจบ ปัญหาทั้งสองมาจากลูปเดิมของผู้วิจัยที่ตั้งใจคงไว้เพื่อให้เทียบกันได้ อีกบทเรียนคือข้อความโจทย์สำคัญมาก เวอร์ชันแรกที่เขียน task file เองวางแผนได้แย่กว่าการใช้ข้อความต้นฉบับ

มุมมอง AI Curator

ใจความจริงของเรื่องนี้ไม่ใช่ “โมเดลเล็กชนะโมเดลใหญ่” แต่คือ harness กำลังเป็นตัวแปรที่มีน้ำหนักระดับเดียวกับน้ำหนักโมเดล กระโดด 25.6 จุดจากการจัดการ context กับไฟล์บนดิสก์ล้วน ๆ หมายความว่าเวลาเลือกโมเดลในองค์กร การดู benchmark แบบเรียกครั้งเดียวอาจไม่ได้บอกศักยภาพจริง

แต่ก็อย่าเพิ่งยกเลิกแผน frontier โจทย์แข่งขันมีคำตอบตรวจได้ด้วยตัวเอง ซึ่งเป็นงานที่ลูปแบบนี้ได้เปรียบที่สุด งานจริงใน codebase ของบริษัทไทยแทบไม่มี hidden test ให้ตัดสิน และเวลา 40 นาทีต่อข้อก็ใช้กับงานโต้ตอบไม่ได้ ที่ควรลองคือใช้แบบ batch กับงานที่มีเทสต์ครบ เช่น แก้บั๊กที่มีเทสต์จำลองอาการ หรืองานย้ายโค้ด ถ้ามีการ์ดรัน 27B อยู่แล้ว ต้นทุนส่วนเพิ่มจะต่ำมากและข้อมูลไม่ออกนอกเครื่อง

แหล่งข่าว

• team-solve workflow — Memdoor GitHub
• GVS5H: Zero-Shot Self-Orchestration with Ledger-Based Control — arXiv
• GVS5H repository — GitHub
• team-solve result page — Memdoor