Cách giảm hallucination khi AI Agent trả lời khách hàng

Hallucination là khi AI Agent tạo ra thông tin nghe hợp lý nhưng không có trong bất kỳ nguồn nào: một thời hạn đổi trả không tồn tại, một mức ưu đãi chưa từng áp dụng, một tính năng sản phẩm không có. Với khách hàng, câu trả lời sai mà tự tin còn tệ hơn không trả lời, vì khách tin và hành động theo nó.

Không có cách nào đưa hallucination về không. Nhưng có thể giảm mạnh tần suất và, quan trọng hơn, chặn những câu bịa trước khi đến tay khách. Bài này tập trung vào kỹ thuật phòng ngừa khi thiết kế: bắt agent dựa vào nguồn và trích dẫn, đặt ngưỡng tin cậy để biết lúc nào phải dừng, dạy agent từ chối đúng cách và kiểm thử có chủ đích.

Nếu chatbot của bạn đã chạy và đang trả lời sai, hãy đọc trước bài 8 nguyên nhân chatbot AI trả lời sai để tìm lỗi nằm ở dữ liệu, truy xuất hay tích hợp, rồi quay lại đây để dựng các lớp chặn.

1. Bản chất của hallucination

Mô hình ngôn ngữ được huấn luyện để viết tiếp văn bản một cách trôi chảy, không phải để kiểm tra điều nó viết có thật hay không. Khi thiếu thông tin, nó có xu hướng lấp chỗ trống bằng điều nghe hợp lý nhất. Vì vậy giảm hallucination chủ yếu là việc của hệ thống bao quanh mô hình: đưa đúng dữ liệu vào, giới hạn điều được nói và kiểm tra trước khi gửi. Đổi sang mô hình khác chỉ là một phần nhỏ, như đã phân tích ở bài chọn mô hình AI cho AI Agent.

Rủi ro khác nhau ở ba mức việc. Ở hỏi đáp, agent chỉ được nói những gì có trong đoạn tài liệu đã truy xuất. Ở tra cứu, các con số như giá, tồn kho, trạng thái đơn phải lấy nguyên từ kết quả công cụ, không để mô hình viết lại hay làm tròn. Ở thao tác ghi, tham số như mã đơn hay số lượng phải đến từ người dùng hoặc hệ thống, không bao giờ để mô hình đoán; thiếu thì hỏi lại.

2. Các kỹ thuật cần thiết kế

1. Nguồn có thẩm quyền

Agent chỉ được trả lời từ những nguồn đã chỉ định cho từng chủ đề, ví dụ chính sách đổi trả lấy từ một trang duy nhất do bộ phận chăm sóc khách hàng quản lý. Hướng dẫn cho mô hình phải nói rõ không dùng hiểu biết chung để trả lời về sản phẩm, giá hay chính sách của doanh nghiệp. Mỗi nguồn gắn người sở hữu và ngày hiệu lực để hệ thống loại được bản đã hết hạn trước khi truy xuất.

2. Truy xuất đúng đoạn

Chất lượng truy xuất quyết định mô hình có dữ liệu đúng để dựa vào hay không. Kỹ thuật hay dùng là chia tài liệu theo mục có tiêu đề rõ, gắn thêm thông tin như dòng sản phẩm hay khu vực để lọc trước khi tìm, và đặt ngưỡng điểm liên quan. Đoạn dưới ngưỡng thì không đưa cho mô hình; nếu không đoạn nào đạt, agent đi thẳng sang nhánh từ chối thay vì cố trả lời từ dữ liệu yếu.

3. Trích dẫn

Yêu cầu agent gắn mỗi ý trả lời với đoạn nguồn đã dùng, và hiện cho khách tên tài liệu hoặc đường dẫn khi phù hợp. Quan trọng hơn là bước kiểm tra tự động phía sau: trích dẫn có trỏ tới đúng đoạn đã truy xuất không, con số trong câu trả lời có xuất hiện trong đoạn đó không. Câu trả lời không qua được bước này thì bị chặn hoặc chuyển người.

4. Phạm vi trả lời

Viết danh sách chủ đề agent được trả lời và chủ đề phải chuyển đi, rồi thêm một bước phân loại câu hỏi trước khi truy xuất. Câu hỏi ngoài phạm vi được xử lý bằng câu trả lời soạn sẵn, không đi qua phần sinh văn bản tự do. Phạm vi càng hẹp và rõ, mô hình càng ít chỗ để tự điền.

5. Từ chối đúng

Từ chối đúng là nói rõ chưa có thông tin, rồi đưa khách một bước tiếp theo: chuyển nhân viên, để lại số điện thoại hoặc gửi đường dẫn liên quan. Nên soạn sẵn vài mẫu từ chối theo tình huống để câu chữ nhất quán. Cần kiểm thử cả chiều ngược lại: agent từ chối cả những câu có trong tài liệu cũng là lỗi, vì khách sẽ bỏ đi.

6. Dữ liệu thời gian thực

Giá, tồn kho, lịch trống và trạng thái đơn phải lấy qua công cụ gọi vào hệ thống nguồn tại thời điểm hỏi. Kết quả công cụ nên được chèn vào câu trả lời qua mẫu có sẵn, thay vì để mô hình diễn đạt lại. Khi công cụ lỗi hoặc hết thời gian chờ, agent báo không lấy được dữ liệu, tuyệt đối không dùng con số trong tài liệu tĩnh để thay thế.

7. Kiểm thử

Bộ kiểm thử cho hallucination cần những câu được thiết kế để dụ agent bịa: hỏi về chính sách không tồn tại, hỏi sản phẩm không kinh doanh, hỏi con số không có trong tài liệu, hoặc câu có tiền đề sai như “bên em bảo hành trọn đời đúng không”. Kết quả mong đợi là từ chối hoặc đính chính, không phải một câu trả lời trôi chảy. Bộ này chạy lại sau mỗi lần sửa tài liệu, prompt hay đổi mô hình.

8. Phản hồi người dùng

Nút đánh giá câu trả lời và chỗ để nhân viên đánh dấu câu sai là nguồn phát hiện hallucination trong vận hành thật. Mỗi câu bị đánh dấu được lưu cùng đoạn nguồn đã dùng, người phụ trách xem lại rồi biến thành ca kiểm thử mới. Không nên sửa bằng cách gắn câu trả lời cứng cho từng trường hợp, vì cách đó không chặn được các biến thể của cùng một câu hỏi.

3. Quy trình áp dụng thực tế

Bước 1: Xác định phạm vi và kết quả cần đo

Chọn các chủ đề có hậu quả lớn nếu trả lời sai, thường là giá, đổi trả, bảo hành và điều kiện ưu đãi. Với từng chủ đề, ghi nguồn, người sở hữu và những điều agent không được khẳng định khi thiếu nguồn. Đầu ra là bảng chủ đề kèm mức rủi ro, do quản lý chăm sóc khách hàng duyệt.

Bước 2: Chuẩn hóa dữ liệu cùng quyền truy cập

Gom tài liệu về một kho, gỡ bản trùng và bản hết hiệu lực, chia theo mục có tiêu đề rõ và gắn thông tin để lọc. Agent chỉ được truy xuất trong kho đã duyệt, không đọc các thư mục nội bộ khác. Người sở hữu từng nhóm tài liệu xác nhận bản đưa vào là bản hiện hành.

Bước 3: Thiết kế tích hợp ngoại lệ và phê duyệt

Cài các lớp chặn: ngưỡng điểm truy xuất, bước kiểm tra trích dẫn, danh sách chủ đề phải chuyển người. Kết nối công cụ tra cứu cho dữ liệu thời gian thực và định nghĩa câu trả lời khi công cụ lỗi. Các mẫu từ chối và lời chuyển nhân viên do bộ phận chăm sóc khách hàng duyệt câu chữ.

Bước 4: Kiểm thử vận hành rồi cải thiện theo log

Chạy bộ câu hỏi dụ bịa cùng bộ câu hỏi thường, chấm theo ba kết quả: trả lời đúng, từ chối đúng, bịa. Khi đã vận hành, định kỳ đọc nhật ký các câu có điểm truy xuất thấp và các câu bị khách đánh giá kém, rồi bổ sung tài liệu hoặc chỉnh ngưỡng. Mỗi lần chỉnh đều chạy lại toàn bộ bộ kiểm thử.

4. Ví dụ giả định

Chatbot không tìm thấy chính sách đổi hàng nên từ chối và chuyển nhân viên thay vì tạo ra thời hạn không tồn tại.

Từ tình huống này có thể dựng ba ca kiểm thử. Ca đầu: khách hỏi thẳng thời hạn đổi hàng khi kho kiến thức chưa có chính sách, kết quả mong đợi là từ chối và chuyển người. Ca thứ hai: khách hỏi kèm tiền đề sai, kiểu “nghe nói được đổi trong một tháng phải không”, agent không được xác nhận điều đó. Ca thứ ba: sau khi chính sách được thêm vào kho, cùng câu hỏi phải được trả lời đúng kèm trích dẫn, để chắc agent không bị kẹt mãi ở chế độ từ chối.

5. Rủi ro và giới hạn

• Không tự động hóa khi dữ liệu hoặc thẩm quyền chưa rõ
• Giới hạn quyền đọc ghi theo nhu cầu tối thiểu
• Giữ người phụ trách cho ngoại lệ và quyết định quan trọng
• Theo dõi log và kiểm thử lại sau mỗi thay đổi

Kể cả khi đã áp đủ kỹ thuật, agent vẫn có thể diễn giải sai một đoạn tài liệu đúng, nhất là với chính sách có nhiều điều kiện lồng nhau. Vì vậy các chủ đề ảnh hưởng tiền hoặc cam kết với khách nên có ngưỡng chuyển người thấp hơn các chủ đề thông tin chung. Cũng cần nhớ hướng dẫn trong prompt không phải hàng rào: khách có thể cố tình dẫn dắt agent nói điều sai, nên bước kiểm tra trích dẫn và phạm vi phải chạy ở tầng hệ thống.

6. Phân chia trách nhiệm vận hành

Bộ phận chăm sóc khách hàng sở hữu nội dung nguồn, danh sách chủ đề nhạy cảm và các mẫu từ chối; họ cũng xem lại những câu bị đánh dấu sai. Đội kỹ thuật lo truy xuất, ngưỡng, bước kiểm tra trích dẫn và tích hợp công cụ tra cứu. Người phụ trách sản phẩm hoặc chính sách báo và xác nhận mỗi khi có thay đổi cần cập nhật vào kho kiến thức.

Khi một câu bịa lọt tới khách, cần xác định nó lọt qua lớp nào: không có nguồn mà vẫn trả lời, có nguồn nhưng trích sai, hay dữ liệu thời gian thực bị thay bằng tài liệu tĩnh. Mỗi lớp có người chịu trách nhiệm sửa riêng. Với câu trả lời sai về giá hay cam kết, quản lý chăm sóc khách hàng quyết định có liên hệ lại khách để đính chính hay không.

7. Chỉ số nên theo dõi

• Tỷ lệ hoàn thành đúng theo tiêu chí đã duyệt
• Tỷ lệ từ chối đúng và chuyển người phụ trách
• Lỗi tích hợp, độ trễ và số thao tác phải sửa
• Chi phí cùng tác động kinh doanh của quy trình

Chỉ số quan trọng nhất là tỷ lệ bịa trên bộ câu hỏi dụ bịa và số câu bịa bị phát hiện trong vận hành thật, tách theo chủ đề. Nên đặt cạnh tỷ lệ từ chối: tỷ lệ bịa giảm nhưng từ chối tăng vọt thường nghĩa là ngưỡng đang quá chặt hoặc kho kiến thức còn thiếu. Theo dõi thêm tỷ lệ câu trả lời có trích dẫn hợp lệ để biết lớp kiểm tra có thực sự làm việc.

8. Checklist trước khi vận hành

• Nguồn dữ liệu và chủ sở hữu đã xác nhận
• Quyền đọc ghi đã thử với nhiều vai trò
• Có phương án khi hệ thống lỗi hoặc thiếu dữ liệu
• Có log, phê duyệt và cơ chế chống thao tác trùng
• Có bộ kiểm thử hồi quy và người vận hành

9. Câu hỏi thường gặp

Có thể giảm hallucination cho AI Agent ngay không? Một số kỹ thuật áp được nhanh, như giới hạn nguồn, thêm mẫu từ chối và chặn câu hỏi ngoài phạm vi. Ngưỡng truy xuất và bước kiểm tra trích dẫn thì cần bộ kiểm thử để chỉnh, nên phải làm cùng dữ liệu thật.

Nên bắt đầu giảm hallucination từ đâu? Bắt đầu từ các chủ đề có hậu quả lớn nhất khi sai, thường là giá, chính sách đổi trả và bảo hành. Gom nguồn chính thức cho các chủ đề này và dựng bộ câu hỏi dụ bịa trước khi chỉnh bất cứ thứ gì khác.

Khi nào câu trả lời của AI Agent cần nhân viên xem lại? Khi agent không tìm được nguồn đủ tin cậy, khi câu hỏi liên quan tiền, bảo hành hay khiếu nại, và khi khách phản đối câu trả lời. Các trường hợp này nên được chuyển nhân viên kèm đoạn hội thoại và những nguồn agent đã tìm.

Đổi sang mô hình mạnh hơn có hết hallucination không? Không. Mô hình mạnh hơn có thể bịa ít hơn, nhưng nếu thiếu nguồn, truy xuất sai hoặc không có bước kiểm tra thì vẫn sai. Nên xử lý nguồn và lớp kiểm tra trước, rồi mới cân nhắc đổi mô hình.

Kết luận

Giảm hallucination không dựa vào một câu dặn trong prompt mà vào nhiều lớp: nguồn rõ ràng, truy xuất có ngưỡng, trích dẫn được kiểm tra, từ chối đúng cách và dữ liệu thời gian thực lấy thẳng từ hệ thống. Một agent đáng tin là agent biết dừng khi không có căn cứ, và bộ câu hỏi dụ bịa là cách kiểm chứng điều đó trước khi khách phát hiện.

Trao đổi với Naventic để rà soát nguồn dữ liệu và cơ chế chặn câu trả lời thiếu căn cứ. Đọc thêm: AI Chatbot.