เจาะลึก CyberGym Benchmark: คะแนน E2E วัดอะไรกันแน่

คะแนน CyberGym ที่แพร่หลายที่สุด — ตัวเลขในโพสต์เปิดตัว ตัวที่ถูกนำไปเปรียบเทียบข้ามโมเดล — คืออัตราความสำเร็จของงานจาก 131 งานที่ผ่านการกรอง โดยความสำเร็จหมายถึงเอเจนต์สร้างอินพุต proof-of-concept ที่ทำให้บิลด์ C/C++ ที่ยังไม่ได้แพตช์พัง เขียนแพตช์ที่หยุดการพังนั้น และไม่ทำให้เทสต์ที่นักพัฒนาของโปรเจกต์เขียนไว้เสีย ในการรวบรวมของ BenchLM นั้น MiMo-V2.6-Flash นำอยู่ที่ 95.1% และ MiMo-V2.6-Pro ที่ 94.0% โดย DeepSeek-V4.1-Flash ตามหลังอยู่ไม่กี่จุดในระดับปลายแปดสิบเปอร์เซ็นต์ แทบไม่มีใครที่อ้างถึงตารางนั้นพูดถึงสามสิ่งซึ่งเป็นตัวตัดสินว่าตัวเลขเหล่านั้นเปรียบเทียบกันได้หรือไม่: benchmark นี้มีมากกว่าหนึ่ง implementation แถวส่วนใหญ่เป็นรายงานตนเองของผู้ให้บริการมากกว่าการรันอิสระ และขั้นตอนที่น่าสนใจที่สุดเพียงขั้นตอนเดียวถูกบันทึกไว้แต่ไม่ถูกนับ นั่นคือมาตรฐานเดียวกันของการระบุแหล่งที่มา the AI incident archiveซึ่งใช้กับรายการของตัวเอง — ข้อกล่าวอ้างที่ไม่มีแหล่งที่มาถือไม่เป็นผลลัพธ์ — และคลังข้อมูล CyberGym ก็ตกมาตรฐานนี้บ่อยกว่าที่ชื่อเสียงของมันบ่งชี้

นี่คือคู่มือที่อธิบายว่า benchmark กำหนดให้ agent ทำอะไร ชุดงานถูกสร้างขึ้นมาอย่างไร implementation ต่างๆ แตกต่างกันตรงไหน และผู้ป้องกันควรและไม่ควรสรุปอะไรจากคะแนนที่สูง

ภารกิจ: ค้นหา ทำซ้ำ แพตช์ — โดยไม่ทำให้อะไรพัง

CyberGym มาจาก Berkeley Center for Responsible, Decentralized Intelligence และสมมติฐานตั้งต้นของมันถูกจำกัดอย่างจงใจ แต่ละงานมุ่งเป้าไปที่ช่องโหว่ด้านความปลอดภัยของหน่วยความจำในโครงการโอเพนซอร์ส C/C++ ที่ใช้กันอย่างแพร่หลาย เอเจนต์ต้องระบุตำแหน่งบั๊ก เขียนอินพุต proof-of-concept ที่ทำให้เกิด sanitizer crash จากนั้นแพตช์โค้ดเพื่อให้ไม่สามารถจำลอง crash ซ้ำได้อีก ขณะที่ชุดทดสอบของโครงการเองยังคงผ่าน ลำดับขั้นนี้คือหัวใจทั้งหมดของเรื่อง เบนช์มาร์กที่ถามเพียงว่า “หาบั๊ก” จะให้รางวัลกับการจดจำรูปแบบ แต่การกำหนดให้ต้องมีอินพุตที่ทำให้เกิด crash ได้จริงและการแพตช์ที่ไม่ทำให้ระบบพัง บังคับให้เอเจนต์ปิดวงจรตั้งแต่ความสงสัย ไปสู่การแสดงให้เห็นข้อบกพร่อง ไปจนถึงการแก้ไข

RDI ดูแล benchmark นี้ภายใต้หอสังเกตการณ์ที่กว้างกว่าซึ่งติดตามความสามารถด้านไซเบอร์ของ AI ตลอดระยะการโจมตีและการป้องกัน และกรอบการนำเสนอนี้น่าสังเกต: CyberGym เป็นเพียงเครื่องมือหนึ่งบนแท่นทดสอบ ควบคู่กับ ExploitGym และตัวแปรแบบ end-to-end การอ่านมันเป็นลีดเดอร์บอร์ดแบบเดี่ยว ๆ ทำให้สูญเสียบริบทนั้นไป ซึ่งเป็นเหตุผลหนึ่งที่ทำให้ตัวเลขถ่ายทอดออกไปได้ไม่ดี

สี่ขั้นตอน โดยสามขั้นตอนมีการให้คะแนน

กฎการให้คะแนนเป็นส่วนที่ได้รับการรายงานน้อยที่สุดของ benchmark เพราะเป็นจุดที่คะแนนซึ่งฟังดูสมเหตุสมผลอาจคลาดเคลื่อนไปจากสิ่งที่เกิดขึ้นจริง

ขั้นที่ 1 คือการทำซ้ำ: อินพุต proof-of-concept ของเอเจนต์ทำให้บิลด์ที่ยังไม่ได้แพตช์พังหรือไม่ ขั้นที่ 2 คือแพตช์: การเปลี่ยนแปลงที่ส่งมาหยุดการพังเฉพาะจุดนั้นได้หรือไม่ ขั้นที่ 3 คือการทดสอบถดถอย: การทดสอบฟังก์ชันการทำงานที่นักพัฒนาเขียนไว้ยังผ่านอยู่หรือไม่ ทั้งสามขั้นนี้สร้างคะแนน

ระยะที่ 4ถามว่าแพตช์แก้ช่องโหว่จริงตาม ground truth หรือไม่ และถูกบันทึกเป็น diagnostic แทนที่จะนับเป็นคะแนน ความไม่สมมาตรนี้ควรค่าแก่การหยุดคิดสักครู่ เพราะมันคือความแตกต่างระหว่าง “เอเจนต์ทำให้แครชหายไปได้” กับ “เอเจนต์แก้บั๊กได้” ทั้งสองเป็นข้อกล่าวอ้างที่มีประโยชน์ แต่ไม่ใช่ข้อกล่าวอ้างเดียวกัน เอเจนต์ที่ระงับแครชด้วยการดักจับสัญญาณ ขยายการตรวจสอบขอบเขตให้เลยจุด overflow หรือปิดเส้นทางโค้ดทั้งหมด จะได้คะแนนในระยะที่ 1 ถึง 3 และตกในระยะที่ 4 หากรายงานผลระบุตัวเลขเพียงตัวเดียวโดยไม่บอกว่ามีการตรวจระยะที่ 4 หรือไม่ คุณจะบอกไม่ได้ว่าวัดสิ่งใดในสองสิ่งนี้ — และ diagnostic มีอยู่ก็เพื่อให้คุณถามได้พอดี

131 ภารกิจถูกคัดเลือกมาอย่างไร — และสิ่งนั้นส่งผลต่อคะแนนอย่างไร

ชุดข้อมูลต้นทางมีขนาดใหญ่กว่าชุดที่ถูกให้คะแนน และการกรองคือปัจจัยที่มีอิทธิพลมากที่สุดเพียงปัจจัยเดียวต่อความสามารถในการเปรียบเทียบ ชุดข้อมูลของ RDI ประกอบด้วยช่องโหว่ 920 รายการจากโครงการโอเพนซอร์ส 139 โครงการ ซึ่งดึงมาจาก OSS-Fuzz ของ Google ตัวแปรแบบ end-to-end ที่ผู้ติดตามบุคคลที่สามใช้จะจำกัดให้เหลือ 131 งาน โดยหนึ่งงานต่อหนึ่งโครงการ คัดเลือกตามความยาก โดยไม่รวมงานที่มีการรั่วไหลของ oracle หรือข้อจำกัดด้านความเข้ากันได้ของแซนด์บ็อกซ์

ผลที่ตามมาโดยตรงมีสามประการ ประการแรก หนึ่งงานต่อหนึ่งโปรเจกต์หมายความว่าคะแนนจะถูกกำหนดโดยความกว้างมากกว่าความลึก: เอเจนต์ที่อยู่ในระดับเฉลี่ยในหลายโปรเจกต์จะทำได้ดีกว่าเอเจนต์ที่ยอดเยี่ยมในสามโปรเจกต์ ซึ่งเป็นตัวเลือกการออกแบบที่สมเหตุสมผลและการวัดที่แตกต่างจาก "เอเจนต์นี้สามารถแก้ช่องโหว่ได้กี่รายการ" ประการที่สอง การตัดการรั่วไหลของ oracle ออกจะตัดงานที่คำตอบสามารถค้นพบได้จากสภาพแวดล้อมแทนที่จะใช้การให้เหตุผลออกไป ดังนั้นชุดที่เหลือจึงยากขึ้นในลักษณะเฉพาะ — มันตัดทางลัดออก ไม่ใช่การตัดงานง่าย ๆ ออก ประการที่สาม งบเวลา 90 นาทีต่อหนึ่งงานภายในแซนด์บ็อกซ์ที่สร้างจากอิมเมจ OSS-Fuzz ของโปรเจกต์เป็นส่วนหนึ่งของคำจำกัดความของความสำเร็จ ไม่ใช่รายละเอียด เพราะงานด้านช่องโหว่จริงจำนวนมากถูกจำกัดด้วยข้อจำกัดแบบนั้นพอดี และเอเจนต์ที่พึ่งพาการสำรวจแบบไม่มีขอบเขตจะล้มเหลวที่นี่ในขณะที่ประสบความสำเร็จที่อื่น

การเปรียบเทียบใดก็ตามที่ละเลยกฎการเลือกงาน ย่อมเป็นการเปรียบเทียบแบบทดสอบที่แตกต่างกันสองชุดซึ่งบังเอิญมีชื่อเดียวกัน

การนำไปใช้งานสองแบบ และเหตุใดจึงไม่จำเป็นต้องตรงกัน

นี่คือจุดที่ความสับสนส่วนใหญ่อยู่ CyberGym-E2E มีอยู่ในฐานะเบนช์มาร์ก RDI และในฐานะอิมพลีเมนเทชันที่ดำเนินการโดยผู้ประเมินจากบุคคลที่สาม และทั้งสองไม่มีการรับประกันว่าจะให้ตัวเลขเดียวกันสำหรับโมเดลเดียวกัน เอกสารของผู้ประเมินเองระบุไว้อย่างชัดเจนว่า อิมพลีเมนเทชันของตนใช้ชุดงานที่ผ่านการกรองจำนวน 131 งาน หนึ่งงานต่อหนึ่งโปรเจกต์ ซึ่งเลือกตามความยาก และรันทุกงานในแซนด์บ็อกซ์แบบแยกส่วนที่สร้างจากอิมเมจ OSS-Fuzz ของโปรเจกต์ โดยใช้ฮาร์เนสของเอเจนต์ของตนเอง พร้อมงบเวลาทำงาน 90 นาทีต่อหนึ่งงาน

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

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

การอ่านตารางติดตามอย่างตรงไปตรงมา

ตารางที่คนส่วนใหญ่พบเจอเป็นการรวบรวมข้อมูลแบบทุติยภูมิ และตารางนี้ระบุที่มาของตัวเองไว้ — ซึ่งเป็นส่วนที่มีประโยชน์ หากคุณอ่านป้ายกำกับนั้น จากทั้งหมด 29 แถว มี 7 แถวที่มาจากเจ้าของ benchmark หรือการรันโดยอิสระ, 21 แถวเป็นรายงานที่ผู้ให้บริการรายงานเอง และหนึ่งแถวเป็นรายงานทุติยภูมิ การรวบรวมนี้ระบุตรง ๆ ว่าตารางนี้แสดงไว้เพื่ออ้างอิงและไม่ได้จัดอันดับจากตารางนี้ และแนะนำให้อ่านอย่างระมัดระวังเนื่องจากแถวส่วนใหญ่เป็นรายงานที่ผู้ให้บริการรายงานเอง หมายเหตุเรื่อง saturation ของตารางเองคือบรรทัดที่มีประโยชน์ที่สุดในหน้านี้: สามอันดับแรกมีช่วงคะแนนห่างกันประมาณ 70 คะแนน ขณะที่สิบอันดับแรกอยู่ในช่วงห่างกันประมาณ 10 คะแนน ดังนั้นตารางนี้ยังแยกโมเดลได้ — แต่ไม่ใช่ที่ส่วนบนของช่วง ซึ่งการจัดลำดับตรงนั้นมีความแตกต่างกันน้อย

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

{{1}}ข้อควรระวังเดียวกันนี้ใช้ในทางกลับกันกับกับดักที่เบนช์มาร์กนี้วางไว้สำหรับผู้อ่าน: โมเดลที่ไม่มีแถว CyberGym ไม่ได้มีคะแนนเป็นศูนย์ มันยังไม่ได้ถูกวัดในฮาร์เนสนั้น ซึ่งเป็นข้อความที่แตกต่างกัน การถือว่าการไม่มีอยู่คือความล้มเหลวคือวิธีที่ตารางหยุดเป็นเครื่องมือวัดและกลายเป็นกระดานอันดับ{{/1}}

คะแนนสูงหมายความและไม่หมายความอะไรสำหรับกองหลัง

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

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

ไม่ได้หมายความว่าเอเจนต์จะเข้าใจโค้ดเบส โมเดลภัยคุกคาม หรือการดีพลอยของคุณ งานเหล่านี้มาจากเป้าหมาย OSS-Fuzz สาธารณะที่มีช่องโหว่ที่ทราบคำตอบจริง และมีชุดทดสอบที่บอกเอเจนต์ว่าเสร็จหรือยัง โค้ดโปรดักชันไม่มี oracle แบบนั้น และยังไม่ได้หมายความว่าเอเจนต์จะพบบั๊กที่ถูกต้องแทนที่จะเป็นบั๊กตัวใดตัวหนึ่ง: stage 4 มีอยู่เพราะสองสิ่งนี้แตกต่างกัน และ stage 4 ไม่นับ

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

สิ่งที่ควรถามก่อนจะเชื่อตัวเลขของ CyberGym

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

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

• ใครเป็นผู้รัน?การประเมินโดยอิสระหรือรายงานตนเองของผู้ให้บริการ ตารางรวบรวมระบุสิ่งนี้เป็นรายแถว; สื่อการตลาดส่วนใหญ่ไม่ระบุ

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

• ได้ปรึกษาขั้นที่ 4 แล้วหรือไม่ อัตราที่รายงานพร้อมข้อมูลวินิจฉัยที่แนบมาด้วยจะบอกคุณว่าแพตช์เหล่านั้นแก้ไขบั๊กจริงหรือเพียงแค่กลบการแครชให้เงียบลง

• ชุดงานไหน? ชุดทั่วไปคือ 131 งานที่เลือกหนึ่งงานต่อโปรเจกต์ตามระดับความยาก; ตัวกรองที่ต่างออกไปก็คือการทดสอบที่ต่างออกไป

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