DeepSWE: ทำไม Leaderboard ของ AI Coding Agent เริ่มไม่น่าเชื่อเท่าเดิม

Datacurve เพิ่งปล่อย benchmark ใหม่ชื่อ DeepSWE สำหรับวัดความสามารถของ frontier coding agents

ถ้าดูแบบข่าวเร็ว ๆ เราอาจหยุดที่ leaderboard:

• GPT-5.5 ได้ 70%
• GPT-5.4 ได้ 56%
• Claude Opus 4.7 ได้ 54%
• Claude Sonnet 4.6 ได้ 32%
• Gemini 3.5 Flash ได้ 28%

แต่ผมคิดว่าเรื่องที่สำคัญกว่าอันดับคือคำถามนี้:

benchmark ที่เราใช้ตัดสิน AI coding agent ตอนนี้ วัดความสามารถจริงแค่ไหน

เพราะถ้า benchmark มี contamination, verifier ตัดสินผิด, หรือ environment มีเฉลยซ่อนอยู่ คะแนนสูงก็อาจไม่ได้แปลว่า agent เก่งในงานจริงเท่าที่เราคิด

1) DeepSWE คืออะไร

DeepSWE เป็น benchmark จาก Datacurve ที่ออกแบบมาเพื่อวัดงาน software engineering แบบยาวขึ้น ยุ่งขึ้น และใกล้งานจริงกว่า benchmark สั้น ๆ

จุดที่เขาเน้นมี 4 เรื่อง:

1. งานเขียนใหม่ ไม่ดึง solution จาก public commit หรือ PR ที่มีอยู่แล้ว
2. กระจายหลาย codebase: 113 tasks จาก 91 repositories
3. ครอบคลุม 5 ภาษา: TypeScript, Go, Python, JavaScript, Rust
4. verifier วัดพฤติกรรมของ software ไม่ใช่ว่าต้องเขียนเหมือน reference solution เป๊ะ

ตัวเลขที่น่าสนใจคือ prompt ของ DeepSWE เฉลี่ย 2,158 ตัวอักษร สั้นกว่า SWE-Bench Pro ที่ 4,614 ตัวอักษร

แต่ solution ของ DeepSWE เฉลี่ย 668 lines added เทียบกับ SWE-Bench Pro ที่ 120 lines added

แปลง่าย ๆ คือคนสั่งงานน้อยลง แต่ agent ต้องทำงานเยอะขึ้น

นี่ใกล้กับ workflow จริงมากกว่า

เวลาเราสั่ง AI coworker หรือ coding agent เราไม่ได้อยากเขียน task spec ยาวสิบหน้า เราอยากบอกเป้าหมาย แล้วให้มัน explore codebase, เข้าใจ design, แก้หลายจุด, run tests, และเอา proof กลับมาให้ตรวจ

2) ปัญหาใหญ่ไม่ใช่ใครชนะ แต่คือสนามสอบเชื่อได้แค่ไหน

Datacurve เปรียบเทียบ DeepSWE กับ SWE-Bench Pro แล้วชี้ปัญหา 3 แบบ

Contamination

benchmark ที่สร้างจาก GitHub issues, pull requests หรือ commits จริงมีความเสี่ยงว่า model เคยเห็นข้อมูลนั้นแล้วตอน pretraining

ถ้า model เคยเห็น issue, discussion, test, หรือ solution patch มาก่อน คะแนนที่ได้อาจปน recall กับ problem solving

นี่ไม่ได้แปลว่า benchmark แบบเดิมไม่มีประโยชน์

แต่มันแปลว่าเมื่อ frontier model เก่งขึ้น เราต้องระวังว่า test set อาจไม่สดพอ

Verifier ตัดสินผิด

Datacurve audit 30 tasks จาก DeepSWE และ 30 tasks จาก SWE-Bench Pro แล้วใช้ analyzer ตรวจว่า patch แก้พฤติกรรมที่โจทย์ต้องการจริงไหม

ผลที่เขารายงานคือ:

• SWE-Bench Pro false positive 8.5%: ให้ผ่านทั้งที่ implementation ยังไม่ถูก
• SWE-Bench Pro false negative 24.0%: ให้ตกทั้งที่ solution สมเหตุสมผลหรือแก้โจทย์ได้
• DeepSWE false positive 0.3%
• DeepSWE false negative 1.1%

ถ้าตัวเลขนี้ยืนได้หลัง independent review นี่ไม่ใช่ noise เล็ก ๆ

มันแปลว่า leaderboard อาจตัดสินผิดในระดับที่กระทบการเลือก model จริง

Environment มีเฉลยซ่อนอยู่

ประเด็นที่คนพูดถึงเยอะคือ .git history

Datacurve รายงานว่าใน SWE-Bench Pro บาง container มี full git history หรือ future commit ที่ agent เข้าถึงได้

ถ้า agent run git log --all หรือ git show แล้วเจอ commit ที่เป็น gold solution มันอาจ copy หรือ adapt เฉลยมาได้

GitHub issue #93 ของ SWE-Bench Pro OSS ก็อธิบายปัญหานี้ในชื่อ Git Reward Hacking

ตรงนี้ต้องพูดให้แฟร์:

ในงานจริง การดู git history เป็นพฤติกรรมที่ดีมาก

developer ที่เก่งก็ดู history เพื่อเข้าใจ context

agent ที่ explore environment เก่งก็อาจทำแบบเดียวกัน

แต่ใน benchmark ถ้า future commit คือเฉลยของข้อสอบ แล้วมันอยู่ใน environment นั่นคือปัญหาของสนามสอบ

ไม่ใช่แค่เรื่อง model ฉลาดหรือไม่ฉลาด

3) ทำไมเรื่องนี้สำคัญกับธุรกิจไทย

เพราะหลายทีมกำลังจะซื้อหรือเลือก coding agent จาก leaderboard

เห็น model A ได้ 70% เห็น model B ได้ 54% เห็น model C ได้ 32% แล้วอยากสรุปเร็วว่าใครควรใช้

แต่ถ้าเรากำลังเอา agent เข้า workflow จริง เช่น:

• แก้ production repo
• สร้าง PR
• run migration
• update config
• อ่าน log
• ใช้ MCP server
• แตะระบบลูกค้า
• สร้าง test และ deploy preview

leaderboard เดียวไม่พอแล้วครับ

สิ่งที่ควรถามเพิ่มคือ:

• task ใน benchmark ใกล้กับงานของเราจริงไหม
• codebase ใน benchmark คล้าย repo ของเราไหม
• verifier ยอมรับหลาย implementation ที่ถูกต้องไหม
• environment สะอาดไหม
• agent ถูกอนุญาตให้ใช้ tool แบบเดียวกับ workflow จริงไหม
• model-native tool เช่น apply_patch, text editor, IDE integration, sandbox และ approval ถูกนับไหม
• มี proof หลังจบงานให้คน review ได้แค่ไหน

DeepSWE เองก็มีข้อจำกัด

เขารันทุก model ผ่าน mini-swe-agent เพื่อคุม harness ให้เท่ากัน ซึ่งดีต่อการเปรียบเทียบ model แต่ไม่เหมือนประสบการณ์จริงของ Codex CLI, Claude Code, Cursor หรือ Gemini CLI เต็ม ๆ

ดังนั้นคำตอบที่ดีไม่ใช่ “DeepSWE คือความจริงสุดท้าย”

คำตอบที่ดีคือ “DeepSWE เตือนว่าเราควรจริงจังกับคุณภาพของการวัดมากขึ้น”

4) อย่าเลือก agent จากคะแนน เลือกจาก private eval

สำหรับ Data-Espresso หรือทีมไทยที่อยากเริ่มใช้ coding agent จริง ผมจะทำ private eval เล็ก ๆ ก่อน

ไม่ต้องใหญ่เท่า benchmark ระดับโลก

เริ่มจาก 10 งานใน repo ของเราเองก็พอ:

1. bug fix ที่เคยเจอจริง
2. refactor เล็ก ๆ ที่ต้องเข้าใจหลายไฟล์
3. เพิ่ม feature ที่มี acceptance criteria ชัด
4. update dependency พร้อม regression test
5. เขียน integration กับ API จริงแบบ sandbox
6. งาน docs + code ที่ต้อง sync กัน
7. งานที่ต้องอ่าน log แล้วแก้ root cause
8. งานที่ต้องสร้าง test ก่อนแก้
9. งานที่ต้องขอ approval ก่อนทำ side effect
10. งานที่ต้องสรุป proof หลังจบ

ให้ agent แต่ละตัวทำงานใน sandbox เดียวกัน

ใช้ repo snapshot เดียวกัน

ให้สิทธิ์ tool เท่ากัน

กำหนดว่าอะไรทำเองได้ อะไรต้องขอ approval

แล้ววัดจากผลลัพธ์จริง:

• patch ถูกไหม
• test ผ่านไหม
• มี regression ไหม
• agent อธิบาย reasoning/proof ได้ไหม
• ค่าใช้จ่ายต่อ accepted task เท่าไร
• คน review ใช้เวลาน้อยลงจริงไหม
• agent สร้างงาน follow-up ให้ทีมเพิ่มหรือเปล่า

นี่จะตอบโจทย์ธุรกิจมากกว่า leaderboard กลางเยอะ

เพราะงานของคุณไม่ได้เหมือน benchmark เสมอไป

5) Benchmark ที่ดีควรวัดอะไร

ผมชอบ DeepSWE เพราะมันทำให้เรามี checklist ที่ดีขึ้น

benchmark ที่ดีสำหรับ coding agent ควรมีอย่างน้อย 6 อย่าง:

งานต้องสดและ original

ถ้างานมาจาก public commit ที่ model อาจเคยเห็น คะแนนจะปน memorization

งานที่ดีควรถูกสร้างใหม่ หรืออย่างน้อยต้องมีวิธีลด contamination อย่างจริงจัง

Prompt ควรเหมือนคนสั่งงานจริง

งานจริงไม่ได้มี interface definition พร้อมทุกจุด

prompt ที่ดีควรบอก behavior ที่ต้องการ แล้วปล่อยให้ agent discover codebase เองระดับหนึ่ง

Verifier ต้องวัด behavior

ถ้า solution A ใช้ helper ชื่อหนึ่ง และ solution B ใช้ helper อีกชื่อ แต่ behavior ถูกเหมือนกัน benchmark ควรให้ผ่านทั้งคู่

ไม่ควรวัดว่าต้องเดา structure ของ author ถูก

Environment ต้องไม่มี answer key

ไม่มี future commit ไม่มี hidden branch ที่เป็นเฉลย ไม่มี test fixture ที่หลุดมาจาก gold patch ไม่มีข้อมูลที่ทำให้ agent shortcut งานได้ผิดธรรมชาติ

ต้องวัด self-verification

agent ที่ดีไม่ควรแค่แก้ไฟล์แล้วส่ง

ควร run tests, เขียน temporary repro, เช็ค edge case, และบอกได้ว่า proof อยู่ตรงไหน

DeepSWE มี insight ที่น่าสนใจมากว่า model ที่แข็งแรงกว่ามักเขียนและรัน test เองมากขึ้นเมื่อ prompt ไม่ไปกดพฤติกรรมนี้ไว้

ต้องแยก model capability ออกจาก harness effect

ถ้า benchmark ใช้ harness กลาง คะแนนจะสะอาดขึ้นในแง่เปรียบเทียบ model

แต่ถ้าในชีวิตจริงเราใช้ Codex CLI, Claude Code, Cursor หรือ Gemini CLI พร้อม native tools คะแนนนั้นอาจไม่สะท้อน workflow จริงทั้งหมด

ต้องอ่านตัวเลขพร้อมบริบท

6) มุมมองของผม

DeepSWE ไม่ได้ทำให้ leaderboard หมดความหมาย

แต่มันทำให้ leaderboard กลับมาอยู่ในที่ที่ควรอยู่:

เป็น signal หนึ่ง ไม่ใช่คำตอบสุดท้าย

ยุค AI coding agent กำลังเปลี่ยนจาก autocomplete ไปเป็น delegated engineering

เมื่อ agent เริ่มรับงานยาวขึ้น แก้หลายไฟล์ ใช้ tool เอง และ run tests เอง เราต้องวัดมันด้วยสนามที่ใกล้ของจริงกว่าเดิม

สิ่งที่ธุรกิจไทยควรเอากลับไปไม่ใช่แค่ชื่อ model ที่ชนะ

แต่คือวิธีคิด:

อย่าเชื่อคะแนนถ้าไม่รู้ว่าสนามสอบสะอาดไหม อย่าเชื่อ pass rate ถ้า verifier ยังตัดสินผิดเยอะ อย่าเชื่อ demo ถ้าไม่มี proof หลังงานจบ อย่าเอา agent เข้า repo จริงถ้ายังไม่เคยทำ private eval กับงานของตัวเอง

สุดท้าย AI agent ที่ดีไม่ใช่ตัวที่ชนะ benchmark อย่างเดียว

แต่คือตัวที่ทำงานใน context ของเราได้จริง มี boundary ชัด มี test มี approval เมื่อเสี่ยง และทิ้งหลักฐานให้คนตรวจได้

นั่นแหละครับ จุดที่ coding agent เริ่มกลายเป็นระบบทำงานจริง ไม่ใช่แค่ของเล่นใน leaderboard

FAQ

DeepSWE บอกว่า GPT-5.5 เก่งสุดเสมอใช่ไหม

ไม่ควรสรุปแบบนั้นครับ DeepSWE บอกว่า GPT-5.5 ทำคะแนนสูงสุดใน benchmark นี้ ภายใต้ harness และ task set นี้ แต่การเลือกใช้งานจริงควรดู workflow, tool, cost, security boundary และ private eval ของเราเองด้วย

การที่ Claude ดู git history แปลว่า Claude แย่ไหม

ไม่ใช่ตรง ๆ ครับ ในงานจริงการดู git history เป็นทักษะที่มีประโยชน์ แต่ใน benchmark ถ้า history มี future/gold commit ที่เป็นเฉลย นั่นทำให้คะแนนเสียความหมาย เพราะสนามสอบมี answer key อยู่ใน environment

ธุรกิจเล็กต้องทำ private eval ไหม

ควรทำแบบเล็กครับ ไม่ต้องซับซ้อน เริ่มจาก 5 ถึง 10 งานใน repo หรือ workflow ของตัวเอง วัด patch correctness, test, review time, cost และ proof ก็ให้สัญญาณดีกว่าดู leaderboard อย่างเดียว

Benchmark ยังมีประโยชน์ไหม

มีประโยชน์มาก แต่ต้องอ่านแบบรู้ข้อจำกัด Benchmark เป็นแผนที่ ไม่ใช่พื้นที่จริง ใช้เพื่อคัดกรองและตั้งคำถาม แล้วค่อยยืนยันด้วยงานของเราเอง