RAG là gì? Cách AI trả lời dựa trên tài liệu doanh nghiệp

Nhân viên hỏi chatbot chính sách đổi hàng. Câu trả lời rất rõ, có cả thời hạn và điều kiện. Nhưng mở tài liệu ra, bạn thấy nó đang dùng bản đã thay từ tháng trước. Vấn đề không phải câu chữ khó hiểu. Công cụ đã trả lời trôi chảy từ thông tin không còn đúng với công việc hiện tại.

RAG là cách kết hợp tìm tài liệu với mô hình ngôn ngữ để tạo câu trả lời dựa trên thông tin được lấy ra. Nó có thể giúp AI dùng tài liệu của doanh nghiệp mà không chỉ dựa vào kiến thức sẵn có. Tuy vậy, kết quả còn phụ thuộc nguồn, cách tìm và quyền truy cập. Nối một thư mục vào chatbot chưa tự tạo ra một nơi hỏi đáp đáng tin.

RAG làm gì trong một lượt hỏi?

Giả sử cửa hàng của Linh có nhiều hướng dẫn về đổi hàng. Khi nhân viên hỏi một tình huống, hệ thống RAG tìm các đoạn liên quan, đưa chúng vào ngữ cảnh rồi để mô hình soạn câu trả lời. Người dùng có thể được dẫn tới nguồn nếu ứng dụng thiết kế phần đó.

Tài liệu Microsoft về RAG mô tả đây là mẫu kết hợp tìm kiếm với mô hình ngôn ngữ để câu trả lời dựa trên dữ liệu. Hiểu điểm này giúp bạn đặt đúng câu hỏi khi thử: hệ thống đã tìm được đoạn cần thiết chưa, và câu trả lời có bám đúng đoạn ấy không?

Hai bước có thể lỗi theo hai cách khác nhau. Hệ thống tìm nhầm chính sách cũ thì mô hình có thể diễn đạt rất đúng một nguồn sai thời điểm. Hệ thống tìm đúng nguồn nhưng mô hình bỏ mất điều kiện cũng cho kết quả không dùng được. Vì vậy, chỉ đọc câu cuối thấy hợp lý chưa đủ để đánh giá cả quy trình.

RAG không đồng nghĩa mô hình đã được huấn luyện lại bằng toàn bộ tài liệu. Trong cách hoạt động đang nói tới, tài liệu được tìm và cung cấp cho lượt trả lời. Điều này giúp cập nhật nguồn theo quy trình riêng, nhưng bạn vẫn cần kiểm việc cập nhật đã tới hệ thống tìm kiếm chưa. Sửa một file gốc không bảo đảm mọi thành phần đã nhìn thấy bản mới ngay.

Chuẩn bị tài liệu trước khi kết nối

Trước khi kết nối, Linh gom các bản chính sách và phát hiện ba tài liệu gần giống nhau. Một bản đang áp dụng, một bản cũ và một bản nháp chưa duyệt. Nếu đưa tất cả vào mà không có thông tin phân biệt, hệ thống có thể lấy một đoạn nghe phù hợp nhưng chưa đúng trạng thái. Việc dọn nguồn cần diễn ra trước kỳ vọng về câu trả lời thông minh.

Mỗi tài liệu nên có người phụ trách, trạng thái và phạm vi áp dụng rõ. Ngày cập nhật có ích, nhưng chưa đủ nếu bản mới chỉ dành cho một nhóm sản phẩm. Ghi điều kiện trong nội dung theo cách có thể tìm và hiểu. Đừng để một ngoại lệ quan trọng chỉ nằm trong tên thư mục hoặc lời nhắn riêng mà hệ thống không nhận được.

Chia tài liệu thành các phần có ý nghĩa giúp việc lấy đoạn tham khảo hữu ích hơn. Phần trích cần giữ đủ điều kiện liên quan, tránh chỉ lấy câu kết luận tách khỏi ngoại lệ. Đây là việc nhóm kỹ thuật cần thử với cấu trúc dữ liệu thật. Người nghiệp vụ có thể giúp bằng cách chỉ ra những đoạn nào phải được đọc cùng nhau để tránh hiểu sai.

Ảnh scan, bảng và tài liệu nhiều cột có thể cần kiểm riêng cách đọc nội dung. Đừng mặc định thấy file được tải lên là chữ đã được hiểu đúng. Lấy vài câu hỏi có đáp án nằm trong những phần khó và đối chiếu nguồn. Nếu dữ liệu đầu vào bị đọc thiếu, việc sửa prompt ở bước trả lời có thể không giải quyết nguyên nhân.

Quyền truy cập vẫn phải theo người dùng

Tài liệu có trong doanh nghiệp không có nghĩa mọi nhân viên đều được xem. Hệ thống cần giới hạn phần tìm được theo quyền của người hỏi và quy trình của đơn vị. Hướng dẫn RAG của Azure AI Search cũng đặt kiểm soát truy cập trong phần bảo mật và quản trị. Quyền cần được thực thi ở hệ thống, không chỉ nhắc bằng một câu trong prompt.

Trong ví dụ của Linh, nhân viên bán hàng được xem chính sách phục vụ khách nhưng không được xem ghi chú riêng về nhân sự. Nhóm thử bằng các tài khoản có quyền khác nhau, không chỉ tài khoản quản trị. Một bản demo chạy bằng quyền rộng nhất có thể che mất vấn đề sẽ xuất hiện khi triển khai cho nhiều vai trò.

Kiểm cả lúc quyền thay đổi hoặc tài liệu bị thu hồi. Hệ thống có còn trả lời từ đoạn đã không còn được phép xem không? Nhóm kỹ thuật cần có cách cập nhật và kiểm phù hợp. Không nên dựa vào việc ẩn link trong giao diện nếu nội dung vẫn có thể xuất hiện trong câu trả lời.

Nội dung nguồn cũng có thể chứa chỉ dẫn không nên được thực hiện. Tài liệu tham khảo phải được xử lý như dữ liệu theo thiết kế phù hợp. Nếu chatbot được nối thêm công cụ có quyền hành động, rủi ro cần được xem rộng hơn hỏi đáp. Bài prompt injection và giới hạn của lời nhắc giải thích vì sao nguồn bên ngoài có thể làm lệch hành vi.

Đo chất lượng bằng câu hỏi công việc thật

Linh lấy câu hỏi từ những việc nhân viên thường gặp, rồi thêm các trường hợp thiếu thông tin và có ngoại lệ. Mỗi câu có nguồn đúng, điều kiện cần nêu và phần không được tự suy ra. Cô chuẩn bị đáp án tham chiếu trước khi xem câu trả lời của chatbot. Nhờ vậy, nhóm không bị một đoạn viết mượt kéo lệch tiêu chí đánh giá.

Kiểm hệ thống có biết nói thiếu căn cứ khi tài liệu chưa trả lời được không. Một câu trả lời có vẻ đầy đủ nhưng tự thêm điều kiện sẽ gây công sửa và có thể dẫn người dùng làm sai. Cần xác định khi nào hỏi lại, khi nào dẫn nguồn và khi nào chuyển tới người phụ trách. Những hành vi này nên được thử bằng tình huống thật của công việc.

Nếu câu trả lời có dẫn nguồn, mở nguồn để đối chiếu. Có link chưa chứng minh đoạn được dẫn hỗ trợ đúng kết luận. Kiểm cả điều kiện bị bỏ sót và phạm vi áp dụng. Bài đánh giá AI theo nhiệm vụ giúp nhóm ghi lỗi theo ảnh hưởng, thay vì chỉ chấm câu nào nghe tự nhiên hơn.

Khi nào RAG hợp, khi nào nên chọn cách khác?

RAG phù hợp để cân nhắc khi câu trả lời cần dựa trên kho tài liệu có thể quản lý và tìm lại. Nếu nhu cầu chỉ là xem một bảng quy định ngắn, một trang hướng dẫn rõ hoặc ô tìm kiếm tốt có thể đã đủ. Chọn cách làm theo việc người dùng cần hoàn thành, không theo cảm giác rằng mọi kho tài liệu đều cần chatbot.

Với yêu cầu cần tính toán, quyết định hoặc thao tác trên hệ thống, chỉ tìm tài liệu rồi soạn chữ có thể chưa đủ. Nhóm phải thiết kế thêm các bước kiểm và quyền phù hợp. Đừng mở rộng từ demo hỏi đáp sang tự xử lý công việc mà chưa đánh giá lại. Mỗi quyền mới làm thay đổi điều cần theo dõi và người chịu trách nhiệm.

Một hệ thống RAG dùng được cần được chăm cả nguồn lẫn kết quả. Có người cập nhật tài liệu, có bộ câu hỏi kiểm và có nơi báo câu trả lời sai. Khi nhân viên hỏi chính sách đổi hàng, điều họ cần là thông tin đúng để làm tiếp. Nguồn, quyền và bước kiểm cần rõ như câu trả lời.