Bản đánh giá (benchmark) v1 của CodeVetter chạy 27 trường hợp tổng hợp qua một quy trình đánh giá mã nguồn (code-review) do AI điều khiển và ghi lại liệu công cụ có phát hiện được các lỗi đã được cài cắm sẵn hay không. Sau đó, nó thống kê kết quả đạt (pass) hoặc không đạt (fail) cho từng trường hợp.

Tại sao bản đánh giá này lại quan trọng

Bài kiểm tra đặt ra một câu hỏi hẹp: liệu một trình đánh giá cụ thể có thể nhận diện chính xác các lỗi mà những người thiết kế bản đánh giá đã cài cắm vào bộ các đoạn mã cố định này hay không? Các nhà phát triển có thể sử dụng kết quả này như một cách kiểm tra nhanh phạm vi bao phủ lỗi (issue coverage). Vì kho lưu trữ (repository) cung cấp sẵn các gói tác vụ và kịch bản chấm điểm, bất kỳ ai cũng có thể chạy lại bài kiểm tra và nhận được cùng một kết quả số liệu.

Những gì bản đánh giá này không chứng minh được

Một bộ dữ liệu tổng hợp gồm 27 trường hợp không thể thay thế cho hàng nghìn yêu cầu kéo (pull requests) mà một đội ngũ phải xử lý hàng ngày. Bản đánh giá này không nói lên điều gì về:

  • Sự đa dạng trong thế giới thực – nó chỉ bao gồm một vài ngôn ngữ và một phạm vi hạn chế các loại lỗi.
  • Hiệu suất – nó không cung cấp các phép đo về thời gian hoặc chi phí tính toán.
  • Độ tin cậy trên các cơ sở mã nguồn khác nhau – nếu không có thử nghiệm trên các kho lưu trữ thực tế (live-repo), chúng ta không thể biết liệu công cụ có bỏ lỡ các lỗi tinh vi hoặc tạo ra các cảnh báo sai (false positives) trong môi trường thực tế hay không.

Việc kết hợp các kết quả đã công bố với các tệp hạ tầng và những lời hứa hẹn về "dữ liệu rộng lớn, thực tế" trong tương lai sẽ tạo ra một câu chuyện tiếp thị rằng một con số duy nhất đại diện cho khả năng sẵn sàng triển khai thực tế (production-ready), điều mà dữ liệu hiện tại không hỗ trợ.

Cách bản đánh giá này nằm trong hệ sinh thái kiểm thử rộng lớn hơn

Các bản đánh giá theo kiểu nhận diện (recognition-style), như của CodeVetter, xác định phạm vi bề mặt mà một công cụ có thể xử lý. Chúng bổ trợ cho các bản đánh giá chức năng (functional benchmarks) như SWE-bench, vốn kiểm tra xem một bản vá do AI tạo ra có thực sự giải quyết được một vấn đề thực tế trong một cơ sở mã nguồn hiện có hay không. Cùng với nhau, chúng mang lại một bức tranh đầy đủ hơn: phạm vi bao phủ so với hiệu quả thực tế.

Một bản đánh giá tác nhân (agent benchmark) tốt nên phơi bày toàn bộ các thành phần:

  1. Bộ dữ liệu – đầu vào thô và đầu ra mong đợi.
  2. Tài liệu cho từng trường hợp – một trang cho mỗi bài kiểm tra hiển thị lỗi, cách sửa đúng và phản hồi của công cụ.
  3. Kết quả của trình đánh giá – chính xác các nhận xét hoặc đề xuất mà AI đã tạo ra.
  4. Phương pháp chấm điểm – cách đánh giá các kết quả khớp, bao gồm cả mức độ chấp nhận cho điểm từng phần.
  5. Hướng dẫn tái lập – các phiên bản cố định (version pins), chi tiết phần cứng và các kịch bản để chạy lại bài kiểm tra.

Chỉ khi tất cả các thành phần này minh bạch, chúng ta mới có thể tin tưởng vào một con số tổng hợp duy nhất.

Các hạn chế mà bản thân bản đánh giá đã liệt kê

  • Các trường hợp tổng hợp, không được lấy từ các kho lưu trữ thực tế.
  • Lựa chọn ngôn ngữ và loại lỗi hạn hẹp.
  • Không có dữ liệu về thời gian hoặc chi phí, vì vậy hiệu suất chưa được xác định.
  • Các ràng buộc về độ chính xác có thể che lấp các lỗi cận biên (borderline failures).

Những gì cần theo dõi tiếp theo

Bước tiếp theo cho CodeVetter — và cho bất kỳ ai đang sử dụng các trình đánh giá AI — là các bằng chứng lặp lại trên các tập dữ liệu (corpora) lớn hơn và đa dạng hơn. Điều đó có nghĩa là phải công bố kết quả trên các luồng pull-request thực tế, báo cáo độ trễ và mức tiêu thụ tính toán, cũng như phân tích các chế độ lỗi theo từng danh mục. Cho đến khi các dữ liệu đó xuất hiện, hãy coi điểm số 27 trường hợp này là một chỉ số sớm, chứ không phải là sự đảm bảo về mức độ sẵn sàng.

Kết luận: Một bản đánh giá chỉ cho bạn biết liệu một công cụ có thể phát hiện một vài lỗi được viết sẵn hay không thì hữu ích cho việc kiểm tra tính hợp lý (sanity-checking), nhưng nó không chứng nhận rằng công cụ đó sẽ vượt qua được thực tế phức tạp và nhạy cảm về chi phí của việc đánh giá mã nguồn trong môi trường thực tế.