Bài 6 — Hạn chế false positive: lọc nhiễu để agent đáng tin

Kẻ giết chết mọi agent review không phải là bỏ sót lỗi, mà là false positive — báo lỗi không có thật. Chỉ cần vài nhận xét sai, dev sẽ mất niềm tin và bỏ qua tất cả, kể cả những nhận xét đúng. Mục tiêu bài này: xây nhiều lớp lọc để tỷ lệ nhận xét hữu ích cao.

Vì sao agent hay báo sai

• Thiếu ngữ cảnh: thấy parse(x) không thấy x đã validate ở nơi khác.
• Bịa (hallucination): "đề xuất" một hàm không tồn tại.
• Chê style/thứ đã có công cụ lo: trùng lặp, nhiễu.
• Áp quy chuẩn không hợp repo: repo dùng convention riêng.

Các lớp lọc (áp dụng chồng lên nhau)

Lớp 1 — Ngưỡng confidence

Yêu cầu model tự chấm confidence và bỏ mọi nhận xét < ngưỡng (vd 0.7). Đơn giản mà hiệu quả.

comments = [c for c in comments if c["confidence"] >= 0.7]

Lớp 2 — Chỉ trong diff, chỉ code mới

Bỏ nhận xét trỏ vào dòng không có trong diff, hoặc vào code cũ không đổi (side != RIGHT).

Lớp 3 — Danh sách loại trừ

Lọc theo category và path:

suppress_categories: ["style", "formatting"]   # để linter lo
ignore_paths: ["**/*.generated.*", "migrations/**"]

Lớp 4 — Cung cấp ngữ cảnh nhiều hơn

Gửi kèm vài dòng quanh chỗ đổi + chữ ký hàm liên quan. Nhiều false positive biến mất chỉ vì model đã thấy đủ ngữ cảnh.

Lớp 5 — Vòng suy luận thứ hai (self-check)

Với nhận xét high, hỏi lại model: "Nhận xét này có chắc đúng không? Nếu code ở nơi khác đã xử lý thì rút lại." Bước verify này cắt nhiều báo động giả tốn kém.

Các bước giảm false positive

• Bật ngưỡng confidence và bắt đầu ở mức cao (0.75), hạ dần nếu bỏ sót nhiều.
• Thêm ngữ cảnh xung quanh diff vào prompt.
• Loại category đã có công cụ khác lo (style, format).
• Với lỗi high, chạy một bước self-verify trước khi đăng.
• Cho dev nút phản hồi (👍/👎 hoặc reply "false positive") và thu thsố liệu.
• Định kỳ xem 20 nhận xét gần nhất bị dev bác, tìm mẫu lỗi, thêm ràng buộc vào prompt.

Khung tư duy: đánh đổi Precision vs Recall

• Precision cao (ít báo sai) quan trọng hơn ở giai đoạn đầu — để xây niềm tin.
• Recall cao (bắt được nhiều lỗi) đánh đổi bằng nhiều nhiễu.
• Nguyên tắc: thà bỏ sót một lỗi nhỏ còn hơn báo sai và mất niềm tin. Ưu tiên precision, nới recall dần khi có dữ liệu.

Ví dụ vòng cải tiến

Tuần 1: agent hay chê "biến này có thể None" trong khi repo có decorator validate. Bạn thêm vào prompt: "Nếu tham số đi qua decorator @validated, coi như đã kiểm tra." → nhóm false positive này biến mất.

Sai lầm thường gặp

• Chạy đua recall trước. Bật mọi loại nhận xét từ đầu → ngập nhiễu → mất niềm tin. Bắt đầu hẹp và chính xác.
• Không có kênh phản hồi. Không đo được false positive thì không cải thiện được. Cho dev báo sai dễ dàng.
• Tin tuyệt đối vào confidence của model. Nó là tín hiệu, không phải chân lý; kết hợp với self-verify và lọc theo category.
• Không cập nhật prompt theo lỗi thực tế. Mỗi mẫu false positive lặp lại là một dòng ràng buộc bạn nên thêm.
• Đăng cả nhận xét confidence thấp "cho chắc". Đó chính là nguồn nhiễu lớn nhất. Hãy mạnh dạn bỏ.

Khi tỷ lệ nhận xét hữu ích đã cao, bạn có thể để agent tham gia quyết định merge. Bài 7 bàn về policy chặn merge an toàn.