RAG là gì? Cách AI trả lời dựa trên tài liệu công ty

Mục lục bài viết

RAG là gì? Cách để AI trả lời dựa trên tài liệu công ty thay vì đoán mò

Hãy tưởng tượng công ty bạn có một chatbot hỗ trợ khách hàng. Một khách hỏi: “Sản phẩm này được đổi trả trong bao lâu?”

Chatbot trả lời rất tự tin: “90 ngày.”

Nghe hay đấy. Chỉ có một vấn đề nhỏ: chính sách thật là 30 ngày.

Vậy là team CSKH phải xin lỗi. Team vận hành phải xử lý ngoại lệ. Team pháp chế bắt đầu cau mày. Còn khách hàng thì nghĩ: “Công ty này mỗi nơi nói một kiểu.”

Đây là lúc RAG xuất hiện.

RAG là viết tắt của Retrieval-Augmented Generation, thường dịch là “sinh câu trả lời có tăng cường truy xuất”. Nghe hơi học thuật, nhưng ý tưởng rất đời thường: trước khi trả lời, AI phải đi tìm thông tin trong nguồn đáng tin cậy.

AWS định nghĩa RAG là quá trình tối ưu đầu ra của LLM bằng cách để mô hình tham chiếu một kho tri thức có thẩm quyền bên ngoài dữ liệu huấn luyện trước khi sinh câu trả lời.

Vấn đề của LLM thuần: giỏi nói, nhưng không tự biết tài liệu nội bộ

LLM có thể viết rất mượt. Nhưng nếu không được kết nối với dữ liệu công ty, nó không tự biết:

• Chính sách bảo hành mới nhất.
• Bảng giá đang áp dụng.
• Quy trình nghỉ phép nội bộ.
• Tài liệu onboarding nhân viên.
• Điều khoản hợp đồng.
• FAQ sản phẩm.
• Hướng dẫn xử lý ticket.

Nếu bạn hỏi một câu mà mô hình không có dữ liệu, nó có thể nói chung chung, nói cũ, hoặc tệ hơn: đoán.

RAG như một lựa chọn giữa prompt trực tiếp và fine-tuning, đặc biệt hữu ích khi doanh nghiệp muốn AI dùng dữ liệu thật mà không phải nhồi toàn bộ tài liệu vào prompt hoặc huấn luyện lại mô hình.

Ẩn dụ: AI không chỉ là người viết, nó cần một thủ thư

Hãy hình dung hệ thống RAG gồm ba vai:

1. Thư viện: kho tài liệu công ty.
2. Thủ thư: bộ phận tìm đoạn tài liệu liên quan.
3. Người viết: LLM dùng đoạn tài liệu đó để trả lời.

Nếu không có thủ thư, người viết có thể viết bằng trí nhớ mơ hồ. Có thủ thư, người viết phải dựa vào sách đang mở trước mặt.

Đó là điểm mạnh của RAG: đưa thông tin liên quan vào đúng lúc AI cần trả lời.

RAG hoạt động theo cách nào?

Một hệ thống RAG thường có hai phần: chuẩn bị tài liệu và trả lời câu hỏi.

Phần 1: Chuẩn bị thư viện

Tài liệu được gom lại từ PDF, Google Docs, website, wiki nội bộ, file chính sách, tài liệu sản phẩm.

Sau đó hệ thống sẽ:

• Làm sạch văn bản.
• Chia tài liệu thành các đoạn nhỏ.
• Chuyển từng đoạn thành vector/embedding.
• Lưu vào vector database hoặc hệ thống tìm kiếm phù hợp.

Phần 2: Người dùng đặt câu hỏi

Khi người dùng hỏi, hệ thống không đưa câu hỏi thẳng cho LLM trả lời ngay.

Nó sẽ:

• Chuyển câu hỏi thành embedding.
• Tìm các đoạn tài liệu gần nghĩa nhất.
• Đưa các đoạn này vào prompt.
• Yêu cầu LLM trả lời dựa trên tài liệu được cung cấp.

AWS Prescriptive Guidance mô tả RAG như cách bổ sung dữ liệu bên ngoài, ví dụ tài liệu nội bộ của công ty, để mô hình có ngữ cảnh cần thiết cho một use case cụ thể.

Mini case: Chatbot nội bộ cho phòng nhân sự

Một công ty công nghệ ở Hà Nội có hơn 500 nhân viên. Mỗi tháng HR nhận hàng trăm câu hỏi:

• Nghỉ phép năm tính thế nào?
• Làm remote tối đa bao nhiêu ngày?
• Quy trình xin thiết bị mới ra sao?
• Bảo hiểm bổ sung gồm những gì?
• Nhân viên thử việc có được hưởng chính sách nào?

Trước đây, câu trả lời nằm trong nhiều file: handbook, email cập nhật, Google Drive, Notion, phụ lục chính sách.

Nếu dùng chatbot LLM thuần, rủi ro là nó trả lời theo “kiểu phổ biến” chứ không theo chính sách thật của công ty.

Team IT và HR xây một RAG nhỏ:

• Tập hợp tài liệu chính sách đã duyệt.
• Gắn owner cho từng nhóm tài liệu.
• Chia tài liệu thành đoạn nhỏ có tiêu đề rõ.
• Cập nhật version mỗi khi chính sách thay đổi.
• Chatbot chỉ trả lời dựa trên đoạn được truy xuất.
• Nếu không tìm thấy nguồn, chatbot nói “chưa có thông tin trong tài liệu hiện có”.

Kết quả: HR không bị hỏi đi hỏi lại các câu cơ bản, nhân viên có câu trả lời nhanh hơn, và quan trọng nhất là câu trả lời có nguồn để kiểm tra.

Khi nào nên dùng RAG?

RAG đặc biệt hợp khi:

• Dữ liệu thay đổi thường xuyên.
• Cần trả lời theo tài liệu nội bộ.
• Cần truy vết nguồn.
• Không muốn hoặc chưa thể fine-tune mô hình.
• Use case chủ yếu là hỏi đáp, tra cứu, tóm tắt dựa trên tài liệu.
• Cần kiểm soát câu trả lời theo nguồn đã duyệt.

Ví dụ:

• Chatbot CSKH dựa trên chính sách sản phẩm.
• Trợ lý HR dựa trên handbook nội bộ.
• Trợ lý sales tra cứu bảng giá, case study, proposal mẫu.
• Trợ lý pháp chế tìm điều khoản trong hợp đồng.
• Trợ lý IT trả lời theo tài liệu vận hành.

RAG khác gì fine-tuning?

RAG giống việc cho AI mở tài liệu đúng lúc trả lời.

Fine-tuning giống việc dạy thêm cho mô hình một cách hành xử hoặc một loại nhiệm vụ cụ thể.

Nếu dữ liệu của bạn thay đổi hằng tuần, RAG thường hợp hơn. Nếu bạn cần mô hình bắt chước một phong cách rất đặc thù hoặc xử lý một nhiệm vụ chuyên sâu theo mẫu, fine-tuning có thể đáng cân nhắc.

Phân biệt RAG và fine-tuning: RAG truy xuất dữ liệu bên ngoài mà không thay đổi tham số lõi của mô hình, còn fine-tuning huấn luyện thêm để điều chỉnh hành vi mô hình.

Checklist: Doanh nghiệp đã sẵn sàng làm RAG chưa?

[ ] Tài liệu nguồn có owner rõ ràng?
[ ] Tài liệu đã được cập nhật và loại bỏ bản cũ?
[ ] Có phân quyền ai được xem tài liệu nào?
[ ] Có quy tắc xử lý dữ liệu nhạy cảm?
[ ] Tài liệu có cấu trúc tiêu đề, mục, ngày hiệu lực rõ?
[ ] Có tiêu chí đánh giá câu trả lời đúng/sai?
[ ] Có yêu cầu chatbot trích nguồn?
[ ] Có quy trình cập nhật khi chính sách thay đổi?
[ ] Có người chịu trách nhiệm kiểm thử định kỳ?

Nếu tài liệu nội bộ đang rối, RAG sẽ không tự biến nó thành gọn. RAG không chữa bệnh “quản lý tri thức kém”. Nó chỉ phóng đại chất lượng của thư viện bạn có.

Một prompt RAG nên có rào chắn

Khi xây chatbot hoặc trợ lý tài liệu, prompt hệ thống nên có các nguyên tắc như:

Chỉ trả lời dựa trên tài liệu được cung cấp.
Nếu tài liệu không chứa câu trả lời, nói rõ rằng chưa tìm thấy thông tin.
Không suy đoán chính sách.
Luôn trích nguồn tài liệu, tên mục hoặc ngày hiệu lực nếu có.
Nếu câu hỏi có thể liên quan dữ liệu nhạy cảm, yêu cầu người dùng liên hệ bộ phận phụ trách.

Rào chắn này không hoàn hảo, nhưng tốt hơn nhiều so với việc để AI trả lời tự do.

Kết luận

1. RAG giúp AI trả lời dựa trên nguồn tri thức được truy xuất, không chỉ dựa vào mẫu đã học.
2. RAG đặc biệt hữu ích cho dữ liệu nội bộ, chính sách, FAQ, tài liệu sản phẩm và knowledge base.
3. Một hệ thống RAG cần thư viện tốt, truy xuất tốt, prompt tốt và kiểm thử tốt.
4. RAG không thay thế hoàn toàn fine-tuning; hai kỹ thuật phục vụ mục tiêu khác nhau.
5. RAG giảm hallucination nhưng không loại bỏ hoàn toàn rủi ro.