Có thể tin tưởng vào AI review không?
(medium.com)Trong quá trình vận hành công cụ AI review nội bộ, chúng tôi chia sẻ hành trình đã đo lường định lượng và cải thiện chất lượng để trả lời các câu hỏi như: "Có thể tin tưởng vào AI review không?", "Nó thực sự đang kiểm chứng tốt đến mức nào?"
Bối cảnh
- Mã do AI tạo ra có số issue trên mỗi PR cao gấp 1,7 lần và lỗi logic nhiều hơn 75% so với mã do con người viết (CodeRabbit)
- Sau sự cố từ mã AI, Amazon bắt buộc PR phải được senior phê duyệt; Shopify cấm auto-merge PR do AI tạo
- Trong bối cảnh này, AI review được đưa vào như một phương tiện kiểm chứng để phát hiện sớm issue và error
- Tuy nhiên bản thân AI review có tính phi quyết định, nên trước hết cần đo lường xem "phương tiện kiểm chứng này thực sự có đang kiểm chứng tốt hay không"
Tự xây dựng benchmark
- Hotfix PR → lần ngược về PR gốc để đo xem "ở thời điểm PR gốc, AI review có thể bắt được bug này hay không"
- Chỉ đưa vào các case có thể đánh giá chỉ bằng PR diff, loại trừ những trường hợp cần ngữ cảnh bên ngoài
- Chấm điểm bằng GPT-4o mini theo cách LLM-as-a-Judge. Dù giá trị tuyệt đối có thể không chính xác, vẫn đủ tốt cho so sánh tương đối
- Điểm đầu tiên là 33. Cảm giác "chúng ta đang làm khá tốt" hóa ra chỉ là ảo giác do một số rất ít case thành công tạo nên
Thất bại 1 (orchestration sub-agent)
- Thử cấu trúc có các sub-agent chuyên môn theo từng lĩnh vực và một agent chính điều phối
- Kết quả: tỷ lệ phát hiện ↓, chi phí ↑ 1,5~3 lần
- Có 3 nguyên nhân
- Mất mát thông tin do nén context
- Tầm nhìn bị thu hẹp do giới hạn phạm vi quan tâm
- Khoảng trống trách nhiệm ở các vùng giao thoa giữa nhiều lĩnh vực
Thất bại 2 (benchmark bị ô nhiễm)
- Khi tự động tuning prompt theo vòng lặp, hệ thống hội tụ thành việc liệt kê các chỉ thị kiểu như "hãy kiểm tra Division by Zero"
- SWE-bench cũng đã ở trạng thái bị ô nhiễm
- Từ đó xác nhận rằng benchmark bên ngoài không thể là cơ sở để chọn model
Chỉ số mới (Adoption Rate)
- adopted: review thực sự dẫn đến thay đổi trong mã
- engaged: không có thay đổi nhưng có tương tác qua reply (thừa nhận giá trị kiểm chứng chéo)
- noised: không thay đổi mã, cũng không có reply
- Cách xác định: so sánh commit SHA tại thời điểm review với SHA tại thời điểm merge, nếu có thay đổi trong phạm vi ±3 dòng quanh dòng bị comment thì tính là adopted
A/B giữa Opus 4.6 và GPT-5.2 Codex
- Phân nhánh model theo số PR chẵn/lẻ, so sánh khoảng 100 PR
- Opus 4.6: nhanh và sáng tạo nhưng thiếu độ kỹ lưỡng, dễ Approve
- GPT-5.2 Codex: chậm hơn nhưng kỹ lưỡng, ngay cả ở thời điểm yêu cầu review lại vẫn đưa ra thêm nhiều nhận xét hữu ích
- Sau khi cố định sang Codex, tỷ lệ phản ánh hằng tuần đạt mức cao nhất 60%
3 biện pháp giúp tăng tỷ lệ phản ánh
- Question: với những gì chưa chắc chắn, đặt câu hỏi thay vì chỉ ra lỗi
- Phần Intent/Decisions trong mẫu PR
- Intent: dùng kỹ năng create-pr để chèn câu trả lời cho câu hỏi "vì sao điều này là cần thiết"
- Decisions: dùng hook Claude Stop để tự động trích xuất các quyết định trong phiên hội thoại
- Giảm khoảng 29% false positive vốn phát sinh do reviewer thiếu ngữ cảnh
- Tự động resolve thread: khi xác nhận review đã được phản ánh, AI tự đóng thread
Kết quả
- Đạt tỷ lệ phản ánh theo tháng 63% (tính đến 2026-04-17)
- Vì mọi action đều dựa trên dữ liệu, nên có thể đưa ra quyết định cho thí nghiệm tiếp theo với cơ sở rõ ràng
- Tuy nhiên cũng cần cảnh giác rằng Adoption Rate không đảm bảo "được chấp nhận = đúng", nên chỉ số này cũng có thể bị ô nhiễm
3 bình luận
Nghe như... kiểu "ai sẽ giám sát người giám sát?" vậy.
"Phương tiện kiểm chứng" tôi nói ở trên là muốn chỉ các AI reviewer. Ý tôi là vì AI có tính phi xác định nên trước hết cần có một đường cơ sở (benchmark) để đo chất lượng của việc review bằng AI, nhưng từ góc nhìn của người đọc thì cũng có thể hiểu là phải xem xét trước tính hợp lệ của chính benchmark đó.
Có lẽ tôi đã viết câu hơi mơ hồ nên gây ra sự nhầm lẫn. Cảm ơn bạn đã chỉ ra điều đó..!
Tôi đã dùng Codex cho giai đoạn lập kế hoạch và giai đoạn kiểm chứng, hóa ra là tôi đã làm đúng rồi.