Điểm benchmark AI an ninh mạng cao chưa chứng minh tác nhân vá lỗi trọn vẹn

Điểm benchmark AI an ninh mạng cao chỉ chứng minh tác nhân làm tốt nhiệm vụ mà phép thử thực sự đo. Nếu benchmark dừng ở tái hiện một lỗ hổng đã được mô tả, kết quả đó chưa chứng minh tác nhân có thể tự tìm lỗi, viết bản vá và giữ phần mềm hoạt động bình thường.

Muốn biết một điểm số có phù hợp để chọn tác nhân vá lỗi hay không, cần đối chiếu sáu yếu tố: dữ liệu, ranh giới nhiệm vụ, công cụ, ngân sách suy luận, tiêu chí thành công và khả năng khái quát. Tên chỉ số như pass@1 hoặc nhãn “end-to-end” không thể thay thế phần mô tả phương pháp.

Phạm vi phép đo quan trọng hơn thứ hạng

Một kết quả chỉ so sánh được khi đầu vào, quyền hành động, tài nguyên và bộ xác minh đủ tương đồng. Tác nhân nhận sẵn mô tả lỗ hổng và mã nguồn chưa vá đang giải bài toán hẹp hơn tác nhân chỉ nhận một kho mã chưa được chú thích.

Đầu ra cũng phải được gọi đúng tên. Tạo được PoC làm chương trình lỗi không đồng nghĩa với tìm ra nguyên nhân gốc; ngăn PoC đó gây lỗi chưa chắc đã bảo toàn chức năng; còn một bản vá vượt qua bộ kiểm thử của benchmark chưa mặc nhiên đáp ứng kiểm thử tích hợp, chính sách phê duyệt và điều kiện triển khai của doanh nghiệp.

Vì vậy, khi đọc leaderboard, hãy đặt tên nhiệm vụ ngay cạnh điểm số: tái hiện lỗ hổng, phát hiện lỗ hổng, tạo PoC, chỉ tạo bản vá hay hoàn tất chuỗi end-to-end. Cách ghi này ngăn tỷ lệ thành công ở một công đoạn bị trình bày thành năng lực tự động hóa toàn bộ quy trình.

CyberGym và CyberGym-E2E không đo cùng một công việc

Trang dự án CyberGym mô tả 1.507 trường hợp từ 188 dự án phần mềm. Ở Level 1 dùng cho leaderboard, tác nhân nhận mô tả lỗ hổng cùng mã nguồn chưa vá rồi tạo PoC; một trường hợp thành công khi PoC kích hoạt lỗi trên phiên bản trước bản vá nhưng không kích hoạt trên phiên bản sau bản vá.

CyberGym vì thế cung cấp bằng chứng về khả năng điều hướng kho mã và tái hiện lỗ hổng mục tiêu trong điều kiện đã có mô tả. Chính trang dự án nêu rõ lượt chạy có tính ngẫu nhiên, số lần thử có thể khác nhau và chênh lệch điểm nhỏ chưa chắc phản ánh khoảng cách năng lực có ý nghĩa. Kết quả Level 1 không tự bao hàm phát hiện mục tiêu hoặc tạo bản vá.

Ngược lại, bài nghiên cứu CyberGym-E2E công bố bộ đánh giá gồm 920 lỗ hổng thực tế từ 139 dự án nguồn mở, bao phủ phát hiện lỗ hổng, tạo PoC và tạo bản vá. Trong chế độ end-to-end, dữ liệu đúng về lỗ hổng được giữ lại và tác nhân phải bắt đầu từ mã nguồn; các bước xác minh tích lũy còn kiểm tra bản vá loại bỏ lỗi do PoC gây ra, dự án vẫn qua kiểm thử chức năng và lỗ hổng mục tiêu cũng được chặn.

Hai benchmark vì vậy trả lời hai câu hỏi khác nhau. Điểm CyberGym cho biết tác nhân tái hiện lỗi đã biết tốt đến đâu trong cấu hình cụ thể; kết quả CyberGym-E2E mới kiểm tra một chuỗi tự động hóa rộng hơn. Ngay cả chuỗi này vẫn là vòng đời theo định nghĩa và môi trường của benchmark, không phải chứng nhận sẵn sàng triển khai trong mọi hệ thống doanh nghiệp.

pass@1 phải đi cùng cấu hình chạy

pass@1 ước lượng khả năng một mẫu đầu ra vượt qua bộ chấm. Nó không cho biết nhiệm vụ rộng đến đâu, tác nhân đã được cấp công cụ gì hoặc một lần tạo kết quả tiêu tốn bao nhiêu bước, token và thời gian.

nghiên cứu nền tảng về pass@k cho thấy lấy mẫu lặp lại có thể làm tăng mạnh xác suất tìm được lời giải chạy đúng trên bài toán sinh mã. Do đó, pass@1 và tỷ lệ giải được khi cho nhiều mẫu trả lời hai câu hỏi vận hành khác nhau: xác suất thành công của một mẫu so với khả năng tìm thấy ít nhất một phương án đạt chuẩn trong một ngân sách thử lớn hơn.

Ngay cả hai kết quả cùng ghi pass@1 cũng chưa chắc tương đương nếu cấu hình tác nhân khác nhau về số bước suy luận, phản hồi thực thi, bộ nhớ, debugger, sanitizer hoặc quyền truy cập shell. Khi báo cáo không công bố những điều kiện này, điểm số chưa đủ để suy ra chi phí cho mỗi kết quả đạt chuẩn hay hiệu năng trong quy trình chỉ cho phép một đề xuất.

Sáu câu hỏi phải trả lời trước khi dùng điểm số

1. Dữ liệu gồm những gì? Xem dự án, ngôn ngữ, loại lỗ hổng, thời điểm thu thập và cách tách tập. Dữ liệu lịch sử thực tế vẫn có thể khác kho mã, framework và mô hình đe dọa của tổ chức.
2. Nhiệm vụ bắt đầu và kết thúc ở đâu? Xác định tác nhân có nhận mô tả lỗi, vị trí tệp, stack trace, crash log hoặc PoC hay không; đầu ra được yêu cầu là cảnh báo, PoC, bản vá hay toàn bộ chuỗi.
3. Cấu hình được dùng công cụ gì? Kiểm tra quyền với trình biên dịch, sanitizer, debugger, shell, Internet, kho tri thức và phản hồi từ lần chạy. Điểm của cả hệ thống tác nhân không nên bị quy hoàn toàn cho mô hình nền.
4. Ngân sách suy luận là bao nhiêu? Ghi số mẫu, số lượt thử, giới hạn bước, token, thời gian và cơ chế thử lại. Thành công sau nhiều phương án không tương đương thành công ngay ở một mẫu.
5. Thành công được xác minh thế nào? Với PoC, xem phép thử có phân biệt phiên bản trước và sau bản vá hay không. Với bản vá, cần biết lỗi có biến mất, kiểm thử chức năng có còn qua và lỗ hổng mục tiêu có thực sự bị chặn hay không.
6. Kết quả khái quát đến đâu? Tìm kết quả theo từng dự án, loại lỗi, độ phức tạp kho mã và độ dài PoC thay vì chỉ nhìn trung bình. Ưu tiên thêm dữ liệu mới hoặc tập đánh giá gần với môi trường dự kiến triển khai.

Từ leaderboard đến quyết định chọn tác nhân

Với mỗi cấu hình, hãy lập một hàng gồm sáu trường trên và đánh dấu “chưa công bố” cho dữ liệu còn thiếu. Những ô trống là giới hạn của bằng chứng, không phải chi tiết có thể tự suy diễn từ tên mô hình hoặc vị trí xếp hạng.

Sau đó đối chiếu benchmark với công việc cần tự động hóa. Nếu mục tiêu là hỗ trợ tạo PoC cho lỗi đã biết, kết quả tái hiện có thể là tín hiệu trực tiếp. Nếu tác nhân sẽ được giao quyền sửa mã, phép đo cần bao phủ phát hiện, PoC, bản vá và kiểm thử sau vá; tổ chức vẫn phải đánh giá lại trên kho mã, bộ kiểm thử và chính sách công cụ của mình.

Điểm cao chỉ có giá trị trong phạm vi đã đo. Nó có thể là bằng chứng tốt cho một công đoạn, nhưng tuyên bố về tác nhân vá lỗi trọn vẹn đòi hỏi kết quả end-to-end với tiêu chí xác minh phù hợp và bằng chứng khái quát sang môi trường sử dụng thực tế.

Đọc thêm:

• Mở Salesforce cho tác nhân AI: Sai quyền người dùng có thể thành quyền của bot
• GitHub Copilot đổi cách tính tiền ghế: xóa người dùng giữa kỳ vẫn chưa hết phí
• Ứng dụng vibe coding chạy được chưa chắc an toàn: 10 điểm phải kiểm tra