Skip to content
ข่าวนี้คืออะไรในภาษาคนทำงาน
OpenAI เพิ่งเผยแพร่บทความ Separating signal from noise in coding evaluations เมื่อ 8 กรกฎาคม 2026
ประเด็นหลักคือ OpenAI audit ชุดประเมิน SWE-Bench Pro แล้วพบว่า public tasks จำนวนมากมีปัญหา จนประเมินว่าประมาณ 30% ของงานใน benchmark นี้อาจ broken
ตัวเลขสำคัญจากบทความ:
- SWE-Bench Pro public split มี 731 tasks
- Frontier models เคยเพิ่ม pass rate จาก 23.3% เป็น 80.3% ใน 8 เดือน
- OpenAI datapoint analysis pipeline flag broken tasks 200 งาน หรือ 27.4%
- Human annotation campaign ระบุ broken tasks 249 งาน หรือ 34.1%
- OpenAI จึงถอนคำแนะนำเดิมที่เคยบอกให้ชุมชนหันมาใช้ SWE-Bench Pro
ถ้าแปลเป็นภาษาธุรกิจ:
สนามสอบที่เราใช้วัด AI coding agent อาจมี noise เยอะพอที่จะทำให้การตัดสินใจผิดได้
ไม่ใช่แค่ผิดเล็กน้อยแบบอ่านคะแนนคลาดเคลื่อน แต่ผิดในระดับที่กระทบคำถามว่า “model นี้เก่งจริงไหม” หรือ “agent นี้พร้อมแตะ repo จริงหรือยัง”
ทำไมเรื่องนี้สำคัญกว่าดราม่า leaderboard
หลายคนจะอ่านข่าวนี้เป็นเรื่อง OpenAI vs Scale หรือ model คะแนนตกคะแนนขึ้น
แต่ผมว่าแก่นของเรื่องใหญ่กว่านั้นครับ
ยุคนี้ AI coding agent ไม่ได้เป็นแค่ autocomplete แล้ว เราเริ่มให้มัน:
- อ่าน issue
- แก้ code หลายไฟล์
- run tests
- สร้าง PR
- ใช้ CLI หรือ MCP tools
- อ่าน log
- update docs
- ทำงานแบบ delegated engineering
เมื่อ agent เริ่มทำงานเหมือน junior developer ที่มี tool เต็มมือ การวัดผลก็ต้องจริงจังตามไปด้วย
ถ้า benchmark มี hidden tests ที่บังคับ implementation detail ที่โจทย์ไม่บอก agent อาจแก้ถูกทางแต่โดนตัดตก
ถ้า test coverage ต่ำ agent อาจแก้ไม่ครบแต่สอบผ่าน
ถ้า prompt ทำให้เข้าใจผิด agent อาจเดินผิดทางเพราะข้อสอบออกแบบไม่ดี
นี่ไม่ใช่เรื่องเล็กครับ เพราะบริษัทจำนวนมากกำลังใช้ leaderboard เป็นหนึ่งใน input สำหรับเลือก model, coding agent, IDE agent หรือ AI coworker platform
4 failure modes ที่ OpenAI เจอ
OpenAI แบ่งปัญหา task issues หลัก ๆ เป็น 4 กลุ่ม
1) Overly strict tests
คือ test บังคับรายละเอียด implementation ที่โจทย์ไม่ได้บอก
ตัวอย่างในบทความคือ task ของ OpenLibrary ที่โจทย์บอก spacing แบบหนึ่ง แต่ hidden test คาดหวัง spacing อีกแบบหนึ่ง
ถ้า model ทำตามโจทย์เป๊ะก็ยัง fail ได้ เพราะ hidden test ต้องการรายละเอียดที่ไม่อยู่ใน prompt
ในงานจริง เรื่องนี้คล้ายกับการสั่ง developer ว่า “ทำรายงานให้ export เป็น Markdown” แต่ตอนตรวจดันตัดตกเพราะ spacing ต้องเป็น 2 ช่อง ทั้งที่ requirement บอกแค่ 1 ช่อง
2) Underspecified prompts
โจทย์ไม่บอก requirement ที่ test เอาไปตัดสิน
นี่เป็น pain ที่คนทำงาน software รู้จักดีมากครับ
หลาย ticket ในโลกจริงเริ่มจากคำสั่งสั้น ๆ ไม่ครบ แต่ human developer จะถามต่อ อ่าน context หรือ clarify กับ owner
ถ้า benchmark เอา ticket แบบไม่ครบไปวัด model โดยไม่ออกแบบวิธีจัดการ ambiguity ให้ดี คะแนนจะวัดปนกันระหว่าง “model ไม่เข้าใจ” กับ “โจทย์ไม่แฟร์”
3) Low-coverage tests
test ตรวจไม่ครอบคลุม behavior ที่ควรตรวจ
กรณีนี้ agent อาจส่ง patch ที่ผ่าน test แต่แก้ feature ไม่ครบจริง
นี่อันตรายสำหรับธุรกิจมาก เพราะมันให้ false confidence: ดูเหมือนทำงานเสร็จ แต่จริง ๆ มีช่องว่างซ่อนอยู่
4) Misleading prompt
prompt พา model ไปผิด behavior หรือขัดกับสิ่งที่ test ต้องการ
นี่ทำให้ benchmark กลายเป็นสนามที่เสียงดังแต่ signal ต่ำ
เวลาเราเห็นคะแนน fail จึงต้องถามต่อว่า fail เพราะ model อ่อนจริง หรือ fail เพราะ task สื่อสารผิด
เรื่องนี้ต่อจาก SWE-bench Verified อย่างไร
ก่อนหน้านี้ OpenAI เคยเขียนบทความว่า SWE-bench Verified no longer measures frontier coding capabilities
เหตุผลหลักคือ Verified เริ่มมี contamination และ design issues
OpenAI บอกว่าบาง model อาจเคยเห็นโจทย์หรือ gold patch จากข้อมูลสาธารณะมาก่อน ทำให้คะแนนปน memorization กับ problem solving
ตอนนั้น OpenAI แนะนำให้ชุมชนหันมาใช้ SWE-Bench Pro แทน เพราะ Pro ถูกออกแบบให้ยากขึ้น ยาวขึ้น และ realistic ขึ้นกว่าเดิม
แต่บทความล่าสุดคือการถอยอีกชั้นหนึ่ง:
แม้แต่ benchmark รุ่นที่ควรดีกว่า ก็ยังต้อง audit task quality อย่างหนัก
นี่เป็นสัญญาณว่า coding-agent eval กำลังเข้าสู่ช่วงที่ “benchmark hygiene” สำคัญพอ ๆ กับ model score
แล้ว SWE-Bench Pro ไม่มีประโยชน์แล้วหรือเปล่า
ผมไม่คิดว่าควรสรุปแบบนั้นครับ
SWE-Bench Pro ยังมีคุณค่าในฐานะสนามทดสอบที่ยากและใกล้งานจริงกว่าหลาย benchmark เก่า
Scale ระบุว่า SWE-Bench Pro มีทั้งหมด 1,865 instances แยกเป็น public, held-out และ commercial subsets ครอบคลุม 41 repositories และออกแบบมาเพื่อวัด long-horizon software engineering tasks
แต่สิ่งที่ OpenAI ชี้คือ:
เราต้องอ่านคะแนนด้วยความระวังมากขึ้น
Benchmark ไม่ใช่ความจริงสุดท้าย
Benchmark คือเครื่องมือวัด และเครื่องมือวัดเองก็ต้องถูกวัดด้วย
ถ้าเทอร์โมมิเตอร์เพี้ยน เราไม่ควรถกกันแค่ว่าใครไข้สูงกว่าใคร แต่ควรถามก่อนว่าเทอร์โมมิเตอร์วัดถูกไหม
สัญญาณจากชุมชน: คนเริ่มถามหาคะแนนที่วัด outcome จริง
จาก HN discussion หลังบทความนี้ คนไม่ได้สนใจแค่ “30% broken” อย่างเดียว
มีคนเสนอคำถามที่น่าสนใจกว่า: ถ้าให้ budget API เท่ากัน เช่น 100 ดอลลาร์ model จะทำงานสำเร็จได้มากแค่ไหน
นี่เป็นมุมที่ผมชอบมาก เพราะมันใกล้การตัดสินใจจริงของธุรกิจ
ในโลกงานจริง เราไม่ได้มีแค่คำถามว่า model ไหนฉลาดสุด
เราถามว่า:
- ใช้เงินเท่านี้ ทำงานเสร็จกี่งาน
- ต้อง retry กี่รอบ
- ต้องให้คนช่วยตรงไหน
- run test เองไหม
- ตรวจ proof ได้ไหม
- accepted patch ต่อเงิน 1 บาทคุ้มไหม
นี่คือจุดที่ benchmark ดิบเริ่มไม่พอ
ธุรกิจต้องการ cost per accepted task และ review time saved มากกว่าคะแนนเฉลี่ยบนสนามกลางอย่างเดียว
Operator Kit: Coding Agent Eval Hygiene Checklist
ถ้าทีมคุณกำลังเลือก Codex, Claude Code, Cursor, Gemini CLI, Copilot agent หรือ coding agent ตัวอื่น ผมแนะนำให้ทำ private eval เล็ก ๆ ก่อน
ไม่ต้องใหญ่ครับ เริ่มจาก 5 ถึง 10 งานจริงใน repo ของตัวเองก็พอ
1) เลือกงานจริงที่มีคำตอบอ้างอิง
เลือก bug fix, refactor, dependency update หรือ feature เล็ก ๆ ที่ทีมเคยทำสำเร็จแล้ว
งานที่ดีควรมี:
- input ชัดพอเหมือน issue จริง
- มี test หรือวิธี verify
- ไม่แตะ production secret
- ไม่เกี่ยวกับ customer data จริง
- สามารถรันใน branch หรือ sandbox ได้
2) ให้ agent ทำในสภาพแวดล้อมเดียวกัน
ถ้าจะเปรียบเทียบ agent หรือ model อย่าให้ตัวหนึ่งมี tool เยอะกว่าอีกตัวโดยไม่จดไว้
ต้องกำหนดให้ชัด:
- ใช้ repo snapshot เดียวกันไหม
- ให้สิทธิ์ shell, test, browser, MCP, database mock เท่ากันไหม
- มี timeout เท่ากันไหม
- ให้ budget token หรือเงินเท่ากันไหม
- ให้ดู docs/internal wiki ได้ไหม
ถ้า harness ต่างกัน คะแนนจะปน model capability กับ tool advantage
3) วัดผลจาก accepted work ไม่ใช่ output volume
อย่าวัดว่า agent เขียน code ได้เยอะแค่ไหน
ให้วัดว่า:
- patch ถูกไหม
- test ผ่านไหม
- reviewer รับไหม
- มี regression ไหม
- agent สร้าง proof ให้ตรวจได้ไหม
- คน review ใช้เวลาน้อยลงจริงไหม
- ค่าใช้จ่ายต่อ accepted task เท่าไร
สำหรับธุรกิจ นี่คือ metric ที่เอาไปตัดสินใจได้จริงกว่า pass rate กลาง
4) ตรวจ false positive และ false negative ของเราเอง
False positive คือ agent ดูเหมือนผ่าน แต่จริง ๆ ยังผิด
False negative คือ agent แก้ได้สมเหตุสมผล แต่ checklist หรือ test ของเราตัดตกเพราะแคบเกินไป
สองอย่างนี้เกิดในบริษัทได้เหมือนใน benchmark ระดับโลก
ดังนั้น private eval ที่ดีควรมี human reviewer ดูตัวอย่างที่ fail และ pass บางส่วนเสมอ
5) แยกงานตาม risk
อย่าให้ agent เริ่มจากงานเสี่ยงสูงทันที
จัดงานเป็นกลุ่ม:
- safe: docs, test, small refactor, low-risk bug
- medium: feature branch, integration sandbox, migration draft
- high: production config, payment, auth, customer data, deployment
ให้ agent ทำเองได้ใน safe zone
ให้ขอ approval ใน medium/high zone
และทุกงานต้องมี proof หลังจบ
Data-Espresso take: Leaderboard เป็นแผนที่ ไม่ใช่พื้นที่จริง
บทเรียนของ OpenAI ครั้งนี้ไม่ใช่ “อย่าใช้ benchmark”
แต่คือ “อย่าใช้ benchmark แบบไม่ดูคุณภาพของ benchmark”
สำหรับทีมไทยที่เริ่มเอา AI coding agent มาใช้ ผมจะอ่าน leaderboard แบบนี้:
- ใช้เพื่อ shortlist เครื่องมือที่น่าลอง
- อ่าน methodology ว่า task มาจากไหน
- ดู harness ว่าเหมือน workflow จริงไหม
- ดูว่า verifier วัด behavior หรือ implementation detail
- ทำ private eval บน repo ของตัวเอง
- วัด accepted task, review time, cost, regression และ proof
ถ้าทำครบ เราจะได้คำตอบที่ใช้ตัดสินใจจริงมากกว่า “อันดับหนึ่งในตาราง”
สรุป
OpenAI audit ครั้งนี้ทำให้เห็นชัดว่า AI coding benchmark ไม่ใช่ของศักดิ์สิทธิ์ครับ
มันเป็น measurement system ที่มี bug ได้ มี noise ได้ และต้องถูก QA เหมือน software ตัวหนึ่ง
สำหรับธุรกิจไทย คำถามที่ควรถามไม่ใช่แค่ว่า model ไหนชนะ SWE-Bench Pro
คำถามที่ดีกว่าคือ:
ถ้าเอา agent ตัวนี้เข้า repo ของเรา ภายใต้ tool, approval, test, cost และ reviewer workflow ของเรา มันสร้าง accepted work ได้จริงแค่ไหน
AI coding agent ที่ดีไม่ใช่ตัวที่ชนะสนามสอบกลางอย่างเดียว
แต่คือตัวที่ทำงานจริงในบริบทของเราได้ ปลอดภัยพอให้ลอง ขยันพอให้คุ้ม และมี proof พอให้คนกล้ากด approve ครับ
FAQ
OpenAI บอกว่า SWE-Bench Pro ใช้ไม่ได้เลยใช่ไหม
ไม่ใช่ตรง ๆ ครับ OpenAI บอกว่าพบ task issues จำนวนมากและถอนคำแนะนำเดิมให้ใช้เป็น benchmark หลักสำหรับวัด frontier coding capabilities แปลว่าใช้ได้เป็นสัญญาณหนึ่ง แต่ไม่ควรใช้เป็นคำตอบสุดท้ายโดยไม่ตรวจ methodology และทำ private eval เพิ่ม
ถ้า task ใน benchmark broken 30% แปลว่า model score ทั้งหมดผิดไหม
ไม่จำเป็นต้องผิดทั้งหมดครับ แต่แปลว่าคะแนนมี noise เยอะพอที่จะทำให้การเปรียบเทียบผิดทิศได้ โดยเฉพาะเมื่อคะแนนของ model ใกล้กัน หรือเมื่อใช้คะแนนนั้นไปตัดสินใจเรื่อง deployment จริง
ทำไม hidden tests ถึงเป็นปัญหา
Hidden tests ไม่ใช่ปัญหาโดยตัวเองครับ ปัญหาคือ hidden tests ที่บังคับ requirement หรือ implementation detail ที่โจทย์ไม่ได้บอก ถ้า test วัด behavior จริงและโจทย์ชัด hidden tests ก็ยังมีประโยชน์มาก
ทีมเล็กควรสร้าง benchmark เองไหม
ควรสร้างแบบเล็กครับ ไม่ต้องทำ dataset ใหญ่ เริ่มจาก 5 ถึง 10 งานจริงใน repo ของตัวเอง แล้ววัด patch correctness, test, review time, cost และ proof ก็ให้สัญญาณดีกว่าดู leaderboard อย่างเดียว