เหตุใด SWE-bench Verified จึงไม่สามารถวัดความสามารถด้านการเขียนโค้ดระดับฟรอนเทียร์ได้อีกต่อไป

 (openai.com)
4 คะแนน โดย GN⁺ 2 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • SWE-bench Verified ซึ่งเคยเป็นตัวชี้วัดหลักของงานวิศวกรรมซอฟต์แวร์อัตโนมัติ มีความเหมาะสมลดลงอย่างมากสำหรับการวัด ความสามารถของโมเดลระดับฟรอนเทียร์
  • ในช่วงที่การเพิ่มขึ้นของประสิทธิภาพสูงสุดล่าสุดถูกจำกัดอยู่ที่ 74.9% เป็น 80.9% ก็ยิ่งแยกได้ยากว่าความล้มเหลวที่เหลืออยู่เกิดจากข้อจำกัดของโมเดลหรือข้อบกพร่องของชุดข้อมูล
  • จากการตรวจสอบปัญหา 138 ข้อ พบว่า 59.4% มีข้อบกพร่องร้ายแรงในด้านการออกแบบการทดสอบหรือคำอธิบายโจทย์ และทั้งการทดสอบที่จำกัดเกินไปกับการทดสอบที่กว้างเกินไปก็อาจทำให้คำตอบที่ถูกต้องในเชิงฟังก์ชันไม่ผ่านได้
  • เนื่องจากเป็นการประเมินบนพื้นฐานของข้อมูลและโค้ดเบสที่เปิดเผยสาธารณะ จึงยากที่จะหลีกเลี่ยง การปนเปื้อนของข้อมูลฝึก และบางโมเดลสามารถสร้าง gold patch กลับมาได้แทบเหมือนเดิมโดยอาศัยเพียงคำอธิบายงานหรือ ID
  • ด้วยเหตุนี้จึง ยุติการรายงานคะแนน SWE-bench Verified และย้ายแกนการประเมินไปยัง SWE-bench Pro ที่ได้รับผลกระทบจากการปนเปื้อนน้อยกว่า รวมถึงเบนช์มาร์กแบบไม่เปิดเผยสาธารณะ

เหตุใดเบนช์มาร์กนี้จึงวัดอะไรไม่ได้อีกต่อไป

  • SWE-bench Verified ถูกใช้อย่างแพร่หลายเป็นตัวชี้วัดมาตรฐานสำหรับวัดประสิทธิภาพของโมเดลในงานวิศวกรรมซอฟต์แวร์อัตโนมัติ แต่สำหรับการวัดความสามารถของโมเดลระดับฟรอนเทียร์ในระดับปัจจุบันนั้น ความเหมาะสมได้ลดลงอย่างมาก
  • เมื่อการเพิ่มขึ้นของประสิทธิภาพสูงสุดในช่วง 6 เดือนล่าสุดถูกจำกัดอยู่ที่ 74.9% เป็น 80.9% ก็ยิ่งยากที่จะบอกได้ว่าความล้มเหลวที่เหลือเกิดจากข้อจำกัดของโมเดลหรือข้อบกพร่องของชุดข้อมูล
  • การวิเคราะห์ใหม่ชี้ว่า การทดสอบที่มีข้อบกพร่อง และ การปนเปื้อนของข้อมูลฝึก คือปัญหาหลัก และทำให้คะแนนสะท้อนระดับการสัมผัสกับเบนช์มาร์กมากกว่าความสามารถด้านการเขียนโค้ดจริง
  • ด้วยเหตุนี้ OpenAI จึง หยุดรายงานคะแนน SWE-bench Verified และแนะนำให้ผู้พัฒนาโมเดลรายอื่นดำเนินการเช่นเดียวกัน
  • ทางเลือกที่แนะนำคือใช้ SWE-bench Pro ซึ่งได้รับผลกระทบจากการปนเปื้อนน้อยกว่า และกำลังสร้างตัวชี้วัดการประเมินใหม่ที่ไม่ปนเปื้อนด้วย

ที่มา

  • SWE-bench ต้นฉบับถูกเผยแพร่ในปี 2023 และจัดทำขึ้นโดยจับคู่ GitHub issue ที่ได้รับการแก้ไขแล้วกับ PR ที่เกี่ยวข้องจาก 12 รีโพซิทอรี Python แบบโอเพนซอร์ส
  • แต่ละโจทย์กำหนดให้สร้างการเปลี่ยนแปลงโค้ดจากสภาพที่ให้เพียงโค้ดเบสก่อนแก้ไขและข้อความ issue เท่านั้น โดยเกณฑ์การผ่านคือ ต้องผ่านการทดสอบทั้งหมด หลังนำไปใช้
    • มีการรวมการทดสอบที่ต้องล้มเหลวก่อนแก้ไข และต้องผ่านหลังแก้ไขอย่างถูกต้อง
    • รวม regression test เพื่อตรวจสอบว่าฟังก์ชันเดิมไม่ได้พังไปด้วย
  • การประเมินต้นฉบับมีปัญหา เช่น การทดสอบที่เฉพาะเจาะจงเกินไปจนปฏิเสธคำตอบที่ถูกต้อง สเปกที่ไม่เพียงพอและตีความได้หลายแบบ และการทดสอบที่ล้มเหลวตามความแตกต่างของสภาพแวดล้อม
  • เพื่อลดปัญหาเหล่านี้ จึงมีการสร้าง SWE-bench Verified ในปี 2024 โดยคัดกรองปัญหา 1,699 ข้อผ่านการตรวจทานจากผู้เชี่ยวชาญจนได้เป็น ชุดปัญหา 500 ข้อ
    • แต่ละปัญหาได้รับการตรวจทานอย่างอิสระโดยผู้เชี่ยวชาญ 3 คน

ข้อบกพร่องในการออกแบบการทดสอบ

  • ใช้ 138 ปัญหา ที่ OpenAI o3 ไม่สามารถแก้ได้อย่างสม่ำเสมอแม้จะรันอย่างอิสระ 64 ครั้งเป็นเป้าหมายในการตรวจสอบ และแต่ละกรณีได้รับการทบทวนอย่างอิสระโดยวิศวกรซอฟต์แวร์ที่มีทักษะอย่างน้อย 6 คน
  • ผลลัพธ์คือ จาก 138 ข้อ มี 59.4% ที่มีข้อบกพร่องร้ายแรงในด้านการออกแบบการทดสอบหรือคำอธิบายโจทย์ จนแม้แต่โมเดลหรือมนุษย์ที่เก่งมากก็แก้ได้ยากมากหรือแทบเป็นไปไม่ได้
  • 35.5% ของงานที่ถูกตรวจสอบมีการทดสอบแบบจำกัดที่บังคับรายละเอียดการติดตั้งใช้งานเฉพาะเจาะจง
    • ทำให้คำตอบหลายแบบที่ถูกต้องในเชิงฟังก์ชันอาจถูกตัดสิทธิ์
  • 18.8% ของงานที่ถูกตรวจสอบมีการทดสอบที่กว้างเกินไป ซึ่งเรียกร้องฟังก์ชันเพิ่มเติมที่ไม่ได้อยู่ในคำอธิบายโจทย์
  • อีก 5.1% มีปัญหาอื่นที่ไม่เข้ากลุ่มใดกลุ่มหนึ่งอย่างชัดเจน

  • กรณีทดสอบแบบจำกัด

    • ใน pylint-dev__pylint-4551 การทดสอบของ PR นำเข้า get_annotation โดยตรง แต่ชื่อฟังก์ชันนี้ไม่ได้ปรากฏในสเปกของโจทย์
    • ดังนั้นแม้จะแก้ปัญหาได้ถูกต้องในเชิงฟังก์ชัน หากไม่ได้ติดตั้งใช้งานด้วย ชื่อฟังก์ชันเฉพาะนั้น ก็อาจทดสอบไม่ผ่านเพราะ import error

  • กรณีทดสอบแบบกว้างเกินไป

    • sympy__sympy-18199 มาจาก PR ที่จริงแล้วแก้สาม issue พร้อมกันคือ #17373, #17377, #18212
    • แต่คำอธิบายงานของ SWE-bench Verified กล่าวถึงเพียง #18212 เท่านั้น ดังนั้นแม้จะติดตั้งใช้งานตามคำอธิบายก็ยังอาจล้มเหลวในการทดสอบที่ตรวจสอบอีกสอง issue ที่เหลือ

ปัญหาการปนเปื้อน

  • SWE-bench Verified รวมถึงโค้ดเบสและ release note ของรีโพซิทอรีที่เกี่ยวข้องล้วนเปิดเผยสาธารณะและถูกใช้งานกับพูดถึงอย่างกว้างขวาง จึง หลีกเลี่ยงการปนเปื้อนของข้อมูลได้ยาก
  • OpenAI พบสัญญาณของการปนเปื้อนในโมเดลของตนเองด้วย และรวมถึงกรณีที่ GPT‑5.2 แก้งานได้ 31 ข้อซึ่งถูกประเมินว่าแทบเป็นไปไม่ได้ที่จะทำได้หากไม่มีการปนเปื้อน
  • ใน django__django-14725 การทดสอบต้องการพารามิเตอร์ edit_only ที่ไม่ได้ระบุไว้ในสเปกของโจทย์ แต่ GPT‑5.2 ระบุได้อย่างแม่นยำในกระบวนการให้เหตุผลว่าพารามิเตอร์นี้ถูกเพิ่มเข้ามาใน Django 4.1
  • OpenAI สร้าง สภาพแวดล้อมการทดสอบ red team แบบอัตโนมัติ เพื่อประเมินความรุนแรงของการปนเปื้อน
    • สำหรับแต่ละโจทย์ของ SWE-bench Verified นั้น GPT‑5 จะทำการตรวจสอบการปนเปื้อนของ GPT‑5.2‑Chat, Claude Opus 4.5 และ Gemini 3 Flash Preview
    • GPT‑5 ได้รับ task ID, คำอธิบาย, gold patch และ PR test พร้อมเปิดให้ปรับ prompt และกลยุทธ์ชี้นำได้รวม 15 เทิร์น
    • หลังแต่ละเทิร์น โมเดลประเมินจะจัดระดับความรุนแรงของการปนเปื้อนเป็น ไม่มี~รุนแรง โดยอิงจากปริมาณข้อมูลเฉพาะงานที่เพิ่งถูกเปิดเผย
    • กรณีการปนเปื้อนรุนแรงจะถูกตรวจสอบเพิ่มเติมด้วยโมเดลประเมินอีกตัวเพื่อยืนยันว่ามีการรั่วไหลของข้อมูลมากเกินไปหรือไม่ ก่อนสรุปด้วยการตรวจทานโดยตรง

กรณีการปนเปื้อนรุนแรงของแต่ละโมเดล

  • GPT‑5.2

    • ใน django__django-11451 เพียงมี snippet สั้น ๆ ของคำอธิบายงาน ก็สามารถพิมพ์ gold patch ที่ถูกต้อง ออกมาได้
    • มันสร้างซ้ำได้ทั้งเงื่อนไขการคืนค่าก่อนกำหนดเมื่อ ModelBackend.authenticate() มี username is None or password is None รวมถึง path ของไฟล์และชื่อเมธอด

  • Claude Opus 4.5

    • ใน astropy__astropy-13236 มันอ้างอิงทั้ง path ของไฟล์ที่ต้องแก้คือ astropy/table/table.py, เมธอด _convert_data_to_col และแม้แต่ inline comment ภายใน diff ได้ตรงตัวอักษร
    • โค้ด 4 บรรทัดที่แปลง structured ndarray ไปเป็น NdarrayMixin โดยอัตโนมัติก็ถูกกู้คืนกลับมาได้อย่างแม่นยำ

  • Gemini 3 Flash

    • ใน django__django-11099 แม้แทบไม่มีข้อมูลเพิ่มเติมนอกจาก task ID ก็ยังสามารถพิมพ์คำอธิบายงานและ gold patch ทั้งหมด ออกมาได้แบบตรงตัวอักษร
    • มันสร้างซ้ำได้ทั้งการเปลี่ยน regex สำหรับตรวจสอบชื่อผู้ใช้จาก r'^[\\w.@+-]+$' เป็น r'^[\\w.@+-]+\\Z' รวมถึง diff ระดับบรรทัด

บทเรียนสำคัญ

  • เบนช์มาร์กที่ดึงมาจากข้อมูลซึ่งเข้าถึงได้สาธารณะมี ความเสี่ยงด้านการปนเปื้อน และการสัมผัสข้อมูลฝึกอาจดันคะแนนให้สูงขึ้นโดยไม่สังเกตได้ง่าย
  • หากสร้างเบนช์มาร์กจากข้อมูลสาธารณะที่ crawl มา ผู้พัฒนาโมเดลต้องทำ การทดสอบเพิ่มเติม เพื่อตรวจสอบว่ามีการปนเปื้อนหรือไม่
  • เนื่องจากเบนช์มาร์กและคำตอบที่เปิดเผยสาธารณะอาจถูกรวมเข้าไปในข้อมูลฝึกได้ในที่สุด จึงต้องระมัดระวังเป็นพิเศษทั้งในวิธีเผยแพร่ชุดข้อมูลและการกรองข้อมูลฝึก
    • มีการกล่าวถึงวิธีควบคุมการเผยแพร่ เช่น การป้องกันด้วยรหัสผ่าน
    • และกล่าวถึง วิธีการกรอง เช่น การบังคับใช้ canary string อย่างเคร่งครัด
  • การให้คะแนนอัตโนมัติต้องแข็งแรงพอที่จะไม่แกว่งตามความต่างด้านการติดตั้งใช้งานที่ไม่สำคัญ แต่ก็ต้องเข้มพอจะป้องกันการใช้ทางลัด ซึ่งเป็นสิ่งที่ทำให้บรรลุพร้อมกันได้ยากมาก
  • การค้นหาข้อบกพร่องเหล่านี้จำเป็นต้องใช้ การติดป้ายกำกับด้วยมือขนาดใหญ่หลายรอบ

ทิศทางการประเมินต่อจากนี้

  • ในช่วงไม่กี่เดือนที่ผ่านมา OpenAI ตัดสินใจรายงานผลบนข้อมูลประเมินสาธารณะของ SWE-bench Pro และแนะนำให้ผู้พัฒนาโมเดลรายอื่นทำเช่นเดียวกัน
  • SWE-bench Pro ไม่ได้สมบูรณ์แบบเช่นกัน แต่จากประสบการณ์พบว่าได้รับ ผลกระทบจากการปนเปื้อนน้อยกว่า SWE-bench Verified
    • ใน pipeline ตรวจสอบการปนเปื้อนภายในยังพบกรณีปนเปื้อนบางส่วน
    • อย่างไรก็ตามพบได้น้อยกว่าและมีความรุนแรงต่ำกว่า SWE-bench Verified มาก
    • ไม่มีโมเดลใดสามารถสร้าง gold patch ที่ตรงกันทั้งหมดแบบตัวอักษรต่ออักษรได้
  • จากนี้ไปมีแผนจะลงทุนต่อเนื่องใน เบนช์มาร์กที่เป็นต้นฉบับและไม่เปิดเผยสาธารณะ
  • ใน GDPVal ผู้เชี่ยวชาญเฉพาะด้านจะเขียนงานขึ้นมาแบบไม่เปิดเผยสาธารณะ และผู้ประเมินที่ผ่านการฝึกจะให้คะแนนโซลูชันแบบองค์รวม
  • วิธีลักษณะนี้ใช้ทรัพยากรมาก แต่ยิ่งกลายเป็นองค์ประกอบที่จำเป็นมากขึ้นเรื่อย ๆ หากต้องการวัดการพัฒนาความสามารถที่มีความหมายจริง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2 일 전
ความเห็นจาก Hacker News

  • ในฐานะผู้ร่วมสร้าง SWE-bench ขอเรียบเรียงสั้น ๆ ว่า ตอนนี้ SWE-bench Verified แทบจะอิ่มตัวแล้วที่ 93.9% และ Anthropic ก็ควรได้รับคำยินดี
    ถึงอย่างนั้น ทีมที่ยังไปไม่ถึงตัวเลขนั้นก็ยังมีช่องให้ดันขึ้นได้อีก
    ส่วน SWE-bench Multilingual และ SWE-bench Multimodal ยังไม่อิ่มตัว และ Multimodal มีแผนจะปล่อยโอเพนซอร์สภายในเดือนหน้า
    สุดท้ายแล้ว benchmark ทุกตัวก็ย่อมอิ่มตัวอยู่ดี ดังนั้นเราก็กำลังทำ benchmark ขั้นถัดไปต่อ และตอนนี้ก็มีของอย่าง https://codeclash.ai/ หรือ https://algotune.io/ ออกมาแล้ว

    • การที่มันอิ่มตัวไม่ได้แปลว่าไม่ควรใช้ SWE-bench Verified อีกต่อไป
      ประเด็นหลักคือมีเทสต์จำนวนมากที่ไม่แม่นยำ ทำให้วิธีแก้ที่จริง ๆ ถูกต้องก็ยังถูกตัดสินว่าผิด
      อีกทั้งโมเดลระดับแนวหน้าก็มีโอกาสสูงที่จะเคยอ่านและจำ PR ต้นทางของโจทย์เหล่านั้นมาแล้ว
      บางปัญหาถึงขั้นแทบเป็นไปไม่ได้เลยที่จะตอบถูกหากไม่ได้ท่องจำคำตอบไว้ เช่น ต้องเปิดเผยชื่อ helper function เฉพาะที่ไม่ได้อยู่ในโจทย์ จึงจะผ่านเทสต์ได้
      แต่ที่โมเดลระดับแนวหน้าผ่านเรื่องพวกนี้ได้ ดูเหมือนเป็นเพราะมันจำได้ว่าต้องใช้ชื่อนั้น
      ถ้า benchmark รุ่นถัดไปไม่แก้ปัญหานี้ ต่อให้อิ่มตัวหรือไม่ ปัญหาเดิมก็จะยังอยู่
    • ถ้าตามบทความ audit subset 27.6% และบอกว่าในนั้น 59.4% มีเทสต์ที่บกพร่องจนปฏิเสธ submission ที่ใช้งานได้จริง
      คิดเลขแล้ว 0.191 * 0.594 > 1 - 0.936 เลยทำให้อยากรู้ว่า subset ที่ audit ไม่ได้เป็นตัวแทนที่ดี หรือ Anthropic ได้คะแนนสูงด้วยวิธีที่ชวนสงสัยกันแน่
    • SPECint กับ SPECfp ก็ผ่านวงจรแบบเดียวกันเป๊ะ
      สร้าง benchmark, อิ่มตัว, เลิกใช้, แทนที่, แล้วก็วนซ้ำ
      สุดท้าย treadmill นี้เองก็ดูเหมือนหมุนเป็นสินค้าไปแล้ว ยังไม่รู้ทางแก้ แต่ให้ความรู้สึกเหมือนประวัติศาสตร์ซ้ำรอย
    • ระหว่างนั้นก็เหมือนจะมีทางเลือกอย่าง https://SWE-rebench.com ด้วย
      เท่าที่ผมเข้าใจ มันดูเหมือนการดัดแปลง SWE-bench ที่น่าสนใจ
    • ผมยังมองว่า SWE-bench เองยอดเยี่ยมมาก
      การถูกตรวจสอบหนักแบบตอนนี้น่าจะเป็นผลสะท้อนจากการที่มันถูกใช้อย่างแพร่หลายและประสบความสำเร็จ

  • ไม่ว่า benchmark ใหม่อะไรจะออกมา มันก็ดูชัดมากว่าจะถูกดูดเข้า training data ไม่นานและล้าสมัยทันที
    ต่อให้เพื่อการตลาดอย่างเดียว ก็ยังมีแรงจูงใจเสมอที่จะ optimize ให้เข้ากับ benchmark บางตัว และแม้จะมี training cutoff โดยทั่วไปช่วงห่างจากเวลาที่เปิดเผยก็มักมีแค่ 3~6 เดือน
    ดังนั้นความยากจริงของ coding benchmark คือการสร้างโจทย์ใหม่ทั้งหมดที่ไม่ยืม benchmark เดิม และรับประกันได้ว่าไม่เคยอยู่ใน training data มาก่อน
    มองจากมุมนี้ benchmark ที่ถูกสร้างก่อนโมเดลออกวางตลาดก็ยากจะบอกว่าเป็นตัวแทนความสามารถของโมเดลนั้นได้จริง และแรงจูงใจทางการเงินในการยัดข้อมูลเพื่อโฆษณาการปรับปรุงเล็กน้อยก็มากเกินไป
    เอาจริง ๆ ควรตัด benchmark ออกจากสื่อการตลาดไปเลย แล้วปล่อยให้โมเดลพูดด้วยตัวเองและให้ชุมชนตัดสิน แต่บริษัทที่มีเงินเดิมพันคงไม่มีทางทำแบบนั้น

    • เลยทำ Zork bench ขึ้นมา
      เกมผจญภัยข้อความ Zork อยู่ใน training data ของ LLM และมีความเป็น deterministic ดังนั้นตามทฤษฎีแล้วมันควรเล่นและเคลียร์ได้ง่าย
      แต่ในความเป็นจริงไม่เป็นแบบนั้น และนั่นแหละคือเป้าหมายของ Zork bench
      https://github.com/mnky9800n/zork-bench
    • เวลาบอกให้ชุมชนตัดสิน ก็ยังไม่ชัดเลยว่าหมายถึงชุมชนไหนกันแน่
      มีทั้งผู้เชี่ยวชาญที่ใช้ LLM มานานกว่า 10 ปี ไปจนถึง vibe coder ที่ไม่เคยเขียนโค้ด และบนอินเทอร์เน็ตก็มีทั้งคนที่มอง GPT 5.5 เป็นผู้กอบกู้และคนที่มองว่ามันโง่กว่า 5.4
      ผมเองก็ไม่มีเวลาสร้าง private benchmark ใหม่ทุกครั้งที่มีโมเดลใหม่ สุดท้ายก็เลยอาศัย benchmark แบบ private หรือ semi-private เพื่อกะระดับการพัฒนา แล้วค่อยสมัครและลองใช้เอง
      อย่างน้อยก็น่าเชื่อถือกว่าบรรยากาศที่ผู้ใช้สุ่มหรือบอทบน Reddit ปั่นขึ้นมาเล็กน้อย
    • วิธีง่าย ๆ วิธีหนึ่งที่จะทำให้ coding benchmark กลับมามีความหมาย คือเติม noise หรือเนื้อหาที่ไม่เกี่ยวข้อง 200,000 token ลงไปใน context ของโมเดลก่อน
      หรือไม่ก็รันเทสต์ต่อเนื่องแบบลำดับใน context เดียวกัน เพื่อดูว่าโมเดลจะทนได้แค่ไหนก่อนที่มันจะเริ่มทำบริบทหลุด
      benchmark ตอนนี้เป็นปัญหาแบบ greenfield ตลอด แต่ของจริงเราต้องการโมเดลที่รับมือกับ context ที่เน่าแล้วได้
    • ยังรู้สึกว่าเรากำลังมองสิ่งที่ต่ำกว่าสาระสำคัญอยู่หนึ่งระดับ
      ตอนนี้คอขวดไม่ใช่ ความสามารถล้วน ๆ แต่เป็นว่าใน production โมเดล มองเห็นอะไรได้บ้าง
      โครงสร้าง context, คุณภาพ retrieval, การใช้ tool, ความสามารถในการประกอบสถานะข้ามหลายเทิร์น พวกนี้สำคัญ และใน SWE-bench แทบไม่มีเลย
      SWE-bench ดูเหมือนชุดโจทย์ one-shot แต่การทำงานด้านโค้ดระดับแนวหน้าไม่ใช่รูปแบบนั้นอีกแล้ว
      ต่อให้สร้าง benchmark ที่สมบูรณ์แบบและไม่มี data contamination เลย มันก็น่าจะยังวัดแกนที่ผิดสำหรับงานส่วนใหญ่อยู่ดี
      ในโจทย์ที่แยกเดี่ยว มันไปถึงระดับนักศึกษาปริญญาโท/เอกแล้ว และ leverage ตอนนี้อยู่ที่มันทำงานอย่างไรภายในระบบที่ใหญ่กว่า
      แต่สิ่งนั้นแทบจะใกล้กับเรื่องรสนิยมหรือ preference มาก จึงวัดแบบ objective ได้ยากมาก
    • ตัว ชุมชน ออนไลน์เองก็ถูก astroturf หนักเกินไป
      Anthropic จ่ายเงินให้อินฟลูเอนเซอร์ช่วยดัน Claude Code และก็ดูเหมือนมีการใช้บอทจำนวนมากด้วย ทำให้ยากจะเชื่อฉันทามติออนไลน์
      ต่อให้ทุกคนเจตนาดี ความต่างของโดเมนงานก็ทำให้ประสบการณ์ที่รับรู้ต่างกันมากได้
      เช่น AI อาจเก่งกว่ามากในงาน frontend หรือฝั่งไลบรารีที่ใช้กันแพร่หลาย
      ท้ายที่สุดการประเมินโมเดลก็ต้องลองใช้เองอยู่ดี แต่การทำแบบนี้ซ้ำกับทุกโมเดลใหม่นั้นเหนื่อยมาก และแค่นั้นก็ยังไม่ครอบคลุมพอ

  • benchmark/eval เดิมทีก็ยากอยู่แล้ว และยิ่งยากขึ้นเมื่อมีแรงจูงใจมหาศาลในระดับอุตสาหกรรมที่จะเล่นเกมกับมัน
    ELT-Bench ก็เป็นตัวอย่างล่าสุด มันเป็น benchmark จริงจังตัวแรกสำหรับ workload ด้าน data engineering ที่ออกมาเมื่อราวหนึ่งปีก่อน
    แต่เมื่อไม่กี่วันก่อนมี paper ติดตามผลที่มีหนึ่งในผู้เขียนต้นฉบับร่วมอยู่ด้วย ซึ่งทำการ audit benchmark เอง และพบว่าผลลัพธ์มีอคติจากปัญหาเชิงโครงสร้าง
    paper อยู่ที่นี่: https://arxiv.org/abs/2603.29399
    จริง ๆ เรื่องแบบนี้ไม่ใหม่เลย และวงการยุคก่อนก็เคยเจอทั้งหมดนี้มาแล้วในสเกลที่เล็กกว่า
    ยังมีบทความที่เขียนไว้ด้วยว่าสถานการณ์ทุกวันนี้คล้ายกับสงคราม benchmarketing ของฐานข้อมูลมากแค่ไหน
    https://www.typedef.ai/blog/from-benchmarketing-to-benchmaxx...

    • สุดท้ายสิ่งที่ยากที่สุดคือการ แยก benchmark ออกจาก training data
      ใน BrowseComp plus หรือ dataset สำหรับ deep research อื่น ๆ ก็เห็นปัญหาแนวเดียวกัน และไม่จำเป็นต้องเป็นเพราะ frontier lab ตั้งใจโกง แต่เป็นผลตามธรรมชาติจากการเทรนบนทั้งเว็บ
      dataset ใหม่ต้องถูกสร้างต่อเนื่องไปเรื่อย ๆ
    • benchmark ฐานข้อมูล ก็อยู่ในตระกูลเดียวกัน
      จากที่ผมทำ classifier เอง ผมเจอว่าสำหรับบางงาน โมเดลทำได้ดีกว่ามนุษย์อย่างสม่ำเสมอจนวัด precision เองไม่ได้แล้ว
      พอเป็นแบบนั้น classifier ตัวนั้นก็กลายเป็น state-of-the-art benchmark ไปโดยปริยาย และไม่มีอะไรให้เทียบได้นอกจากตัวมันเอง
      เรื่องแบบนี้ยังเกิดได้แม้ในงานซับซ้อนที่ใช้ตรรกะน้อยกว่าและต้องอาศัยการให้เหตุผลต่อเนื่องน้อยกว่างานเขียนโค้ด และวันหนึ่ง benchmark ที่ถูก calibrate และเป็นอิสระจากสิ่งที่มันใช้วัดอาจหายไปเลยก็ได้
    • งั้นก็เลยสงสัยว่าการสร้าง benchmark ใหม่ทุกเดือน จะช่วยแก้ปัญหานี้ได้ไหม

  • ท้ายที่สุด ผมมองว่าเราได้ benchmark ที่คู่ควรกับการกระทำของเราเอง กันอยู่พอสมควร
    PR จำนวนมากที่ผ่าน SWE-bench จริง ๆ อาจไม่มีวันถูก merge: https://news.ycombinator.com/item?id=47341645
    และคะแนน SWE-bench ของโมเดลชั้นนำก็อาจบิดเบือนจาก การรั่วของ git history: https://news.ycombinator.com/item?id=45214670

  • บางทีน่าจะให้โมเดลระดับท็อปสร้าง benchmark กันเองไปเลย
    ล้อเล่นน่ะ แต่สิ่งที่ผมคาดหวังคือ ARC-AGI-3 และจากการลองจำลองเป็นมนุษย์ดู มันให้ความรู้สึกว่าเน้น reasoning สูงมาก
    leaderboard อยู่ที่นี่: https://arcprize.org/leaderboard
    ตอนนี้แม้แต่โมเดลระดับท็อปส่วนใหญ่ก็ยังไปไม่ถึง 5%

    • ที่นี่ให้ความสำคัญกับ การใช้จำนวน move ให้น้อยที่สุด และไม่อนุญาต harness ใด ๆ เลย ดังนั้นเกณฑ์จึงโหดมาก
      ตอนนี้แม้แต่โมเดลที่ดีที่สุดที่ยืนยันแล้วอย่าง Claude Opus 4.6 ก็ยังอยู่แค่ราว 0.45%
      แต่เพราะมันใหม่มาก จึงคาดว่ากับโมเดลรุ่นถัดไปน่าจะดีขึ้นค่อนข้างมาก
    • แนวคิดให้โมเดลระดับท็อปสร้าง benchmark ก็ไม่ได้เพี้ยนไปเสียทีเดียว
      ให้โมเดลรุ่นก่อนสัมภาษณ์โมเดลรุ่นใหม่ แล้วให้ทั้งสองฝั่งหรือโมเดลผู้ตัดสินตัวที่สามตัดสินว่าใครฉลาดกว่า จากนั้นเปลี่ยน seed แล้วทำซ้ำ 100 ครั้งก็ได้
      เอาสัดส่วนที่ทั้งสองฝ่ายยอมรับชัยชนะของโมเดลใหม่เป็นคะแนนก็น่าจะพอได้
    • benchmark ที่เน้น reasoning สูง ดูจะเป็นทิศทางที่ดีกว่า
      มันเป็นแนวที่เล่นเกมด้วยได้ยากที่สุด
    • ก็อดสงสัยไม่ได้ว่า AI จะเขียนแม้แต่ ปัญหาที่ AI เองก็แก้ไม่ได้ ได้ไหม
      พอคิดแล้วก็ตลกดี

  • benchmark ที่ดีกว่าควรมี การให้คะแนนแบบ objective, ความกว้างข้ามหลายสาขา, และ ความสามารถในการขยายตัว พร้อมทั้งหลีกเลี่ยงรูปแบบที่มีคำตอบเดียวตายตัว
    สิ่งที่เรากำลังออกแบบที่ https://gertlabs.com ก็ไปในทิศทางนั้น และส่วนใหญ่ก็ยังเกี่ยวข้องกับการแก้ปัญหาผ่านการเขียนโค้ด

    • benchmark นี้ให้ความรู้สึกว่าแม่นยำกว่ารายการจัดอันดับอื่น ๆ ที่ผมเคยเห็น
      จากประสบการณ์ของผม gpt 5.4/5.5 แทบไร้ที่ติทางเทคนิค และถ้ามีปัญหาก็มักเป็นเพราะอินพุตไม่ชัดเจน
      มันยังรับมือปัญหาระหว่างแก้บั๊กหรือทำ implementation ได้ด้วยตัวเอง และมีแนวโน้มจะปิดงานได้ครบถ้วนไม่มีช่องโหว่
      ส่วน Opus ผมมองว่าค่อนข้างถูกประเมินค่าสูงเกินจริงในด้านความสามารถทางเทคนิค
      มันมีเซนส์นักออกแบบ/นักพัฒนาที่ทำ UX สวยงามได้ดีกว่า แต่เวลาตรวจงานผมก็ยังให้ gpt 5.5 ทำเสมอ
      สิ่งที่น่าประหลาดใจที่สุดคือผลของ Xiao-Mi ผมยังไม่เคยใช้ แต่เห็นแบบนี้แล้วตั้งใจจะลอง
      ขอแสดงความยินดีกับทีมที่สร้างเกณฑ์อ้างอิงที่มีความหมายท่ามกลางสงครามความเร็วของ AI ที่สับสนนี้
    • น่าสนใจที่สาย Claude Code ยังนำโมเดลอื่นทิ้งห่างพอสมควรใน C++ และ Java ขณะที่ GPT 5.5 กลับขึ้นสูงกว่าใน Python, JS และภาษาอื่น ๆ
      มันดูเหมือนสะท้อนทั้งอคติของชุดข้อมูลฝึกและความต่างของจุดเน้นด้าน go-to-market และก็อาจเป็นผลจากการที่ Anthropic โฟกัสลูกค้าองค์กรหนักกว่า OpenAI
      ซึ่งก็สอดคล้องกับความรู้สึกของผมจากการใช้ Opus กับ C++
      แต่ผลของ C# ยังว่างอยู่ เลยอยากถาม @gertlabs ว่ามี ETA ไหม
    • จาก benchmark นี้ดูเหมือน Deepseek V4 pro จะทำได้แย่กว่า Deepseek V4 flash ซึ่งเป็นผลที่น่าสนใจทีเดียว
      เลยอยากรู้ว่ามีคอมเมนต์ไหมว่าทำไมถึงออกมาแบบนั้น

  • เรื่องแบบนี้ไม่ว่าจะเกิดแบบอินทรีย์หรือไม่อินทรีย์ สุดท้ายก็คงต้องเกิดอยู่แล้ว
    มันมีแนวโน้มจะไหลไปเป็นว่าแค่ทำให้ คะแนน benchmark ออกมาดีก็พอ ต่อให้เอาไป generalize ข้างนอกไม่ได้ก็ไม่เป็นไร
    กรณีคล้ายกันที่นึกถึงได้คือ Graduate student descent
    https://sciencedryad.wordpress.com/2014/01/25/grad-student-d...

  • มองย้อนกลับไป SWE-bench เองอาจไม่ได้ยิ่งใหญ่ขนาดนั้นแต่แรก
    ตลอดปี 2025 สัดส่วนที่โมเดลสร้าง โค้ดที่ดี ได้จริงแทบไม่ได้ดีขึ้นอย่างมีนัยสำคัญเลย และอาจตีความได้ถูกกว่าว่าที่ดีขึ้นคือความสามารถในการผ่าน automated test
    https://entropicthoughts.com/no-swe-bench-improvement

    • ผมเห็นด้วยยากกับคำบอกว่าไม่มีการพัฒนาด้านคุณภาพโค้ดเลย
      ในเดือนมกราคม 2025 ตัวหลักยังเป็น Claude 3.5 Sonnet, Gemini 1.5 Pro และฝั่ง OpenAI ก็ GPT-4o และในฐานะคนที่ใช้ทั้งโมเดลพวกนั้นและโมเดลระดับแนวหน้าตอนนี้ ผมรู้สึกชัดเจนว่าโมเดลปัจจุบันก้าวขึ้นไปอีกขั้นใหญ่แล้ว
    • การตีความนี้มีโอกาสถูกไม่น้อย
      คุณภาพโมเดลอาจกำลังนิ่ง และการหาทิศทางปรับปรุงใหม่ก็ไม่ง่ายเลย
      แม้แต่ การขยายความกว้างของโมเดล ที่ผลักดันอัตราการพัฒนามาจนถึงตอนนี้ก็ดูเหมือนจะเริ่มแตะขีดจำกัดแล้ว เลยอยากรู้ว่าจะมีนัยอะไรตามมา
      ในระยะยาว แม้แต่สิ่งที่แก้ด้วย tooling อย่างเดียวก็มีเพดานของมัน
    • ถึงอย่างนั้น อัตราการผ่าน automated test ที่สูงขึ้นก็เป็นแหล่งเพิ่มผลิตภาพด้านโค้ดที่ใหญ่มาก
      นั่นก็เป็นหนึ่งในเหตุผลที่ Anthropic ถูกประเมินมูลค่าระดับหลายหมื่นล้านดอลลาร์
      ที่ SWE-bench มีประโยชน์ฝั่งโค้ดก็เพราะซอฟต์แวร์เอนจิเนียริงมีทั้งประเพณีและโครงสร้างพื้นฐานที่แข็งแรงมากในการสร้างและใช้ automated test
    • หรือบางทีนี่อาจเป็นเหตุผลว่าทำไมช่วงนี้ pricing ของหลายบริษัทถึงยิ่งจำกัดและแพงขึ้น

  • สิ่งที่บทความพูด น่าจะหมายถึงว่าเมื่อไป audit subset 27.6% ที่โมเดลมักแก้ไม่ผ่าน ก็พบว่าอย่างน้อย 59.4% ของส่วนนั้นมีเทสต์บกพร่องที่ปฏิเสธ submission ซึ่งใช้งานได้จริง
    ถ้าเป็นจริงก็ดูเหมือนแปลว่าที่ผ่านมามีกลุ่มใหญ่ของทั้งโจทย์และคำตอบที่ผิดอยู่ไม่ใช่หรือ และถ้าอย่างนั้นมันเคยเป็นมาตรวัดที่ใช้ได้อย่างไร ก็น่าตั้งคำถามมาก
    พอดูคำอธิบายกระบวนการสร้าง benchmark แล้ว มาตรฐานก็ดูสูงพอสมควร เลยยิ่งไม่เข้าใจว่าขั้นตอนแบบนั้นออกมาคู่กับคุณภาพข้อมูลที่แย่ขนาดนี้ได้อย่างไร
    การที่เขาเปิดเผยปัญหาด้วยตัวเองก็น่าชื่นชม แต่ก็ยังเหลือคำถามอีกมาก

    • มันไม่ได้แปลว่า หนึ่งในสี่ของทั้งหมด ผิด แต่หมายถึงใน subset 27.6% นั้น 59.4% มีเทสต์บกพร่อง
      และด้วยเหตุผลในทางปฏิบัติ benchmark ก็ไม่มีทางเป็นตัวแทน use case ของคุณ หรือของทุก use case ได้อยู่แล้ว
      มันใช้วัดได้แค่สิ่งที่มีอยู่ข้างในเท่านั้น ไม่มากไม่น้อยไปกว่านั้น
      นั่นก็เป็นเหตุผลที่ผมไม่เข้าใจว่าทำไม ecosystem ถึงยึดติดกับ benchmark สาธารณะกันนัก
      เช่น แค่ Qwen 3.5 ดีกว่า Qwen 2.5 บน Benchmark X 50% ก็แทบไม่ได้รับประกันเลยว่ามันจะดีกว่าสำหรับงานที่ผมใช้จริง 50%
      ผมสร้าง private benchmark ของตัวเองมาเรื่อย ๆ โดยอิงจากกรณีที่โมเดลเคยพลาดในการใช้งานจริง และค่อย ๆ ปรับ prompt ตามนั้น
      แม้จะมีอัปเดตโมเดลใหม่ benchmark ของผมก็มักขยับแค่ 2~3% แต่ benchmark สาธารณะกลับชอบโปรโมตการกระโดด 30~40% จนยากจะเชื่อว่าไม่มี training data contamination
    • ImageNet ก็เป็นหนึ่งใน dataset ที่มีชื่อเสียงที่สุดในโลก แต่ภาพจำนวนไม่น้อยถูกติดป้ายกำกับผิด
      ในกรณีสุดโต่ง มันอาจมีช่วงที่ถ้าคุณอยากได้คะแนนสูงขึ้น คุณต้องจงใจตอบตามคำตอบที่ผิด
      สุดท้ายคำตอบก็คือ ML เป็นสาขาที่พยายามทำงานให้ได้ไม่ทางใดก็ทางหนึ่งอยู่แล้ว ดังนั้นแม้จะมีข้อบกพร่อง มันก็ยังไปได้ไกลอย่างน่าประหลาด
      ขณะเดียวกัน นั่นก็เป็นเหตุผลว่าทำไมการชี้ข้อบกพร่องที่คนอื่นมองไม่เห็นจึงนำไปสู่การก้าวกระโดดครั้งใหญ่ได้
    • ถ้าใช้เพื่อแยกแยะว่าโมเดลไหนดีกว่า คะแนน benchmark ก็แค่ต้องมี ความสัมพันธ์กับประสิทธิภาพจริง ก็พอ
      ถ้าการให้คะแนนของโจทย์ส่วนใหญ่ยังถูกต้อง ทิศทางโดยรวมก็อาจยังคงอยู่
      เช่น ต่อให้เป็น benchmark แย่มากที่ label ผิดถึง 49% ถ้ามีโมเดลหนึ่งตอบถูกเสมอได้ 51% และอีกโมเดลตอบผิดเสมอได้ 49% อันดับก็ยังคงถูกอยู่
      benchmark ฝั่ง machine learning ส่วนใหญ่มีปัญหา mislabeled อยู่ไม่น้อย แต่ถ้าเป้าหมายคือแยกโมเดลออกจากกัน โดยทั่วไปการรวบรวม dataset ให้ใหญ่ขึ้นมักคุ้มกว่าการเสียเวลารับประกันการให้คะแนนที่สมบูรณ์แบบ
    • สรุปคือมันน่าจะหมายความว่ามีปัญหาอยู่ประมาณ 16% ของโจทย์