Một số công cụ AI code review đã công bố benchmark của riêng mình. Vấn đề là: không có “SWE-bench” dành cho code review. Không có một thước đo chung. Mỗi vendor chạy benchmark riêng, trên dataset riêng, và đều chiến thắng.
Chúng tôi cũng có “lợi ích trong cuộc chơi này” (gần đây chúng tôi đã công bố benchmark của riêng mình), nên hãy đọc tất cả những điều dưới đây với bối cảnh đó. Chúng tôi cũng sẽ chỉ ra những hạn chế của chính mình.
Vì sao benchmark quan trọng
SWE-bench đã cung cấp cho các coding agent một thước đo chung. Dù còn thiếu sót, nhưng nó là một chuẩn chung. Các team có thể so sánh Devin, SWE-Agent và OpenHands trên cùng một tập task, cùng tiêu chí. Chỉ riêng điều đó đã giúp chuyển cuộc thảo luận từ “hãy tin demo của chúng tôi” sang “hãy đưa ra số liệu của bạn.”
AI code review thì chưa có điều tương tự. Bạn không thể so sánh F1 score của vendor này với recall của vendor khác khi họ đang đo những thứ khác nhau trên dữ liệu khác nhau. Vì vậy, các leader kỹ thuật thường phải quyết định mua dựa trên demo và cảm tính.
Vì sao benchmark code quality là bài toán khó
Security có ground truth tương đối rõ ràng: một CVE либо tồn tại hoặc không. Nhưng code quality thì khó hơn nhiều. Điều gì được xem là “rủi ro bug” so với code chấp nhận được? Một null check bị thiếu là bug hay là quyết định thiết kế có chủ đích? Ngay cả các chuyên gia cũng tranh luận những điều này hàng ngày trong code review.
Không có “CVE database” cho code quality. Để xây dựng ground truth cần các annotator là chuyên gia, trên nhiều ngôn ngữ, và họ phải thống nhất về cách phân loại issue. Bạn cần các phương pháp có nguyên tắc để xử lý bất đồng, và hàng nghìn mẫu đã được gán nhãn để có ý nghĩa thống kê.
Chúng tôi đã thử các cách tiếp cận tự động, sử dụng GitHub API để xây dựng ground truth từ lịch sử review và pattern sửa bug. Nhưng tín hiệu quá nhiễu. Reviewer không đồng ý với nhau, mỗi team có tiêu chuẩn khác nhau, và điều được xem là critical ở codebase này có thể chấp nhận được ở codebase khác.
Chuẩn bị dataset thủ công là điều bắt buộc — và đó là lý do vì sao chưa ai xây dựng được một benchmark code quality đáng tin cậy. Những thứ gần nhất hiện nay là các rule set của linter (ESLint, Pylint), nhưng chúng chỉ định nghĩa “phát hiện cái gì”, chứ không phải một tập test để đánh giá khả năng phát hiện.
Các benchmark của vendor
Chúng tôi đã khảo sát các benchmark công khai do các vendor AI code review công bố tính đến tháng 2 năm 2026.
Greptile
Greptile công bố một trong những benchmark sớm nhất: 50 PR từ 5 repository. Các bug được tái dựng từ các commit sửa lỗi thực tế, tốt hơn so với việc chèn bug giả lập. Nhưng 50 PR trên 5 repo là dataset nhỏ, và mỗi PR chỉ được rút gọn thành một bug đã biết. Benchmark này đo việc tool có tìm được một issue đã được chọn trước hay không, chứ không phải khả năng phát hiện đầy đủ các vấn đề trong một review thực tế.
Cả 5 repo đều là các dự án open-source lớn, nổi tiếng, với lịch sử commit sạch. Không có giải thích vì sao chọn các repo này thay vì các ứng viên khác. Với 50 data point, chỉ vài edge case cũng có thể làm lệch kết quả tổng đáng kể.
Greptile báo cáo 82% recall, cao hơn tool đứng sau 24 điểm. Nhưng với 50 data point, khoảng tin cậy của chênh lệch này rất rộng. Greptile thiết kế benchmark, chọn repo và tự chạy đánh giá.
Sau đó, Augment Code chạy benchmark riêng trên đúng 5 repo đó. Kết quả: Greptile đạt 45%, không phải 82%.
Cùng dataset, nhưng kết quả hoàn toàn khác nhau tùy người chạy benchmark.
Qodo
Qodo công bố một “real-world benchmark” gồm 100 PR và 580 issue trên 8 repository, nhưng các bug là synthetic (giả lập), không phải thực tế.
Qodo thu thập PR từ repo open-source qua GitHub API, sau đó dùng LLM để chèn vi phạm và bug vào. Các tool được đánh giá không phải trên bug do con người viết và deploy, mà là bug do LLM tạo ra và chèn vào. Ground truth được tạo bởi LLM, đánh giá cũng dùng LLM-as-a-judge, và không có bằng chứng rằng bug synthetic phản ánh phân bố hay độ tinh vi của bug thật.
Dataset là một repository mapping liên kết PR với kết quả review của từng tool, nhưng ground truth (các bug dùng để chấm điểm) không được công bố. Vì vậy không ai có thể tái lập kết quả. Qodo thiết kế và chạy benchmark, báo cáo F1 là 60.1%.
Các vendor khác
Augment Code công bố benchmark với 50 PR từ cùng 5 repo như Greptile, mô tả dataset là “expanded and corrected” từ bản gốc. Augment báo cáo F1 là 59%.
Propel sử dụng dataset của Augment như một framework đánh giá “externally-authored”. Propel báo cáo F1 là 64%.
Macroscope công bố benchmark gồm 118 bug trên 45 repo và 8 ngôn ngữ — dataset rộng hơn về độ đa dạng. Macroscope báo cáo tỷ lệ phát hiện là 48%.
Entelligence công bố benchmark gồm 67 bug trên cùng 5 repo như Greptile, test 8 tool. Ground truth được xây dựng bằng cách cho 3 LLM frontier tạo comment review độc lập, lọc theo majority vote, sau đó được xác thực bởi reviewer nội bộ. Entelligence báo cáo F1 là 47.2%.
Các tool khác (CodeRabbit, Devin, Cursor BugBot) chưa công bố benchmark — và mọi vendor đã công bố thì đều thắng benchmark của chính mình.
Vấn đề tự đánh giá
Điều này không hẳn là cố ý. Khi bạn thiết kế benchmark, bạn phải đưa ra hàng chục quyết định nhỏ: chọn repo nào, định nghĩa bug “thực” là gì, chấm điểm partial match ra sao. Người thiết kế tự nhiên hiểu rõ tiêu chí của mình và sẽ (có ý thức hoặc không) tối ưu theo nó. Trường hợp Greptile/Augment cho thấy rõ: cùng repo, nhưng khác rule đánh giá, dẫn đến bảng xếp hạng hoàn toàn khác.
Các công ty dược không tự thiết kế và chạy thử nghiệm lâm sàng cho sản phẩm của mình. Tự đánh giá luôn có bias, kể cả khi thiện chí. Đánh giá độc lập, dataset công khai, phương pháp có thể tái lập — hiện chưa tồn tại trong AI code review.
Điều gì tạo nên một benchmark đáng tin cậy
-
Ground truth thực: bug từ CVE database, commit sửa lỗi, hoặc defect đã được con người xác thực — không phải synthetic. Nếu ground truth do model tạo, không rõ benchmark đang đo cái gì.
-
Dataset công khai có thể tải về: tối thiểu phải có artifact được version hóa mà bất kỳ ai cũng có thể chạy lại.
-
Đánh giá mù (blind evaluation): judge (người hoặc LLM) không được biết kết quả thuộc về tool nào.
-
Chạy độc lập: lý tưởng nhất là bên không có lợi ích tài chính chạy benchmark. Nếu tự chạy, phải công bố output thô, prompt của judge, logic chấm điểm, và từng verdict.
-
Cỡ mẫu đủ lớn: 50 PR là không đủ. Nhiễu thống kê sẽ chi phối, và vài edge case có thể làm lệch 10+ điểm. Bất kỳ dataset nào dưới 100 entry đều nên bị nghi ngờ.
Benchmark của chúng tôi — và giới hạn của nó
Chúng tôi sẽ là đạo đức giả nếu không áp dụng chính tiêu chí này cho benchmark của mình.
Chúng tôi sử dụng 165 CVE thực từ dataset OpenSSF, không phải bug synthetic. Dataset gốc lớn hơn, nhưng chúng tôi lọc theo các tiêu chí:
-
Có cả commit trước và sau khi patch, để dựng lại phiên bản có lỗ hổng và đã sửa.
-
Trường “weaknesses” không rỗng, vì cần định danh CWE để biết ground truth.
-
File bị ảnh hưởng dưới 1,000 dòng, để đảm bảo thời gian chạy hợp lý trên 165 entry.
Một số entry bị loại vì không thể dựng lại diff, có thể do commit bị force-push làm mất lịch sử. Chúng tôi chấp nhận 165 entry chắc chắn thay vì 300 entry đáng ngờ.
Toàn bộ kết quả đã chấm được công bố dưới dạng JSONL trong repo benchmark, và LLM judge (Claude Opus 4.5) không thấy tên tool, nên không thể thiên vị.
Nhưng chúng tôi vẫn có hạn chế:
-
Benchmark do chính chúng tôi chạy
-
Dataset đã công bố nhưng chưa có bên thứ ba xác minh
-
165 entry vẫn chưa phải là lớn
-
Chỉ cover security, chưa có code quality
Trang benchmark ghi rõ “Security Benchmarks”, không phải “AI Code Review Benchmarks” — vì sự khác biệt này là quan trọng.
Điều còn thiếu
AI code review cần một thứ giống như SWE-bench đã làm cho coding agent: một benchmark do cộng đồng duy trì, không thuộc kiểm soát của bất kỳ vendor nào. Dataset CVE của OpenSSF là nền tảng gần nhất cho security. Nhưng với code quality, công việc này vẫn chưa được thực hiện — và không một vendor nào có đủ động lực hoặc uy tín để làm một mình.
Cho đến khi điều đó xuất hiện, hãy nhìn mọi benchmark của vendor — kể cả của chúng tôi — với sự hoài nghi. Hãy tìm dataset công khai, phương pháp có thể tái lập, và phạm vi được mô tả trung thực. Và đặc biệt cảnh giác với bất kỳ benchmark nào mà người thiết kế cũng chính là người chiến thắng.