Senior SWE-Bench: เบนช์มาร์กโอเพนซอร์สสำหรับประเมินเอเจนต์ระดับวิศวกรอาวุโส

 (senior-swe-bench.snorkel.ai)
3 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Senior SWE-Bench คือเบนช์มาร์กที่มุ่งประเมิน coding agent ให้ใกล้เคียงกับงานพัฒนาฟีเจอร์ แก้บั๊ก และปัญหาประสิทธิภาพที่วิศวกรอาวุโสทำจริง แทนที่จะเป็นโจทย์ระดับจูเนียร์ที่ถูกจัดระเบียบมากเกินไป
  • โจทย์ฟีเจอร์ใช้ คำสั่งที่สมจริง ซึ่งอ่านเหมือนข้อความภาษาธรรมชาติ และเพิ่มความน่าเชื่อถือของการประเมินด้วย validation agent ที่สร้าง behavioral tests ให้สอดคล้องกับวิธีแก้ที่ส่งมา
  • โจทย์บั๊กเริ่มจากรายงานผู้ใช้ และนำมาจาก PR ที่ต้องอาศัย การสืบสวนขณะรันไทม์ เช่น การรันบริการ log, profiling data และขั้นตอนการ reproduce
  • คะแนนไม่ได้ดูแค่ความถูกต้องขณะรันไทม์ แต่ยังรวมตัวชี้วัดคุณภาพตามแนวปฏิบัติของ codebase เพื่อประเมิน tasteful solve และแนวปฏิบัติสำคัญที่ไม่ได้ระบุไว้ในคำสั่งก็อาจถูกตรวจสอบได้
  • แม้ Claude Opus 4.8 ซึ่งเป็นโมเดลอันดับสูงสุดบน leaderboard ก็ทำได้เพียง pass@1 24.0% ในการตั้งค่า Mini-SWE-Agent max แสดงว่าโมเดลระดับบนยังล้มเหลวมากกว่า 75% ในการแก้โจทย์ให้มีทั้งความถูกต้องและ taste ระดับอาวุโส

การออกแบบโจทย์ให้ใกล้เคียง PR จริง

  • Senior SWE-Bench เป็นเบนช์มาร์กที่ต้องการลดช่องว่างระหว่างการใช้งาน coding agent ที่ในความเป็นจริงถูกใช้เหมือนวิศวกรอาวุโส แต่กลับถูกประเมินเหมือนโจทย์สำหรับจูเนียร์
  • โจทย์นำมาจาก PR ใน repository หลายประเภท ตั้งแต่ไลบรารีไปจนถึงแอปพลิเคชันหลายบริการ โดยเลือก PR ที่สร้างโดยวิศวกรซึ่งเคยเขียน หลายร้อย commit ในแต่ละ repository
  • ประเภทโจทย์หลักแบ่งเป็นสองสาย
    • PR ฟีเจอร์ ที่ครอบคลุมหลายขั้นตอนและหลาย stack
    • PR บั๊กและประสิทธิภาพ ที่ต้องอาศัยการสืบสวนขณะรันไทม์อย่างมาก
  • โจทย์สาธารณะมี 50 รายการ และมีโจทย์ไม่เปิดเผยอีก 50 รายการ
  • ตัวอย่าง repository ที่รวมอยู่มีดังนี้
    • posthog 8 รายการ
    • electric 6 รายการ
    • gitea 6 รายการ
    • better-auth 4 รายการ
    • harbor 4 รายการ
    • repository อื่นอีก 7 รายการ

โจทย์ฟีเจอร์: คำสั่งที่ใกล้เคียงภาษาธรรมชาติ

  • โจทย์ฟีเจอร์ใช้ คำสั่งที่สมจริง ซึ่งอ่านเหมือนข้อความภาษาธรรมชาติ แทนข้อกำหนดที่ถูกแยกย่อยละเอียดเกินไป
  • เพื่อประเมินโจทย์ลักษณะนี้อย่างเสถียร จึงนำ validation agent มาใช้
    • ใช้ recipe ที่ออกแบบโดยผู้เชี่ยวชาญ
    • เขียน behavioral tests ให้สอดคล้องกับวิธีแก้ที่ส่งมา
  • คำสั่งสะท้อนการสื่อสารกับเอเจนต์ที่เป็นธรรมชาติ และมีค่ามัธยฐานของความยาวอยู่ที่ประมาณ 31% ของ SWE-Bench Pro

โจทย์บั๊ก: จากรายงานผู้ใช้สู่การสืบสวนขณะรันไทม์

  • โจทย์บั๊กสะท้อน รายงานผู้ใช้ ที่ซับซ้อน โดยต้องการการสืบหาสาเหตุและขั้นตอนการ reproduce มากกว่าการแก้โค้ดแบบตรงไปตรงมา
  • โจทย์อาจรวมงานต่อไปนี้
    • เริ่มบริการ
    • ดีบักปัญหารันไทม์ที่ละเอียดอ่อน
    • ตรวจสอบ log
    • ใช้ profiling data
    • ไล่ตามขั้นตอนการ reproduce
  • แหล่งที่มาคือ PR ที่ในกระบวนการแก้ต้องอาศัย การสืบสวนขณะรันไทม์ อย่างมาก

เกณฑ์การประเมิน: วัดทั้งความถูกต้องและ taste

  • Senior SWE-Bench ให้คะแนน tasteful solve โดยผสานการทดสอบความถูกต้องขณะรันไทม์กับตัวชี้วัดคุณภาพหลายรายการ
  • ตัวชี้วัดคุณภาพอิงตามแนวปฏิบัติของ codebase ที่สังเกตได้
  • verifier และ validation agent สามารถทดสอบแนวปฏิบัติที่สำคัญใน codebase ได้ แม้จะไม่ได้เขียนไว้ในคำสั่ง
  • เงื่อนไข solve บน leaderboard รวมรายการต่อไปนี้
    • Verifiers pass
    • Validation pass
    • Rubric > 0.5
    • Bloat < 2×
    • Practice > 2/5
    • Rel. taste > 2/5

Leaderboard: แม้โมเดลสูงสุดก็มี pass@1 ต่ำ

  • leaderboard แสดงผลตาม Tasteful solve rate(pass@1)
  • ผลลัพธ์อันดับต้น ๆ มีดังนี้
    • Claude Opus 4.8, Mini-SWE-Agent max: 24.0%
    • Claude Sonnet 5, Mini-SWE-Agent max: 19.4%
    • GPT-5.5, Mini-SWE-Agent xhigh: 16.0%
    • Claude Opus 4.7, Mini-SWE-Agent max: 14.1%
    • GPT-5.4, Mini-SWE-Agent xhigh: 14.0%
    • GLM-5.2, Mini-SWE-Agent max: 12.5%
    • Kimi K2.6, Mini-SWE-Agent default: 8.2%
    • Claude Sonnet 4.6, Mini-SWE-Agent high: 8.2%
    • Gemini 3.1 Pro, Mini-SWE-Agent high: 6.1%
    • Gemini 3.5 Flash, Mini-SWE-Agent medium: 3.0%
  • แม้แต่ frontier model ที่แข็งแกร่งที่สุดก็ยังทำโจทย์ที่ต้องมีทั้งความถูกต้องและ taste ระดับอาวุโสไม่สำเร็จ มากกว่า 75%

ขอบเขตโจทย์และลักษณะของเบนช์มาร์ก

  • ประเภทโจทย์แสดงเป็น feature, bug, perf, migrat
  • stack รวมถึง Py Svc, Elixir, Go, SQL, TS Lib, Py Lib, Rust, TS FE เป็นต้น
  • โจทย์ฟีเจอร์อาจครอบคลุมหลายบริการ และแตะไฟล์เฉลี่ย 11 ไฟล์ ต่อโจทย์
  • ออกแบบมาให้ต้องใช้ workflow ยาว แม้แต่เอเจนต์ที่แข็งแกร่งที่สุดก็ยังต้องใช้ หลายร้อยขั้นตอน
  • SLOC และจำนวนไฟล์ของวิธีแก้อ้างอิงถูกวัดด้วยวิธีเดียวกันในเบนช์มาร์กทั้งสามชุด
  • ความยาวของคำสั่งไม่นับ harness boilerplate
  • จำนวน token และจำนวนขั้นตอนของเบนช์มาร์กอื่นอิงตามตัวชี้วัดที่แต่ละเบนช์มาร์กรายงานเอง

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

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

 
GN⁺ 4 시간 전
ความเห็นจาก Hacker News

  • เท่าที่เห็นใน Twitter น่าจะมีการสอบในคลาสแมชชีนเลิร์นนิงของ Tsinghua University ที่ให้นักศึกษาสร้าง ควิซที่ทำให้ LLM ล้มเหลวให้ได้มากที่สุด
    เลยคิดว่าน่าจะลองทำเบนช์มาร์กแบบนี้แล้วติดคะแนน ELO ดู โมเดลจะมาสู้กันเองโดยตั้งคำถาม บั๊ก หรือ implementation ที่ยังไม่เสร็จ แล้วให้อีกฝ่ายตอบ แก้ หรือทำให้เสร็จ

    • แบบนี้อาจเรียกว่า Generative Adversarial Network (GAN) ก็ได้ :)
      https://en.wikipedia.org/wiki/Generative_adversarial_network
    • ปัญหาคือจะป้องกัน degenerate strategy อย่างไร เช่น ถ้าให้ค่าแฮช SHA256 มาแล้วให้ทายอินพุตต้นฉบับ ก็สามารถสร้างโจทย์ที่เป็นไปไม่ได้ง่ายเกินไป
      ในชั้นเรียนอาจตั้งกติกาว่าอย่างน้อยต้องมี LLM หนึ่งตัวที่ตอบได้ แต่ถ้าเป็นการดวลตัวต่อตัวก็ไม่รู้จะจัดการอย่างไร
    • น่าจะไม่ใช่ Tsinghua แต่เป็น Fudan มากกว่า

  • สงสัยว่าเบนช์มาร์กนี้จะรักษา ความเกี่ยวข้อง ไว้ได้อย่างไรเมื่อเวลาผ่านไป
    ถ้าเบนช์มาร์กคือการ implement ฟีเจอร์ของโปรเจ็กต์โอเพนซอร์ส LLM อาจมีการเปลี่ยนแปลงเหล่านั้นอยู่ในข้อมูลฝึกแล้ว จึงอาจตอบแบบเดิมหรือดัดแปลงเล็กน้อยได้
    ในทางกลับกัน ถ้าใส่เฉพาะการเปลี่ยนโค้ดหลัง knowledge cutoff ของโมเดล ปัญหาในช่วงเวลา T และ T+1 ก็จะต่างกัน ทำให้เทียบข้ามเวลาได้ยาก

  • ถ้าเป็น Staff SWE Bench ก็คงสงสัยตั้งแต่แรกว่า LLM ควรทำสิ่งนี้ไหม ตั้งคำถามกับทั้งโปรเจ็กต์ ปฏิเสธการ merge โค้ด แต่ยินดีลบทิ้งให้

    • ฟังดูเหมือนมุก แต่จริง ๆ แล้ว การปฏิเสธ คือแกนสำคัญของงาน ไม่ใช่แค่ “ไม่ได้ ไปเถอะ” แต่คือการถอยออกมามองภาพใหญ่ ขอให้ชัดเจนว่าองค์กรทั้งองค์กรต้องการและรับภาระโปรเจ็กต์นั้นในระยะยาวได้จริงหรือไม่ ซึ่งแทบจะเป็นขั้นตอนขั้นต่ำก่อนเริ่มงาน
      LLM ก็น่าจะทำสิ่งนี้ได้ดีพอ หรืออาจดีกว่าเราด้วยซ้ำ แต่ต้องฝึกมาเฉพาะทางสำหรับเรื่องนี้ เพียงแต่ยังนึกไม่ออกว่าจะหา training data แบบนั้นจากที่ไหน
    • เวอร์ชัน Principal ก็คล้ายกัน แต่จะบอกเพิ่มว่ามีวิธีเดียวที่ยอมรับได้คือ วิธีที่เคยทำในบริษัทเก่า

  • แบบนี้ก็อธิบายได้ว่าทำไมฉันถึงรู้สึกเสมอว่า Opus 4.8 นำหน้า GPT 5.5 ไปไกลมาก มันเก่งมากในการรับ requirement ที่ไม่สมบูรณ์แล้วเติมช่องว่างอย่างสมเหตุสมผลให้เข้ากับโปรเจ็กต์

    • ไม่เข้าใจตั้งแต่แรกว่าทำไมถึงให้ requirement ที่ไม่สมบูรณ์ โมเดลทั้งสองตัวเก่งในการตรวจสมมติฐาน คิดถึง edge case และถามคำถามเพื่อขอความชัดเจน แต่ดูเหมือนจะทำเมื่อถูกขออย่างชัดเจนเท่านั้น เช่น เวลาขอด้วยเทคนิคอย่าง “brainstorming”
      ผมคิดว่าการประเมินทั้งสองแบบยังไม่ได้ชี้นำโมเดลมากพอให้ตั้งคำถามกับทุกสมมติฐานและซักถามกลับ ซึ่งอาจเป็นเพราะผู้ใช้อาจรำคาญ แต่ขั้นตอนนั้นแทบจะจำเป็น
      ตระกูล GPT-5 ทั้งหมดละเอียดมาก จึงมีประโยชน์กับ code review และคณิตศาสตร์ ซึ่งสำคัญกับงานของผม แต่กลับเหมือนเป็นอุปสรรคต่อโค้ดที่ “สวยงาม” เช่น พยายามป้องกันแม้แต่ edge case ที่มีโอกาสเกิดต่ำมากทั้งหมด
      ดูเหมือนจะมี trade-off ระหว่างความยืดหยุ่นกับการทำตามคำสั่ง จากประสบการณ์ของผม Opus บางครั้งเพิกเฉยต่อคำสั่งแต่เติมช่องว่างได้ดีกว่า ส่วน GPT-5.5 ทำตามคำสั่งได้ดีกว่าแต่ก็แข็งทื่อขึ้นตามไปด้วย
    • เบนช์มาร์กที่ดีที่สุดคือ เบนช์มาร์กที่คุณทำเอง
      จากประสบการณ์ของผม Opus ไม่ได้ทิ้งห่างหรือดีกว่าแบบขาดลอย ยังไงก็ตาม GPT 5.5 มีทั้ง Instant, Medium, High, Extra High และ Pro แต่ในตารางดูเหมือนจะเทียบกับ Extra High ดังนั้นไม่ควรเทียบกับ Pro หรือ?
    • ไม่รู้ว่าผมอยู่ในฟองสบู่ประหลาดหรือเปล่า แต่สำหรับผม GPT 5.5 ดีกว่า Opus 4.8 มากจนอยากรู้เลยว่าคุณประเมินอย่างไรและทำงานแบบไหน
      มีงานเฉพาะบางอย่างที่ Opus ทำได้ดีกว่า เช่น การพัฒนาฟรอนต์เอนด์และการออกแบบ แต่นอกจากนั้น 5.5 เหนือกว่าชัดเจน
    • อาจจะดีกว่าสำหรับพวก vibe coder ที่ชอบระบุรายละเอียดให้น้อยอยู่แล้ว แต่ปัญหาคือ ณ จุดไหนโมเดลจะตัดสินว่า “requirement ระบุไว้ไม่พอ” แล้วทำเกินสเปกที่จริง ๆ ระบุไว้พอแล้ว
    • ผมก็สังเกตเหมือนกัน Opus 4.8 ดูเป็นผู้ใหญ่มากกว่า และจะถามกลับหรือคัดค้านเมื่อคำขอชวนให้ติดใจ ในขณะที่ GPT 5.5 มักจะเห็นด้วยและทำตามที่สั่ง แต่บ่อยครั้งต้องให้ทำใหม่หลายรอบ
      4.8 เองก็ยังต้องใช้มากกว่าหนึ่งพรอมป์ต์ แต่คุณภาพผลลัพธ์สูงกว่ามากและให้ insight มากกว่า
      แต่ Fable 5 นี่เป็นอีกเรื่องหนึ่งเลย

  • ตอนนี้อัตราการแก้สำเร็จสูงสุดของ Opus 4.8 อยู่ที่ 24% แล้วถ้าเป็นมนุษย์ที่มีความสามารถควรได้ประมาณเท่าไร?

    • มนุษย์ก็น่าจะใช้สิ่งที่โมเดลที่ดีที่สุดใช้ได้ด้วย ดังนั้นอาจสูงกว่านั้นไหม
      ในทางกลับกันก็สงสัยว่า ถ้าโมเดลสามารถสั่งมนุษย์ได้ตามใจ จะทำคะแนนได้สูงกว่านี้หรือเปล่า
    • ถ้าสมมติว่าปัญหาเหล่านี้ทั้งหมดเป็นสิ่งที่เคยถูกแก้มาแล้ว ก็น่าจะ 100% แน่นอนว่าไม่ได้มีคนคนเดียวเป็นคนแก้ทั้งหมด แต่โมเดลต้องเก่งกับหลาย codebase ขณะที่มนุษย์สามารถเชี่ยวชาญและเรียนรู้แค่ผลิตภัณฑ์เดียวได้
      ผมว่าการเทียบกับคนที่คุ้นกับงานของผลิตภัณฑ์นั้นถือว่ายุติธรรม
      ผมสนใจมากกว่าว่า Fable จะออกมาอย่างไร

  • คุณค่าของบทบาทระดับซีเนียร์อยู่ที่การนำวิธีแก้และกลยุทธ์ที่รู้จักแล้วไปใช้กับ ปัญหาใหม่ ไม่แน่ใจว่าเบนช์มาร์กที่ไม่เปลี่ยนเลยจะยังเป็นความท้าทายใหม่ได้อีกนานแค่ไหน
    ถ้าจะเป็นเบนช์มาร์กที่ดีจริง น่าจะต้องใช้ TRIZ ทั้งชุดเพื่อสร้างก้อนปัญหาใหญ่ก่อน แล้วดูว่า AI จะอนุมานวิธีแก้ที่เหมาะสมที่สุดได้ไหม

  • ยินดีที่เห็น เบนช์มาร์กสาธารณะ ใหม่จาก Snorkel ฝั่งนั้นทำงานที่ค่อนข้างประณีตอยู่

  • น่าสนใจที่ Sonnet 5 เข้าใกล้ Opus 4.8 ได้มากพอสมควร

  • ถ้าวิธีนี้ใช้ได้ผล ก็แปลว่าเราน่าจะทำ การสัมภาษณ์ทางเทคนิค ให้เป็นอัตโนมัติได้ด้วยไม่ใช่หรือ?

  • แนวทางที่ให้ LLM ทำ การตัดสินเชิงอัตวิสัย แบบ “You are a senior SWE-Bench reviewer, make no mistakes.” ดูมีข้อบกพร่องเชิงพื้นฐาน
    แต่ก็ไม่รู้ว่ามีวิธีที่ดีกว่านี้อะไรบ้างโดยยังคงความเป็นไปได้ในการใช้งานจริงไว้

    • ที่สำคัญกว่านั้นคือ วิธีนี้อาจรบกวนการทำงานจริงได้ ถ้า LLM ทำผิด มันอาจถูกชี้นำให้ ลดทอนแล้วข้ามผ่านไป แทนที่จะยอมรับและแก้ไข
    • วิธีนี้โดยพื้นฐานคือการฝังบริบทว่า LLM ควรทำตัวอย่างไร “senior reviewer” คือสไตล์คำตอบที่ต้องการ และ “SWE-Bench” คือบริบทและโดเมนที่ LLM จะทำงานอยู่
      นี่เป็นวิธีที่พบบ่อยใน system prompt และช่วยกำหนดกรอบของคำตอบ
      เช่น ถ้าบอกว่าเป็น “โจรสลัดที่เขียนเพลงชาวเรือเกี่ยวกับการเขียนโปรแกรม”, “นักข่าวที่เขียนบทความฟิสิกส์”, หรือ “วิศวกรซอฟต์แวร์อาวุโสที่รู้ PostgreSQL อย่างสมบูรณ์แบบ” คำตอบก็จะออกมาต่างกัน
      ถ้าเป็นแบบแรก ก็อาจตอบในสไตล์ Wellerman ว่า “There once was a program that was set to C ...”
      แต่ส่วน “make no mistakes” นี่น่าสงสัย ถ้าลองเทียบผลลัพธ์ระหว่างใส่กับไม่ใส่วลีนั้น และทดสอบวิธีอื่นเพื่อให้ได้พฤติกรรมที่ต้องการแบบเดียวกัน ก็น่าจะน่าสนใจ
    • คำสั่งสอนอย่าง “make no mistakes” ดูค่อนข้างน่าขำ ใน YouTube ก็โดนล้อไปเยอะแล้ว แต่ก็จินตนาการได้ง่ายว่ามันอาจทำงานในแบบหนึ่ง เช่น อาจถูกตีความง่าย ๆ ว่า “ให้ตรวจทานงาน”
      แน่นอนว่าดูเหมือนไม่มีที่ไหนที่ทำการวัดเปรียบเทียบแบบนี้อย่างเปิดเผยเพื่อให้ไปถึงข้อสรุปที่สมเหตุสมผล