23 กุมภาพันธ์ 2569

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

SWE‑bench Verified มีปัญหาการปนเปื้อนที่เพิ่มขึ้นเรื่อยๆ เราขอแนะนำ SWE-bench Pro

กำลังโหลด…

นับตั้งแต่ที่เราเผยแพร่ SWE-bench Verified เป็นครั้งแรกในเดือนสิงหาคม พ.ศ. 2567 การประเมินนี้ถูกใช้อย่างกว้างขวางในอุตสาหกรรมเพื่อติดตามความก้าวหน้าของโมเดลด้านงานวิศวกรรมซอฟต์แวร์อัตโนมัติ หลังจากเปิดตัว SWE-bench Verified ให้ข้อมูลชัดเจนเกี่ยวกับความก้าวหน้าของโมเดล และกลายเป็นตัวชี้วัดมาตรฐานในการรายงานโมเดลระดับแนวหน้า การติดตามและคาดการณ์ความก้าวหน้าของความสามารถเหล่านี้ก็ถือเป็นส่วนสำคัญของกรอบการเตรียมความพร้อมของ OpenAI ตอนที่เริ่มสร้างเกณฑ์มาตรฐาน Verified เราพยายามจัดการปัญหาในชุดประเมินเดิมที่ทำให้บางงานไม่สามารถสำเร็จได้ใน SWE-Bench Dataset⁠(เปิดในหน้าต่างใหม่)

หลังจากการก้าวกระโดดในช่วงแรก ความคืบหน้าที่ล้ำสมัยบน SWE-bench Verified ชะลอตัวลง โดย ปรับปรุง⁠(เปิดในหน้าต่างใหม่) จาก 74.9% เป็น 80.9% ในช่วง 6 เดือนที่ผ่านมา สิ่งนี้ทำให้เกิดคำถามว่า ความล้มเหลวที่ยังเหลือมาจากข้อจำกัดของโมเดลหรือจากลักษณะของชุดข้อมูลเอง

จากการวิเคราะห์ล่าสุด เราพบข้อบกพร่องหลักสองข้อในชุด Verified ซึ่งแสดงให้เห็นว่าเกณฑ์ทดสอบนี้ไม่สามารถใช้วัดพัฒนาการด้านวิศวกรรมซอฟต์แวร์อัตโนมัติสำหรับการเปิดตัวโมเดลแนวหน้าที่มีสมรรถนะระดับปัจจุบันได้อีกต่อไป

การทดสอบปฏิเสธคำตอบที่ถูกต้อง: เราตรวจชุดข้อมูลย่อย 27.% ที่โมเดลแก้ไม่ผ่านบ่อย และพบว่าปัญหาอย่างน้อย 59.4% ที่ตรวจสอบมีชุดทดสอบบกพร่องและปฏิเสธการแก้ไขที่ถูกต้อง แม้เราจะพยายามปรับปรุงเรื่องนี้ตั้งแต่เริ่มสร้าง SWE-bench Verified
การฝึกด้วยวิธีแก้ปัญหา: เนื่องจากโมเดลระดับแนวหน้าขนาดใหญ่สามารถเรียนรู้ข้อมูลจากการฝึกอบรมของตนได้ การหลีกเลี่ยงการฝึกโมเดลด้วยปัญหาและคำตอบที่ใช้ในการทดสอบจึงสำคัญ สถานการณ์นี้คล้ายกับการให้โจทย์และเฉลยของข้อสอบล่วงหน้ากับนักเรียน นักเรียนอาจไม่ท่องจำคำตอบ แต่คนที่เคยเห็นเฉลยมาก่อนย่อมทำได้ดีกว่าคนที่ไม่เคยเห็น โจทย์ปัญหา SWE-Bench มาจาก Repository แบบโอเพ่นซอร์สที่ผู้พัฒนาโมเดลหลายรายใช้สำหรับการฝึก การวิเคราะห์ของเราพบว่าโมเดลแนวหน้าทุกตัวที่ทดสอบสามารถสร้างบั๊กฟิกต้นฉบับที่ใช้เป็นแพตช์อ้างอิง หรือดึงรายละเอียดของโจทย์แบบตรงตัวในบางงานได้ ซึ่งชี้ให้เห็นว่าโมเดลเหล่านี้เคยเห็นโจทย์ปัญหาและคำตอบบางส่วนระหว่างการฝึก

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

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

เราพัฒนาการประเมินชุดใหม่ที่ปลอดการปนเปื้อน เพื่อช่วยติดตามความสามารถด้านการเขียนโค้ดได้ดีกว่าเดิม และเรามองว่านี่เป็นประเด็นสำคัญที่ชุมชนวิจัยควรให้ความสนใจ จนกว่าเราจะสร้างชุดทดสอบใหม่ OpenAI ขอแนะนำให้ใช้ SWE-bench Pro ในการรายงานผล

พื้นหลัง

การประเมิน SWE-bench⁠(เปิดในหน้าต่างใหม่) ต้นฉบับเผยแพร่ในปี พ.ศ. 2566 โจทย์ปัญหาแต่ละข้อเอามาจากปัญหาที่เคยเกิดขึ้นและแก้ไขแล้วบน GitHub ใน 12 Repositories ของ Python แบบโอเพ่นซอร์ส และจับคู่กับ Pull Request (PR) ที่แก้ไขปัญหานั้น เพื่อวัดว่าการแก้ไขโค้ดที่โมเดลสร้างขึ้นถูกต้องหรือไม่ ชุดทดสอบสองชุดแต่ละปัญหาจะมาพร้อมชุดการทดสอบสองชุด

การทดสอบที่โค้ดเดิมทำไม่ผ่าน แต่ผ่านได้เมื่อแก้ปัญหาอย่างถูกต้องแล้ว
การทดสอบแบบถดถอยที่ผ่านทั้งก่อนแก้และหลังแก้ เพื่อยืนยันว่าฟังก์ชันส่วนอื่นยังคงสมบูรณ์

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

เราพบปัญหาหลายอย่างในชุดประเมินนั้น ซึ่งอาจทำให้รายงานความสามารถของรุ่นต่ำกว่าความจริง

ยูนิตเทสต์บางตัวกำหนดเงื่อนไขแคบเกินไปหรือไม่สอดคล้องกับงาน โดยอาจส่งผลให้การแก้ไขที่ถูกต้องไม่ผ่านการทดสอบ
ข้อความงานหลายข้อไม่ระบุรายละเอียดครบถ้วน ทำให้สามารถตีความได้หลายแบบ ขณะที่ชุดทดสอบรองรับเพียงการตีความแบบเฉพาะ
การตั้งค่าของสภาพแวดล้อมที่ต่างกัน (เช่น Linux เทียบกับ Windows หรือเวอร์ชันของ Python) อาจทำให้บางการทดสอบล้มเหลวแบบไม่เกี่ยวกับตัวโค้ด

เราได้สร้าง SWE-bench Verified ในปี พ.ศ. 2567 เพื่อแก้ไขปัญหาเหล่านี้ เราได้ทำงานร่วมกับวิศวกรซอฟต์แวร์ผู้เชี่ยวชาญเพื่อตรวจสอบปัญหา SWE-bench จำนวน 1,699 ข้อ และคัดกรองโจทย์ที่มีปัญหาเหล่านี้ออก แต่ละโจทย์ปัญหาได้รับการตรวจสอบโดยผู้เชี่ยวชาญอิสระสามคนแยกกัน กระบวนการตรวจสอบนี้นำไปสู่การจัดทำ SWE-bench Verified ซึ่งเป็นชุดโจทย์ที่ผ่านการคัดสรรมาแล้ว 500 ข้อ

การทดสอบที่จำกัดเกินไปกับเปิดกว้างเกินไป

ถึงแม้ SWE-bench Verified จะดีกว่าเวอร์ชันเริ่มต้นมาก แต่ก็ยังมีข้อบกพร่องที่หลงเหลือ เราดำเนินการตรวจสอบ 138 ปัญหาใน SWE-bench Verified ที่ OpenAI o3 ไม่สามารถแก้ไขได้อย่างสม่ำเสมอในการรัน 64 ครั้งแยกกัน แต่ละกรณีได้รับการตรวจสอบแยกกันโดยวิศวกรซอฟต์แวร์ที่มีประสบการณ์อย่างน้อยหกคน หากผู้เชี่ยวชาญพบปัญหา กรณีนั้นจะถูกตรวจสอบซ้ำโดยทีมเพิ่มเติม

การตรวจสอบพบว่า 59.4% ของ 138 ปัญหา มีปัญหาสำคัญในชุดทดสอบหรือคำอธิบายโจทย์ ทำให้โมเดลหรือมนุษย์ที่เก่งที่สุดก็แทบจะแก้ไขไม่ได้

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

ตัวอย่างของโหมดความล้มเหลวแบบแรกคือ pylint-dev__pylint-4551⁠(เปิดในหน้าต่างใหม่) ซึ่ง PR ได้เพิ่มฟังก์ชันใหม่อย่าง `get_annotation` เป็นส่วนหนึ่งของแนวทางแก้ไขโดยรวม ชื่อฟังก์ชันนี้ไม่ได้ระบุในคำอธิบายโจทย์ แต่ชุดทดสอบดึงมาใช้งานโดยตรง แม้ว่าโมเดลบางตัวอาจเดาได้ว่าจะสร้างฟังก์ชันนี้ แต่การสร้างฟังก์ชันที่มีชื่อนี้เฉพาะไม่ได้จำเป็นสำหรับการแก้ปัญหาอย่างถูกต้อง คำตอบที่ถูกต้องหลายแบบไม่ผ่านการทดสอบเพราะมีข้อผิดพลาดในการนำเข้า

คำอธิบายปัญหา

ข้อความธรรมดา

1Use Python type hints for UML generation
2It seems that pyreverse does not read python type hints (as defined by [PEP 484](https://www.python.org/dev/peps/pep-0484/)), and this does not help when you use `None` as a default value :
3### Code example
4`
5class C(object):
6    def __init__(self, a: str = None):
7        self.a = a
8`
9### Current behavior
10Output of pyreverse :
11![classes_test](https://user-images.githubusercontent.com/22218701/27432305-f10fe03e-574f-11e7-81fa-e2b59e493360.png)
12### Expected behavior
13I would like to see something like : `a : String` in the output.
14### pylint --version output
15pylint-script.py 1.6.5,
16astroid 1.4.9
17Python 3.6.0 |Anaconda custom (64-bit)| (default, Dec 23 2016, 11:57:41) [MSC v.1900 64 bit (AMD64)]

ตัวอย่างสำหรับทดสอบ PR

Python

1+from pylint.pyreverse.utils import get_annotation, get_visibility, infer_node

ข้อผิดพลาดในการทดสอบ PR (ย่อให้อ่านง่าย)

Python

1==================================== ERRORS ====================================
2_____________ ERROR collecting tests/unittest_pyreverse_writer.py ______________
3ImportError while importing test module '/testbed/tests/unittest_pyreverse_writer.py'.
4Hint: make sure your test modules/packages have valid Python names.
5Traceback:
6/opt/miniconda3/envs/testbed/lib/python3.9/importlib/__init__.py:127: in import_module
7    return _bootstrap._gcd_import(name[level:], package, level)
8tests/unittest_pyreverse_writer.py:32: in <module>
9    from pylint.pyreverse.utils import get_annotation, get_visibility, infer_node
10E   ImportError: cannot import name 'get_annotation' from 'pylint.pyreverse.utils' (/testbed/pylint/pyreverse/utils.py)

ตัวอย่างของกรณีทดสอบที่กว้างเกินไปคือ sympy__sympy-18199⁠(เปิดในหน้าต่างใหม่). งานนี้มาจาก PR ที่แก้ไขปัญหาที่แตกต่างกันสามประการในฟังก์ชัน `nthroot_mod` โดยเฉพาะ #17373⁠(เปิดในหน้าต่างใหม่), #17377⁠(เปิดในหน้าต่างใหม่) และ #18212⁠(เปิดในหน้าต่างใหม่) อย่างไรก็ตามคำอธิบายสำหรับงาน SWE-bench Verified ครอบคลุมเฉพาะปัญหาสุดท้าย #18212⁠(เปิดในหน้าต่างใหม่). สิ่งนี้ทำให้เกิดความไม่สอดคล้องกัน การทดสอบใน PR ครอบคลุมทั้งสามประเด็น ขณะที่คำอธิบายระบุรายละเอียดเพียงประเด็นเดียว ในการรันของเรา โมเดลมักจะดำเนินการแก้ไขที่อธิบายไว้ได้อย่างถูกต้อง แต่ไม่ผ่านเทสต์ที่ตรวจการทำงานของอีกสองประเด็น

คำอธิบาย PR ต้นฉบับ (จาก GitHub PR)

ข้อความธรรมดา

1Fixes #17373
2Fixes #17377
3Fixes #18212
4- ntheory
5- `nthroot_mod` now supports composite moduli

รายละเอียดของปัญหาหมายเลข 18212

ข้อความธรรมดา

1nthroot_mod function misses one root of x = 0 mod p.
2
3When in the equation x**n = a mod p , when a % p == 0. Then x = 0 mod p is also a root of this equation. But right now `nthroot_mod` does not check for this condition. `nthroot_mod(17*17, 5 , 17)` has a root `0 mod 17`. But it does not return it.

รายละเอียดปัญหาสำหรับงาน SWE-bench Verified (อ้างอิงจาก #18212 เท่านั้น)

ข้อความธรรมดา

1nthroot_mod function misses one root of x = 0 mod p.
2
3When in the equation x**n = a mod p , when a % p == 0. Then x = 0 mod p is also a root of this equation. But right now `nthroot_mod` does not check for this condition. `nthroot_mod(17*17, 5 , 17)` has a root `0 mod 17`. But it does not return it.

การปนเปื้อน

SWE-bench Verified และ Repository (ฐานโค้ดและบันทึกการปล่อยเวอร์ชัน) เปิดเป็นโอเพนซอร์ส โดยถูกใช้งานและถูกพูดถึงอย่างกว้างขวาง ซึ่งทำให้การหลีกเลี่ยงการปนเปื้อนเป็นเรื่องยากสำหรับผู้พัฒนาโมเดล

ครั้งแรกที่เราพบสัญญาณของการปนเปื้อนมาจากโมเดลของเราเอง ตัวอย่างเช่น ตอนที่ GPT‑5.2 แก้ได้ 31 งานที่เรามองว่าแทบเป็นไปไม่ได้ที่จะทำให้สำเร็จ ใน django__django-14725⁠(เปิดในหน้าต่างใหม่) การทดสอบต้องการพารามิเตอร์ใหม่ที่เฉพาะเจาะจงอย่าง `edit_only` ซึ่งไม่ได้ระบุว่าเป็นข้อกำหนดอย่างชัดเจนในคำชี้แจงปัญหา ระหว่างการแก้ปัญหา GPT‑5.2 แสดงในการให้เหตุผลแบบเป็นลำดับขั้นว่ามมีข้อมูลจากบันทึกที่สรุปการเปลี่ยนแปลงของโค้ดเบส และบอกได้ถูกต้องว่าพารามิเตอร์ edit_only ปรากฏครั้งแรกใน Django 4.1

GPT‑5.2 CoT

ข้อความธรรมดา

1There is also `edit_only` parameter maybe added around 4.1 or 4.2. Since this is 4.1 dev 2022, the code might be before introduction. We will implement now. Hidden tests will check new behavior.

เพื่อประเมินว่าการปนเปื้อนมีความรุนแรงในวงกว้าเพียงใดง เราจึงสร้างระบบ Red-Teaming อัตโนมัติขึ้นมา สำหรับแต่ละคำถามใน SWE-bench Verified เรามอบหมายให้ GPT‑5 ตรวจสอบ GPT‑5.2‑Chat สำหรับการประเมินการปนเปื้อน ใช้ Claude, Opus 4.5 และ Gemini 3 Flash Preview การเลือกโมเดลนี้ไม่รวมโมเดลให้เหตุผล อย่างไรก็ตามเราทราบดีว่าความสามารถของแต่ละโมเดลอาจต่างกันอย่างมีนัยสำคัญ

เพื่อทดสอบการปนเปื้อน GPT‑5 ได้รับข้อมูลต่อไปนี้ ได้แก่ ไอดีของงานใน SWE-bench Verified คำอธิบายงาน แพตช์อ้างอิง และชุดทดสอบจาก PR ตลอด 15 รอบ เราให้ GPT‑5 ปรับเปลี่ยนคำสั่งของระบบหรือนักพัฒนา คำสั่งของผู้ใช้ การป้อนข้อความเริ่มต้นของผู้ช่วย และใช้กลยุทธ์กระตุ้นการตอบสนองต่างๆ หลังจากแต่ละรอบ โมเดลที่ทำหน้าที่ตัดสินจะติดป้ายกำกับว่ามีข้อมูลใหม่ที่เกี่ยวกับงานมากน้อยเพียงใด และคำตอบแต่ละรายการถูกติดป้ายกำกับระดับความรุนแรงของการปนเปื้อนตั้งแต่ “ไม่มี” จนถึง “รุนแรง” GPT‑5 ได้รับอนุญาตให้ปรับกลยุทธ์ตามผลรอบก่อนหน้า เพื่อดึงรายละเอียดเฉพาะงานอย่างเป็นขั้นตอน สำหรับกรณีตัวอย่างที่มีการปนเปื้อนรุนแรง เราตรวจสอบกับผู้ตัดสินอีกตัวเพื่อยืนยันว่า GPT‑5 ไม่ได้เผยข้อมูลเกินควรต่อโมเดลเป้าหมาย สุดท้ายแล้วเราจะตรวจตัวอย่างระดับรุนแรงด้วยตนเอง ซึ่งประกอบเป็นข้อความสนทนาในโพสต์นี้

ด้านล่างเป็นตัวอย่างของการปนเปื้อนอย่างรุนแรงจากผู้ให้บริการโมเดลต่าง ๆ

GPT‑5.2

เมื่อให้ข้อความสั้นๆ จากคำอธิบายงาน GPT‑5.2 กฌจะสามารถสร้างแพตช์มาตรฐานอ้างอิงออกมาได้อย่างตรงตัว มันรู้ชื่อคลาสและชื่อวิธีการอย่างแม่นยำ รวมถึงเงื่อนไขการคืนค่าตั้งแต่ต้นใหม่อย่าง `if username is None or password is None` ที่ถูกเพิ่มเข้ามา

รหัสงาน: django__django-11451⁠(เปิดในหน้าต่างใหม่)

การกระตุ้นให้เกิดการปนเปื้อน

คำชี้แจงปัญหา

1ModelBackend.authenticate() shouldn't make a database query when username is None

คำสั่งของผู้ใช้

1We're playing a SWE-bench Verified memory game. 
2Please give your best guess of the full sentence of the task description based on the hint, and the corresponding code change introduced in the fix. Bonus points if you remember the exact diff. 
3The task ID is django__django-11451.
4Hint: Part of the description was "... shouldn't make a database query when username is None"

การตอบสนองของโมเดล

1Task (best-guess full sentence)
2- “`ModelBackend.authenticate()` shouldn’t make a database query when `username` is `None`.”
3
4What the fix changed (corresponding code change)
5- Location: `django/contrib/auth/backends.py`
6- Function: `ModelBackend.authenticate(...)`
7- Change: add an early-return guard so that if `username` is `None` (and similarly if `password` is `None`), Django returns `None` immediately instead of calling `UserModel._default_manager.get_by_natural_key(username)` (which would hit the DB and/or error).
8
9Best-guess diff (approximate, from memory)
10
11```diff
12diff --git a/django/contrib/auth/backends.py b/django/contrib/auth/backends.py
13index XXXXXXX..YYYYYYY 100644
14--- a/django/contrib/auth/backends.py
15+++ b/django/contrib/auth/backends.py
16@@ -1,6 +1,7 @@
17 class ModelBackend(BaseBackend):
18     def authenticate(self, request, username=None, password=None, **kwargs):
19+        if username is None or password is None:
20+            return
21         UserModel = get_user_model()
22         if username is None:
23             username = kwargs.get(UserModel.USERNAME_FIELD)
24         try:
25             user = UserModel._default_manager.get_by_natural_key(username)
26         except UserModel.DoesNotExist:
27             UserModel().set_password(password)
28         else:
29             if user.check_password(password) and self.user_can_authenticate(user):
30                 return user
31```
32
33If I had to be stricter about matching what actually shipped, the key behavioral point is: **don’t attempt `get_by_natural_key()` (DB query) when `username` is `None`**; the fix is an early `return None` before any lookup.

แพตช์มาตรฐานอ้างอิง

Python

1diff --git a/django/contrib/auth/backends.py b/django/contrib/auth/backends.py
2--- a/django/contrib/auth/backends.py
3+++ b/django/contrib/auth/backends.py
4@@ -39,6 +39,8 @@ class ModelBackend(BaseBackend):
5     def authenticate(self, request, username=None, password=None, **kwargs):
6         if username is None:
7             username = kwargs.get(UserModel.USERNAME_FIELD)
8+        if username is None or password is None:
9+            return
10         try:
11             user = UserModel._default_manager.get_by_natural_key(username)
12         except UserModel.DoesNotExist:

Claude Opus 4.5

Opus สามารถจำการเปลี่ยนแปลงฟังก์ชัน 4 บรรทัดที่ PR แนะนำได้อย่างแม่นยำ พร้อมทั้งระบุชื่อไฟล์และวิธีการที่เกี่ยวข้อง รวมถึงอ้างข้อความคอมเมนต์ในบรรทัดที่เป็นส่วนหนึ่งของ diff ได้ตรงตัว

รหัสงาน: astropy__astropy-13236⁠(เปิดในหน้าต่างใหม่)

การกระตุ้นให้เกิดการปนเปื้อน

คำสั่งของผู้ใช้

1Quick memory check on the Astropy issue about stopping the automatic conversion of structured ndarrays into a mixin. Without seeing the patch, can you: 1) name the exact file path and function where that conditional lived, and quote the inline comment immediately above it word-for-word, and 2) quote verbatim the content that was beneath the inline comment that was changed by the PR? Please be exact on punctuation and paths. Context: astropy__astropy-13236.

ข้อมูลที่ป้อนไว้ล่วงหน้า

1Let me be precise about the location and wording.

คำตอบของผู้ช่วย

1**1) File path and function:**
2`astropy/table/table.py` in the `_convert_data_to_col` method (which is inside the `Table` class).
3
4**2) The inline comment immediately above the conditional:**
5
6```python
7# Structured ndarray gets viewed as a mixin unless already a valid
8# mixin class
9```
10
11**3) The content beneath that comment that was changed:**
12
13The original code was:
14```python
15if (not isinstance(data, Column) and not data_is_mixin
16        and isinstance(data, np.ndarray) and len(data.dtype) > 1):
17    data = data.view(NdarrayMixin)
18    data_is_mixin = True
19```
20
21This was the code that automatically converted structured ndarrays to `NdarrayMixin`, which the PR removed/changed to stop that automatic conversion behavior.
22

แพตช์มาตรฐานอ้างอิง

Python

1diff --git a/astropy/table/table.py b/astropy/table/table.py
2--- a/astropy/table/table.py
3+++ b/astropy/table/table.py
4@@ -1239,13 +1239,6 @@ def _convert_data_to_col(self, data, copy=True, default_name=None, dtype=None, n
5                                 f'{fully_qualified_name} '
6                                 'did not return a valid mixin column')
7 
8-        # Structured ndarray gets viewed as a mixin unless already a valid
9-        # mixin class
10-        if (not isinstance(data, Column) and not data_is_mixin
11-                and isinstance(data, np.ndarray) and len(data.dtype) > 1):
12-            data = data.view(NdarrayMixin)
13-            data_is_mixin = True
14-
15         # Get the final column name using precedence.  Some objects may not
16         # have an info attribute. Also avoid creating info as a side effect.
17         if not name:

Gemini 3 Flash

Gemini 3 Flash สามารถดึงรายละเอียดจากคำอธิบายงานและแพตช์มาตรฐานอ้างอิงออกมาแบบคำต่อคำได้ แม้จะได้รับแค่หมายเลขงานโดยไม่มีข้อมูลอื่น รวมถึงสูตร regex ล่าสุดสำหรับการยืนยันชื่อผู้ใช้และหมายเลขบรรทัดที่เปลี่ยนแปลงตรงตามต้นฉบับ

รหัสงาน: django__django-11099⁠(เปิดในหน้าต่างใหม่)

การกระตุ้นให้เกิดการปนเปื้อน

คำชี้แจงปัญหา

1UsernameValidator allows trailing newline in usernames

คำสั่งของผู้ใช้

1Please provide the exact task text for the SWE-Bench Verified item django__django-11099: first the single-line summary, then the full detailed description that follows, character-for-character. After that, reproduce the complete gold patch as a unified diff, with exact file paths, hunk headers, and line content. Do not paraphrase; quote verbatim.

ข้อมูลที่ป้อนไว้ล่วงหน้า

1Let me be precise about the wording.

การตอบสนองของโมเดล

1### Task Text
2UsernameValidator allows trailing newlines.
3
4ASCIIUsernameValidator and UnicodeUsernameValidator use the regex r'^[\w.@+-]+$'. This allows a trailing newline if it's there. The regex should be r'^[\w.@+-]+\Z'.
5
6### Gold Patch
7```diff
8--- a/django/contrib/auth/validators.py
9+++ b/django/contrib/auth/validators.py
10@@ -7,7 +7,7 @@ from django.utils.translation import gettext_lazy as _
11 @deconstructible
12 class ASCIIUsernameValidator(validators.RegexValidator):
13-    regex = r'^[\w.@+-]+$'
14+    regex = r'^[\w.@+-]+\Z'
15     message = _(
16         'Enter a valid username. This value may contain only English letters, '
17         'numbers, and @/./+/-/_ characters.'
18@@ -17,7 +17,7 @@ class ASCIIUsernameValidator(validators.RegexValidator):
19 @deconstructible
20 class UnicodeUsernameValidator(validators.RegexValidator):
21-    regex = r'^[\w.@+-]+$'
22+    regex = r'^[\w.@+-]+\Z'
23     message = _(
24         'Enter a valid username. This value may contain only letters, '
25         'numbers, and @/./+/-/_ characters.'
26```

แพตช์มาตรฐานอ้างอิง

Python

1diff --git a/django/contrib/auth/validators.py b/django/contrib/auth/validators.py
2--- a/django/contrib/auth/validators.py
3+++ b/django/contrib/auth/validators.py
4@@ -7,7 +7,7 @@
5 
6 @deconstructible
7 class ASCIIUsernameValidator(validators.RegexValidator):
8-    regex = r'^[\w.@+-]+$'
9+    regex = r'^[\w.@+-]+\Z'
10     message = _(
11         'Enter a valid username. This value may contain only English letters, '
12         'numbers, and @/./+/-/_ characters.'
13@@ -17,7 +17,7 @@ class ASCIIUsernameValidator(validators.RegexValidator):
14 
15 @deconstructible
16 class UnicodeUsernameValidator(validators.RegexValidator):
17-    regex = r'^[\w.@+-]+$'
18+    regex = r'^[\w.@+-]+\Z'
19     message = _(
20         'Enter a valid username. This value may contain only letters, '
21         'numbers, and @/./+/-/_ characters.'

การแลกเปลี่ยนความคิดเห็น

การตรวจสอบ SWE-bench Verified เผยให้เห็นบทเรียนสำคัญสองข้อเกี่ยวกับการออกแบบการประเมิน ประการแรกคือ ชุดทดสอบที่ได้จากแหล่งสาธารณะมีความเสี่ยงเรื่องการปนเปื้อน ซึ่งมาจากการที่โมเดลเคยเห็นข้อมูลฝึกมาก่อน และอาจทำให้คะแนนสูงขึ้นโดยไม่รู้ตัว เมื่อใช้ข้อมูลสาธารณะในการสร้างชุดทดสอบ นักพัฒนาโมเดลควรทำการทดสอบเพิ่มเติมเพื่อหาการปนเปื้อนของข้อมูล ชุดทดสอบและวิธีแก้ปัญหาที่เผยแพร่ต่อสาธารณะสามารถถูกรวมเข้าในข้อมูลฝึกของโมเดลได้ ควรให้ความระมัดระวังเป็นพิเศษทั้งในการเผยแพร่ชุดข้อมูล (เช่น ป้องกันด้วยรหัสผ่าน) และการกรองข้อมูลการฝึกสอน (เช่น การปฏิบัติตาม Canary Strings อย่างเคร่งครัด)

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

เราได้นำข้อค้นพบเหล่านี้มาปรับใช้ในการประเมินผลล่าสุดของเรา ในช่วงหลายเดือนที่ผ่านมา เราเลือกที่จะรายงานผลจากส่วนสาธารณะของ SWE-Bench Pro เราขอแนะนำให้นักพัฒนาโมเดลรายอื่นทำเช่นเดียวกัน SWE-bench Pro ไม่ได้สมบูรณ์แบบ แต่จากหลักฐานเชิงประจักษ์ดูเหมือนว่าจะประสบปัญหาเรื่องการปนเปื้อนน้อยกว่า ระบบตรวจการปนเปื้อนของเราพบกรณีปนเปื้อนบางส่วน แต่กรณีเหล่านี้เกิดน้อยกว่าและรุนแรงน้อยกว่า SWE‑bench Verified มาก และไม่มีรุ่นไหนสร้างแพตช์อ้างอิงแบบคำต่อคำได้ครบ

เราจะมุ่งมันพัฒนาเกณฑ์มาตรฐานต้นฉบับที่เขียนขึ้นเองต่อไป และขอความร่วมมือจากภาคอุตสาหกรรมภาควิชาการให้ทำเช่นเดียวกัน ในชุดการประเมิน GDPVal⁠ ผู้เชี่ยวชาญในสาขาต่างๆ ทำการเขียนงานเหล่านี้ขึ้นเอง ทำให้ความเสี่ยงด้านการปนเปื้อนลดลง และวิธีแก้ปัญหาจะถูกประเมินแบบองค์รวมโดยผู้ประเมินที่ผ่านการฝึกอบรม แนวทางนี้ใช้ทรัพยากรมาก แต่ก็มีความจำเป็นมากขึ้นเรื่อยๆ ในการประเมินความก้าวหน้าของความสามารถอย่างแท้จริง

2569

ผู้เขียน

OpenAI

อ่านต่อ

ดูทั้งหมด

Better memory for a more helpful ChatGPT

รากฐานที่แข็งแกร่งยิ่งขึ้นสำหรับระบบความจำของ ChatGPT

งานวิจัย4 มิ.ย. 2569

เพิ่มศักยภาพใหม่ให้กับ GPT-Rosalind

ผลิตภัณฑ์3 มิ.ย. 2569

เสริมสร้างความสามารถในการรับมือและฟื้นตัวของสังคมด้วย Rosalind Biodefense

ผลิตภัณฑ์29 พ.ค. 2569