8 กรกฎาคม 2569

การแยกผลลัพธ์ที่แท้จริงออกจากข้อผิดพลาดในการประเมินการเขียนโค้ด

จากการตรวจสอบอย่างละเอียด เราพบปัญหาของงานใน SWE-Bench Pro เป็นวงกว้าง และประเมินว่างานประมาณ 30% มีข้อบกพร่องจนใช้งานไม่ได้

กำลังโหลด…

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

เมื่อเร็วๆ นี้ เราได้ตรวจสอบว่า SWE-bench Verified ซึ่งเป็นหนึ่งในเกณฑ์มาตรฐานด้านการเขียนโค้ดที่นิยมใช้กันมากที่สุด มีปัญหาด้านการออกแบบและการปนเปื้อนของข้อมูลอย่างร้ายแรง และพบว่าการประเมินดังกล่าวไม่สามารถสะท้อนความสามารถด้านการพัฒนาซอฟต์แวร์ได้อย่างมีความหมายอีกต่อไป ในขณะนั้นเราได้สนับสนุนให้ชุมชนนักพัฒนาหันไปใช้ SWE-Bench Pro แทน

SWE-Bench Pro⁠(เปิดในหน้าต่างใหม่) ได้รับการออกแบบขึ้นเพื่อพัฒนาต่อยอดจาก SWE-bench Verified โดยทดสอบโมเดลกับงานที่ต้องดำเนินการต่อเนื่องยาวนานขึ้นและโจทย์การเขียนโค้ดที่สมจริงยิ่งขึ้น เพื่อให้ติดตามความสามารถด้านการเขียนโค้ดแบบเอเจนต์ได้ดียิ่งขึ้น เช่นเดียวกับ SWE-bench Verified งานต่างๆ ถูกคัดเลือกโดยอัตโนมัติจากประวัติการเปลี่ยนแปลงฟีเจอร์ในชุด Repository ทั้งแบบสาธารณะและแบบส่วนตัว โมเดลต้องพัฒนาโซลูชันที่สามารถผ่านชุดทดสอบใหม่สำหรับฟีเจอร์นั้นได้ โดยไม่ทำให้ฟังก์ชันการทำงานเดิมเสียหาย ในชุดข้อมูลทดสอบสาธารณะจำนวน 731 งาน โมเดลระดับแนวหน้ามีอัตราความสำเร็จเพิ่มขึ้นจาก 23.3% เป็น 80.3% ภายในระยะเวลา 8 เดือน

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

เราพบหลักฐานว่าชุดข้อมูลส่วนสำคัญมีปัญหาที่ทำให้ระบบทำงานผิดพลาด ไปป์ไลน์การวิเคราะห์ข้อมูลของเราตรวจพบปัญหาใน 200 รายการ ซึ่งคิดเป็น 27.4% ในขณะที่กระบวนการตรวจสอบโดยมนุษย์พบรายการที่มีปัญหาจำนวน 249 รายการ คิดเป็น 34.1%

ปัญหาต่างๆ ส่วนใหญ่แบ่งออกเป็นสี่หมวดหมู่:

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

ผลการศึกษาของเราแสดงให้เห็นถึงความท้าทายในการจัดทำชุดทดสอบที่ยากแต่มีความเป็นธรรม และการใช้เอเจนต์ที่มีบทบาทมากขึ้นในการตรวจสอบคุณภาพข้อมูลในระดับที่ใหญ่ขึ้น จากผลลัพธ์เหล่านี้ เราประเมินว่างานใน SWE-bench Pro ประมาณ 30% มีปัญหา และแนะนำให้นักพัฒนาโมเดลตรวจสอบผลลัพธ์อย่างรอบคอบ

วิธีการ

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

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

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

การตรวจสอบโดยเอเจนต์ภายใต้การกำกับดูแลของมนุษย์

ปัญหาแต่ละรายการที่ถูกทำเครื่องหมายจะได้รับการตรวจสอบโดยเอเจนต์ที่ใช้ Codex เป็นพื้นฐาน ซึ่งได้รับสิทธิ์เข้าถึง Repository และสภาพแวดล้อมของงาน แนวทางนี้ช่วยให้สามารถแยกแยะความคลุมเครือของงานที่ยังสมเหตุสมผล ซึ่งมักสามารถแก้ไขได้โดยการศึกษาโค้ดใกล้เคียงและแนวปฏิบัติของ Repository ออกจากการระบุรายละเอียดไม่เพียงพออย่างแท้จริง เอเจนต์สามารถรันการทดสอบ ตรวจสอบไฟล์ใน Repo และตรวจสอบความพยายามของโมเดล รวมถึงรูปแบบความล้มเหลวที่พบบ่อยของโมเดลในงานนั้นได้ หลังจากดำเนินการตรวจประเมินเชิงลึกหลายรอบโดยแยกกันอย่างอิสระแล้ว นักวิจัยจะตรวจสอบสรุปผล ตัดสินผลขั้นสุดท้าย และติดป้ายกำกับประเภทของปัญหาที่มีแนวโน้มจะเกิดขึ้น

แคมเปญการติดป้ายกำกับข้อมูลโดยมนุษย์

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

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

ผู้ตรวจสอบที่เป็นมนุษย์มีแนวโน้มที่จะระบุว่างานมีความบกพร่องได้บ่อยกว่าเอเจนต์ผู้ตรวจสอบ นอกจากนี้ ทั้งสองแนวทางการตรวจสอบยังมีความเห็นไม่ตรงกันอยู่บ้างในเรื่องการจัดหมวดหมู่ของปัญหา แต่ในบรรดาโจทย์ที่ถูกทำเครื่องหมายไว้ทั้งหมด ไม่มีโจทย์ข้อใดเลยที่ผู้ตรวจสอบที่เป็นมนุษย์ส่วนใหญ่ระบุว่า “ไม่มีปัญหา” ในบรรดาหมวดหมู่ที่ไปป์ไลน์ของเอเจนต์ทำเครื่องหมายไว้ การตัดสินของผู้ตรวจสอบมีความเห็นตรงกันถึง 74% ของเคสทั้งหมด

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

รูปแบบความล้มเหลว

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

This task involves normalizing table-of-contents entries and rendering them back to Markdown via TocEntry.to_markdown(). The task prompt specifies serialization down to character-level spacing, describing how exact spacing and pipes are enforced, and gives examples such as " | Chapter 1 | 1" and "** | Chapter 1 | 1":

ไม่มี

1"[space]| Chapter 1 | 1"
2"**[space]| Chapter 1 | 1"
3"[space]| Just title | "

The hidden test_to_markdown assertions instead require " | Chapter 1 | 1" and "** | Chapter 1 | 1":

ไม่มี

1"[space][space]| Chapter 1 | 1"
2"**[space][space]| Chapter 1 | 1"
3"[space][space]| Just title | "

There are two leading spaces in the hidden tests, but the example given to the model only contains one leading space. If a model rightly follows the given prompt, that one-character difference would fail the hidden test cases and the task would be marked incorrect.

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

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

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

เราหวังว่าชุมชนด้านการประเมินในวงกว้างจะร่วมกันพัฒนาเกณฑ์มาตรฐานชุดใหม่ๆ ที่สร้างโดยนักพัฒนาซอฟต์แวร์ที่มีประสบการณ์ เพื่อทดสอบขีดความสามารถของโมเดลโดยเฉพาะ แนวทางดังกล่าวจะช่วยรักษาทั้งมาตรฐานที่สูงและความสมจริงที่เราต้องการใช้วัดความสามารถของโมเดล พร้อมทั้งเอื้อให้มีการกำกับดูแลโดยมนุษย์ได้ดียิ่งขึ้นตลอดทั้งกระบวนการ จากปัญหาที่พบในการวิเคราะห์นี้ เราขอยกเลิกคำแนะนำก่อนหน้าที่ให้ใช้ SWE-Bench Pro

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