Nhân viên hỗ trợ đã trả lời yêu cầu đặt lại xác thực hai yếu tố của người dùng bằng các bước hoàn toàn không tồn tại. Câu trả lời trông rất tự tin, yêu cầu HTTP trả về 200 OK, độ trễ bình thường và mọi biểu đồ giám sát đều hiển thị màu xanh.
Một nhân viên hỗ trợ vận hành bằng AI đã "ảo giác" (hallucinated) ra một câu trả lời vì các bước kiểm tra nội bộ lẽ ra phải phát hiện được lỗi đã không bao giờ được thực hiện. Các bảng điều khiển (dashboards) mà các kỹ sư tin dùng báo cáo một quá trình vận hành hoàn hảo, trong khi nhân viên hỗ trợ âm thầm bịa đặt ra một giải pháp.
Tại sao các bảng điều khiển truyền thống bỏ lỡ các lỗi ảo giác của AI
Hầu hết các ngăn xếp quan sát (observability stacks) đều coi một tác nhân AI giống như bất kỳ microservice nào khác: một yêu cầu đầu vào duy nhất và một phản hồi đầu ra duy nhất. Chúng ghi lại trạng thái HTTP, thời gian phản hồi và số lượng lỗi. Chúng không ghi lại các bước ẩn bên trong yêu cầu – việc truy xuất các tài liệu bên ngoài, các lệnh gọi đến các mô hình ngôn ngữ lớn, việc sử dụng các công cụ bổ trợ và bất kỳ logic rào chắn (guard-rail) nào nhằm xác thực đầu ra.
Khi một bước truy xuất trả về kết quả trống, mô hình thường "lấp đầy khoảng trống" bằng các văn bản nghe có vẻ hợp lý. Từ góc nhìn của hệ thống giám sát, lệnh gọi đã thành công vì không có gì bị lỗi và mã trạng thái vẫn là 200. Sự ảo giác vẫn vô hình, và triệu chứng duy nhất là một câu trả lời sai đến tay người dùng.
Biến một "hộp đen" thành một cây dữ liệu có thể đọc được
Bước đầu tiên để gỡ lỗi đáng tin cậy là ngừng coi tác nhân như một lệnh gọi nguyên khối (monolithic call) và bắt đầu trực quan hóa từng hoạt động nội bộ thành một hàng riêng biệt trong bảng truy vết (trace table). Một lượt chạy điển hình được chia nhỏ thành:
- Lệnh gọi tác nhân ở cấp cao nhất
- Bước truy xuất để lấy các tài liệu liên quan
- Mọi suy luận mô hình ngôn ngữ (inference) để xử lý dữ liệu đã truy xuất
- Mỗi lệnh gọi công cụ (ví dụ: tra cứu cơ sở dữ liệu, yêu cầu API)
- Các bước kiểm tra rào chắn (guard-rail) để đảm bảo tính xác thực hoặc tuân thủ chính sách
Mỗi hàng ghi lại dấu thời gian, cờ thành công và dữ liệu (payload) đi qua bước đó. Với cấu trúc này, quá trình thực thi trở thành một cái cây có thể được kiểm tra từng dòng thay vì phải đoán mò từ kết quả đầu ra cuối cùng.
Lỗi đã lọt qua khe hở
Trong tương tác hỗ trợ bị lỗi, vết truy vết trông như thế này:
- Truy xuất đã chạy nhưng không trả về tài liệu nào.
- Bước tiếp theo vẫn tiếp tục diễn ra, truyền một ngữ cảnh trống vào mô hình.
- Mô hình đã tạo ra một câu trả lời bằng cách lấp đầy thông tin còn thiếu với các bước tự bịa đặt.
- Hệ thống trả về 200 vì quy trình (pipeline) không gặp phải ngoại lệ (exception).
Sự ảo giác không phải là lỗi của bản thân mô hình ngôn ngữ; đó là do thiếu một rào chắn (guard-rail) giữa giai đoạn truy xuất và giai đoạn tạo văn bản. Tác nhân đã trả lời ngay cả khi không có gì để làm căn cứ (grounding) cho câu trả lời của mình.
Các rào chắn đơn giản giúp ngăn chặn sự ảo giác
Hai thay đổi cụ thể đã loại bỏ vấn đề này:
- Hủy bỏ khi truy xuất trống – nếu kho tài liệu không trả về gì, tác nhân phải trả lời "Tôi không thể tìm thấy thông tin bạn cần" thay vì tiếp tục bước tạo văn bản.
- Kiểm tra căn cứ (Grounding check) – sau khi mô hình tạo ra phản hồi, hãy xác minh rằng mọi khẳng định về sự thật đều xuất hiện trong nội dung đã truy xuất. Nếu việc kiểm tra thất bại, hãy từ chối câu trả lời và chuyển sang phản hồi "không thể trả lời".
Quy trình làm việc thực tế để gỡ lỗi nhanh hơn
- Truy vết mọi lệnh gọi nội bộ – thiết lập công cụ (instrument) cho tác nhân để mỗi lần truy xuất, suy luận mô hình và sử dụng công cụ đều ghi một hàng vào nhật ký (log) lưu trữ lâu dài.
- Lưu lại các lượt chạy thất bại – lưu trữ toàn bộ vết truy vết của bất kỳ tương tác nào mà người dùng báo cáo là sai. Việc xóa chúng để tiết kiệm dung lượng sẽ làm mất đi dữ liệu cần thiết để tìm ra các lỗi hồi quy (regressions).
- Gắn thẻ các lượt chạy với thông tin phiên bản – bao gồm mã định danh bản phát hành và bất kỳ trạng thái cờ tính năng (feature-flag) nào trong mỗi hàng truy vết. Điều này cho phép bạn liên kết một lỗi mới với một thay đổi mã nguồn gần đây.
- Đánh giá chất lượng, không chỉ tốc độ – thêm các chỉ số đo lường mức độ tuân thủ hướng dẫn của câu trả lời và mức độ bám sát nội dung đã truy xuất. Thông lượng (throughput) cao cũng chẳng có ý nghĩa gì nếu các câu trả lời bị sai.
- Xem xét các lỗi hàng ngày – việc xem xét định kỳ và ngắn gọn các lỗi đã lưu thường giúp phát hiện ra các quy luật (ví dụ: một loại truy vấn cụ thể liên tục trả về kết quả truy xuất trống) trước khi chúng ảnh hưởng đến nhiều người dùng.
Bằng cách chuyển đổi trạng thái từ "màu xanh" sang "đã xác minh", các đội ngũ có thể phát hiện sớm các lỗi ảo giác và giữ cho trải nghiệm người dùng luôn đáng tin cậy.
Cái giá của việc phớt lờ các lỗi nội bộ
Khi các bảng điều khiển chỉ báo cáo sự thành công ở lớp HTTP, các tổ chức sẽ triển khai những tác nhân trông có vẻ đáng tin cậy nhưng lại thường xuyên đưa ra những hướng dẫn sai lệch.
Những điều cần theo dõi tiếp theo
Cho đến khi những điều đó trở nên phổ biến, cách tiếp cận an toàn nhất là coi mọi hoạt động nội bộ đều có thể quan sát được và thực hiện cơ chế "fail fast" khi thiếu bằng chứng.
Bài học rút ra: Một dashboard hiển thị màu xanh cho bạn biết hệ thống vận hành trơn tru; nhưng nó không đảm bảo rằng câu trả lời là chính xác. Bằng cách truy vết từng lượt truy xuất, lời gọi mô hình và kiểm tra rào chắn (guard-rail), bạn biến những sự ảo tưởng tiềm ẩn thành những lỗi có thể nhìn thấy được để có thể khắc phục trước khi chúng đến tay người dùng.