Code Review Agent Benchmark: Cách đánh giá một người duyệt mã và chạy c-CRAB trên mã của riêng bạn

Làm sao để biết một tác nhân đánh giá mã nguồn có thực sự tốt? Trong phần lớn lịch sử ngắn ngủi của lĩnh vực này, câu trả lời là "đo xem các nhận xét của nó gần với nhận xét của một người đánh giá đến mức nào" — điều này nghe có vẻ hợp lý cho đến khi bạn thực sự thử, vì hai người đánh giá có thể nêu cùng một vấn đề bằng những từ ngữ hoàn toàn khác nhau. Code Review Agent Benchmark — bài báo là arXiv:2603.23448, bộ dữ liệu của nó là c-CRAB — là nỗ lực nghiêm túc đầu tiên nhằm chấm điểm một bài đánh giá dựa trên kết quả khi hành động theo nó thay vì dựa trên cách diễn đạt. Benchmark này đã chuyển 234 nhận xét đánh giá của con người thành các bài kiểm tra có thể thực thi, chạy bốn trình đánh giá được sử dụng rộng rãi — PR-Agent, Devin, Claude Code và Codex — và phát hiện ra rằng cả bốn cộng lại chỉ vượt qua 41.5% số bài kiểm tra đó, "chỉ khoảng 40%" theo đúng lời của bài báo. Trang này là một cẩm nang: cách đọc kết quả đó mà không làm sai lệch, cách tự chạy c-CRAB, và phải làm gì khi codebase của bạn không nằm trong benchmark này.

Con số nổi bật là thứ ít hữu ích nhất trên trang này. Thứ hữu ích là phương pháp và các chế độ thất bại: vì sao mọi cách chấm điểm trước đó đều đo sai thứ cần đo, cái giá phải trả để chấm điểm một bài đánh giá bằng các bài kiểm tra thực thi được thay vào đó là gì, và vì sao câu "các agent đánh giá chỉ phát hiện được 40% lỗi" là một sự hiểu sai trên ba phương diện về kết quả thực tế. Mọi thứ ở đây là cách đọc của cộng đồng về điểm chuẩn đã công bố và về kinh nghiệm chạy nó của những người thực hành — chứ không phải hướng dẫn từ phía nhà cung cấp là các nhà sản xuất công cụ liên quan.

Tại sao các chỉ số hiển nhiên lại không hiệu quả

Trước khi có c-CRAB, việc đánh giá các tác nhân rà soát mã nguồn chỉ nằm gọn trong một số ít nhóm, và bảng so sánh của chính bài báo (Bảng 1) đã trình bày rõ nguồn gốc đó. Nhóm lâu đời nhất là trùng lặp văn bản — BLEU, ROUGE, chrF và các biến thể cùng họ, được sử dụng bởi các bộ chuẩn như CodeReviewer và ContextCRBench. Ý tưởng là nhận xét của một tác nhân được coi là tốt khi các n-gram của nó khớp với n-gram của con người. Ý tưởng này sụp đổ ở đúng loại tình huống xuất hiện khắp nơi trong rà soát mã nguồn: cùng một lỗi được mô tả bằng những từ ngữ khác nhau.

Ca nghiên cứu trong bài báo là ví dụ sáng giá nhất. Trong một pull request tại python-telegram-bot (PR #3514), người đánh giá con người và Codex đều chỉ ra cùng một lỗi robustness về lập chỉ mục lồng nhau. Đánh giá của Codex chính xác về mặt hành vi — một tác nhân viết mã hành động theo nó đã tạo ra bản sửa lỗi vượt qua bài kiểm tra thực thi. Tuy nhiên, các chỉ số văn bản cho điểm nó lần lượt là BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74 và độ tương đồng embedding 54.59. Không có sự trùng lặp n-gram nào, vậy mà đánh giá lại đúng. Cùng một quan ngại, khác cách diễn đạt: các chỉ số chuỗi không thể nhìn ra nó. Độ tương đồng embedding là một bước tiến một phần — 54.59 so với một kết quả vượt qua được xác nhận vẫn còn rất xa ngưỡng có thể sử dụng — và nó thừa hưởng cùng vấn đề dưới dạng nhẹ hơn.

LLM làm giám khảo, trong đó một mô hình so sánh bài đánh giá của tác nhân với bài của con người rồi bỏ phiếu, giải quyết vấn đề từ vựng nhưng lại đưa vào ba vấn đề mới mà bài báo nêu thẳng tên: thiên vị, bất ổn định và nhạy cảm với thiết kế prompt. Chạy cùng một phép so sánh hai lần, một giám khảo có thể đưa ra hai phán quyết khác nhau; viết lại prompt đánh giá và thứ hạng sẽ thay đổi. Khi bạn đang chọn giữa hai bên đánh giá cách nhau ba điểm trên cùng một chuẩn, một giám khảo có độ dao động như vậy không thể hậu thuẫn cho quyết định — và một điểm số không thể tái tạo thì không phải là điểm số.

Điều mà một oracle thực thi mang lại — và cái giá phải trả

Ý tưởng mà c-CRAB được xây dựng dựa trên vừa đơn giản vừa đột phá: thay vì hỏi "nhận xét này nghe có giống nhận xét của con người không?", hãy hỏi "nếu bạn hành động theo nhận xét, mã nguồn có được sửa không?". Mỗi nhận xét đánh giá của con người được giữ lại sẽ được chuyển đổi thành một bài kiểm tra thực thi được nhằm nắm bắt vấn đề cốt lõi. 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 khiến bài kiểm tra vượt qua — và mọi phiên bản đều đi kèm với môi trường Docker có thể chạy được, vì vậy việc "làm cho bài kiểm tra vượt qua" là một thực tế chứ không phải một nhận định.

Bài báo xác định hai loại kiểm thử. 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", gọi các hàm "với đầu vào cụ thể" và kiểm tra "đầu ra hoặc xác minh các ngoại lệ". Kiểm thử cấu trúc "kiểm tra văn bản mã nguồn, khớp mẫu và rà soát bề mặt API để xác định liệu các thay đổi mã mong muốn đã được thực hiện hay chưa". Tỷ lệ phân chia 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%) — và sự chênh lệch đó xứng đáng được nói thẳng: phần lớn oracle này là khớp mẫu trên văn bản mã nguồn, chứ không phải thực thi mã. Tiêu chuẩn vàng là kiểm thử hành vi; phần lớn tập dữ liệu là phiên bản thực dụng của nó.

Việc xây dựng oracle là một phễu gồm bốn giai đoạn, và mỗi giai đoạn đều loại bỏ một số thứ:

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

• 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 hội thoại hoặc chủ quan.

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

• Chuyển đổi các 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 tạo bằng GPT-5.2 trong vòng lặp tinh chỉnh có hướng dẫn thực thi (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 ở phiên bản trước và vượt qua ở phiên bản sau.

• Xác thực với một tác nhân mã hóa — 184 PR, 234 bình luận (vòng cuối). Claude Code trên backend Sonnet-4.6 cố gắng sửa mã chỉ dựa trên nhận xét đá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ỏ.

Khoảng 27% số pull request ban đầu sống sót. Cần nói thẳng điều đó, vì đó là cái giá trung thực của một oracle dựa trên kiểm thử: nếu một bình luận không đủ tính khả thi để trở thành một bài kiểm thử thất bại, hoặc môi trường không thể được dựng lên, hoặc một agent lập trình có năng lực không thể sửa mã chỉ từ bình luận đó, thì instance sẽ bị loại. Đây cũng là lý do benchmark nhỏ. 184 instance PR và 234 bình luận đã được xác thực là một bộ dữ liệu bạn có thể đọc, chứ không phải một kho ngữ liệu bạn có thể chìm ngập — và đối với một oracle phải chạy môi trường Docker thực, sự nhỏ gọn chính là một tính năng.

Để hình dung quy mô: một instance trung bình chạm tới 418,1 dòng mã đã sửa đổi, các bài kiểm thử trung bình 31,8 dòng, và có 1,27 bài kiểm thử trên mỗi instance. Hai người chú thích đồng ý 84% số lần — trên 50 instance được lấy mẫu — về việc liệu một bài kiểm thử được tạo ra có trung thực nắm bắt được mối quan tâm của người đánh giá hay không.

Một điểm tỳ vết về thư mục mà bạn sẽ gặp phải nếu tự đọc bài báo: bảng dữ liệu (Bảng 4) liệt kê 67 kho lưu trữ, trong khi phần Threats to Validity lại nói "184 trường hợp pull request với 234 oracle có thể xác minh trên 56 kho lưu trữ." Bài báo đưa ra cả hai con số ở những chỗ khác nhau và không giải thích sự khác biệt. Đừng chọn một con số ưa thích và đừng lấy trung bình — hãy trích dẫn từng con số đúng nơi nó xuất hiện. Những khác biệt như thế này chính là chi tiết mà người đọc dùng để quyết định một bộ tiêu chuẩn có đáng để họ bỏ thời gian hay không.

Để thẩm định tính độc lập: bài báo công bố rằng một tác giả có liên kết với SonarSource, và nêu rằng các phát hiện không nên được diễn giải như là "an evaluation of the quality of products at SonarSource." Đó là tuyên bố miễn trừ trách nhiệm của họ, được trích dẫn nguyên văn thay vì diễn giải lại.

Cách đọc bản nhạc trên c-CRAB mà không trích dẫn sai nó

Chỉ số chính là tỷ lệ vượt qua: trên mỗi instance, tỷ lệ các bài kiểm tra của PR đó vượt qua, được tính trung bình trên 184 instance. Dưới đây là bảng kết quả đầy đủ từ bài báo, mỗi dòng tương ứng với một người đánh giá. Hàng dành cho con người là một điểm mốc thang đo chứ không phải đối thủ cạnh tranh — con người đã viết oracle, nên họ đạt 100% theo thiết kế:

• Claude Code — 1.336 bình luận, 7,3 mỗi PR, tổng thể 32,1% (hành vi 38,1%, cấu trúc 30,7%).

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

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

• Codex — 324 bình luận, 1.8 mỗi PR, tổng thể 20.1% (hành vi 38.1%, cấu trúc 16.1%).

• Con người — 234 bình luận, 1,3 mỗi PR, 100% theo thiết kế.

Ba sự đính chính, vì con số "chỉ khoảng 40%" trong tóm tắt đang là con số bị trích dẫn sai nhiều nhất trong mảng thảo luận về AI-coders hiện nay. Thứ nhất, con số 41,5% — 97 trong số 234 bài kiểm tra được vượt qua bởi ít nhất một công cụ — là phép hợp trên cả bốn người đánh giá: một bài kiểm tra chỉ được tính một lần nếu bất kỳ tác tử nào vượt qua nó. Không có tác tử đơn lẻ nào đạt 41,5%; điểm đơn lẻ cao nhất là 32,1% của Claude Code. Thứ hai, hàng con người là oracle, không phải thí sinh tham gia; diễn giải lại nó thành "con người đánh bại bot" là một sai lầm về phân loại. Thứ ba, và quan trọng nhất: c-CRAB không ghi nhận công cho một vấn đề hợp lệ mà người đánh giá là con người chưa bao giờ nêu ra. Oracle chính là ý định đánh giá của con người. Một tác tử tìm ra lỗi thực sự mà không ai đề cập sẽ bị điểm zero cho lỗi đó. Vì vậy, "các tác tử đánh giá AI chỉ bắt được 40% lỗi" sai theo ba cách — đó là phép hợp, không phải tỷ lệ bắt lỗi, và nó đo lường sự đồng thuận với người đánh giá con người, chứ không phải độ đúng đắn tuyệt đối.

Lượng bình luận chính là cái bẫy.

Con số thú vị nhất trong kết quả không phải là 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 mỗi PR — để đạt 32,1% và 24,8%. Codex đăng 324 bình luận, khoảng 1,8 bình luận mỗi PR, và đạt 20,1%. Đường cơ sở của con người là 1,3 bình luận mỗi PR. Số lượng không phải là độ phủ: gần gấp năm lần số bình luận chỉ mang lại chưa đến gấp đôi tỷ lệ vượt qua. Nếu bạn đang chọn một người đánh giá, chi phí thực sự của tất cả những bình luận bổ sung đó là sự mệt mỏi khi đánh giá của con người — mỗi bình luận mà một tác nhân đăng là một quyết định mà một người phải phân loại.

Phát hiện về tính hữu ích lại theo chiều hướng ngược lại, và đó chính là yếu tố giúp câu chuyện này không trở thành một câu chuyện sáo rỗng kiểu "các bot gây nhiễu". Các tác giả đã kiểm tra thủ công 92 bình luận trên 6 PR và đánh giá 84% (77/92) là hữu ích — 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 không phải là nhiễu; chúng đề cập đến điều mà người duyệt không nêu ra. Cỡ mẫu nhỏ — 92 bình luận, 6 PR — và cũng đáng được nhắc đến cùng một lúc với các tỷ lệ phần trăm.

Những gì hai bên thực sự trao đổi giải thích hình dạng của kết quả. 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 diễn giải đ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ì thay thế — và đây cũng là lời giải thích tốt nhất hiện có cho việc tại sao điểm số trông thấp. Một bộ đánh giá sắc bén với các trường hợp biên nhưng ít đề cập đến thiết kế sẽ bỏ sót một cách hệ thống các hạng mục mà con người nêu ra, và oracle được xây dựng hoàn toàn từ các đánh dấu của con người.

Những người thực hành đã trải qua điều này đều đi đến cùng một kết luận. Một bài viết chi tiết của Daniel Vaughan gọi công trình này là CR-bench cũng đi đến kết luận tương tự và biến nó thành một quy trình làm việc: để tác nhân AI đảm nhận việc rà soát độ mạnh mẽ và tính đúng đắn, giữ con người phụ trách thiết kế, quy ước và kiến trúc — những hạng mục mà tác nhân AI đạt điểm kém nhất — và điều hướng tác nhân bằng các chỉ dẫn đánh giá nêu rõ các hạng mục yếu kém đó. Điều cảnh báo hữu ích nhất của anh ấy cho bất kỳ ai đọc bảng xếp hạng: "mức độ hữu ích không giống với tỷ lệ vượt qua bài kiểm tra", vì bộ kiểm thử yêu cầu khớp với bản sửa lỗi mà con người dự định, và một cách sửa lỗi thay thế hợp lệ sẽ không vượt qua được bài kiểm tra. Theo đánh giá của anh ấy, con đường từ 20% lên một điểm số cao hơn đáng kể không phải là nâng cấp mô hình — mà là công việc cấu hình.

Tự chạy c-CRAB

Tất cả những gì ở trên đều là đọc kết quả của người khác. Gói tái tạo làm cho benchmark có thể chạy được — nó nằm tại c-CRAB-Benchmark/dataset trên GitHub — và README trung thực về những gì cần thiết.

Yêu cầu: code>uv sync/code>; Docker; và một trong hai code>OPENAI_API_KEY/code> hoặc code>ANTHROPIC_API_KEY/code> (Claude Code cũng đọc thông tin xác thực từ code>~/.claude/.credentials.json/code>, được gắn vào container theo mặc định). Cấu trúc gồm năm thư mục: code>pipeline//code> (logic pipeline và các prompt), code>execution//code> (các trình xây dựng image Docker và các helper runtime), code>results_preprocessed//code> (tập con benchmark đã phát hành), code>results_pipeline_funnel//code> (các tệp JSONL stage0–stage4 và tóm tắt funnel), và code>raw_results_compressed//code> (kết quả thô từ thử nghiệm). Năm bước, theo thứ tự:

1. Xây dựng các môi trường Docker — code>uv run python -m execution.build_swe_care --split test --instance results_preprocessed/instance-ids.txt --max-workers 4/code>. Các image dựng sẵn cũng được xuất bản trên tổ chức GitHub Packages c-CRAB-Benchmark nếu bạn muốn bỏ qua bước xây dựng.

2. Tạo các bài kiểm tra — code>./run_testgen_full.sh --instances-file results_preprocessed/instance-ids.txt --workers 4 --output-dir results_testgen/code>.

3. Thu thập các bài đánh giá cơ sở — code>uv run python run_batch_baselines.py --split test --instances-file results_preprocessed/instance-ids.txt --tools pr-agent devin claude-code codex --output-dir baselines_output --workers 4/code>. Cấu hình thông tin xác thực của các công cụ bên ngoài tương ứng trước bước này.

4. Chạy phân giải tác nhân — code>uv run python run_batch_agent_resolution.py --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --output-dir results_agent_resolution --workers 4/code>.

5. Đánh giá — lặp lại một lần cho mỗi công cụ: code>uv run python run_batch_tool_eval.py --tool pr-agent --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --tool-results-dir baselines_output --output-dir results_eval_pr-agent --workers 4/code>.

Có hai điều mà README không đề cập. Việc thêm reviewer thứ năm đồng nghĩa với việc phải sửa code>run_batch_baselines.py/code> — đó là nơi chứa các prompt đánh giá baseline cho từng công cụ, và không có giao diện plugin; README không mô tả điểm mở rộng nào rõ ràng hơn. Hơn nữa, kho lưu trữ không có tệp giấy phép rõ ràng, nên đừng cho rằng mã nguồn là MIT hay Apache — bài báo có giấy phép CC BY 4.0, còn các điều khoản của chính mã nguồn thì không được nêu rõ.

Chi phí là hạng mục khác không được công bố. Bài báo không công bố số liệu token hay đô la cho việc chạy pipeline, vì vậy hãy coi mọi con số chi phí bạn thấy trích dẫn trực tuyến là chưa được xác minh. Điều mà cấu trúc ngụ ý đã đủ rõ ràng: một Docker image cho mỗi PR trên 184 instance, cộng với một lượt xử lý phân giải của coding-agent và một lượt đánh giá cho mỗi công cụ. Đó không phải là một buổi chiều quy mô laptop — hãy dự trù ngân sách cho tài nguyên tính toán thực thụ.

Khi bạn không thể sử dụng các oracle thực thi được

Quan điểm trung thực của hầu hết các đội ngũ là: benchmark đã đúng khi cho rằng một LLM judge không thể chấm điểm các bài đánh giá, nhưng việc xây dựng một oracle dựa trên kiểm thử cho các PR của riêng bạn là một việc không hề nhỏ. Sự khác biệt đáng nêu ra là giữa LLM judge với vai trò bộ chấm điểm và LLM judge với vai trò bộ lọc. Việc c-CRAB bác bỏ judge như một oracle không khiến judge trở nên vô dụng bên trong một reviewer — một judge biết nhóm các phát hiện trùng lặp và loại bỏ các phát hiện yếu vẫn có thể nâng cao độ chính xác. Kiểu lỗi cần thiết kế để phòng tránh là tính độc lập.

Một bộ chấm điểm chạy trên chính mô hình của bộ đánh giá sẽ tự đồng tình với chính nó: nó đọc bài đánh giá, thấy có vẻ hợp lý, rồi báo cáo thành công mà không thay đổi gì. Một bộ chấm điểm từ nhà cung cấp khác làm giảm sự tự đồng tình đó — nó không biến một bộ chấm điểm thành một bài kiểm tra, nhưng nó ngăn được việc đóng dấu cao su. Chúng tôi có thể cho bạn thấy một ví dụ cụ thể, có thể kiểm chứng, về chính cơ chế bảo vệ này vì khung thử nghiệm của chúng tôi là mã nguồn mở: Orca-Code-Review trên GitHub được cấp phép MIT, và công thức định tuyến của nó nêu quy tắc bằng chính lời của kho lưu trữ — bộ chấm điểm "KHÔNG ĐƯỢC NÊU TÊN MÔ HÌNH MẶC ĐỊNH", vì "trên chính mô hình của bộ đánh giá thì nó tự đồng tình 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." Action không bao giờ nêu tên mô hình; công thức quyết định. Theo cấu hình hiện hành, mặc định của bộ đánh giá là deepseek/deepseek-v4-flash-0731, và một quy tắc khớp với code>x-cr-lens: judge/code> header gửi lượt đánh giá của bộ chấm điểm đến z-ai/glm-5.3 — một nhà cung cấp khác. Đó là một điểm tương đồng trong thiết kế với lập luận của c-CRAB, chứ không phải một kết quả: chúng tôi không nằm trong benchmark và không có điểm c-CRAB nào cho bộ đánh giá của chúng tôi. Nhưng đó là biện pháp giảm thiểu thực tế dành cho bất kỳ ai không thể xây dựng các oracle thực thi được, và nó sẽ rẻ khi bộ chấm điểm và bộ đánh giá có thể nằm trên các nhà cung cấp khác nhau chỉ với một khóa API — đó chính là điều mà một bộ định tuyến dùng để làm. Trên OrcaRouter, bộ đánh giá và bộ chấm điểm của nó là hai dòng trong một DSL định tuyến, và bạn trả đúng giá niêm yết của nhà cung cấp với mức chênh lệch bằng không.

Khi mã của bạn không nằm trong benchmark

184 PR trên 56 hoặc 67 kho lưu trữ công khai không phải là codebase của bạn, và nó cũng chưa bao giờ có thể là. Phần có thể chuyển giao chính là phương pháp, và bạn có thể chạy nó trên lịch sử của chính mình ở quy mô nhỏ hơn nhiều. Hãy lấy các PR đã được merge có nhận xét đánh giá từ con người. Với một mẫu các nhận xét đó, hãy viết một bài kiểm tra thất bại trước khi đánh giá được thực hiện và vượt qua sau đó — tính chất "thất bại rồi mới vượt qua" chính là toàn bộ trò chơi. Chạy công cụ đánh giá ứng viên của bạn trên bản diff trước khi đánh giá. Sau đó kiểm tra xem việc áp dụng các nhận xét của nó có làm cho bài kiểm tra vượt qua hay không. Điều bạn nhận được là một con số được tính trên mã nguồn bạn thực sự phát hành, giá trị hơn một vị trí trên bảng xếp hạng. Cái giá phải trả chính là bức tường mà bài báo đã va phải: bạn cần môi trường tái lập được cho từng PR, vì một bài kiểm tra chỉ vượt qua trên laptop của bạn không phải là một oracle.

Bạn không cần 234 bài kiểm tra. Một tá bài được chọn lọc kỹ trên các PR mà đội của bạn thực sự tranh cãi sẽ cho bạn biết nhiều hơn về người đánh giá của bạn so với một điểm số chuẩn. Và một phân tích thực hành song song về nhóm điểm chuẩn này thẳng thắn về cánh cổng chặn: độ chính xác của bộ phân loại LLM trong việc xác định một bình luận có phải là vấn đề hợp lệ, có thể kiểm chứng được rơi vào khoảng từ 66% đến 85%, vì vậy hãy coi bộ lọc máy là một danh sách rút gọn và giữ một bước phân xử của con người trước khi bất cứ điều gì trở thành một bài kiểm tra. Bài viết tương tự cũng lưu ý rằng ReviewBench của LangChain, được xây dựng độc lập trên cùng ý tưởng chuyển bình luận thành bài kiểm tra, chỉ khôi phục được khoảng 30% số vấn đề cơ sở trong trường hợp tốt nhất — cùng mức với 20–32% của c-CRAB, và là lời nhắc rằng chênh lệch một chữ số trên bảng xếp hạng giữa các công cụ thường nhỏ hơn nhiễu của chính thiết lập của bạn.

Nếu bạn đang phân vân có nên mua một công cụ đánh giá mã hay không, đó lại là một câu hỏi khác — hướng dẫn mua agent đánh giá mã của chúng tôi đề cập đến bot so với agent, giá theo ghế so với giá theo token, và khi nào tự lưu trữ là lựa chọn tối ưu — và một khi bạn đã có một công cụ, chi phí vận hành của bộ khung đánh giá trên mỗi lần push sẽ được trình bày trong bài giải thích về đánh giá mã tự động của chúng tôi. Trang này chỉ tập trung vào đo lường, và bài viết đi kèm sẽ trình bày chi tiết cấu trúc của benchmark: phễu xây dựng dữ liệu, số liệu thống kê của tập dữ liệu, và bảng kết quả đầy đủ.

Câu hỏi thường gặp

41.5% có phải là điểm số tốt nhất của agent không? Không. 41.5% là hợp của cả bốn công cụ — một bài kiểm tra chỉ được tính một lần nếu bất kỳ công cụ nào trong số đó vượt qua nó. Điểm số riêng lẻ tốt nhất là 32.1% của Claude Code.

c-CRAB có đo số lượng lỗi mà người đánh giá phát hiện không? Không. Nó đo mức độ khớp của bài đánh giá với những gì một người đánh giá con người đã nêu ra, được chuyển thành các bài kiểm tra có thể thực thi. Một lỗi thực sự mà con người không đề cập đến sẽ bị điểm không, dù nó có hợp lệ đến đâu.

Các nhà đánh giá con người có "đánh bại" được các bot không? Hàng 100% con người chính là oracle — chính con người đã viết các bài kiểm tra — nên nó là một mốc trên thang đo, không phải là đối thủ cạnh tranh.

c-CRAB có phải cùng một thứ với CR-bench không? Vâng. Bộ dữ liệu là c-CRAB; một số bài viết của bên thứ ba gọi nó là CR-bench, nhưng ở đây chỉ có một benchmark duy nhất.

Chi phí để chạy nó là bao nhiêu?Bài báo không công bố số liệu chi phí nào. Một Docker image cho mỗi PR trên 184 instance, cùng với một lượt phân giải bằng tác tử, ngụ ý một khối lượng tính toán thực sự — không phải quy mô một buổi chiều trên laptop.

Kết luận

Đóng góp của c-CRAB không phải là bảng xếp hạng — mà là minh chứng rằng một bài đánh giá có thể được chấm điểm bằng cách thực thi lời khuyên của nó, và rằng các phương pháp so sánh độ tương tự văn bản và LLM-judge trước đó đã chấm sai thứ. Nếu bạn chỉ rút ra một điều, hãy rút ra phép hiệu chỉnh ba phần: 41.5% là một union, hàng con người là oracle, và benchmark không cho điểm cho bất kỳ lỗi nào mà con người chưa từng nêu ra. Và nếu bạn muốn một con số cụ thể để hành động, phương pháp này có thể chuyển giao — các bài test fail-then-pass trên các PR đã merge của chính bạn, một bước phân xử bằng con người, và nếu bạn không thể xây dựng các oracle thực thi được, thì ít nhất hãy dùng một bộ đánh giá có mô hình độc lập với mô hình của người đánh giá.

Nếu bạn muốn đo lường một người đánh giá hơn là tranh luận về nó, hãy bắt đầu từ một bộ khung bạn có thể đọc được. OrcaCode Review chạy một lượt đánh giá và một thẩm phán xác minh độc lập, tính theo token thay vì theo chỗ ngồi, và mọi prompt trong đó đều công khai — vì vậy bạn có thể hướng nó vào một điểm chuẩn như thế này và nhận được con số của riêng bạn thay vì của chúng tôi.