เกณฑ์มาตรฐานโค้ดที่มีอยู่ในปัจจุบันกำลังเผชิญกับความท้าทายหลักสองประการ: ความเสี่ยงของการปนเปื้อนของข้อมูล และความเข้มงวดในการทดสอบที่ไม่เพียงพอ อันแรกทำให้การประเมินอาจถดถอยเป็น “การสอบแบบเปิดหนังสือ” ส่วนอันหลังมักนำไปสู่ “ภาพลวงตาของความถูกต้อง” — โค้ดที่สร้างโดยโมเดลอาจผ่านตัวอย่างทดสอบเพียงไม่กี่ตัวอย่างได้ แต่กลับพังทลายในสถานการณ์ขอบเขตที่ซับซ้อนของโลกแห่งความเป็นจริง
เพื่อทำลาย “ภาพลวงตาของคะแนนสูง” นี้ ทีมวิจัยจากมหาวิทยาลัยการบินและอวกาศปักกิ่งได้เสนอปรัชญาการสร้างเกณฑ์มาตรฐานใหม่ — การขยายสองเท่า และสร้างกรอบงานอัตโนมัติแบบ end-to-end ขึ้นบนพื้นฐานนี้ชื่อว่า Code2Bench การวิจัยนี้มีเป้าหมายเพื่อสร้างกระบวนทัศน์ใหม่ที่ไดนามิก เข้มงวด และมีคุณสมบัติในการวินิจฉัยมากขึ้น สำหรับการประเมินโมเดลภาษาขนาดใหญ่สำหรับโค้ด
ปัจจุบัน งานวิจัยนี้ได้รับการตีพิมพ์ใน ICLR 2026 แล้ว
* ชื่อบทความวิจัย: Code2Bench: Scaling Source and Rigor for Dynamic Benchmark Construction
* ลิงก์บทความวิจัย: https://arxiv.org/pdf/2508.07180
* ลิงก์กระดานคะแนน: https://code2bench.github.io/
เราต้องการวิธีการสร้าง Benchmark แบบไหน?
เกณฑ์มาตรฐานการประเมินโค้ดในอุดมคติไม่ควรเป็นการรวบรวมชุดคำถามแบบคงที่อย่างง่าย แต่ควรเป็นสภาพแวดล้อมแบบต้านทานที่วิวัฒนาการอย่างต่อเนื่อง มันต้องเป็นไปตามเงื่อนไขสองประการพร้อมกัน: คำถามต้อง “ใหม่สด” สำหรับโมเดลอย่างแน่นอน เพื่อป้องกันการโกงด้วยการจำ และการทดสอบต้องเข้มงวดพอที่จะเผยให้เห็นจุดอ่อนที่ซ่อนอยู่ในตรรกะ
อย่างไรก็ตาม ระบบการประเมินส่วนใหญ่ในปัจจุบันยังคงติดอยู่ในกระบวนทัศน์เก่าของ “สร้างครั้งเดียว ใช้ซ้ำในระยะยาว” พวกมันอาจพึ่งพาการเขียนด้วยมือมนุษย์ (ซึ่งเสี่ยงต่อการปนเปื้อน) หรือดึงข้อมูลจากแพลตฟอร์มการแข่งขัน (ซึ่งมักแยกจากความเป็นจริงทางวิศวกรรม) กรณีทดสอบโดยทั่วไปก็เบาบางและตื้นเขิน ไม่สามารถแยกแยะระหว่าง “ใช้งานได้” กับ “เชื่อถือได้สำหรับการผลิต”
ตารางที่ 1: การเปรียบเทียบหลายมิติของเกณฑ์มาตรฐานการสร้างโค้ดหลักที่มีอยู่ในปัจจุบัน
ตารางที่ 1 วาดภาพ “ช่องว่างความสามารถ” ของแวดวงการประเมินในปัจจุบันได้อย่างชัดเจน: เกณฑ์มาตรฐานส่วนใหญ่พึ่งพาการเขียนด้วยมือมนุษย์ (ซึ่งปนเปื้อนได้ง่ายมากโดยชุดข้อมูลการฝึกในภายหลัง) หรือดึงข้อมูลจากแพลตฟอร์มการแข่งขัน (ซึ่งมักแยกจากตรรกะทางวิศวกรรมในทางปฏิบัติ) ที่ร้ายแรงกว่านั้นคือ กรณีทดสอบของพวกมันโดยทั่วไปเบาบางและตื้นเขิน สามารถตรวจสอบแค่ “ใช้งานได้” แต่ไม่สามารถแยกแยะ “เชื่อถือได้สำหรับการผลิต”
เพื่อเติมเต็มช่องว่างนี้ วิธีการสร้างเกณฑ์มาตรฐานสำหรับอนาคตต้องมีคุณลักษณะสี่ประการต่อไปนี้:
* ความไดนามิก: แหล่งที่มาของปัญหาต้องได้รับการอัปเดตอย่างต่อเนื่อง เพื่อต่อต้านการปนเปื้อนของข้อมูลตั้งแต่รากฐาน
* ความแท้จริง: ปัญหาควรมาจากคลังโค้ดโปรเจกต์ที่แท้จริงและซับซ้อน ไม่ใช่ “ปัญหาของเล่น” ที่เขียนขึ้นโดยมนุษย์
* ความเข้มงวด: การทดสอบต้องลึกซึ้งและครอบคลุม สามารถขุดพบข้อบกพร่องทางตรรกะที่ละเอียดอ่อนที่สุด
* ความครอบคลุม: ควรสามารถจัดการกับการพึ่งพาลิเบรารีภายนอกที่ซับซ้อน และมีความสามารถในการขยายไปยังหลายภาษา
การแสวงหาคุณลักษณะทั้งสี่ประการนี้เองที่ทำให้ปรัชญาการสร้างหลักของ Code2Bench เกิดขึ้นมา
“การขยายสองเท่า”: ปรับโครงสร้างตรรกะการสร้างเกณฑ์มาตรฐานโค้ด
Code2Bench ไม่ได้เพียงแค่เผยแพร่ชุดข้อมูลใหม่ แต่เสนอไปป์ไลน์การสร้างเกณฑ์มาตรฐานแบบ end-to-end อัตโนมัติเต็มรูปแบบ และสามารถวิวัฒนาการอย่างยั่งยืน หัวใจสำคัญคือปรัชญา “การขยายสองเท่า” — ด้วยการขยายความกว้างของแหล่งที่มาและความลึกของการทดสอบอย่างเป็นระบบ เพื่อรับประกันว่าจะสามารถสร้างงานประเมินคุณภาพสูง ต้านทานการปนเปื้อน และครอบคลุมสูงได้อย่างไม่รู้จบ
รูปที่ 1: ภาพรวมของ Code2Bench Pipeline
1. ขยายแหล่งที่มาของโค้ด: แข่งกับเวลากับการปนเปื้อนของข้อมูล
เพื่อให้แน่ใจถึงความใหม่และความแท้จริงของปัญหา กรอบงานนี้ละทิ้งชุดคำถามแบบคงที่ และหันไปสร้างไปป์ไลน์แบบไดนามิกเพื่อรับโค้ดแทน:
* การรับแบบไดนามิกและการกรองตามประทับเวลา: ดึงฟังก์ชันโดยตรงจากโปรเจกต์โอเพนซอร์สบน GitHub ที่มีจำนวนมหาศาลและใช้งานอยู่ และกรองอย่างเข้มงวดตามวันที่ตัดความรู้ของโมเดลที่ต้องการประเมินแต่ละตัว โดยเลือกเฉพาะโค้ดที่ถูกคอมมิตหลังจากวันที่นั้นเท่านั้น นี่ไม่เพียงแต่ป้องกัน “การท่องจำข้อสอบ” แต่ยังหมายความว่าตราบใดที่ GitHub มีโค้ดใหม่ Code2Bench ก็จะสามารถผลิตคำถามใหม่ได้อย่างไม่รู้จบ
* การวิเคราะห์ Scope Graph ที่ไม่ขึ้นกับภาษา: ในฐานะที่เป็นแกนกลางทางเทคนิคสำหรับการจำแนกประเภทอย่างเป็นระบบ วิธีนี้ไม่พึ่งพาไวยากรณ์ภาษาที่เฉพาะเจาะจง แต่ผ่านกราฟขอบเขตเชิงตรรกะที่เป็นนามธรรมสูงเพื่อระบุการพึ่งพาภายนอกได้อย่างแม่นยำ และแบ่งงานออกเป็น:
* งานแบบพึ่งพาตนเอง: ไม่มีการพึ่งพาภายนอก มุ่งเน้นการประเมินความสามารถในการสังเคราะห์ตรรกะหลัก
* งานแบบพึ่งพาตนเองแบบอ่อน: พึ่งพาเฉพาะไลบรารีมาตรฐานหรือไลบรารีในรายการขาวเท่านั้น ประเมินความสามารถในการประยุกต์ใช้ API ในการพัฒนาที่แท้จริง
การออกแบบนี้ทำให้กรอบงานรองรับการขยายหลายภาษาโดยธรรมชาติ เป็นรากฐานสำหรับการรวมภาษาเช่น Go, JavaScript ในอนาคต
2. ขยายความเข้มงวดของการทดสอบ: สิ้นสุด “ภาพลวงตาของความถูกต้อง” ด้วยมาตรฐานระดับอุตสาหกรรม
เพื่อรับมือกับข้อเสียของกรณีทดสอบที่เบาบางในเกณฑ์มาตรฐานแบบดั้งเดิม Code2Bench ได้นำความเข้มงวดขั้นสูงมาเป็นหลักการสำคัญ:
* การทดสอบตามคุณสมบัติ: กรอบงานจะสร้างชุดทดสอบที่มีอินพุตนับร้อยหรือนับพันสำหรับแต่ละฟังก์ชันผู้สมัครโดยอัตโนมัติ อินพุตเหล่านี้ครอบคลุมค่าทั่วไป ค่าขอบเขต และโครงสร้างที่ซับซ้อนแบบซ้อนกัน
* “Great Filter” — ความครอบคลุมสาขา 100%: นี่คือการออกแบบที่เป็นสัญลักษณ์ที่สุดของ Code2Bench ฟังก์ชันและชุดทดสอบที่ตรงกัน จะถูกนำมาใช้ในที่สุดก็ต่อเมื่อการดำเนินการสามารถครอบคลุมทุกสาขาทางตรรกะภายในฟังก์ชันได้ ข้อกำหนดที่ดูเหมือนง่ายนี้ เป็นประตูตรวจสอบคุณภาพที่เข้มงวดอย่างยิ่ง มันรับประกันว่าทุกปัญหาในเกณฑ์มาตรฐานคือความท้าทายที่สมบูรณ์ทางตรรกะและสามารถตรวจสอบได้อย่างลึกซึ้ง
เกณฑ์มาตรฐาน Code2Bench-2509
เพื่อตรวจสอบประสิทธิผลของปรัชญา “การขยายสองเท่า” ทีมวิจัยได้สร้างชุดเกณฑ์มาตรฐาน Code2Bench-2509 ขึ้นโดยอัตโนมัติตามกรอบงานนี้ นี่คือ “ข้อสอบปฏิบัติจริง” ที่ดึงข้อมูลแบบไดนามิกจากการคอมมิตล่าสุดบน GitHub ตั้งแต่เดือนพฤษภาคมถึงกันยายน 2025 ประกอบด้วยอินสแตนซ์ดั้งเดิมของ Python และ Java
ตัวชี้วัดเชิงปริมาณในตารางที่สองเผยให้เห็นข้อได้เปรียบ “ต่างรุ่น” ของ Code2Bench-2509 ในมิติทางวิศวกรรมเหนือเกณฑ์มาตรฐานแบบดั้งเดิมอย่างชัดเจน:
ตารางที่สอง: ตัวชี้วัดหลักของ Code2Bench-2509
- ความซับซ้อนเพิ่มขึ้นอย่างก้าวกระโดด: ในงานตรรกะล้วน ความซับซ้อนแบบวนซ้ำโดยเฉลี่ยอยู่ที่ 5.3 สูงกว่า HumanEval ซึ่งอยู่ที่ 2.8 อย่างมาก
- ความเข้มงวดที่เหนือกว่า: ต่างจาก HumanEval ที่มีกรณีทดสอบเฉลี่ยเพียงประมาณ 7.8 กรณีต่อข้อ Code2Bench สร้างกรณีทดสอบประมาณ 500 กรณีสำหรับแต่ละข้อ
- ความหลากหลายของระบบนิเวศ: ในงานแบบพึ่งพาตนเองแบบอ่อน เกณฑ์มาตรฐานครอบคลุมไลบรารีบุคคลที่สามหลักกว่า 30 ไลบรารี จำลองการพึ่งพาความสามารถในการประยุกต์ใช้ API ในการพัฒนาซอฟต์แวร์สมัยใหม่ได้อย่างแท้จริง
แผนภูมิภูมิทัศน์การประเมินหลายมิติในรูปที่สองแสดงให้เห็นถึงการก้าวกระโดดนี้อย่างชัดเจน:
รูปที่สอง: การเปรียบเทียบหลายมิติระหว่าง Code2Bench-2509 กับเกณฑ์มาตรฐานหลักในด้านความเข้มงวดของการทดสอบ ความลึกของการพึ่งพา และความสามารถในการขยายของกรอบงาน
เมื่อเทียบกับเกณฑ์มาตรฐานหลักเช่น HumanEval และ BigCodeBench แล้ว Code2Bench ได้สร้างการเปลี่ยนแปลงที่สำคัญในสามมิติ: ความเข้มงวดของการทดสอบ ความลึกของการพึ่งพา และความสามารถในการขยายของกรอบงาน มันไม่ได้หยุดอยู่แค่การตรวจสอบว่าโมเดล “สามารถเขียนโค้ดที่ถูกต้องได้หรือไม่” แต่ผ่าน “การขยายภาษา” และ “การขยายการพึ่งพา” ได้ผลักดันการประเมินไปสู่ระบบนิเวศทางวิศวกรรมซอฟต์แวร์ที่กว้างขึ้น การก้าวข้ามหลายมิติเช่นนี้ เป็นรากฐานสำหรับการเปิดเผยข้อบกพร่องความสามารถที่ลึกซึ้งยิ่งขึ้นของโมเดลในภายหลัง
ลายนิ้วมือการวินิจฉัย: เผยให้เห็นช่องว่างความสามารถและผลกระทบของ “นั่งร้านประสิทธิภาพ”
คะแนน Pass@1 แบบดั้งเดิมมักเป็น “กล่องดำ”: มันทราบผลลัพธ์ แต่ปกปิดกระบวนการคิดของโมเดล ต้องขอบคุณการขยายขนาดของความเข้มข้นในการทดสอบของ Code2Bench เราจึงได้มุมมองที่มีความละเอียดสูงพอที่จะร่าง “สเปกตรัมของข้อผิดพลาด” ได้ “ลายนิ้วมือการวินิจฉัย” นี้ทำให้การประเมินวิวัฒนาการจากการนับสถิติ “คะแนน” แบบมิติเดียว ไปสู่การมองลึกเข้าไปในรูปแบบความล้มเหลวของกระบวนการคิดของโมเดล
จากข้อมูล Pass@1 ในตารางที่ 3 สามารถสังเกตเห็นปรากฏการณ์ “ความถนัดเฉพาะด้าน” ของโมเดลต่างๆ ในสนามแข่งขันที่แตกต่างกัน:
- ในงานอัลกอริทึมล้วน (SC-Python) Claude-4-Sonnet นำด้วยอัตราชนะ 40.1% ซึ่งเน้นย้ำถึงข้อได้เปรียบในการให้เหตุผลเชิงตรรกะโดยไม่มีการพึ่งพา
- ในงานประยุกต์ใช้ API (WSC-Python) Mistral-small-3.1 มีผลงานโดดเด่น (38.7%) เทียบเท่ากับ Claude ซึ่งแสดงให้เห็นถึงความเชี่ยวชาญในการเรียกใช้ไลบรารีที่ค่อนข้างสูง
- ในงานอัลกอริทึม Java (SC-Java) DeepSeek-V3 นำด้วยคะแนน 47.8%
ตารางที่สาม: ประสิทธิภาพ Pass@1 (%) บนชุดทดสอบ Code2Bench-2509
อย่างไรก็ตาม ความเข้าใจที่แท้จริงซ่อนอยู่ในรูปที่สาม — การเปลี่ยนแปลงของการกระจายความล้มเหลวในแผนภูมิลายนิ้วมือ เผยให้เห็นข้อเท็จจริงสำคัญสองประการที่ถูกปกปิดด้วยคะแนนเดียว:
รูปที่สาม: การเปรียบเทียบลายนิ้วมือการวินิจฉัยของโมเดล: การกระจายผลลัพธ์ของ SC-Python, WSC-Python และ SC-Java
- ช่องว่างความสามารถ: ถนัด “เรียกใช้ API” แต่ดิ้นรนกับ “เขียนอัลกอริทึม”
แผนภูมิลายนิ้วมือเผยให้เห็นประสิทธิภาพที่แตกต่างกันอย่างสิ้นเชิงของโมเดลเมื่อเผชิญกับงานที่ต่างกัน: ในงานอัลกอริทึมล้วน (SC-Python) จุดสูงสุดของความล้มเหลวจะกระจุกตัวอยู่ที่ข้อผิดพลาดทางตรรกะ (LogicErr) แต่เมื่อเกี่ยวข้องกับการเรียกใช้ไลบรารีภายนอก (WSC-Python) จุดสูงสุดจะเปลี่ยนไปสู่ข้อผิดพลาดขณะรันไทม์ (RuntimeErr) อย่างรวดเร็ว นี่บ่งชี้ว่าจุดคอขวดของโมเดลในปัจจุบันได้เปลี่ยนจาก “จำพารามิเตอร์ API ไม่ได้” ไปสู่ “ไม่สามารถสร้างตรรกะที่ซับซ้อนได้ด้วยตนเอง” ซึ่งลึกซึ้งยิ่งขึ้น - ผลกระทบของ “นั่งร้านประสิทธิภาพ”: แบบแผนภาษากำหนดประสิทธิภาพของโมเดลอย่างไร
สิ่งที่ให้ความกระจ่างมากกว่าคือการเปรียบเทียบระหว่าง Python กับ Java ในงาน SC-Java ข้อผิดพลาดทางตรรกะที่พบบ่อยใน Python ถูกกดดันลงอย่างมาก อัตราการผ่านแบบสมบูรณ์แบบ (Perfect) เพิ่มขึ้นอย่างเห็นได้ชัด นี่ไม่ใช่เพราะงานง่ายลง แต่เป็นเพราะระบบประเภทข้อมูลแบบสถิตของ Java ทำหน้าที่เป็น “นั่งร้านประสิทธิภาพ” — มันสกัดกั้นข้อผิดพลาดระดับต่ำจำนวนมากก่อนที่โค้ดจะถูกดำเนินการ
กล่าวอีกนัยหนึ่ง การเปลี่ยนแปลงของการกระจายในแผนภูมิลายนิ้วมือนั้นเอง คือหลักฐานโดยตรงที่มองเห็นได้ว่าแบบแผนภาษากำหนดความสามารถของโมเดล มันเผยให้เห็นข้อเท็จจริงสำคัญ: ความสามารถในการเขียนโปรแกรมของโมเดลไม่ได้มีอยู่อย่างเป็นนามธรรม ประสิทธิภาพของมันเชื่อมโยงอย่างลึกซึ้งกับระบบนิเวศของภาษาปลายทาง — ระบบประเภทข้อมูลแบบสถิตไม่ใช่
⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง
本文来自网络搜集，不代表คลื่นสร้างอนาคต立场，如有侵权，联系删除。转载请注明出处：https://www.itsolotime.com/th/archives/22883