Đánh giá AI coding agent: điểm tổng tăng vẫn có thể che hồi quy

Muốn đánh giá AI coding agent đáng tin cậy, hãy kết hợp ba lớp bằng chứng: kiểm thử hành vi nhỏ để thấy agent đã làm gì, tác vụ kho mã đầu-cuối để đo kết quả cuối và chỉ số vận hành để theo dõi chi phí cùng rủi ro. Không lớp nào đủ nếu đứng riêng.

Điểm tổng chỉ là tín hiệu định hướng. Một cấu hình mới có thể hoàn thành nhiều tác vụ hơn nhưng lại thường xuyên bỏ qua bước chạy test, sửa tệp ngoài phạm vi hoặc gọi sai công cụ. Vì vậy, mỗi thay đổi mô hình, prompt, tool schema hoặc chính sách quyền cần đi qua cùng một bộ hồi quy cố định, với trace đủ chi tiết để truy nguyên từng lỗi.

Vì sao điểm tổng có thể che hồi quy

Benchmark đầu-cuối trả lời agent hoàn thành được bao nhiêu tác vụ, nhưng thường không chỉ ra nguyên nhân khiến kết quả thay đổi. Hai lần chạy cùng tạo được bản vá đạt test vẫn có thể khác nhau đáng kể: một lần xác định đúng tệp và kiểm tra bản vá ngay, lần còn lại thử nhiều thao tác không hợp lệ rồi chỉ thành công nhờ tự phục hồi.

Hướng dẫn về behavioral eval của Google mô tả các kiểm tra nhỏ nhắm vào hành động quan sát được, như hỏi lại khi yêu cầu thiếu dữ kiện hoặc chạy trình xác thực sau khi sửa tệp build. Bài viết coi chúng là phần bổ sung cho benchmark đầu-cuối: benchmark đo đích đến, còn kiểm thử hành vi giúp phát hiện bước trung gian đã hỏng.

Do đó, không nên nén mọi tín hiệu thành một con số và đặt một ngưỡng duy nhất. Báo cáo cần tách tỷ lệ hoàn thành tác vụ khỏi các hành vi bắt buộc; điểm đầu-cuối tăng không thể bù cho việc vi phạm quyền, bỏ qua xác minh hoặc tạo thay đổi ngoài phạm vi.

Dựng khung đánh giá ba lớp

Lớp thứ nhất là kiểm thử hành vi. Mỗi ca nên nhắm vào một failure mode có thể chẩn đoán: không chạy test trước khi kết thúc, đoán API thay vì tra cứu, chỉnh tệp bị cấm hoặc tiếp tục sau lỗi quyền. Kết quả phải chỉ ra assertion nào thất bại và sự kiện tương ứng nằm ở đâu trong trace.

Lớp thứ hai là tác vụ kho mã. Chọn một tập lỗi, thay đổi nhỏ và công việc bảo trì đại diện cho ngôn ngữ, công cụ build, quy ước cùng quyền truy cập thực tế của nhóm. Chấm bản vá bằng test độc lập, kiểm tra hồi quy sẵn có và rubric về phạm vi thay đổi, thay vì chỉ so khớp với một bản vá mẫu.

Lớp thứ ba là vận hành. Theo dõi lượt gọi mô hình và công cụ, độ trễ, chi phí, số lần thử lại, lỗi sandbox, tỷ lệ cần người can thiệp và thay đổi ngoài phạm vi. Với mã có khả năng được triển khai, cần thêm các kiểm tra bảo mật phù hợp vì một chương trình chạy đúng chức năng vẫn có thể để sót vấn đề trên bề mặt kiểm tra an toàn.

Đối tượng cần đánh giá là toàn bộ cấu hình agent, không chỉ tên mô hình. Nghiên cứu mã nguồn của 11 coding harness xác định bảy phân hệ chuẩn: vòng lặp agent, tích hợp LLM, công cụ và hành động, bộ nhớ và ngữ cảnh, an toàn và quyền, điều phối, cùng khả năng mở rộng. Kết quả vì thế có thể đổi khi runtime, quyền hoặc cách quản lý ngữ cảnh thay đổi dù mô hình vẫn giữ nguyên.

Viết ca hành vi nhỏ mà không khóa cứng đường giải

Bắt đầu từ một lỗi đã quan sát được rồi chuyển nó thành điều kiện kiểm tra được. Chẳng hạn, sau khi sửa mã, agent phải gọi test runner trước khi báo hoàn tất; khi công cụ trả lỗi quyền, agent không được lặp lại cùng thao tác bị cấm.

Với tác vụ phức tạp, không nên ép agent tuân theo toàn bộ chuỗi lệnh lý tưởng. Nhiều đường giải có thể cùng hợp lệ, nên assertion chỉ cần bảo vệ bất biến quan trọng: tệp cấm không bị sửa, test liên quan được chạy và lỗi công cụ được xử lý. Benchmark kho mã chịu trách nhiệm xác nhận kết quả cuối.

Mỗi ca cần lưu đầu vào đã chuẩn hóa, phiên bản prompt, định nghĩa tool schema, mã mô hình, tham số lấy mẫu, snapshot kho mã, chính sách quyền, sự kiện gọi công cụ, diff, kết quả test và lý do dừng. Thiếu các trường này, nhóm có thể thấy điểm giảm nhưng không tái hiện được điều kiện gây lỗi.

Dùng rubric và trọng tài độc lập

Một rubric gọn có thể tách thành bốn phần: đúng chức năng, tuân thủ phạm vi, quy trình xác minh và hiệu quả vận hành. Mỗi tiêu chí phải gắn với bằng chứng quan sát được; “đã xác minh” nghĩa là trace ghi nhận đúng nhóm test cùng mã thoát, không phải agent tự tuyên bố rằng test đã qua.

Ưu tiên kiểm tra tất định cho lệnh gọi công cụ, diff, quyền và kết quả test. LLM-as-a-judge phù hợp với những phẩm chất khó biểu diễn bằng luật, nhưng không nên là trọng tài duy nhất. Trong cuộc kiểm toán SWE-Bench Pro của OpenAI, các tác vụ bị gắn cờ được xem xét qua nhiều lượt investigator-agent rồi được năm kỹ sư phần mềm đánh giá độc lập; hai nhánh có bất đồng và người đánh giá thường nhận diện nhiều nhãn lỗi hơn.

Nếu dùng model judge, hãy cố định prompt chấm, phiên bản mô hình và rubric, đồng thời lưu nhận định cùng bằng chứng được viện dẫn. Nên lấy mẫu định kỳ cho người đánh giá không biết cấu hình thử nghiệm và chuyển những lỗi lặp lại thành assertion tất định khi có thể.

Đặt cổng hồi quy cho mọi thay đổi

Quy trình phát hành cần bắt đầu từ một cấu hình chuẩn và bộ ca được khóa phiên bản. Khi khả thi, mỗi ứng viên chỉ thay một biến; các lần chạy dùng cùng snapshot môi trường, giới hạn tài nguyên và dữ liệu đầu vào để kết quả có thể so sánh.

1. Chạy toàn bộ behavioral suite, đánh dấu riêng các hành vi bắt buộc về quyền, phạm vi và xác minh.
2. Chạy cùng tập tác vụ kho mã và chấm bản vá bằng test cùng rubric độc lập.
3. So sánh chi phí, độ trễ, số lần thử lại và nhu cầu can thiệp của con người.
4. Mở trace của mọi ca mới thất bại, ca đổi trạng thái và một mẫu trong nhóm thành công.
5. Chỉ chấp nhận thay đổi khi không vi phạm ngưỡng cứng; mọi suy giảm được cho phép phải có lý do và người chịu trách nhiệm.

Có thể duy trì một bộ hồi quy nhỏ, chạy nhanh cho mỗi pull request và một tập tác vụ kho mã lớn hơn trước khi phát hành. Khi production xuất hiện failure mode mới, hãy rút gọn nó thành ca tái hiện, loại bỏ dữ liệu nhạy cảm rồi bổ sung vào bộ cố định. Cách tổ chức này giữ điểm tổng làm thước đo đích đến nhưng không cho phép nó che mất một hành vi đã xấu đi.

Đọc thêm:

• Ứng dụng vibe coding chạy được chưa chắc an toàn: 10 điểm phải kiểm tra
• Lean báo proof hợp lệ chưa đủ: vẫn phải kiểm tra định lý và tiên đề
• View YouTube tăng từ khung hình đầu, nhưng tiền vẫn theo lượt xem gắn kết