Tóm tắt: Chatbot RAG thường dừng ở PoC (bản chạy thử) vì chưa ai đo được nó đúng đến đâu. Muốn lên bản chạy thật, cần chuẩn bị tài liệu, chia đoạn hợp lý, lập bộ câu hỏi thật có đáp án để đo, thiết kế cách trả lời "không biết", phân quyền và duy trì vòng cải tiến sau khi chạy.
Mục lục
- Vì sao chatbot RAG chạy tốt lúc demo nhưng dừng ở PoC?
- Độ chính xác của RAG hỏng ở khâu nào?
- Tài liệu cần chuẩn bị gì trước khi nạp vào chatbot?
- Bộ câu hỏi đánh giá nên làm thế nào?
- Chatbot nên làm gì khi không biết câu trả lời?
- Sau khi chạy thật, vòng vận hành gồm những gì?
- Khi nào chưa nên đưa chatbot RAG lên bản chạy thật?
1. Vì sao chatbot RAG chạy tốt lúc demo nhưng dừng ở PoC?
Chatbot RAG (tìm đoạn tài liệu liên quan rồi để AI soạn câu trả lời dựa trên đó) thường dừng ở PoC vì buổi demo dùng vài câu hỏi đã chọn sẵn, còn người dùng thật hỏi những câu chưa ai nghĩ tới. Khi nhân viên bắt đầu dùng, vài câu trả lời sai lọt ra, và lúc đó không ai trả lời được câu hỏi "nó đúng bao nhiêu phần trăm".
Không có con số, hội đồng duyệt không có gì để ký. Người phụ trách thì chỉ còn cách sửa từng câu sai theo cảm tính, và mỗi lần sửa lại không biết có làm hỏng câu khác không. Dự án dễ kéo dài vài tháng rồi chìm xuống.
Đổi mô hình AI thường không phải bước đầu tiên. Bước đầu tiên là đặt thước đo, rồi sửa đúng khâu đang hỏng.
2. Độ chính xác của RAG hỏng ở khâu nào?
Độ chính xác của chatbot RAG hỏng ở một trong hai khâu: tìm sai đoạn tài liệu, hoặc có đoạn đúng nhưng AI diễn đạt sai. Hai lỗi này cần hai cách sửa khác nhau, nên phải phân biệt được trước khi chỉnh bất cứ thứ gì.
| Triệu chứng | Nguyên nhân thường gặp | Hướng xử lý |
|---|---|---|
| Trả lời lấy từ tài liệu sai hoặc bản cũ | Nhiều phiên bản tài liệu cùng nằm trong kho; thiếu ngày hiệu lực | Dọn kho tài liệu, gắn phiên bản và ngày hiệu lực |
| Không tìm ra đoạn có sẵn trong tài liệu | Cách chia đoạn cắt rời ý; câu hỏi dùng từ khác với tài liệu | Chia đoạn theo cấu trúc, kết hợp tìm theo từ khoá và theo ngữ nghĩa |
| Bảng, biểu mẫu trả lời sai số | PDF dạng ảnh hoặc bảng bị tách nát khi đọc | Chuyển bảng sang dạng có cấu trúc trước khi nạp |
| Có đoạn đúng nhưng câu trả lời sai ý | Đoạn bị cắt dở; câu hỏi cần ghép nhiều đoạn | Chia đoạn lại, giới hạn cách AI được phép suy diễn |
| Trả lời tự tin dù tài liệu không có | Không có quy tắc "không biết" | Thiết kế ngưỡng và câu từ chối (mục 5) |
Bảng cho thấy phần nhiều triệu chứng bắt nguồn từ tài liệu và tìm kiếm. Chỉnh câu lệnh cho AI chỉ giải quyết được phần còn lại.
3. Tài liệu cần chuẩn bị gì trước khi nạp vào chatbot?
Tài liệu cần được chọn, làm sạch và gắn thông tin trước khi nạp vào chatbot RAG, vì chatbot chỉ giỏi bằng tài liệu nó đọc. Việc này dễ bị cắt bớt để kịp tiến độ PoC, và kết quả là chatbot đọc tài liệu rác.
- Chọn nguồn đúng. Mỗi chủ đề nên có một tài liệu gốc. Bản nháp, bản cũ và bản sao chép qua email cần bị loại khỏi kho.
- Xử lý định dạng khó. PDF scan, bảng nhiều ô gộp, chú thích trong hình, slide chỉ có sơ đồ đều dễ bị đọc sai. Nên mở thử từng loại và xem hệ thống đọc ra gì.
- Chia đoạn (chunking) theo ý. Chia theo đề mục và điều khoản thường tốt hơn chia theo số ký tự cố định. Một điều khoản bị cắt làm đôi sẽ cho ra đoạn nửa đúng nửa thiếu.
- Gắn thông tin đi kèm. Phiên bản, ngày hiệu lực, phòng ban, mức mật. Các thông tin này vừa giúp loại tài liệu cũ vừa là nền cho phân quyền.
- Quyết ai sở hữu tài liệu. Khi quy chế đổi, ai cập nhật kho? Nếu không có tên người, chatbot sẽ trả lời theo quy chế đã hết hiệu lực.
Mục 5 dễ bị quên nhất, và cũng là lý do khiến một chatbot đúng lúc ra mắt trở nên sai sau vài tháng.
4. Bộ câu hỏi đánh giá nên làm thế nào?
Bộ đánh giá nên gồm 50 đến 100 câu hỏi thật của người dùng, mỗi câu có đáp án và tài liệu nguồn do người trong nghiệp vụ xác nhận. Đây là cách VAON đề xuất cho PoC chatbot, vì nó biến "có vẻ ổn" thành con số có thể ký duyệt.
Cách lập bộ câu hỏi:
- Lấy câu hỏi từ thực tế. Email hỏi đáp nội bộ, lịch sử gọi tổng đài, câu nhân viên hay hỏi bộ phận hành chính. Đừng để đội dự án tự nghĩ ra, vì họ sẽ hỏi theo cách tài liệu viết.
- Gồm nhiều loại. Câu tra cứu một sự kiện, câu cần ghép hai tài liệu, câu hỏi bằng cách nói khác với tài liệu, và cả câu mà tài liệu không có đáp án.
- Người nghiệp vụ viết đáp án. Không phải người làm kỹ thuật.
- Chốt tiêu chí đạt trước khi chạy. Ví dụ ngưỡng tỷ lệ đúng nào thì cho lên bản chạy thật. Con số do khách và VAON thống nhất, không có ngưỡng chung cho mọi dự án.
Khi đo, tách ba chỉ số: tìm có ra đúng đoạn không, câu trả lời có đúng không, và với câu không có đáp án thì chatbot có từ chối đúng không. Tách như vậy mới biết sửa tài liệu hay sửa cách trả lời.
Một ví dụ về cách nêu kết quả. VAON từng làm dự án tự động hoá xử lý tài liệu cho một công ty dịch vụ web tại Nhật (ẩn danh): công thủ công giảm 20 đến 35%, độ chính xác 85 đến 92%. Đây là dự án xử lý tài liệu, không phải chatbot RAG, nên không dùng làm mốc cho chatbot. Điều đáng giữ lại là cách nêu: kết quả là một khoảng, gắn với một tập dữ liệu cụ thể, chứ không phải một con số tròn cho mọi trường hợp. Chatbot của bạn cũng nên được báo cáo như vậy.
5. Chatbot nên làm gì khi không biết câu trả lời?
Chatbot RAG nên nói thẳng là không tìm thấy thông tin và chỉ đường tới người hoặc tài liệu liên quan, thay vì đoán. Một câu "tôi chưa tìm thấy, bạn hỏi phòng nhân sự nhé" ít gây hại hơn nhiều so với một câu trả lời sai nói bằng giọng chắc chắn.
Để làm được, cần thiết kế từ đầu:
- Quy định ngưỡng: khi các đoạn tìm được không đủ liên quan, chatbot từ chối thay vì cố trả lời.
- Hiển thị nguồn: mỗi câu trả lời nêu tài liệu và mục đã dùng, để người dùng tự kiểm.
- Có đường chuyển người: câu từ chối kèm nơi hỏi tiếp.
- Đưa câu "không biết" vào bộ đánh giá, để đo cả việc từ chối đúng lúc.
Phân quyền cũng thuộc phần này. Chatbot chỉ nên tìm trong những tài liệu mà người hỏi được phép xem, và việc lọc phải diễn ra ở bước tìm kiếm, không chỉ ở giao diện. Chatbot trả lời đúng nhưng cho nhầm người xem tài liệu nội bộ vẫn là chatbot không dùng được. Tài liệu bị cài chỉ dẫn độc cũng là một rủi ro riêng, đã nêu ở bài prompt injection và tấn công vào hệ thống RAG. Về điều khoản dữ liệu của dịch vụ chatbot, xem bài RAG khác huấn luyện ở đâu và cần kiểm tra gì.
6. Sau khi chạy thật, vòng vận hành gồm những gì?
Sau khi chạy thật, vòng vận hành của chatbot RAG gồm bốn việc lặp lại: thu thập câu hỏi thật, xem lại các câu trả lời sai hoặc bị từ chối, sửa tài liệu hoặc cách tìm, rồi chạy lại bộ đánh giá. Bỏ vòng này, độ chính xác sẽ giảm dần khi tài liệu đổi.
- Thu thập. Ghi lại câu hỏi người dùng thật và lượt đánh giá "hữu ích / không hữu ích".
- Xem lại. Mỗi tuần hoặc mỗi tháng, người nghiệp vụ đọc các câu bị đánh giá thấp và các câu bị từ chối.
- Sửa đúng chỗ. Thiếu tài liệu thì bổ sung, tài liệu cũ thì thay, cách chia đoạn sai thì chia lại. Đổi mô hình thường là phương án sau cùng.
- Đo lại. Thêm các câu hỏi mới vào bộ đánh giá, chạy lại toàn bộ để chắc sửa chỗ này không làm hỏng chỗ khác.
Câu hỏi thật là dữ liệu quý nhất của bạn. Sau vài vòng, bộ đánh giá phản ánh người dùng của bạn tốt hơn mọi bộ câu hỏi lập ở giai đoạn PoC.
7. Khi nào chưa nên đưa chatbot RAG lên bản chạy thật?
Chưa nên đưa chatbot RAG lên bản chạy thật khi tài liệu nguồn chưa ổn định, chưa có người sở hữu, hoặc câu trả lời sai gây hậu quả mà chưa có người kiểm tra. Lúc đó, việc đầu tiên là sửa tài liệu, không phải sửa chatbot.
Một số trường hợp cần cân nhắc kỹ: chatbot trả lời về điều khoản pháp lý, y tế, hay quyết định có tác động tài chính trực tiếp. RAG giảm câu trả lời bịa nhưng không loại bỏ hoàn toàn, nên các nội dung này cần người xác nhận trước khi tới tay người dùng. Nếu dữ liệu không được ra khỏi mạng nội bộ, cần xét phương án khác, xem chatbot RAG chạy trong mạng nội bộ. Phần dịch vụ AI của VAON nằm ở trang tự động hoá và AI.
Chatbot RAG của bạn đang dừng ở PoC và chưa biết sửa từ đâu? Mang vài chục câu hỏi thật và vài tài liệu mẫu tới buổi trao đổi đầu tiên. Có CEO của VAON tham dự, không ràng buộc. Đặt lịch trao đổi 60 phút miễn phí
Tài liệu tham khảo
- Lewis, P. et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020: https://arxiv.org/abs/2005.11401
