LangChain ra mắt ReviewBench: Đánh giá AI code review qua phản hồi thực tế từ Pull Request

Hiện nay đã có nhiều tác nhân (agent) hỗ trợ đánh giá mã nguồn hơn, và chúng tôi cũng đang tự xây dựng một tác nhân cho riêng mình. Việc đánh giá quá trình review mã nguồn rất khó khăn. Không có nhiều bộ tiêu chuẩn (benchmark) mà chúng tôi tin tưởng để đo lường xem một tác nhân có thực sự hữu ích trong quy trình review của chúng tôi hay không, bởi vì chúng không tích hợp các tiêu chuẩn review nội bộ của chúng tôi.

Chúng tôi muốn có một bộ tiêu chuẩn gắn liền với các loại vấn đề mà các chuyên gia review của chúng tôi thường phát hiện trong các PR thực tế. Vì vậy, chúng tôi đã xây dựng ReviewBench. Nó được xây dựng dựa trên phản hồi từ các PR thực tế trong mono-repo LangSmith của chúng tôi. Chúng tôi bắt đầu bằng cách thu thập các bình luận từ những chuyên gia review đáng tin cậy, chọn lọc chúng thành các vấn đề review cụ thể và chuyển đổi chúng thành các tác vụ Harbor có thể tái lập.

Bắt đầu từ các bài review thực tế

Chúng tôi muốn ReviewBench đo lường được các loại vấn đề mà người review thực sự nêu ra, vì vậy chúng tôi bắt đầu từ lịch sử review thực tế thay vì tự tạo ra các lỗi giả lập từ đầu.

Chúng tôi đã thu thập các bình luận từ những chuyên gia review đáng tin cậy trên các PR đã được hợp nhất trong codebase LangSmith và coi chúng là các phát hiện tiềm năng. Nhiều bình luận trong số đó phụ thuộc vào các tiêu chuẩn riêng của codebase, chẳng hạn như thiếu các ràng buộc tenant trong các truy vấn cơ sở dữ liệu hoặc các cron chạy trên môi trường production cần tuân thủ các quy tắc khóa (locking patterns) hiện có. Để một tác nhân có thể tìm ra những vấn đề này, nó cần phải tái cấu trúc các hợp đồng hệ thống ngầm định từ mã nguồn xung quanh thay vì chỉ kiểm tra các dòng đã thay đổi một cách cô lập.

Chuyển đổi các bình luận review thành các tác vụ đánh giá (eval tasks)

Suy nghĩ ban đầu của chúng tôi là sử dụng trực tiếp các bình luận review thô làm nhãn đối chứng (ground truth labels), nhưng chúng lại quá nhiễu để sử dụng trực tiếp. Một số là những phát hiện quan trọng, nhưng nhiều cái chỉ là các lỗi nhỏ (nits) hoặc câu hỏi. Chúng tôi cần chuyển đổi các bình luận thô đó thành một tập hợp nhỏ hơn các phát hiện cụ thể và có thể kiểm chứng được.

Chúng tôi chỉ giữ lại những bình luận xác định được một vấn đề thực sự do thay đổi đó gây ra và đủ cụ thể để một trình xác thực (verifier) có thể đánh giá. Chúng tôi đã đưa các bài review PR chưa qua lọc qua một bộ lọc LLM để đánh dấu các ứng viên yếu, sau đó xem xét thủ công từng bình luận còn lại.

Chính quá trình chọn lọc này làm cho ReviewBench trở nên hữu ích như một công cụ đánh giá. Bộ tiêu chuẩn này không yêu cầu các tác nhân phải tái hiện lại mọi thứ mà một chuyên gia review đã nói. Nó đo lường xem một tác nhân có thể khôi phục các lỗi thực chất được đại diện bởi các phát hiện đã qua chọn lọc của chuyên gia hay không.

Một vấn đề trong bộ tiêu chuẩn trông như thế nào

Dưới đây là một số ví dụ cụ thể về hình thức của các tác vụ này.

Một vấn đề liên quan đến truy vấn SQL cơ sở dữ liệu, trong đó tài nguyên được tìm nạp và xóa theo ID mà không kiểm tra tenant. Để phát hiện ra nó, tác nhân cần nhận diện được quy tắc an toàn ở cấp độ dự án và áp dụng nó vào một đường dẫn mã nguồn cụ thể.

Một vấn đề khác liên quan đến việc di chuyển endpoint (endpoint migration) đã loại bỏ một bộ lọc vốn có trong API gốc, làm thay đổi hành vi của endpoint đó. Việc phát hiện ra lỗi này đòi hỏi phải so sánh hai cách triển khai và nhận diện được sự suy giảm tính tương thích của API (API-parity regression).

Đây là những loại vấn đề mà chúng tôi muốn ReviewBench đo lường. Chúng đòi hỏi nhiều hơn là chỉ quét các dòng đã thay đổi để tìm các lỗi hiển nhiên.

Chạy ReviewBench với Harbor

ReviewBench hiện có 59 tác vụ bao gồm 64 vấn đề cơ sở. Các tác vụ được viết theo định dạng Harbor. Harbor cung cấp cho chúng tôi một định dạng tác vụ tiêu chuẩn cho hướng dẫn, môi trường và trình xác thực. Chúng tôi đã chuyển đổi các vấn đề review đã chọn lọc thành các tác vụ Harbor bằng cách sử dụng cùng quy trình kỹ thuật đánh giá được mô tả trong bài "Towards Automating Eval Engineering".

Khi bắt đầu một tác vụ, tác nhân nhận được ngữ cảnh PR đã được đóng băng và các hướng dẫn để review PR đó. Một GitHub stub cục bộ sẽ cung cấp siêu dữ liệu và diff của PR đã đóng băng, vì vậy tác vụ không phụ thuộc vào trạng thái trực tiếp của GitHub.

Tác nhân có thể kiểm tra toàn bộ kho lưu trữ đã được nạp (seeded repository), sau đó gửi một danh sách các phát hiện có cấu trúc bao gồm vị trí, tiêu đề và giải thích cho từng vấn đề. Sau khi gửi, trình xác thực sẽ so sánh các phát hiện đó với các vấn đề cơ sở đã được chọn lọc.

Cách thức tính điểm

ReviewBench tính điểm dựa trên độ bao phủ (coverage) và độ chính xác (precision). Mỗi tác vụ có một trình xác thực ẩn sử dụng LLM-as-judge để so sánh bài review do tác nhân gửi với dữ liệu cơ sở đã chọn lọc.

Độ bao phủ đo lường xem tác nhân có tìm ra vấn đề cơ sở hay không. Một vấn đề cơ sở được tính là đã bao phủ khi trình xác thực xác định rằng tác nhân đã nhận diện được cùng một vấn đề cốt lõi trong cùng một đường dẫn mã nguồn. Chúng tôi chấm điểm vấn đề cốt lõi, không phải cách diễn đạt của bình luận.

Độ chính xác là tỷ lệ các phát hiện được gửi mà trình xác thực đánh giá là đúng. Một phát hiện có thể đúng ngay cả khi nó không khớp với vấn đề cơ sở đã chọn lọc, miễn là nó được hỗ trợ bởi mã nguồn. Những phát hiện bổ sung đó được tính vào độ chính xác, nhưng chúng không làm tăng độ bao phủ hay nhận được điểm thưởng riêng. Điểm số chính là F1, vì vậy độ bao phủ và độ chính xác được tính trọng số ngang nhau.

Kết quả

Chúng tôi đã chạy từng mô hình với cùng một bộ khung Deep Agents cơ bản trên 59 tác vụ của ReviewBench với ba lần thử cho mỗi tác vụ. Chúng tôi cố tình bỏ qua các system prompt tùy chỉnh dành riêng cho việc review để bảng kết quả có thể so sánh các mô hình dưới cùng một cấu trúc tối thiểu, cung cấp một tiêu chuẩn chung thay vì đo lường hiệu suất được tinh chỉnh tốt nhất của từng mô hình.

Kết quả chính là các mô hình hiện tại với bộ khung cơ bản vẫn bỏ sót hầu hết các phát hiện của chuyên gia review. Các lượt chạy mạnh nhất chỉ khôi phục được khoảng 30% các vấn đề cơ sở. Các tác nhân thường báo cáo các vấn đề hợp lệ, nhưng chúng vẫn bỏ lỡ nhiều vấn đề cụ thể mà các chuyên gia review đáng tin cậy đã phát hiện trong các PR thực tế.

Kết quả của Luna và Terra thấp hơn chúng tôi mong đợi. Khi xem xét các lượt chạy, chiến lược review của chúng có vẻ hẹp hơn. Chúng có xu hướng tập trung vào một số ít các phát hiện rồi dừng lại. Điều đó giúp giữ mức sử dụng token và chi phí thấp, nhưng làm giảm độ bao phủ vì nhiều vấn đề mục tiêu đòi hỏi phải nhìn xa hơn các dòng thay đổi hiển nhiên nhất.

Prompt thay đổi kết quả

Kết quả của Luna đặt ra một câu hỏi tiếp theo. Liệu nó có hoạt động tốt hơn nếu bộ khung cung cấp cho nó một chiến lược review có chủ đích hơn không?

Chúng tôi đã chạy một so sánh đối chiếu trên 20 tác vụ ReviewBench với ba lần thử cho mỗi tác vụ. Cấu hình Luna đã tinh chỉnh sử dụng nỗ lực suy luận cao và một prompt review có cấu trúc. Opus 4.8 và Kimi K3 sử dụng bộ khung review gốc.

Cấu hình tinh chỉnh không cung cấp cho Luna bất kỳ công cụ mới nào. Giống như cấu hình gốc, nó có thể đọc và tìm kiếm trong kho lưu trữ nhưng không thể chạy mã hoặc các lệnh shell. Điểm mới duy nhất là một prompt mới. Prompt mới hướng dẫn Luna xác định những gì PR đã thay đổi, truy vết cách hệ thống xung quanh phụ thuộc vào hành vi đó và xác thực các phát hiện của nó đối với các trình gọi (callers), các bài kiểm thử và các triển khai liên quan.

Prompt review có cấu trúc mới này đã thay đổi đáng kể kết quả của Luna. Trên lát cắt 20 tác vụ này, Luna đạt điểm số 0.32, cao hơn các lượt chạy của Kimi và Opus với phương thức review tĩnh trên cùng các tác vụ đó.

Đây là sự so sánh về bộ khung, không phải so sánh thuần túy về mô hình. Điểm mấu chốt là chiến lược review rất quan trọng. Cùng một mô hình trông có vẻ yếu dưới bộ khung cơ bản đã hoạt động tốt hơn nhiều khi prompt thúc đẩy nó lập bản đồ các thay đổi và kiểm tra các điểm lỗi tiềm ẩn trước khi gửi các phát hiện.

Đối với các tác nhân review mã nguồn, hiệu suất tốt hơn có thể đến từ việc thay đổi cách tác nhân thực hiện review, chứ không chỉ từ việc thay đổi mô hình hoặc thêm nhiều công cụ hơn.

Bước tiếp theo

ReviewBench cung cấp cho chúng tôi một điểm khởi đầu để đánh giá các tác nhân review mã nguồn dựa trên phản hồi PR thực tế. Tiếp theo, chúng tôi muốn làm cho nó lớn hơn và rộng hơn.

Chúng tôi muốn thêm nhiều tác vụ hơn để kết quả ổn định hơn. Chúng tôi cũng muốn mở rộng phạm vi bao phủ các vấn đề mà người review thực tế thường gặp phải, bao gồm các ràng buộc bảo mật, tính tương thích của API và các trường hợp đòi hỏi ngữ cảnh bên ngoài các dòng đã thay đổi.

Theo thời gian, chúng tôi muốn ReviewBench đo lường được liệu các tác nhân review mã nguồn có thể tìm ra các vấn đề thực chất trong các thay đổi thực tế mà không gây ra nhiễu review không cần thiết hay không.