Bài 6 — Giảm ảo giác (hallucination) trong coding agent

Ảo giác trong code trông như thế nào

Agent bịa ra thứ nghe hợp lý nhưng không tồn tại: gọi hàm user.get_full_name() khi model chỉ có first_name/last_name; import thư viện fastjson không cài; dùng tham số API sai; "nhớ" một endpoint mà repo không có. Code trông đúng, nhưng chạy là lỗi.

Nguyên nhân gốc: agent lấp khoảng trống thông tin bằng phỏng đoán từ dữ liệu huấn luyện, thay vì thừa nhận không biết.

Sáu kỹ thuật chống ảo giác

• Grounding — buộc dựa trên nguồn thật: yêu cầu agent đọc code/định nghĩa trước, và chỉ dùng API mà nó đã thấy trong context.
• Verify bằng công cụ: cho agent chạy test, lint, type-check, build. Sự thật đến từ máy, không từ lời khẳng định của agent.
• Cho phép "tôi không chắc": hướng dẫn agent dừng và hỏi khi thiếu thông tin, thay vì đoán.
• Yêu cầu trích dẫn: "mỗi API bạn dùng, chỉ ra nó định nghĩa ở file:dòng nào bạn đã đọc."
• Kiểm tra sự tồn tại trước khi dùng: với dependency lạ, yêu cầu agent kiểm tra nó có trong requirements.txt/package.json không.
• Vòng lặp phản hồi lỗi: đưa thông báo lỗi thật (build/test fail) trở lại cho agent để nó tự sửa dựa trên bằng chứng.

Ví dụ cụ thể

Agent viết:

from utils import format_currency  # có tồn tại không?
total = order.grand_total()        # method này có thật không?

Prompt chống ảo giác:

Trước khi dùng bất kỳ hàm/method nào của order hay utils,
hãy grep để xác nhận nó tồn tại. Nếu không thấy, DỪNG và báo,
ĐỪNG tự tạo giả định. Sau khi viết, chạy pytest -q và dán kết quả.

Nếu grand_total() không có, agent sẽ báo thay vì bịa — bạn phát hiện ngay ở bước 0.

Khung "Trust but Verify"

Agent khẳng định X ("đã xong", "hàm này tồn tại", "test pass")
   -> Có bằng chứng máy sinh ra không?
      Có  -> chấp nhận
      Không -> yêu cầu chạy công cụ để chứng minh

Không chấp nhận "tôi đã sửa xong" mà không có output test.

Các bước giảm ảo giác trong quy trình

• Bật/yêu cầu agent đọc code liên quan trước khi viết (grounding).
• Trong prompt, cấm dùng API chưa được xác nhận tồn tại.
• Yêu cầu agent tự chạy test/lint và dán kết quả.
• Khi có lỗi, đưa nguyên văn lỗi lại cho agent.
• Với thay đổi rủi ro cao, yêu cầu agent liệt kê giả định để bạn duyệt.

Checklist chống ảo giác

• [ ] Agent đã đọc code trước khi dùng API của nó
• [ ] Đã cấm dùng hàm/thư viện chưa xác nhận tồn tại
• [ ] Có bước chạy test/lint thật, không chỉ lời khẳng định
• [ ] Lỗi thật được đưa lại cho agent để sửa
• [ ] Agent được phép nói "không chắc" thay vì đoán

Bốn dấu hiệu cảnh báo ảo giác

Học nhận diện sớm giúp bạn bắt lỗi trước khi tốn thời gian:

• Import thư viện lạ — tên nghe hợp lý nhưng dự án chưa từng dùng. Kiểm tra requirements.txt/package.json.
• Gọi method "tiện quá mức" — ví dụ order.calculate_everything() làm đúng y hệt điều bạn cần một cách quá suôn sẻ. Thực tế hiếm khi có sẵn hàm hoàn hảo như vậy; hãy grep xác nhận.
• Tham số API sai kiểu — agent "nhớ" chữ ký hàm từ dữ liệu huấn luyện, không phải từ code thật của bạn.
• Khẳng định chắc nịch không kèm bằng chứng — "chắc chắn chạy đúng" mà chưa chạy test là cờ đỏ.

Khi thấy bất kỳ dấu hiệu nào, chuyển sang chế độ verify: buộc agent grep, chạy test, hoặc chỉ ra file:dòng nơi API được định nghĩa.

Sai lầm thường gặp

• Tin lời "đã test và pass" mà không thấy output — agent có thể chưa chạy gì.
• Không cho công cụ verify — thiếu test/lint thì không có cơ chế bắt lỗi bịa.
• Prompt khuyến khích đoán — "cứ làm đại đi" khiến agent lấp khoảng trống bằng ảo giác.
• Bỏ qua dependency lạ — import thư viện chưa cài là dấu hiệu ảo giác kinh điển.
• Không đưa lỗi thật lại — mô tả lỗi mơ hồ khiến agent tiếp tục đoán mò.
• Bỏ qua method "tiện quá mức" — hàm giải quyết mọi thứ một cách hoàn hảo thường là hàng bịa.

Grounding + verify là hai trụ cột. Bài sau: dùng tool và test làm context phản hồi.