Xây dựng ứng dụng hỏi đáp với RAG: những bước thực tế để tránh câu trả lời sai

Trong các dự án dùng mô hình ngôn ngữ lớn, một nhu cầu rất phổ biến là xây dựng hệ thống hỏi đáp dựa trên tài liệu nội bộ: quy trình công ty, tài liệu kỹ thuật, hướng dẫn sản phẩm, hợp đồng mẫu hoặc kho tri thức chăm sóc khách hàng. Cách tiếp cận thường gặp là RAG, viết tắt của Retrieval-Augmented Generation: truy xuất thông tin liên quan trước, sau đó đưa vào mô hình để sinh câu trả lời. RAG hấp dẫn vì không nhất thiết phải huấn luyện lại mô hình. Tuy nhiên, nếu triển khai vội, hệ thống vẫn có thể trả lời sai, trích dẫn nhầm hoặc “nói rất tự tin” về nội dung không có trong tài liệu. Dưới đây là một quy trình thực tế để xây dựng RAG tốt hơn. 1. Bắt đầu từ dữ liệu, không phải từ mô hình Nhiều nhóm chọn mô hình trước rồi mới gom tài liệu sau. Cách làm này dễ dẫn đến kết quả kém vì chất lượng dữ liệu quyết định phần lớn chất lượng câu trả lời. Hãy rà soát các điểm sau: - Tài liệu có bị trùng lặp nhiều không? - Có phiên bản cũ và mới mâu thuẫn nhau không? - File PDF scan có lỗi OCR không? - Tiêu đề, mục lục, bảng biểu có bị mất cấu trúc khi trích xuất văn bản không? - Có thông tin nhạy cảm không nên đưa vào hệ thống không? Ví dụ: nếu tài liệu chính sách hoàn tiền có 3 phiên bản khác nhau, hệ thống có thể truy xuất nhầm phiên bản cũ và trả lời sai. Trước khi nghĩ đến embedding hay vector database, hãy chuẩn hóa tên tài liệu, ngày hiệu lực và loại bỏ bản lỗi thời. 2. Chia nhỏ tài liệu đúng cách Một lỗi phổ biến là cắt văn bản thành các đoạn có độ dài cố định mà không quan tâm ngữ cảnh. Nếu cắt giữa chừng một điều khoản, mô hình có thể nhận được đoạn thiếu ý và suy diễn thêm. Gợi ý thực tế: - Ưu tiên chia theo tiêu đề, mục, điều khoản, câu hỏi thường gặp. - Giữ metadata như tên tài liệu, ngày cập nhật, phòng ban, đường dẫn nguồn. - Dùng overlap vừa phải giữa các đoạn để không mất ngữ cảnh. - Với bảng biểu, nên chuyển thành dạng văn bản rõ nghĩa thay vì chỉ nối các ô tùy tiện. Ví dụ, thay vì chia “Chính sách bảo hành” thành các đoạn 500 ký tự, nên chia theo các mục như “Thời hạn bảo hành”, “Trường hợp không được bảo hành”, “Quy trình gửi sản phẩm”. Khi người dùng hỏi “sản phẩm rơi vỡ có được bảo hành không?”, hệ thống dễ truy xuất đúng mục liên quan. 3. Thiết kế truy xuất theo câu hỏi thật Đừng chỉ kiểm thử bằng vài câu hỏi mẫu quá sạch. Người dùng thường hỏi thiếu từ khóa, dùng từ đồng nghĩa hoặc diễn đạt theo ngôn ngữ đời thường. Ví dụ tài liệu ghi “hủy đơn hàng”, nhưng người dùng hỏi “mình lỡ đặt nhầm thì bỏ được không?”. Nếu chỉ tìm kiếm từ khóa, hệ thống có thể bỏ sót. Đây là lý do embedding hữu ích: nó giúp tìm theo ngữ nghĩa, không chỉ theo chuỗi ký tự. Tuy vậy, embedding không phải phép màu. Với các trường hợp cần mã sản phẩm, số điều khoản, ngày tháng, tên riêng, bạn nên cân nhắc kết hợp: - Tìm kiếm ngữ nghĩa bằng vector. - Tìm kiếm từ khóa truyền thống. - Bộ lọc metadata, ví dụ chỉ lấy tài liệu còn hiệu lực. - Reranking để sắp xếp lại các đoạn được truy xuất. 4. Yêu cầu mô hình trả lời dựa trên nguồn Prompt cho RAG nên đặt ranh giới rõ ràng. Thay vì chỉ nói “hãy trả lời câu hỏi”, nên yêu cầu mô hình: - Chỉ dùng thông tin trong các đoạn tài liệu được cung cấp. - Nếu không đủ thông tin, nói rõ là không tìm thấy căn cứ. - Trích dẫn tên tài liệu hoặc mục liên quan nếu có. - Không tự bịa chính sách, con số, cam kết. Một mẫu chỉ dẫn đơn giản có thể là: “Bạn là trợ lý trả lời dựa trên tài liệu nội bộ. Chỉ sử dụng phần ngữ cảnh bên dưới. Nếu ngữ cảnh không đủ để kết luận, hãy nói rằng chưa có thông tin trong tài liệu được cung cấp.” 5. Đánh giá bằng bộ câu hỏi kiểm thử RAG không nên được đánh giá chỉ bằng cảm giác. Hãy tạo một bộ câu hỏi kiểm thử gồm: - Câu hỏi có câu trả lời rõ trong tài liệu. - Câu hỏi cần tổng hợp từ nhiều đoạn. - Câu hỏi gây nhiễu, dùng cách diễn đạt khác. - Câu hỏi không có đáp án trong tài liệu. - Câu hỏi liên quan đến phiên bản cũ và mới. Với mỗi câu hỏi, ghi lại câu trả lời mong muốn và nguồn đúng. Khi thay đổi cách chia đoạn, mô hình embedding hoặc prompt, bạn có thể chạy lại bộ kiểm thử để xem hệ thống tốt lên hay tệ đi. 6. Theo dõi lỗi sau khi đưa vào sử dụng Khi triển khai thật, hãy lưu các thông tin cần thiết để cải tiến: câu hỏi người dùng, đoạn tài liệu được truy xuất, câu trả lời, phản hồi đúng/sai nếu có. Lưu ý cần xử lý dữ liệu cá nhân và thông tin nhạy cảm một cách cẩn trọng. Các lỗi thường gặp gồm: - Truy xuất sai tài liệu. - Truy xuất đúng nhưng mô hình diễn giải sai. - Tài liệu gốc thiếu hoặc lỗi thời. - Người dùng hỏi ngoài phạm vi hệ thống. Mỗi loại lỗi cần cách xử lý khác nhau. Nếu truy xuất sai, hãy xem lại chunking, embedding, metadata hoặc reranking. Nếu truy xuất đúng nhưng trả lời sai, hãy chỉnh prompt hoặc định dạng ngữ cảnh. Nếu tài liệu thiếu, vấn đề nằm ở quy trình quản trị tri thức, không phải ở mô hình. Kết luận RAG là một hướng tiếp cận thực tế để đưa mô hình ngôn ngữ lớn vào doanh nghiệp và sản phẩm phần mềm. Nhưng chất lượng không đến từ việc “gắn LLM vào vector database” một cách đơn giản. Một hệ thống tốt cần dữ liệu sạch, chia đoạn hợp lý, truy xuất có kiểm soát, prompt rõ ràng và đánh giá liên tục. Nếu bạn mới bắt đầu, lời khuyên là hãy làm nhỏ: chọn một bộ tài liệu hẹp, tạo khoảng vài chục câu hỏi kiểm thử, triển khai pipeline đơn giản rồi đo lỗi. Khi đã hiểu hệ thống sai ở đâu, việc tối ưu mô hình hay hạ tầng sẽ có cơ sở hơn nhiều.