Lần hallucination đầu tiên khiến tôi thật sự khó chịu không có gì kịch tính. Chỉ là một câu sai nằm giữa hai chi tiết đúng trong bản summary. Văn trôi chảy, cấu trúc gọn, câu sai lại bình thường đến mức rất dễ lọt qua nếu không ai đối chiếu. Hallucination nguy hiểm trong công việc hằng ngày chính ở chỗ đó: nó hiếm khi tự đeo biển “đừng tin tôi”.
Với LLM, hallucination là phần trả lời nghe hợp lý nhưng không có căn cứ cần thiết cho yêu cầu. Model có thể bịa nguồn, trộn hai khái niệm gần nhau, hoặc tự điền chỗ trống vì prompt vô tình đòi nó phải hữu ích bằng mọi giá. Không cần gán cho model ý định nói dối. Vấn đề kỹ thuật nằm ở chỗ ngôn ngữ mượt có thể xuất hiện ngay cả khi căn cứ còn yếu.
Lớp phòng vệ đầu tiên là thu hẹp đề bài. “Giải thích trường hợp khách hàng này” để model tự chọn phạm vi quá nhiều. Yêu cầu tốt hơn cần nói rõ tài liệu nào được phép dùng, câu hỏi nào phải trả lời, phần chưa chắc phải báo ra sao và đầu ra cần theo định dạng gì. Model vẫn có thể sai, nhưng khoảng đất dành cho suy đoán không căn cứ đã nhỏ đi đáng kể.
Ngữ cảnh đúng quan trọng hơn ngữ cảnh nhiều. Đổ cả thư mục vào prompt có thể làm câu trả lời trông dày dặn hơn mà vẫn che một bước truy xuất kém. Câu hỏi cần hỏi là model có nhận đúng bằng chứng không, chứ không phải nó đã đọc bao nhiêu nội dung. Với công cụ dùng tri thức nội bộ, điều này kéo theo việc chia tài liệu hợp lý, giữ tiêu đề và ngày cập nhật, lấy đoạn sát câu hỏi nhất, rồi đặt nguồn gần phần trả lời được sinh ra.
RAG hữu ích khi yêu cầu dựa vào kiến thức bên ngoài hoặc dữ liệu riêng. Thay vì bắt model “nhớ” quy định, chi tiết sản phẩm hay quyết định dự án, hệ thống tìm nguồn liên quan rồi yêu cầu trả lời từ chính nguồn ấy. Nhưng RAG không phải phép màu. Bước truy xuất kéo nhầm tài liệu, lấy bản đã cũ hoặc cắt một đoạn mất ngữ cảnh thì câu trả lời vẫn sai — đôi khi còn tự tin hơn vì giờ nó có vẻ như đã “tham khảo tài liệu”.
Trích dẫn giúp người đọc kiểm tra, nhưng chỉ khi nó thật sự nâng đỡ nhận định đi kèm. Một đường dẫn đặt cuối đoạn cho có không biến phần nội dung thành đúng. Trong quy trình nghiêm túc, người dùng phải mở được nguồn và so sánh mà không mất công đào lại từ đầu. Trích dẫn lúc này không phải đồ trang trí để tạo cảm giác tin cậy; nó là giao diện của bước xác minh.
Hệ thống cũng phải cho phép model từ chối và nói rõ phần chưa biết. Nhiều sản phẩm vô tình thưởng cho việc trả lời mọi câu hỏi. Một luồng an toàn hơn chấp nhận những câu như “ngữ cảnh hiện có không chứa chi tiết này”, “phần này chưa đủ căn cứ”, hoặc “từ nguồn được cung cấp, tôi chỉ trả lời được câu đầu”. Nghe kém ấn tượng hơn một phỏng đoán trơn tru, nhưng hữu ích hơn nhiều.
Việc xác minh không nên bị nhốt trong prompt. Code thì chạy test. Phép tính thì giao cho công cụ cho kết quả xác định. Dữ kiện thì đối chiếu nguồn. Đầu ra có cấu trúc thì kiểm tra schema. Câu trả lời về quy định thì kiểm tra nguồn trích dẫn. Model có thể đề xuất kế hoạch xác minh, nhưng không nên vừa làm bài vừa là người duy nhất tự chấm bài.
Bộ đánh giá là lúc nhóm thôi đánh giá bằng vài cuộc chat mới nhất. Hãy gom các ví dụ phản ánh kiểu lỗi thật: thiếu ngữ cảnh, hai tài liệu mâu thuẫn, quy định đã cũ, tên sản phẩm giống nhau, trường hợp biên khó và câu hỏi đáng ra phải bị từ chối. Sau đó chạy thay đổi prompt, bước truy xuất hay model trên cùng bộ này. Không có bộ đánh giá, “tốt hơn” thường chỉ là một cảm giác vừa xuất hiện.
UX cũng quyết định người dùng sẽ tin theo cách nào. Nếu tính năng AI trình bày mọi câu trả lời như kết luận cuối, người dùng dễ học thói quen sai. Giao diện nên cho thấy nguồn, ngày cập nhật, ranh giới phần chắc và chưa chắc, câu hỏi tiếp theo, cùng đường mở bằng chứng. Mục tiêu không phải khiến ai cũng nghi ngờ mọi câu; mục tiêu là giúp họ đặt mức tin cậy đúng với bằng chứng đang có.
Không có một prompt hoàn hảo đủ sức giải quyết tất cả. Độ tin cậy đến từ nhiều lớp phối hợp: giao việc rõ, truy xuất tốt, nguồn nhìn thấy được, quyền từ chối, kiểm tra bằng công cụ xác định và đánh giá liên tục. Mỗi lớp bắt một nhóm lỗi khác nhau; bỏ một lớp thì phần còn lại phải gánh quá sức.
Bài học quan trọng là độ tin cậy của AI là bài toán thiết kế hệ thống, không chỉ là bài toán chọn model. Ngôn ngữ trôi chảy không phải bằng chứng. Khi nhìn lại một công cụ AI mình đang dùng hoặc xây, guardrail đáng giữ là thứ thật sự làm người dùng thay đổi cách kiểm tra: trích dẫn, test, truy xuất tốt hơn, hoặc một luồng sản phẩm dám để phần chưa chắc hiện ra.