FeatureBench: เติมเต็มช่องว่างในการประเมินการพัฒนาฟังก์ชันที่ซับซ้อนแบบ end-to-end สำหรับโมเดลขนาดใหญ่ สถาบันอัตโนมัติของ Chinese Academy of Sciences และ Huawei ร่วมกันเปิดตัวมาตรฐานใหม่

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

อย่างไรก็ตาม การปฏิบัติวิศวกรรมซอฟต์แวร์จริงนั้นมีมากกว่าการแก้ไขข้อบกพร่อง งานสำคัญจำนวนมากเกิดขึ้นในการพัฒนาระดับฟีเจอร์แบบครบวงจร (end-to-end): ซึ่งมักหมายถึงเส้นทางโค้ดที่ยาวขึ้น การพึ่งพาข้ามไฟล์ที่ซับซ้อนยิ่งขึ้น และความเข้าใจเชิงลึกในบริบทระยะยาวและพฤติกรรมของระบบโดยรวม กล่าวอีกนัยหนึ่ง ความสามารถในการแก้ไขข้อบกพร่องไม่ได้หมายความว่าจะสามารถส่งมอบฟีเจอร์ที่สมบูรณ์ได้

เพื่อเติมเต็มช่องว่างนี้ สถาบันอัตโนมัติแห่งสถาบันวิทยาศาสตร์จีน (Chinese Academy of Sciences) และ Huawei ได้ร่วมกันเสนอ FeatureBench (Benchmarking Agentic Coding in End-to-End Development of Complex Features) โดยมุ่งเน้นที่แนวทางการประเมินแบบทดสอบเป็นตัวขับเคลื่อน (test-driven development) และสร้างโครงสร้างพื้นฐานแบบครบวงจรที่ครอบคลุมการสร้างข้อมูล การอนุมาน และการประเมิน ข้อมูลที่เกี่ยวข้อง รหัสไปป์ไลน์ และอิมเมจการปฏิบัติการได้ถูกเปิดเผยแบบโอเพนซอร์สทั้งหมด โดยมีเป้าหมายเพื่อจัดเตรียมมาตรฐานใหม่สำหรับการประเมินและขับเคลื่อนโมเดลการเขียนโค้ดแบบเอเจนต์ที่ทรงพลังและครอบคลุมยิ่งขึ้น

• ชื่อบทความ: FeatureBench: Benchmarking Agentic Coding for Complex Feature Development
• หน้าแรกโครงการ: https://libercoders.github.io/FeatureBench/
• บทความ arXiv: https://arxiv.org/abs/2602.10975
• ชุดข้อมูล Hugging Face: https://huggingface.co/datasets/LiberCoders/FeatureBench
• ที่เก็บโค้ด GitHub: https://github.com/LiberCoders/FeatureBench
• อิมเมจ Docker: https://hub.docker.com/u/libercoders

ความแม่นยำสูง: การดึงโค้ดระดับฟีเจอร์ที่แม่นยำด้วยการติดตามแบบไดนามิก

การสร้างภารกิจของ FeatureBench เริ่มต้นจากแบบทดสอบหน่วย (unit test) ในที่เก็บโค้ดจริง ในแนวปฏิบัติวิศวกรรมซอฟต์แวร์ที่ครบถ้วน แบบทดสอบหน่วยมักครอบคลุมเส้นทางฟังก์ชันที่สมบูรณ์หรือส่วนประกอบสำคัญของมัน และอธิบายขอบเขตพฤติกรรมและสมมติฐานการใช้งานของฟีเจอร์โดยปริยาย ดังนั้นจึงเหมาะโดยธรรมชาติที่จะเป็นจุดเริ่มต้นในการกำหนดขอบเขตของฟีเจอร์

แตกต่างจากวิธีการประเมินที่มีอยู่ซึ่งใช้แบบทดสอบหน่วยเพียงเป็นเครื่องมือประเมินผลเท่านั้น FeatureBench นำแบบทดสอบหน่วยเข้ามาในขั้นตอนการสร้างภารกิจ ใช้มันเพื่อระบุตำแหน่งย้อนกลับและดึงโค้ดการใช้งานที่เกี่ยวข้องอย่างใกล้ชิดกับฟีเจอร์เป้าหมาย จึงสร้างภารกิจประเมินที่ต้องการให้เอเจนต์โค้ดเติมเต็มฟีเจอร์นั้นเอง กล่าวโดยเฉพาะ ระบบจะค้นพบและกรองแบบทดสอบหน่วยที่ปฏิบัติการได้อัตโนมัติในที่เก็บโค้ดจริงก่อน โดยถือว่าสิ่งที่แบบทดสอบหน่วยเหล่านี้ทดสอบคือฟีเจอร์เป้าหมายของภารกิจ เพื่อใช้เป็นแบบทดสอบ “ล้มเหลวสู่ผ่าน” (fail-to-pass) ในภายหลัง พร้อมกันนี้ ยังนำแบบทดสอบ “ผ่านสู่ผ่าน” (pass-to-pass) มาใช้ เพื่อจำกัดการทำลายฟีเจอร์ที่ไม่ใช่เป้าหมายที่อาจเกิดขึ้นในระหว่างกระบวนการสร้างภารกิจ

ในระหว่างการดำเนินการทดสอบ FeatureBench ใช้เทคนิคการติดตามแบบไดนามิก (dynamic tracing) โดยเริ่มจากแบบทดสอบหน่วย “ล้มเหลวสู่ผ่าน” จับความสัมพันธ์การเรียกใช้ฟังก์ชันและการพึ่งพาอ็อบเจกต์บนเส้นทางการปฏิบัติการ และทำการติดป้ายกำกับและจำแนกประเภทการใช้งานที่เกี่ยวข้องในระดับอ็อบเจกต์ จากนั้น ระบบจะดึงและลบเฉพาะโค้ดการใช้งานที่เกี่ยวข้องอย่างใกล้ชิดกับแบบทดสอบ “ล้มเหลวสู่ผ่าน” และไม่ส่งผลให้แบบทดสอบ “ผ่านสู่ผ่าน” ล้มเหลว ส่วนที่เหลือจะคงไว้ตามเดิม ข้อมูลเช่นลายเซ็นอินเทอร์เฟซของโค้ดที่ถูกลบจะถูกดึงอัตโนมัติจากโค้ดต้นฉบับผ่านกฎ และจะถูกจัดเตรียมให้กับโมเดลเป็นส่วนหนึ่งของคำอธิบายภารกิจในภายหลัง

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

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

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

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

ความสามารถในการปฏิบัติการสูง: กลไกการสร้างภารกิจโดยอาศัยการย้อนกลับประวัติข้อผิดพลาด

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

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

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

กลไกการตรวจสอบที่แข็งแกร่ง: ข้อจำกัดการประเมินที่ประกอบด้วยการจัดแนวเป้าหมาย วงจรปิดการตรวจสอบ และความซับซ้อนของสายโซ่ยาว

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

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

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

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

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

1) การจัดแนวเป้าหมาย (ความยุติธรรมของการประเมิน)

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

2) วงจรปิดการตรวจสอบ (ความครบถ้วนของการประเมิน)

3) ความซับซ้อนของสายโซ่ยาว (ลักษณะระยะยาวของการประเมิน)

การสร้างภารกิจของ FeatureBench ปฏิบัติตามกระบวนการขยายออกเป็นระดับจากแบบทดสอบหน่วย → อ็อบเจกต์ระดับบนสุด → อ็อบเจกต์ที่เกี่ยวข้องและการพึ่งพาระดับลึก อินเทอร์เฟซระดับบนสุดอธิบายเพียงพฤติกรรมภายนอกของฟีเจอร์ ซึ่งมักสอดคล้องกับรายละเอียดการใช้งานและการพึ่งพาโดยปริยายข้ามไฟล์และข้ามอ็อบเจกต์จำนวนมาก

ดังนั้น ภารกิจใน FeatureBench มักเกี่ยวข้องกับเส้นทางโค้ดที่ยาวขึ้นและขอบเขตการแก้ไขที่กว้างขึ้น ซึ่งเรียกร้องความสามารถในการให้เหตุผลระยะยาว ความเข้าใจในระดับระบบ และการ把握ข้อจำกัดพฤติกรรมที่มีอยู่โดยรวมของเอเจนต์ในระดับที่สูงขึ้น

ความซับซ้อนสูง: ตัวอย่างการประเมินที่ปฏิบัติการได้ในวงกว้างสำหรับฟีเจอร์จริง

จากไปป์ไลน์การสร้างข้อมูลอัตโนมัติ ทีมวิจัยได้สร้างสภาพแวดล้อมแซนด์บ็อกซ์และตัวอย่างภารกิจผู้สมัครที่ปฏิบัติการได้ 3,825 ตัวอย่างอย่างเป็นระบบภายใน 3 วัน ครอบคลุมที่เก็บโค้ด GitHub 24 แห่งจากโลกจริง ซึ่งครอบคลุมสถานการณ์การใช้งานที่แตกต่างกัน ตัวอย่างทั้งหมดสามารถรันได้โดยตรง เป็นพื้นฐานการปฏิบัติการที่統一สำหรับการกรองและการประเมินในภายหลัง

จากพื้นฐานนี้ โดยการบังคับใช้ข้อจำกัดการกรองที่統一เพิ่มเติม รวมถึงช่วงเวลาโค้ด (หลังเดือนพฤษภาคม 2022) ความเข้มข้นของการครอบคลุมการทดสอบ (จำนวนจุดทดสอบมากกว่า 10) และขนาดการดึงฟีเจอร์ (จำนวนบรรทัดโค้ดที่ดึงมากกว่า 100 บรรทัด) เพื่อรับประกันความสม่ำเสมอของความซับซ้อนและความเป็นตัวแทนของภารกิจ หลังจากการตรวจสอบโดยมนุษย์ จึงกำหนดชุดข้อมูลการประเมินอย่างเป็นทางการของ FeatureBench:

• FeatureBench Full: ประกอบด้วยภารกิจประเมิน 200 ภารกิจ ภารกิจเดียวสามารถดึงโค้ดได้มากสุด 4,495 บรรทัด เกี่ยวข้องกับไฟล์โค้ดต่างกันมากสุด 76 ไฟล์
• FeatureBench Lite: กรองภารกิจ 30 ภารกิจจากชุด Full เพิ่มเติม เป็นชุดย่อยสำหรับการประเมินต้นทุนต่ำ เพื่ออำนวยความสะดวกในการทดลองเปรียบเทียบอย่างรวดเร็วและการพัฒนาวิธีการในชุมชน

โดยรวม ภารกิจใน FeatureBench Full มีความซับซ้อนในการกระจายตัวในด้านขนาดโค้ด ความกว้างของการพึ่งพา และความเข้มของข้อจำกัดการทดสอบ สูงกว่ามาตรฐานการทดสอบการแก้ไขข้อบกพร่องทั่วไปอย่างมีนัยสำคัญ และใกล้เคียงกับการกระจายตัวของความซับซ้อนในการพัฒนาระดับฟีเจอร์ในสภาพแวดล้อมทางวิศวกรรมจริงมากขึ้น

ความซับซ้อนของ FeatureBench สูงกว่ามาตรฐานการทดสอบการแก้ไขข้อบกพร่องทั่วไปอย่างมีนัยสำคัญ ครอบคลุมการใช้งานฟีเจอร์จริงที่มีการพึ่งพาข้ามไฟล์ ข้ามอ็อบเจกต์ และระยะยาว

ความสามารถในการแยกแยะสูง: การประเมินภารกิจระดับฟีเจอร์เปิดช่องว่างความสามารถของโมเดลใหม่อีกครั้ง

⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง