SWE-bench (benchmark) (TH)

From Systems analysis Wiki
Jump to navigation Jump to search

SWE-bench — คือ benchmark ขนาดใหญ่ (ชุดโจทย์ทดสอบ) สำหรับประเมินความสามารถของ large language models (LLM) ในด้าน การพัฒนาซอฟต์แวร์อัตโนมัติ และ การดีบักโปรแกรม[1] บนชมาร์กนี้ได้รับการพัฒนาโดยกลุ่มนักวิจัยจากมหาวิทยาลัย Princeton และองค์กรอื่น ๆ และได้รับการนำเสนอในการประชุม ICLR 2024[2] SWE-bench แตกต่างจาก benchmark ด้านโค้ดแบบดั้งเดิมตรงที่ใช้ โจทย์จากการพัฒนาจริง: ชุดทดสอบประกอบด้วย 2,294 โจทย์ ที่อิงจาก issues ที่ปิดแล้วและ pull request ที่เกี่ยวข้องจาก Python repository ยอดนิยม 12 แห่งบน GitHub[1][3] แต่ละโจทย์มีคำอธิบายปัญหา (issue) และให้โมเดลเข้าถึงซอร์สโค้ดของโปรเจกต์ที่เกี่ยวข้อง โดยเป้าหมายของโมเดลคือการสร้างการเปลี่ยนแปลงขั้นต่ำใน codebase (patch) เพื่อแก้ไขปัญหาที่ระบุ[1][3]

วิธีการและลักษณะเฉพาะของการประเมิน

SWE-bench จำลองกระบวนการพัฒนาซอฟต์แวร์จริง สำหรับแต่ละโจทย์ โมเดลจะได้รับข้อความของ GitHub issue ต้นฉบับ (คำอธิบายปัญหา) และ snapshot ของโค้ด repository ในเวอร์ชันก่อนที่จะมีการแก้ไข[4] โมเดล (หรือ agent ที่อิงจากโมเดล) จะต้องวิเคราะห์ซอร์สโค้ด ทำความเข้าใจลักษณะของข้อผิดพลาดหรือการเปลี่ยนแปลงที่ต้องการ และแก้ไขไฟล์โค้ดที่เกี่ยวข้องเพื่อแก้ปัญหา[4][5] การตรวจสอบความถูกต้องของคำตอบ เป็นแบบอัตโนมัติ: แต่ละโจทย์ผูกกับการทดสอบหน่วยจริงจาก pull request ที่ปิดปัญหานั้น ซึ่งประกอบด้วยทั้ง การทดสอบแบบ «fail-to-pass» (ที่ล้มเหลวบนโค้ดต้นฉบับแต่ต้องผ่านหลังจากใช้การแก้ไขที่ถูกต้อง) และ การทดสอบ regression (pass-to-pass ที่ผ่านในตอนแรกและต้องยังคงผ่านหลังจากทำการเปลี่ยนแปลง)[3] patch ที่โมเดลเสนอจะถูกนำไปใช้กับโค้ด จากนั้นจึงรันการทดสอบที่เกี่ยวข้อง: หากการทดสอบ fail-to-pass ทั้งหมดเริ่มผ่าน และการทดสอบ pass-to-pass ไม่ถูกทำลาย โจทย์นั้นจะถือว่าแก้ไขได้อย่างถูกต้อง[3] แนวทางการประเมินนี้ช่วยตรวจสอบไม่เพียงแค่ความสามารถของโมเดลในการสร้างโค้ดที่ถูกต้องทางไวยากรณ์ แต่ยังรวมถึงความสามารถในการแก้ปัญหาที่กำหนดไว้จริง ๆ โดยไม่ทำลายฟังก์ชันการทำงานที่มีอยู่ด้วย ในขณะเดียวกัน โมเดลต้องทำงานกับ context ขนาดใหญ่ (repository โค้ดทั้งหมด) เข้าใจความสัมพันธ์ระหว่างองค์ประกอบต่าง ๆ และประสานการเปลี่ยนแปลงในหลายไฟล์พร้อมกัน[1] — ซึ่งทั้งหมดนี้ซับซ้อนกว่าโจทย์ทั่วไปในการเขียนฟังก์ชันตามคำอธิบายมาก

ในการประเมิน SWE-bench มักไม่ใช้ LLM เพียงอย่างเดียว แต่ใช้ ระบบ agent ที่ห่อโมเดลด้วยเครื่องมือช่วยเหลือ (เช่น สำหรับการนำทางไฟล์ การรันโค้ด การใช้ debugger เป็นต้น)[4][6] ระบบดังกล่าวจำลองวงจรการพัฒนาจริง: โมเดลสามารถดูไฟล์ต่าง ๆ ตามลำดับ รัน test หรือ script และปรับปรุงคำตอบทีละขั้นจนกว่าจะได้ผลลัพธ์ที่สำเร็จ[4] สิ่งที่น่าสังเกตคือประสิทธิภาพในการแก้โจทย์ SWE-bench ส่วนใหญ่ขึ้นอยู่กับคุณภาพของ «scaffolding» นี้ (โครงสร้างพื้นฐานของ agent): โมเดลพื้นฐานเดียวกันอาจให้ผลลัพธ์ที่แตกต่างกัน ขึ้นอยู่กับวิธีการจัดการการโต้ตอบกับ repository และเครื่องมือต่าง ๆ[4][7] ดังนั้น SWE-bench จึงทำหน้าที่เป็นตัววัดความสามารถของโมเดลร่วมกับกลยุทธ์การแก้ปัญหา ทำให้การประเมินใกล้เคียงกับสภาพการทำงานจริงของ นักพัฒนา AI อัตโนมัติ[4][7]

ชุดโจทย์รูปแบบต่าง ๆ

ผู้สร้าง SWE-bench และชุมชนได้นำเสนอชุดโจทย์ย่อยหลายชุดในภายหลังสำหรับวัตถุประสงค์การประเมินที่แตกต่างกัน:

  • SWE-bench Lite — เวอร์ชันที่เบากว่าของ benchmark ประกอบด้วย ~300 โจทย์[8] ที่คัดเลือกมาเพื่อลดความซับซ้อนและค่าใช้จ่ายในการคำนวณสำหรับการทดสอบโมเดล ชุดย่อยนี้ถูกสร้างขึ้นเพื่อการทดลองอย่างรวดเร็วกับโมเดลต่าง ๆ และไม่รวมการตรวจสอบที่ใช้เวลามากที่สุด ในขณะที่ยังคงความเป็นตัวแทนของปัญหาหลัก[7] โดยพื้นฐานแล้ว Lite มีโจทย์การแก้บั๊กที่ง่ายกว่าและสั้นกว่า และผลลัพธ์ของโมเดลบน Lite มักสูงกว่าบนชุดเต็ม เนื่องจากการตัดกรณีที่ยากที่สุดออก[7]
  • SWE-bench Verified — ชุดย่อยที่กรองด้วย การตรวจสอบด้วยมือ นำเสนอในเดือนสิงหาคม 2024 ร่วมกับ OpenAI[7] นักวิจัยได้รับการสนับสนุนจาก นักพัฒนาวิชาชีพ 93 คน เพื่อวิเคราะห์แต่ละโจทย์ใน benchmark ต้นฉบับและกำจัดกรณีที่คำอธิบายปัญหาต้นฉบับไม่ชัดเจนเกินไปหรือพฤติกรรมที่ต้องการตาม test ไม่ได้ระบุไว้อย่างชัดเจนในเงื่อนไขของโจทย์[7] นอกจากนี้ยังลบโจทย์ที่ไม่สามารถแก้ได้ในทางปฏิบัติเนื่องจากปัญหาด้านสภาพแวดล้อมหรือ test ที่ไม่ถูกต้อง[7] ผลลัพธ์ที่ได้คือชุด 500 โจทย์ ที่รับประกันว่าแก้ได้และมีการกำหนดปัญหาอย่างถูกต้อง[7] SWE-bench Verified มีวัตถุประสงค์เพื่อให้การประเมินความสามารถของโมเดลที่น่าเชื่อถือยิ่งขึ้น โดยกำจัดกรณีที่แม้แต่คำตอบที่ถูกต้องก็ถูกปฏิเสธเนื่องจากความไม่เหมาะสมของ test หรือโจทย์[7] ชุดนี้ได้แทนที่ชุดทดสอบต้นฉบับของ SWE-bench (ทั้งแบบเต็มและ Lite) ในฐานะจุดอ้างอิงหลักสำหรับการเปรียบเทียบโมเดล[7] นอกจากนี้ พร้อมกับ Verified ยังมีการเผยแพร่การประเมินความยากของโจทย์ (เช่น การแยกโจทย์ «ง่าย» ที่คนแก้ได้ภายใน 15 นาที และโจทย์ «ยาก» ที่ต้องใช้เวลามากกว่า 1 ชั่วโมง)[7] รวมถึงการเผยแพร่กรอบเครื่องมือใหม่ที่ใช้ Docker เพื่อการรัน test ที่เสถียรและทำซ้ำได้มากขึ้น[7]
  • SWE-bench Multimodal — การขยาย benchmark ที่นำเสนอในเดือนมกราคม 2025 ซึ่งรวมโจทย์ที่คำอธิบายปัญหาไม่ได้มีแค่ข้อความ แต่ยัง องค์ประกอบทางภาพ ด้วย (เช่น รูปภาพของ interface ภาพหน้าจอของข้อผิดพลาด เป็นต้น)[8] ชุดนี้ (517 โจทย์[8]) ทดสอบความสามารถของโมเดลและ agent ในการเข้าใจและใช้ข้อมูลภาพในการแก้ปัญหาการเขียนโปรแกรม การประเมินบน ชุด multimodal จัดขึ้นในลักษณะเดียวกัน แต่ต้องการความสามารถ multimodal จากโมเดล (เช่น การจดจำข้อความในภาพ) ส่วนทดสอบของ SWE-bench Multimodal ถูกเก็บไว้เป็นความลับ (ซ่อน) เพื่อป้องกันการปรับคำตอบให้เข้ากับคำตอบที่รู้อยู่แล้ว นักพัฒนาสามารถส่งคำตอบไปยัง leaderboard ระยะไกลเพื่อประเมินโมเดลของตนในโจทย์เหล่านี้[2]

นอกจากรูปแบบหลักเหล่านี้แล้ว ยังมี ecosystem ของเครื่องมือที่ก่อตัวขึ้นรอบ ๆ SWE-bench: SWE-agent — โปรแกรม «agent» ที่เป็น open source สำหรับการแก้ปัญหา ซึ่งแสดงผลลัพธ์ที่ดีที่สุดในโจทย์ benchmark[2]; SWE-smith — framework สำหรับการฝึกโมเดลนักพัฒนาของตัวเอง; SWE-REX — เครื่องมือสำหรับการดึงและประมวลผลข้อมูลจาก repository ขั้นสูง เป็นต้น โปรเจกต์เหล่านี้มุ่งเป้าไปที่การทำให้การทำซ้ำผลลัพธ์ง่ายขึ้นและส่งเสริมการวิจัยในด้านระบบการเขียนโปรแกรมอัตโนมัติ

ผลลัพธ์และความก้าวหน้าของโมเดล

เมื่อ SWE-bench ปรากฏขึ้นครั้งแรก มันเผยให้เห็นช่องว่างที่สำคัญระหว่าง LLM สมัยใหม่และทักษะของโปรแกรมเมอร์ที่มีประสบการณ์ ผู้เขียนรายงานว่าแม้แต่โมเดลที่ทรงพลังที่สุดในต้นปี 2023 ก็สามารถแก้ได้เพียง เปอร์เซ็นต์เล็กน้อย ของโจทย์: เช่น โมเดล Claude 2 จาก Anthropic แก้โจทย์ได้สำเร็จน้อยกว่า 2% ของชุดเต็ม[1] โมเดลที่ผู้เขียน benchmark ฝึกขึ้นมาโดยเฉพาะ (บนพื้นฐาน LLaMA ที่ได้รับชื่อว่า SWE-Llama) และโมเดลเชิงพาณิชย์อย่าง GPT-4 สามารถแก้ได้เฉพาะข้อผิดพลาดที่ง่ายที่สุดเป็นหลัก[1] ตัวเลขเริ่มต้นที่ต่ำเหล่านี้เน้นย้ำความซับซ้อนของ SWE-bench และเป็นแรงกระตุ้นให้พัฒนาแนวทางใหม่ ๆ

ตลอดปี 2024 เมื่อโมเดลที่ซับซ้อนยิ่งขึ้นและแผนงาน agent ปรากฏขึ้น ผลลัพธ์ก็ดีขึ้นอย่างมีนัยสำคัญ นักวิจัยจาก Princeton นำเสนอระบบ SWE-agent ที่รวม GPT-4 กับการค้นหาโค้ด การวางแผน และเครื่องมืออื่น ๆ ซึ่งบรรลุประมาณ 12.5% ของโจทย์ที่แก้ได้บนชุดเต็ม สร้างจุดอ้างอิงใหม่สำหรับโมเดลเชิงวิชาการ[5] ในช่วงกลางปี 2024 คำตอบที่ดีที่สุดบน leaderboard อย่างเป็นทางการของ SWE-bench (รวมถึงแบบเชิงพาณิชย์) บรรลุประมาณ 20% ของการแก้สำเร็จบน benchmark เต็มและสูงถึง 43% บนชุด Lite ที่ลดความซับซ้อนแล้ว[7] การเติบโตดังกล่าวเชื่อมโยงกับการปรับปรุงโมเดล (เช่น การปรากฏตัวของ GPT-4, Claude 2 และ 3) และโดยเฉพาะอย่างยิ่งกับการพัฒนา «scaffolding» — กลยุทธ์ภายนอกที่ช่วยให้โมเดลแบ่งโจทย์เป็นขั้นตอนได้อย่างมีประสิทธิภาพ อ่านเอกสาร รันเซสชัน debug เป็นต้น[7]

หลังจากการนำชุด Verified มาใช้ในปลายปี 2024 (ที่ทำความสะอาดจากโจทย์ที่ไม่ถูกต้อง) ประสิทธิภาพที่วัดได้ก็เพิ่มขึ้นอีกมาก โมเดล GPT-4 (รูปแบบ GPT-4o) แสดงผล 33% ของการแก้สำเร็จบน Verified ทันที เทียบกับ ~16% ก่อนหน้านี้บนชุดต้นฉบับ[7] framework agent แบบ open source ที่ดีที่สุด (เช่น Agentless) เพิ่มผลลัพธ์เป็นสองเท่าจาก ~16% เป็น 32% บน Verified[7] สิ่งนี้ยืนยันสมมติฐานที่ว่า benchmark ต้นฉบับ ประเมินค่าต่ำเกินไป เนื่องจากมีกรณีที่แก้ไม่ได้[7] ในขณะเดียวกัน การปรับปรุงผลลัพธ์บน Verified เมื่อเทียบกับ Lite ไม่ได้ดราม่ามากนัก (โมเดลที่ดีที่สุดบรรลุ ~43% บน Lite แล้ว) ซึ่งสมเหตุสมผล: Lite คัดเลือกตัวอย่างที่ง่ายกว่าในตอนแรก ในขณะที่ Verified กำจัดกรณีที่เป็นไปไม่ได้แต่ยังคงโจทย์ที่ยากไว้[7] สิ่งสำคัญที่ควรสังเกตคือการเติบโตของตัวชี้วัดเมื่อเปลี่ยนไปใช้ Verified เกิดขึ้น ในทุกหมวดหมู่ความยากของโจทย์ ไม่ใช่แค่จากการกำจัดกรณีที่ยากที่สุด — นั่นคือ การกรองช่วยกำจัดกรณีที่ไม่สามารถทำได้จริง ๆ ที่ซ่อนอยู่แม้กระทั่งในหมู่โจทย์ที่ค่อนข้างง่าย[7]

ในต้นปี 2025 ระบบ AI ชั้นนำแสดงประสิทธิภาพที่ใกล้เคียงมนุษย์แล้วบนชุดโจทย์ที่ผ่านการตรวจสอบ แม้ว่าเพดาน 100% ยังอยู่ห่างไกล ในเดือนมกราคม 2025 บริษัท Anthropic รายงานว่าโมเดลใหม่ Claude 3.5 Sonnet ร่วมกับ agent ที่ปรับปรุงแล้วแก้ได้ 49% ของโจทย์ SWE-bench Verified[4] โดยขึ้นสู่อันดับหนึ่งชั่วคราว บริษัทเทคโนโลยีขนาดใหญ่และทีมอิสระก็มีส่วนร่วมอย่างแข็งขันในการแข่งขันอย่างไม่เป็นทางการบน benchmark นี้ด้วย โดยทีม CodeStory พัฒนาแนวทาง multi-model พร้อมการลองหลายรูปแบบ («Midwit Agent») ที่บรรลุผลสำเร็จสูงสุดถึง 62.2% ของโจทย์ที่แก้ได้บน Verified (ข้อมูล ณ ต้นปี 2025)[5][9] มีการสังเกตว่าเพื่อให้บรรลุสิ่งนี้ต้องเพิ่มทรัพยากรการคำนวณในขั้นตอน inference (ที่เรียกว่า inference time scaling) อย่างมีนัยสำคัญ โดยรันการพยายามแก้ปัญหาจำนวนมากและเลือกผลลัพธ์ที่ดีที่สุด[5] ในทางกลับกัน ในสื่อของ OpenAI มีการกล่าวถึงระบบทดลอง GPT-o3 ซึ่งเมื่อปรับขนาดการคำนวณให้เพียงพออ้างว่าสามารถ突破เกณฑ์ 70% บน Verified ได้ (ข้อมูลไม่เป็นทางการ)[5] อย่างไรก็ตาม ยังไม่มีการยืนยันอิสระของผลลัพธ์เหล่านี้ และตัวเลขสูงดังกล่าวยังคงเป็นจุดอ้างอิงสำหรับการวิจัยในอนาคตมากกว่าเกณฑ์ที่บรรลุแล้ว

ตามการวิจัยของ Microsoft Research (2025) แม้แต่โมเดลล่าสุดเมื่อติดตั้งเครื่องมือ debug ก็ยัง ไม่ผ่านเกณฑ์ 50% ของการแก้บั๊กสำเร็จจาก SWE-bench Lite[6] ในการทดสอบนี้ Claude 3.7 Sonnet ทำได้ดีที่สุดด้วย ~48.4% ของโจทย์ที่แก้ได้ ในขณะที่ระบบบน GPT-4 (OpenAI o1) แก้ได้ประมาณ 30% และโมเดลที่เบากว่า o3-mini แก้ได้เพียง 22%[6] ผลลัพธ์เหล่านี้เน้นย้ำว่า แม้จะมีความก้าวหน้าอย่างรวดเร็ว AI สมัยใหม่ยังคงด้อยกว่าโปรแกรมเมอร์ที่มีประสบการณ์: สำหรับมนุษย์ การแก้โจทย์ดังกล่าว (เมื่อมีความเข้าใจในโค้ด) ไม่ใช่เรื่องยาก ในขณะที่โมเดลมักไม่สามารถใช้เครื่องมือ debug ได้อย่างมีประสิทธิภาพหรือประสบปัญหาจากการขาดข้อมูลการฝึกที่สะท้อนกระบวนการแก้บั๊กแบบหลายขั้นตอน[6]

ข้อจำกัดและแนวโน้ม

SWE-bench กลายเป็นแพลตฟอร์มมาตรฐานสำหรับการประเมิน code agent ที่มีความฉลาด อย่างไรก็ตาม การวิจัยได้เผยให้เห็นข้อจำกัดบางประการด้วย ปัญหาหลักคือ การทดสอบที่ไม่ครบถ้วน: ชุดการทดสอบสำหรับแต่ละโจทย์นำมาจาก pull request เฉพาะและโดยปกติรวมเฉพาะ unit test ที่ถูกเปลี่ยนแปลงระหว่างการแก้ไขข้อผิดพลาด[3] ดังที่การวิเคราะห์ของกลุ่มนักวิทยาศาสตร์จากมหาวิทยาลัย Zhejiang และมหาวิทยาลัย Stuttgart (Wang et al. 2025) แสดงให้เห็น การละเว้น test อื่น ๆ ของโปรเจกต์อาจซ่อนความไม่ถูกต้องของคำตอบบางส่วน[3] การตรวจสอบซ้ำของคำตอบบนชุด test ทั้งหมดของ repository เผยให้เห็นว่าโดยเฉลี่ย 7.8% ของ patch ที่ถูกทำเครื่องหมายว่าสำเร็จใน SWE-bench จริง ๆ แล้ว ไม่ผ่าน test อื่น ๆ ในโปรเจกต์[3] สิ่งนี้นำไปสู่การประเมินค่าสูงเกินไปของตัวชี้วัด «โจทย์ที่แก้ได้» ประมาณ 4-6 จุดเปอร์เซ็นต์[3] กรณีที่ละเอียดอ่อนยิ่งกว่าคือเมื่อ patch ที่สร้างขึ้นผ่าน test ต้นฉบับทั้งหมด แต่ ไม่เทียบเท่า กับคำตอบของนักพัฒนาและเปลี่ยนพฤติกรรมของโปรแกรมไม่ตรงตามที่คาดหวัง ด้วยการสร้าง test case เพิ่มเติม (วิธีการ PatchDiff) นักวิจัยพบว่าเกือบ 30% ของการแก้ไขที่ AI เสนอมีพฤติกรรมต่างจาก patch อ้างอิง และประมาณ 11% ผิดพลาดอย่างชัดเจนแม้จะไม่ถูกตรวจพบโดย test ที่มีอยู่[3] ดังนั้นความสามารถที่แท้จริงของโมเดลอาจถูกประเมินค่าสูงเกินไปหากพึ่งพาเพียงการผ่านชุด test ที่จำกัด ผู้สร้าง SWE-bench ยอมรับช่องโหว่นี้และเน้นย้ำว่า benchmark ควรมีการพัฒนาตามเวลา: ปรับปรุงความครอบคลุมของ test เพิ่มการตรวจสอบการไม่มีผลข้างเคียงที่ไม่ต้องการ ขยายชุดประเภทโจทย์[7] การพัฒนาเครื่องมือการประเมินดังกล่าวเป็นส่วนสำคัญของการเตรียมพร้อมสำหรับการปรากฏตัวของนักพัฒนา AI ที่มีความเป็นอัตโนมัติและทรงพลังมากขึ้นเรื่อย ๆ และประสบการณ์จาก SWE-bench แสดงให้เห็นถึงความจำเป็นในการให้ความสนใจอย่างรอบคอบต่อคุณภาพของ benchmark[7]

SWE-bench แม้จะเป็นเพียงชุดโจทย์แบบคงที่ที่ไม่ครอบคลุมทุกแง่มุมของการเขียนโปรแกรม แต่ก็กลายเป็น มาตรฐานโดยพฤตินัย สำหรับการวิเคราะห์เปรียบเทียบโมเดลด้านโค้ด[3] มันถูกใช้ในงานวิจัยทางวิทยาศาสตร์เพื่อสาธิตวิธีการและอัลกอริทึมใหม่ ๆ รวมถึงโดยกลุ่มวิจัยอุตสาหกรรมเพื่อประเมินศักยภาพของระบบที่ออกแบบมาเพื่อทำให้การเขียนโปรแกรมเป็นอัตโนมัติ[3] การเติบโตอย่างต่อเนื่องของผลลัพธ์บน SWE-bench ในช่วงปี 2023-2025 แสดงให้เห็นอย่างชัดเจนถึงการปรับปรุงอย่างรวดเร็วของความสามารถของ LLM ในการแก้ปัญหาการพัฒนาในทางปฏิบัติ ในขณะเดียวกัน มันยังทำหน้าที่เป็นบารอมิเตอร์ของความซับซ้อน: แม้จะเข้าใกล้ 50-60% ของโจทย์ที่แก้ได้ โมเดลยัง ห่างไกลจากการทดแทนมนุษย์ได้อย่างสมบูรณ์ โดยเฉพาะในสภาวะที่ข้อมูลจำกัดและจำเป็นต้องเข้าใจข้อกำหนดอย่างละเอียด[4][7] อย่างไรก็ตาม ความก้าวหน้าไม่ได้หยุดนิ่ง — ด้วยความคิดริเริ่มเช่น SWE-bench ชุมชนเห็นเป้าหมายและข้อจำกัดของตนอย่างชัดเจน และยังคงเดินหน้าสู่การสร้างนักพัฒนา AI ที่สมบูรณ์แบบซึ่งสามารถเข้าใจและแก้ไขซอร์สโค้ดได้อย่างอัตโนมัติในระดับผู้เชี่ยวชาญมนุษย์[4][7]

ลิงก์

  • SWE-bench บน GitHub
  • leaderboard อย่างเป็นทางการของ SWE-bench

บรรณานุกรม

  • Liang, P. et al. (2022). Holistic Evaluation of Language Models (HELM). arXiv:2211.09110.
  • Chang, Y. et al. (2023). A Survey on Evaluation of Large Language Models. arXiv:2307.03109.
  • Ni, S. et al. (2025). A Survey on Large Language Model Benchmarks. arXiv:2508.15361.
  • Biderman, S. et al. (2024). The Language Model Evaluation Harness (lm-eval): Guidance and Lessons Learned. arXiv:2405.14782.
  • Kiela, D. et al. (2021). Dynabench: Rethinking Benchmarking in NLP. arXiv:2104.14337.
  • Ma, Z. et al. (2021). Dynaboard: An Evaluation‑As‑A‑Service Platform for Holistic Next‑Generation Benchmarking. arXiv:2106.06052.
  • Goel, K. et al. (2021). Robustness Gym: Unifying the NLP Evaluation Landscape. arXiv:2101.04840.
  • Xu, C. et al. (2024). Benchmark Data Contamination of Large Language Models: A Survey. arXiv:2406.04244.
  • Liu, S. et al. (2025). A Comprehensive Survey on Safety Evaluation of LLMs. arXiv:2506.11094.
  • Chiang, W.-L. et al. (2024). Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference. arXiv:2403.04132.
  • Boubdir, M. et al. (2023). Elo Uncovered: Robustness and Best Practices in Language Model Evaluation. arXiv:2311.17295.
  • Huang, L. et al. (2023). A Survey on Hallucination in Large Language Models. arXiv:2311.05232.

หมายเหตุ

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 Jimenez, Carlos E. et al. «SWE-bench: Can Language Models Resolve Real-World GitHub Issues?». arXiv. [1]
  2. ↑ 2.0 2.1 2.2 «SWE-bench/SWE-bench». GitHub. [2]
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 Wang, Shuyang et al. «Are "Solved Issues" in SWE-bench Really Solved Correctly? An Empirical Study». arXiv. [3]
  4. ↑ 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 «Claude SWE-Bench Performance». Anthropic. [4]
  5. ↑ 5.0 5.1 5.2 5.3 5.4 Jain, Sulbha. «SWE Benchmark: LLM evaluation in Software Engineering Setting». Medium. [5]
  6. ↑ 6.0 6.1 6.2 6.3 Hatmaker, Taylor. «AI models still struggle to debug software, Microsoft study shows». TechCrunch. [6]
  7. ↑ 7.00 7.01 7.02 7.03 7.04 7.05 7.06 7.07 7.08 7.09 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 «Introducing SWE-bench Verified». OpenAI. [7]
  8. ↑ 8.0 8.1 8.2 «SWE-bench Leaderboard». [8]
  9. ↑ «SOTA on swebench-verified: relearning the bitter lesson». Hacker News (Y Combinator). [9]
Retrieved from "https://systems-analysis.info/int/index.php?title=SWE-bench_(benchmark)_(TH)&oldid=6534"