c-CRAB, Điểm chuẩn Code Review Agent: Nó đo lường gì, nó phát hiện ra điều gì, và 41.5% thực sự nghĩa là gì

Một tác nhân đánh giá mã và một người đánh giá đã xem cùng một yêu cầu kéo và nêu ra cùng một mối quan ngại. Việc thực hiện theo bình luận của tác nhân sẽ sửa lỗi; bài kiểm tra vượt qua. Và mọi chỉ số tương đồng văn bản mà các tác giả tính toán đều đánh giá bài đánh giá của tác nhân về cơ bản là không liên quan đến bài của con người: BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, độ tương đồng embedding 54.59. Cùng một mối quan ngại, nhưng từ ngữ khác nhau, và cách chấm điểm bài đánh giá tiêu chuẩn không thể thấy rằng chúng nhất quán. Ví dụ đó chính là lập luận đằng sau c-CRAB (phát âm là “see-crab”), chuẩn đánh giá tác nhân đánh giá mã được công bố dưới dạng arXiv:2603.23448.

c-CRAB đánh giá các agent đánh giá mã, không phải các agent viết mã. Với một pull request — có thể đến từ con người hoặc từ một agent viết mã — một agent đánh giá tạo ra một bản đánh giá, và c-CRAB chấm điểm bản đánh giá đó dựa trên việc thực hiện theo nó có tạo ra một bản sửa lỗi đúng về mặt hành vi hay không. Điểm chuẩn này được xây dựng bởi các nhà nghiên cứu kỹ thuật phần mềm Yuntong Zhang, Zhiyuan Pan, Imam Nur Bani Yusuf, Haifeng Ruan, Ridwan Shariffdeen và Abhik Roychoudhury, và nó đánh giá bốn công cụ: PR-Agent, Devin, Claude Code và Codex. Một trong các tác giả có liên kết với SonarSource, và bài báo nói rõ điều đó có nghĩa gì và không có nghĩa gì, theo chính lời của bài báo: “Các quan điểm và kết luận được trình bày trong bài báo này là của riêng các tác giả và không đại diện cho các chính sách chính thức hay sự tán thành của SonarSource. Hơn nữa, các phát hiện được nêu ở đây là độc lập và không nên được hiểu như là sự đánh giá chất lượng các sản phẩm tại SonarSource.”

Hai lưu ý trước khi đi vào chi tiết. Một số bài viết của bên thứ ba gọi cùng công trình này là “CR-bench”; đó là cùng một benchmark, và trang này dùng c-CRAB xuyên suốt. Mọi biểu đồ bên dưới là kết quả do chính bài báo báo cáo, được đọc từ bài báo và gói tái lập ở thời điểm hiện tại — không phải chạy lại độc lập — và phần diễn giải là của chúng tôi cùng với các thảo luận từ giới thực hành mà bài báo đã thu hút. Không có gì trong số đó là khuyến nghị từ các nhà cung cấp có công cụ được đánh giá. Và nếu bạn vẫn đang cân nhắc có nên chạy một tác nhân rà soát mã hay không, hướng dẫn người mua về các tác nhân rà soát mã của chúng tôi là điểm khởi đầu tốt hơn; trang này nói về cách các tác nhân đó được đo lường.

Tại sao c-CRAB chấm điểm các bài đánh giá bằng bài kiểm tra thay vì dùng bộ chấm điểm LLM

Cách thông thường để chấm điểm một tác nhân đánh giá mã là so sánh bài đánh giá của nó với bài của con người, sử dụng LLM-as-judge hoặc một độ đo tương đồng văn bản. Các tác giả của c-CRAB bác bỏ cả hai. Họ lập luận rằng LLM-as-judge mắc phải sự thiên vị, bất ổn định và nhạy cảm với prompt, khiến việc chấm điểm nhất quán và có thể tái lập trở nên khó khăn. Và nghiên cứu điển hình ở trên cho thấy các độ đo chuỗi thực sự đo lường điều gì: cách diễn đạt, chứ không phải hiệu quả. Trong pull request python-telegram-bot đó, bài đánh giá của Codex nói điều tương tự như con người, nhưng BLEU-4 và ROUGE-L không thể nhận ra điều đó.

So c-CRAB làm điều ngược lại. Mỗi nhận xét đánh giá của con người được chuyển thành một bài kiểm tra có thể thực thi nhằm nắm bắt vấn đề cơ bản. Một nhận xét đánh giá được coi là đúng nếu hành động theo nó tạo ra một bản sửa lỗi đúng về mặt hành vi — một bản sửa lỗi làm cho bài kiểm tra vượt qua. Mỗi instance đi kèm với một môi trường Docker có thể thực thi, vì vậy quyết định đạt/không đạt được đưa ra bằng cách chạy mã, không phải bằng cách hỏi một mô hình khác xem hai văn bản giống nhau đến mức nào. Đó là lý do tại sao điều này quan trọng: công việc của một bài đánh giá là thay đổi những gì lập trình viên làm, và một bài kiểm tra là tín hiệu chấm điểm duy nhất đo lường trực tiếp sự thay đổi đó.

Bài báo định nghĩa hai loại kiểm thử, theo chính lời của nó: “Kiểm thử hành vi nhập và thực thi mã được kiểm thử tại thời điểm chạy. Chúng gọi các hàm được kiểm thử với các đầu vào cụ thể, kiểm tra đầu ra hoặc xác minh các ngoại lệ. Mặt khác, kiểm thử cấu trúc xem xét văn bản mã nguồn, so khớp các mẫu và kiểm tra bề mặt API để xác định xem các thay đổi mã mong muốn đã được thực hiện hay chưa.” Tỷ lệ cuối cùng là 42 kiểm thử hành vi (17,9%) và 192 kiểm thử cấu trúc (82,1%). Đáng để nói một câu thành thật: phần lớn oracle là so khớp mẫu trên văn bản nguồn, chứ không phải thực thi mã. Sự lệch đó là một hạn chế thực sự cần ghi nhớ.

Benchmark được xây dựng như thế nào, và chi phí phễu là bao nhiêu.

c-CRAB được xây dựng dựa trên bộ dữ liệu inclusionAI/SWE-CARE hiện có, bộ dữ liệu này cung cấp các phiên bản pull-request kèm siêu dữ liệu commit; đóng góp riêng của c-CRAB là oracle, không phải kho PR. Quy trình tuyển chọn chạy bốn bộ lọc, và mỗi bộ lọc làm giảm số lượng phiên bản. Bài báo trình bày phễu lọc như sau:

• Bộ dữ liệu ban đầu — 671 PR, 1.313 bình luận.

• Lọc đánh giá — 410 PR, 595 bình luận. Bộ phân loại LLM, được hiệu chuẩn dựa trên bộ vàng gồm 100 bình luận được chú thích thủ công, chỉ giữ lại các vấn đề có thể xác minh khách quan và loại bỏ phản hồi mang tính trò chuyện hoặc chủ quan.

• Xây dựng môi trường thực thi — 410 PR, 595 bình luận. Một image Docker cho mỗi PR, với việc phân giải phụ thuộc được chuyển sang tác nhân lập trình khi tự động hóa thất bại.

• Chuyển đổi bình luận ngôn ngữ tự nhiên thành bài kiểm tra — 339 PR, 481 bình luận. Các bài kiểm tra được tạo bằng GPT-5.2 trong vòng lặp tinh chỉnh có hướng dẫn thực thi với tối đa ba lần thử; một bài kiểm tra chỉ được giữ lại nếu nó thất bại trên mã gốc và vượt qua sau khi sửa.

• Kiểm chứng với tác nhân lập trình — 184 PR, 234 bình luận. Claude Code trên backend Sonnet-4.6 cố gắng sửa mã khi chỉ được cung cấp bình luận đánh giá của con người; những trường hợp không thể làm bài kiểm tra vượt qua sẽ bị loại bỏ. Đây là tập hợp cuối cùng.

Khoảng 27% số pull request ban đầu sống sót. Đó là cái giá thực tế của một oracle dựa trên kiểm thử, và cũng là lý do benchmark nhỏ gọn thay vì rộng lớn. Tập hợp sống sót: 184 trường hợp PR, 234 nhận xét đánh giá đã xác thực, 1.27 bài kiểm thử trên mỗi trường hợp, trung bình 418.1 dòng mã sửa đổi trên mỗi PR, 31.8 dòng trên mỗi bài kiểm thử. Hai người chú thích độc lập đánh giá liệu một bài kiểm thử được tạo ra có phản ánh trung thực mối quan tâm của người đánh giá hay không, trên 50 trường hợp mẫu, và đồng thuận 84% thời gian.

Một điểm không nhất quán bạn sẽ nhận thấy nếu đọc kỹ: bảng dữ liệu liệt kê 67 kho lưu trữ, trong khi phần về các mối đe dọa đến tính giá trị lại ghi “184 trường hợp pull request với 234 oracle có thể kiểm chứng trên 56 kho lưu trữ.” Bài báo đưa ra cả hai con số ở những vị trí khác nhau, và chúng tôi không định lấy trung bình hay âm thầm chọn con số thuận tiện. Độc giả dùng chính loại chi tiết này để đánh giá liệu một bộ chuẩn có đáng để họ bỏ thời gian hay không, vì vậy cả hai con số đều được sao chép lại tại đây như khi công bố.

Các kết quả, và cách đọc chúng

Tỷ lệ vượt qua là tỷ lệ vượt qua kiểm thử tổng hợp: với mỗi trường hợp, đó là tỷ lệ các bài kiểm thử của PR đó vượt qua, và con số chính là giá trị trung bình trên tất cả các trường hợp. Bài báo trình bày theo từng công cụ:

• Claude Code — 1,336 bình luận, 7.3 mỗi PR — hành vi 38.1%, cấu trúc 30.7%, tổng thể 32.1%

• Devin — 1.344 bình luận, 7,3 mỗi PR — hành vi 31,0%, cấu trúc 23,4%, tổng thể 24,8%

• PR-Agent — 524 bình luận, 2.8 mỗi PR — hành vi 38.1%, cấu trúc 19.8%, tổng thể 23.1%

• Codex — 324 bình luận, 1,8/PR — hành vi 38,1%, cấu trúc 16,1%, tổng thể 20,1%

• Con người — 234 bình luận, 1.3 mỗi PR — 100% theo thiết kế. Con người đã viết oracle, vì vậy hàng này là một mốc thang đo, không phải đối thủ cạnh tranh.

Hãy đọc kỹ các hàng đó trước khi trích dẫn bất kỳ hàng nào. Con số “chỉ khoảng 40%” trong phần tóm tắt là một phép hợp: 41,5% trong số 234 bài kiểm tra đã được ít nhất một trong bốn công cụ vượt qua. Đây không phải là điểm số của bất kỳ tác nhân đơn lẻ nào — điểm số đơn lẻ cao nhất là 32,1% của Claude Code — và nó không có nghĩa là bốn công cụ cùng nhau phát hiện được 40% lỗi thực tế. Phần dưới đây giải thích lý do.

Con số thú vị nhất không phải là con số của người chiến thắng. Claude Code và Devin mỗi bên đã đăng hơn 1.300 bình luận — khoảng 7,3 bình luận trên mỗi PR — để đạt 32,1% và 24,8%. Codex đăng 324 bình luận, khoảng 1,8 trên mỗi PR, để đạt 20,1%. Đường cơ sở của con người là 1,3 bình luận trên mỗi PR. Hãy làm phép tính: khối lượng bình luận gấp khoảng bốn lần nhưng tỷ lệ vượt qua chỉ tăng chưa đến gấp đôi. Khối lượng không đồng nghĩa với độ bao phủ. Một người đánh giá hay bình luận nhiều không giống với một người đánh giá hữu ích, và c-CRAB là chuẩn đánh giá đầu tiên được thiết lập để chứng minh điều đó.

Sự hữu ích lại có tác dụng ngược lại.

Tỷ lệ vượt qua thấp bị hiểu như một lời lên án cho đến khi bạn xem xét những gì khác mà các tác giả đã đo lường. Họ đã tự tay kiểm tra 92 bình luận trên 6 PR và đánh giá 84% trong số đó hữu ích (77/92) — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. Vì vậy, hầu hết các bình luận không vượt qua bài kiểm tra c-CRAB không phải là nhiễu; chúng đề cập đến điều gì đó mà người đánh giá con người không nêu ra. Mẫu nghiên cứu nhỏ — 92 bình luận, 6 PR — và bài báo thừa nhận điều đó, và chúng ta cũng nên thừa nhận như vậy.

Cùng một mô hình đó cũng xuất hiện trong những gì các nhà đánh giá thảo luận. Các nhà đánh giá là con người thiên về khả năng bảo trì, thiết kế và tài liệu; các công cụ thiên về độ mạnh mẽ, kiểm thử và xử lý lỗi. Bài báo đọc điều này như một lập luận cho sự cộng tác giữa con người và tác nhân thay vì sự thay thế. Đây cũng là lời giải thích hợp lý nhất cho việc vì sao điểm số trông thấp: các tác nhân và con người thường không nhìn vào cùng một thứ, và oracle chỉ thưởng cho danh sách của con người’s.

Điều c-CRAB không thể nhìn thấy

Điểm chuẩn này nói rõ về điểm mù của nó, và chúng tôi cũng vậy. c-CRAB không cho điểm một vấn đề hợp lệ mà người đánh giá con người chưa từng nêu ra. Oracle là ý định đánh giá của con người: một tác nhân tìm ra lỗi thực sự mà không ai nhắc đến sẽ bị điểm 0 cho lỗi đó. Bài báo nói thẳng — các công cụ đánh giá tự động có thể tạo ra những bình luận giá trị khác mà người đánh giá con người không nhận ra, nhưng “giống như các điểm chuẩn hiện có khác, c-CRAB không trực tiếp đánh giá những bình luận bổ sung này.”

Câu đơn lẻ đó chính là lời đính chính cho hầu hết các bài đưa tin về kết quả này. Bất kỳ ai trích dẫn “review agents only solve 40%” như thể nó đo lường số lượng lỗi thực tế mà các tác nhân phát hiện được thì đang hiểu sai con số này. Nó đo lường số lượng các mối quan tâm do con người nêu ra mà các tác nhân, cùng nhau, đã giải quyết được — một tuyên bố hẹp hơn và trung thực hơn nhiều.

Tự chạy

Nếu bạn muốn tái tạo các số liệu hoặc thêm người đánh giá của riêng mình, gói sao chép (replication package) được công khai tại c-CRAB-Benchmark/dataset. Tệp README chính là tài liệu thực tế, và nó mô tả trung thực về hình thức của công cụ. Quá trình thiết lập là code>uv sync/code>; bạn cần có Docker và một code>OPENAI_API_KEY/code> hoặc code>ANTHROPIC_API_KEY/code>, và Claude Code đọc thêm thông tin xác thực từ code>~/.claude/.credentials.json/code>. Tổ chức này cũng công bố các hình ảnh Docker được dựng sẵn cho các môi trường.

Bố cục: code>pipeline//code> chứa logic pipeline và các prompt, code>execution//code> chứa các bộ xây dựng image Docker và các trình trợ giúp runtime, code>results_preprocessed//code> chứa tập con benchmark đã phát hành (410 trường hợp đã được tiền xử lý), code>results_pipeline_funnel//code> chứa các tệp JSONL stage0–stage4 và bản tóm tắt funnel, và code>raw_results_compressed//code> chứa các đầu ra thử nghiệm thô.

Để tái tạo toàn bộ quy trình, cần năm bước: xây dựng các môi trường Docker (code>execution.build_swe_care/code>), tạo các bài kiểm thử (code>run_testgen_full.sh/code>), thu thập các đánh giá cơ sở (code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>), chạy quá trình giải quyết của agent (code>run_batch_agent_resolution.py/code>), sau đó đánh giá (code>run_batch_tool_eval.py --tool <name>/code>). Nếu bạn muốn thêm một công cụ đánh giá thứ năm, hãy lưu ý rằng điểm mở rộng không phải là giao diện plugin: các lời nhắc đánh giá cơ sở cho từng công cụ được đặt trong code>run_batch_baselines.py/code>, và README không mô tả cách tinh gọn hơn — bạn phải sửa chính script đó.

Hai sự thật nữa trước khi bạn clone nó. Bài báo được cấp phép CC BY 4.0; trang repository không nêu giấy phép cho mã nguồn, vì vậy đừng cho rằng có giấy phép. Và bài báo không công bố số liệu chi phí hay mức sử dụng token để chạy benchmark — điều đó không được công bố, nên chúng ta sẽ không bịa ra. Điều pipeline ngụ ý: một Docker image cho mỗi PR trên 184 instance, cộng với một lượt giải quyết của agent, không phải là việc làm trong một buổi chiều với một chiếc laptop.

Điều này có ý nghĩa gì đối với bất kỳ ai triển khai một quy trình đánh giá.

Lập luận cốt lõi của c-CRAB là một giám khảo LLM là một nhà tiên tri không đáng tin cậy. Nếu bạn không thể xây dựng các nhà tiên tri thực thi được — và hầu hết các nhóm không thể — biện pháp giảm thiểu tốt nhất hiện có là không bao giờ để giám khảo chạy trên mô hình đã tạo ra bài đánh giá. Một giám khảo dùng chung mô hình với người đánh giá sẽ tự đồng ý với chính mình, và quá trình xác minh biến thành một con dấu cao su vẫn trả về một con số.

Đó chính xác là lỗi mà công thức định tuyến đằng sau trình đánh giá chúng tôi cung cấp đã ngăn chặn — và đó là một sự tương đồng về thiết kế với lời phê bình của c-CRAB, chứ không phải là một kết quả điểm chuẩn. Bộ khung vẫn chạy một giám khảo LLM như một lượt thứ hai, nhóm các phát hiện lại, chấm từng nhóm với điểm từ 0–1 để xác định liệu đó có phải là một lỗi cụ thể trong thay đổi này hay không, và loại bỏ mọi thứ dưới ngưỡng. Công thức chi phối nó, code>recipes/orcacode-review.dsl.yaml/code>, là một tệp công khai. Action không bao giờ nêu tên một mô hình: nó gọi một bí danh bộ định tuyến, và công thức sẽ quyết định. Theo cấu hình được thiết lập, công thức chỉ gồm bốn dòng — mặc định của trình đánh giá là code>deepseek/deepseek-v4-flash-0731/code>, và một quy tắc khớp với header code>x-cr-lens: judge/code> sẽ gửi lượt đánh giá của giám khảo đến code>z-ai/glm-5.3/code>, một nhà cung cấp khác. Chính lời của công thức yêu cầu rằng giám khảo “KHÔNG ĐƯỢC NÊU TÊN MÔ HÌNH MẶC ĐỊNH”, bởi vì trên chính mô hình của trình đánh giá, nó “tự đồng ý với chính mình, nên lượt đánh giá trở nên vô hiệu trong khi vẫn báo cáo thành công”.

Một bộ đánh giá từ nhà cung cấp khác làm giảm sự tự nhất quán; nó không biến một bộ đánh giá LLM thành một bài kiểm tra. c-CRAB đã không kiểm tra bộ đánh giá của chúng tôi, và chúng tôi sẽ không ngụ ý điều ngược lại. OrcaCode Review chạy một lượt rà soát cùng với một bộ đánh giá xác minh độc lập, tính theo token thay vì theo ghế, và mọi prompt trong đó đều công khai — vì vậy bạn có thể trỏ nó vào một benchmark như thế này và nhận được con số của riêng mình thay vì của chúng tôi.

Kết luận

c-CRAB là benchmark đánh giá code-review đầu tiên mà bạn có thể phần lớn tin tưởng rằng điểm số phản ánh đúng ý nghĩa của nó: một review chỉ được coi là đạt khi hành động theo nó sẽ sửa được mã. Các con số nổi bật thực sự thấp — công cụ đơn lẻ tốt nhất 32,1%, hợp nhất 41,5% — nhưng chúng đo lường sự trùng lặp với các mối quan tâm do con người nêu ra, chứ không phải chất lượng của bản thân các review, và dữ liệu về tính hữu ích cho thấy hầu hết các bình luận đều là tín hiệu thực. Những bài học lâu dài chính là những điều mà chính bài báo lập luận: số lượng không phải là độ phủ, tác nhân và con người nhìn nhận những thứ khác nhau, và cách triển khai đúng đắn là sự hợp tác giữa con người và tác nhân. Và benchmark này là mở, nên bước tiếp theo trung thực là chạy công cụ review của riêng bạn trên nó và có được con số của chính mình.