Giải thích Benchmark CyberGym: Điểm E2E thực sự đo lường điều gì

Điểm CyberGym được lan truyền rộng rãi nhất — con số trong bài đăng ra mắt, con số được đem so sánh giữa các mô hình — là tỷ lệ thành công tác vụ trên 131 tác vụ đã lọc, trong đó thành công nghĩa là một tác nhân tạo ra đầu vào proof-of-concept làm sập một bản dựng C/C++ chưa được vá, viết một bản vá ngăn được sự cố sập đó và không làm hỏng các bài kiểm thử do nhà phát triển của dự án viết. Trong bản tổng hợp của BenchLM, MiMo-V2.6-Flash dẫn đầu với 95,1% và MiMo-V2.6-Pro với 94,0%, còn DeepSeek-V4.1-Flash kém vài điểm, ở mức cuối tám mươi. Gần như không ai trích dẫn bảng đó nhắc đến ba điều quyết định liệu các con số có so sánh được hay không: benchmark tồn tại ở nhiều hơn một cách triển khai, phần lớn các hàng là tự báo cáo của nhà cung cấp chứ không phải các lần chạy độc lập, và giai đoạn thú vị nhất lại được ghi nhận nhưng không được tính. Đó cũng là chuẩn ghi nguồn kho lưu trữ sự cố AI áp dụng cho chính các mục của mình — một tuyên bố không có nguồn thì không phải là kết quả — và tập dữ liệu CyberGym vi phạm chuẩn này thường xuyên hơn mức danh tiếng của nó gợi ý.

Đây là hướng dẫn về những gì benchmark yêu cầu một tác nhân phải làm, cách bộ nhiệm vụ được xây dựng, những điểm mà các cách triển khai khác nhau, và điều mà người phòng thủ nên và không nên kết luận từ một điểm số cao.

Nhiệm vụ: tìm, tái hiện, vá — mà không làm hỏng bất cứ thứ gì

CyberGym đến từ Berkeley Center for Responsible, Decentralized Intelligence, và tiền đề của nó được cố ý thu hẹp. Mỗi tác vụ nhắm vào một lỗ hổng an toàn bộ nhớ trong một dự án C/C++ mã nguồn mở được sử dụng rộng rãi. Tác tử phải định vị lỗi, viết đầu vào proof-of-concept gây ra sự cố sanitizer, rồi vá mã để sự cố không còn tái hiện — trong khi các bài kiểm thử của chính dự án vẫn tiếp tục đạt. Chuỗi thao tác đó chính là toàn bộ mục đích. Một benchmark chỉ yêu cầu “tìm lỗi” sẽ thưởng cho việc nhận diện mẫu; việc yêu cầu một đầu vào gây sự cố thực sự hoạt động và một bản vá không làm hỏng thứ khác buộc tác tử phải khép kín vòng lặp từ nghi ngờ đến khuyết điểm được chứng minh đến sửa chữa.

RDI vận hành benchmark này bên trong một đài quan sát rộng hơn, theo dõi năng lực mạng của AI xuyên suốt các giai đoạn tấn công và phòng thủ, và cách định khung này đáng để lưu ý: CyberGym chỉ là một dụng cụ trên bàn thí nghiệm, cùng với ExploitGym và biến thể end-to-end. Đọc nó như một bảng xếp hạng độc lập sẽ đánh mất bối cảnh đó, và đây là một lý do khiến các con số lan truyền kém.

Bốn giai đoạn, trong đó ba giai đoạn được tính điểm

Quy tắc tính điểm là phần ít được báo cáo nhất của bài đánh giá chuẩn, vì đây là nơi một điểm số nghe có vẻ hợp lý có thể lệch khỏi những gì thực sự đã xảy ra.

Giai đoạn 1 là bước tái hiện: đầu vào proof-of-concept của tác nhân có làm sập bản dựng chưa được vá hay không. Giai đoạn 2 là bản vá: thay đổi được gửi có chặn được đúng sự cố sập đó hay không. Giai đoạn 3 là kiểm tra hồi quy: các bài kiểm thử chức năng do nhà phát triển viết có còn vượt qua hay không. Ba bước đó tạo ra điểm số.

Stage 4 hỏi liệu bản vá có khắc phục đúng lỗ hổng ground-truth thực tế hay không, và nó được ghi nhận như một chẩn đoán thay vì được tính điểm. Sự bất đối xứng đó đáng để dừng lại một chút, vì nó là khác biệt giữa "tác nhân có thể làm một sự cố sập biến mất" và "tác nhân có thể sửa được lỗi". Cả hai đều là những khẳng định hữu ích; chúng không phải là cùng một khẳng định. Một tác nhân triệt tiêu sự cố sập bằng cách bắt tín hiệu, mở rộng kiểm tra biên vượt quá lỗi tràn, hoặc vô hiệu hóa hoàn toàn đường thực thi mã sẽ ghi điểm ở các giai đoạn 1 đến 3 và trượt giai đoạn 4. Nếu một bài viết báo cáo một con số duy nhất mà không nói liệu giai đoạn 4 có được xem xét hay không, bạn không thể biết điều nào trong hai điều đã được đo — và chẩn đoán tồn tại chính xác để bạn có thể hỏi.

Cách 131 tác vụ được chọn — và điều đó ảnh hưởng đến điểm số như thế nào

Bộ dữ liệu nguồn lớn hơn tập được chấm điểm, và việc lọc là đòn bẩy lớn nhất đối với tính so sánh được. Bộ dữ liệu của RDI chứa 920 lỗ hổng trên 139 dự án mã nguồn mở, được lấy từ OSS-Fuzz của Google. Biến thể end-to-end được các trình theo dõi bên thứ ba sử dụng thu hẹp tập đó xuống còn 131 tác vụ, với một tác vụ cho mỗi dự án, được chọn theo độ khó, loại trừ các tác vụ có rò rỉ oracle hoặc ràng buộc tương thích sandbox.

Ba hệ quả rút ra trực tiếp. Thứ nhất, một tác vụ cho mỗi dự án nghĩa là điểm số bị chi phối bởi độ bao phủ hơn là độ sâu: một agent chỉ ở mức trung bình trên nhiều dự án sẽ vượt trội hơn một agent xuất sắc trên ba dự án, đây là một lựa chọn thiết kế có thể biện minh được và là một phép đo khác với "agent này có thể sửa bao nhiêu lỗ hổng". Thứ hai, loại trừ rò rỉ oracle loại bỏ những tác vụ mà câu trả lời có thể được phát hiện từ môi trường thay vì được suy luận ra, vì vậy tập còn lại khó hơn theo một cách cụ thể — nó loại bỏ các lối tắt thay vì loại bỏ các tác vụ dễ. Thứ ba, ngân sách 90 phút cho mỗi tác vụ bên trong một sandbox được xây dựng từ image OSS-Fuzz của dự án là một phần của định nghĩa thành công, không phải chi tiết, bởi vì một phần lớn công việc lỗ hổng thực tế bị giới hạn bởi chính xác loại ràng buộc đó và những agent phụ thuộc vào khám phá không giới hạn sẽ thất bại ở đây trong khi thành công ở nơi khác.

Bất kỳ so sánh nào bỏ qua quy tắc chọn tác vụ đều là đang so sánh hai bài kiểm tra khác nhau mà tình cờ trùng tên.

Hai cách triển khai, và lý do tại sao chúng không nhất thiết phải khớp với nhau

Đây chính là nơi phần lớn sự nhầm lẫn nằm ở đó. CyberGym-E2E tồn tại như một benchmark RDI và như một triển khai do một đơn vị đánh giá bên thứ ba vận hành, và hai thứ này không được đảm bảo sẽ tạo ra cùng một con số cho cùng một mô hình. Tài liệu của chính đơn vị đánh giá nói rõ điều đó: triển khai của họ sử dụng một tập hợp đã lọc gồm 131 tác vụ, mỗi dự án một tác vụ, được chọn theo độ khó, và nó chạy mọi tác vụ trong một sandbox biệt lập được dựng từ image OSS-Fuzz của dự án bằng bộ khung agent của riêng họ với ngân sách 90 phút cho mỗi tác vụ.

Câu đó chứa hai biến quyết định điểm số. Khung kiểm thử là vòng lặp mà tác nhân vận hành bên trong — cách nó quan sát đầu ra của công cụ, số bước nó có thể thực hiện, cách nó phục hồi sau một lần thử thất bại. Một khung kiểm thử mạnh hơn với một mô hình yếu hơn có thể đánh bại chiều ngược lại, và khung kiểm thử không thuộc về trọng số của mô hình. Ngân sách tương tác với cả hai. Vì vậy, một con số CyberGym được viết đúng cách là "mô hình này, trong khung kiểm thử này, trong cách triển khai này", và một con số được trích dẫn mà không có cách triển khai là một con số không có mẫu số.

Có một hiệu ứng bậc hai đáng được nêu rõ: bởi vì harness đang thực hiện công việc thực sự, nên mức cải thiện điểm CyberGym giữa hai phiên bản mô hình có thể một phần là nhờ cải thiện harness, và một nhà cung cấp báo cáo kết quả harness của chính mình là đang báo cáo năng lực hệ thống chứ không phải năng lực mô hình. Cả hai đều chính đáng; đánh đồng chúng thì không.

Đọc bảng theo dõi một cách trung thực

Bảng mà hầu hết mọi người gặp phải là một bản tổng hợp thứ cấp, và bảng này tự ghi rõ nguồn gốc của mình — đó là phần hữu ích, nếu bạn đọc phần ghi chú đó. Trong 29 dòng, có 7 dòng đến từ đơn vị sở hữu benchmark hoặc một lượt chạy độc lập, 21 dòng là báo cáo tự công bố của nhà cung cấp, và một dòng là báo cáo thứ cấp. Bản tổng hợp nói thẳng rằng nó trình bày bảng để tham khảo và không xếp hạng dựa trên đó, đồng thời khuyên đọc cẩn trọng vì phần lớn các dòng là tự báo cáo. Ghi chú về độ bão hòa của chính bảng là dòng hữu ích nhất trên trang: ba mô hình đứng đầu trải rộng khoảng 70 điểm trong khi top 10 nằm trong khoảng chênh lệch chừng 10 điểm, nên bảng vẫn phân tách được các mô hình — nhưng không phải ở phần cao nhất của dải, nơi thứ tự xếp hạng rất mỏng manh.

Tự báo cáo của nhà cung cấp là bằng chứng có thể hiển thị. Đó không phải là đo lường độc lập, và sự khác biệt này quan trọng trong chuẩn đánh giá này hơn hầu hết các trường hợp khác, vì biến harness cho nhà cung cấp khá nhiều dư địa để tinh chỉnh con số mà họ báo cáo. Khi tự báo cáo và một lần chạy độc lập mâu thuẫn với nhau, lần chạy độc lập sẽ thắng. Khi chỉ tồn tại một tự báo cáo, cách đọc trung thực là “chưa được xác minh, có vẻ hợp lý, không có đường cơ sở so sánh được”.

Lời cảnh báo tương tự cũng áp dụng theo chiều ngược lại đối với cái bẫy mà benchmark này đặt ra cho người đọc: một mô hình không có hàng CyberGym nào không có nghĩa là đã đạt điểm không. Nó chưa được đo trong harness đó, và đó là một khẳng định khác. Coi sự vắng mặt là thất bại chính là cách một bảng biểu thôi là phép đo và trở thành bảng xếp hạng.

Điểm cao có ý nghĩa gì và không có ý nghĩa gì đối với một hậu vệ

Câu hỏi mà một đội bảo mật thực sự quan tâm không phải là "mô hình nào đứng đầu bảng" mà là "một tác nhân đạt điểm cao trong bài này sẽ tác động thế nào đến rủi ro của tôi". Bộ đánh giá chuẩn trả lời một câu hỏi hẹp hơn câu đang được hỏi, và khoảng cách đó đáng được gọi tên.

Điều đó thực sự có nghĩa là tác nhân có thể, trong vòng 90 phút và bên trong một bản dựng đã biết, định vị một lỗi an toàn bộ nhớ trong mã nguồn mở thực tế, tạo ra một đầu vào gây sập hoạt động được, và viết một thay đổi ngăn được sự cố sập mà không làm hỏng các bài kiểm thử. Đó là một năng lực thực sự, nó liên quan trực tiếp đến công việc phân loại và vá lỗi, và đó là kiểu nhiệm vụ mà một tác nhân có năng lực có thể rút ngắn đáng kể hàng đợi của chuyên viên phân tích.

Điều đó không có nghĩa là tác nhân hiểu được cơ sở mã của bạn, mô hình mối đe dọa của bạn hay cách triển khai của bạn. Các nhiệm vụ được lấy từ các mục tiêu OSS-Fuzz công khai có một lỗ hổng đã biết làm chuẩn đối chứng và một bộ kiểm thử cho tác nhân biết liệu nó đã hoàn thành chưa. Mã trong môi trường sản xuất không có oracle như vậy. Điều đó cũng không có nghĩa là tác nhân sẽ tìm ra lỗi đó thay vì một lỗi: giai đoạn 4 tồn tại vì chúng phân kỳ, và giai đoạn 4 không được tính.

Và nó không chuyển sang phía tấn công, nơi cùng một năng lực lại được hiểu theo cách khác. Một tác nhân có thể định vị và tái tạo một lỗ hổng an toàn bộ nhớ có thể làm điều đó trong đoạn mã mà nó không được cấp quyền kiểm thử, đó là lý do vì sao năng lực ở cấp độ này chính là điều thúc đẩy kiểm soát truy cập ở cấp độ mô hình thay vì một lời miễn trừ trách nhiệm trong lời nhắc hệ thống.

Cần hỏi những gì trước khi tin vào một con số CyberGym

Năm câu hỏi, có thể trả lời được từ một bản báo cáo được viết chỉn chu và thường không thể trả lời được từ một bài đăng giới thiệu ra mắt.

• Triển khai nào? Bộ đánh giá chuẩn của RDI, hay một biến thể đã được lọc của đơn vị đánh giá bên thứ ba. Nếu báo cáo không nêu rõ, con số đó không thể so sánh với bất cứ điều gì.

• Lượt chạy của ai?Đánh giá độc lập hay tự báo cáo của nhà cung cấp. Bảng tổng hợp ghi nhãn cho từng dòng; hầu hết tài liệu tiếp thị thì không.

• Khung kiểm thử nào, và ngân sách bao nhiêu? Nếu khung kiểm thử là của chính nhà cung cấp và không được mô tả, hãy coi kết quả là một tuyên bố ở cấp hệ thống về một cấu hình sản phẩm cụ thể.

• Đã tham khảo giai đoạn 4 chưa? Tỷ lệ được báo cáo cùng với thông tin chẩn đoán đi kèm cho bạn biết liệu các bản vá đã sửa lỗi hay chỉ làm im lặng sự cố.

• Bộ tác vụ nào? 131 tác vụ, mỗi dự án một tác vụ, được chọn theo độ khó là bộ phổ biến; một bộ lọc khác là một bài kiểm tra khác.

Cybergym là một benchmark được xây dựng tốt cho một nhiệm vụ thực tế, khó, và cách nó được xây dựng thú vị hơn cả bảng xếp hạng của nó. Các giai đoạn cho bạn biết một agent đã phải làm gì; việc lọc cho bạn biết điểm số là điểm số của cái gì; harness cho bạn biết ai xứng đáng được ghi công. Một con số đi kèm với ba thứ đó là thực sự hữu ích. Một con số xuất hiện một mình chỉ là một thông cáo báo chí kèm dấu phần trăm.