RAG là gì? Cách xây chatbot hỏi đáp tài liệu mà bớt bịa
RAG giúp AI tìm tài liệu liên quan trước khi trả lời. Hướng dẫn này giải thích cách hoạt động, trường hợp nên dùng, lỗi thường gặp và checklist triển khai.
Bởi Võ Danh — 13 Tháng 9, 2026 trong Công nghệ
Bạn hỏi chatbot nội bộ: “Nhân viên thử việc được nghỉ phép thế nào?” Nó trả lời rất mượt, đúng ngữ pháp, còn xuống dòng đẹp như văn mẫu. Chỉ có một vấn đề nhỏ: quy định ấy không tồn tại trong sổ tay nhân sự. Đây là kiểu sai khiến người dùng vừa bực vừa khó phát hiện, vì câu trả lời nghe quá hợp lý.
RAG được dùng để xử lý đúng bài toán này. Thay vì bắt mô hình ngôn ngữ trả lời hoàn toàn bằng những gì nó đã học, hệ thống tìm thông tin trong kho dữ liệu đã chọn, đưa các đoạn liên quan vào câu hỏi rồi mới yêu cầu mô hình soạn câu trả lời. Bài viết này giải thích RAG là gì, nó chạy ra sao, khác gì với huấn luyện lại mô hình và cách làm một bản thử nghiệm không biến thành dự án “chat với PDF” kéo dài vô tận.
Nói trước cho đỡ hụt hẫng: RAG không phải thuốc trị bách bệnh cho AI bịa. Nó giúp câu trả lời bám dữ liệu hơn, nhưng dữ liệu sai, tìm kiếm dở hoặc phân quyền ẩu thì kết quả vẫn sai. Máy chỉ làm rất nhanh điều ta cấu hình cho nó, kể cả cấu hình nhầm.
RAG là gì?
RAG là viết tắt của Retrieval-Augmented Generation, có thể hiểu là “sinh câu trả lời có bổ sung bước truy xuất”. Nhóm tác giả tại Facebook AI Research, University College London và New York University trình bày kiến trúc này trong bài báo được gửi lên arXiv năm 2020. Theo phần giải thích của AWS, hệ thống tham chiếu một kho kiến thức có thẩm quyền nằm ngoài dữ liệu huấn luyện của mô hình trước khi tạo câu trả lời.
Có hai việc tách biệt ở đây. Việc thứ nhất là tìm: hệ thống chọn những đoạn tài liệu có khả năng chứa đáp án. Việc thứ hai là viết: mô hình ngôn ngữ đọc câu hỏi cùng các đoạn vừa tìm được để soạn câu trả lời. Nếu thiết kế tốt, câu trả lời còn gắn liên kết hoặc trích dẫn để người đọc mở tài liệu gốc và kiểm tra.
Hãy hình dung một nhân viên mới rất giỏi diễn đạt nhưng chưa thuộc quy định công ty. Đừng bắt người đó đoán. Hãy đưa đúng trang trong sổ tay, yêu cầu trả lời theo trang ấy và ghi rõ đã đọc ở đâu. RAG hoạt động gần như vậy, chỉ nhanh hơn và không xin nghỉ cà phê.
RAG hợp với dữ liệu riêng, thường xuyên thay đổi hoặc quá chuyên biệt để nằm sẵn trong mô hình: quy trình nội bộ, tài liệu sản phẩm, hướng dẫn vận hành, hợp đồng mẫu, danh mục hàng hóa, bài viết hỗ trợ khách hàng. Nó cũng có thể là một phần của AI agent khi agent cần tra cứu trước lúc quyết định hoặc thực hiện công việc.
RAG hoạt động ra sao từ lúc nạp tài liệu đến khi trả lời?
Một hệ thống RAG cơ bản có hai giai đoạn: chuẩn bị kho kiến thức và xử lý câu hỏi. Tách hai giai đoạn này ra sẽ dễ tìm lỗi hơn. Nếu cứ gom tất cả vào một hộp đen, lúc chatbot trả lời sai bạn chỉ còn cách nhìn màn hình và suy tư về nhân sinh.
1. Chọn và làm sạch nguồn dữ liệu
Đầu vào có thể là PDF, trang web, tài liệu Word, bản ghi trong cơ sở dữ liệu hoặc nội dung từ hệ thống quản lý kiến thức. Chất lượng nguồn quan trọng hơn số lượng. Một thư mục có ba phiên bản quy trình, trong đó hai bản đã hết hiệu lực, sẽ khiến hệ thống tìm được đáp án cũ rất nhanh.
Mỗi tài liệu nên có thông tin đi kèm như tiêu đề, ngày cập nhật, phòng ban sở hữu, trạng thái hiệu lực và nhóm người được xem. Đừng đợi đến lúc chạy thật mới bổ sung phân quyền. Khi dữ liệu đã trộn thành một nồi lẩu, tách lại thường đau đầu hơn nhiều.
2. Chia tài liệu thành các đoạn vừa đủ
Tài liệu dài thường được chia thành những đoạn nhỏ, hay gọi là chunk. Nếu đoạn quá ngắn, một quy định có thể bị cắt mất điều kiện hoặc ngoại lệ. Nếu đoạn quá dài, phần liên quan bị chìm giữa nhiều chữ thừa, tốn cửa sổ ngữ cảnh và chi phí xử lý.
Không có một kích thước đoạn đúng cho mọi dữ liệu. Hợp đồng nên được chia theo điều khoản. Hướng dẫn kỹ thuật có thể chia theo đề mục nhưng cần giữ khối lệnh đi cùng phần giải thích. Bảng giá phải giữ tên cột và đơn vị. Cách chia theo cấu trúc tài liệu thường hữu ích hơn việc cứ đủ một số ký tự là cắt.
3. Biến đoạn văn thành biểu diễn số để tìm theo nghĩa
Mô hình embedding chuyển mỗi đoạn thành một dãy số thể hiện đặc điểm ngữ nghĩa. Các dãy số này được lưu trong chỉ mục hoặc cơ sở dữ liệu vector. Khi người dùng đặt câu hỏi, câu hỏi cũng được chuyển thành vector; hệ thống tìm những đoạn nằm gần nó trong không gian số.
Nhờ vậy, câu hỏi “chính sách làm việc tại nhà” vẫn có thể tìm thấy tài liệu dùng cụm “quy định làm việc từ xa”, dù từ ngữ không giống hệt nhau. Tuy nhiên, tìm theo nghĩa không phải lúc nào cũng thắng. Mã sản phẩm, số hóa đơn, tên lỗi và từ viết tắt thường cần khớp từ khóa chính xác.
4. Truy xuất, xếp hạng lại rồi ghép ngữ cảnh
Khi có câu hỏi, hệ thống lấy một nhóm kết quả ban đầu. Nhiều triển khai kết hợp tìm từ khóa với tìm vector, thường gọi là tìm kiếm lai. Tài liệu Azure AI Search của Microsoft mô tả cách kết hợp truy vấn từ khóa, vector và xếp hạng ngữ nghĩa để tăng khả năng lấy đúng nội dung.
Sau bước tìm, một bộ xếp hạng lại có thể chấm điểm các đoạn để chọn phần sát câu hỏi nhất. Hệ thống ghép các đoạn tốt nhất, câu hỏi và chỉ dẫn thành một prompt. Chỉ dẫn nên nói rõ: trả lời dựa trên nguồn được cung cấp, trích dẫn tài liệu, và từ chối nếu bằng chứng không đủ.
5. Sinh câu trả lời và trả lại nguồn
Mô hình viết câu trả lời từ ngữ cảnh vừa nhận. Ứng dụng nên hiển thị tên tài liệu, liên kết và tốt hơn nữa là đoạn được dùng. Một dòng “Nguồn: sổ tay nhân sự” nghe có vẻ nghiêm túc nhưng chưa giúp người đọc kiểm tra được gì. Nguồn phải mở đúng tài liệu mà người dùng có quyền xem, lý tưởng là đến đúng trang hoặc đúng mục.
Google Cloud lưu ý rằng khâu truy xuất có tính quyết định: nếu lấy về thông tin không liên quan, câu trả lời vẫn có thể bám nguồn nhưng lạc đề hoặc sai. Khi sửa RAG, đừng vội đổi sang mô hình lớn hơn nếu máy tìm kiếm đang đưa nhầm giấy cho nó đọc.
RAG khác tìm kiếm, cửa sổ ngữ cảnh dài và fine-tuning thế nào?
| Cách làm | Hợp khi nào | Điểm phải canh |
|---|---|---|
| Tìm kiếm truyền thống | Người dùng muốn tự đọc danh sách tài liệu | Không tổng hợp thành câu trả lời |
| Đưa toàn bộ tài liệu vào prompt | Kho nhỏ, ít thay đổi, vừa cửa sổ ngữ cảnh | Tốn token; nội dung liên quan dễ bị chìm |
| RAG | Kho lớn, cần cập nhật và trích dẫn nguồn | Phụ thuộc mạnh vào chất lượng truy xuất |
| Fine-tuning | Muốn chỉnh hành vi, giọng điệu hoặc định dạng ổn định | Không phải cách tiện để cập nhật kiến thức thường xuyên |
RAG không thay thế tìm kiếm; nó dùng tìm kiếm làm phần đầu của quy trình. Điểm khác là người dùng nhận một câu trả lời tổng hợp thay vì danh sách kết quả. Vì mô hình có thể diễn giải sai, giao diện vẫn nên cho phép mở nguồn gốc.
Với vài tài liệu ngắn, đưa toàn bộ nội dung vào cửa sổ ngữ cảnh có thể đơn giản hơn dựng một hệ thống truy xuất. Khi dữ liệu tăng, RAG giúp lọc bớt nội dung phải gửi vào mô hình. Google Cloud cũng nêu cách nhìn này: ngữ cảnh dài phù hợp khi nguồn còn nằm gọn trong giới hạn; RAG hữu ích khi lượng thông tin lớn hơn hoặc cần mở rộng hiệu năng.
Fine-tuning, tức huấn luyện bổ sung trên tập ví dụ, hợp để dạy mô hình cách phản hồi hoặc cách trình bày. Nó không tiện bằng RAG cho một bảng giá đổi mỗi tuần. Bạn có thể dùng cả hai: fine-tuning để giữ hành vi, RAG để cấp dữ kiện mới. Nhưng một bản thử nghiệm nhỏ thường chưa cần chất thêm tầng kỹ thuật cho đẹp sơ đồ.
Khi nào nên dùng RAG, khi nào chưa cần?
RAG đáng làm khi người dùng đặt câu hỏi bằng ngôn ngữ tự nhiên, đáp án nằm rải trong nhiều tài liệu và việc dẫn nguồn có giá trị. Ví dụ dễ thấy là trợ lý tra quy trình cho nhân viên, chatbot hỗ trợ kỹ thuật, công cụ hỏi đáp tài liệu pháp lý nội bộ hoặc hệ thống giúp nhân viên bán hàng tìm thông số sản phẩm.
Nếu câu trả lời chỉ là một giá trị chính xác trong cơ sở dữ liệu, hãy cân nhắc truy vấn có cấu trúc hoặc API. Hỏi “đơn hàng 123 đang ở đâu” không nhất thiết cần embedding và vector. Một câu lệnh lấy đúng bản ghi thường gọn, rẻ và dễ kiểm tra hơn.
Cũng chưa nên làm RAG nếu tổ chức chưa biết tài liệu nào đang có hiệu lực. Công nghệ không giải quyết được chuyện ba phòng ban giữ ba bản chính sách khác nhau và ai cũng nhận bản của mình là chuẩn. Trước tiên cần chỉ định chủ sở hữu dữ liệu và quy trình cập nhật.
RAG có thể kết hợp với công cụ bên ngoài qua Model Context Protocol (MCP), nhưng hai khái niệm không đồng nghĩa. RAG lấy kiến thức để trả lời. MCP là một cách chuẩn hóa việc ứng dụng AI kết nối tới công cụ và nguồn dữ liệu. Một agent có thể dùng MCP để gọi dịch vụ tìm kiếm RAG, sau đó dùng kết quả cho bước tiếp theo.
Cách dựng bản thử nghiệm RAG có thể đo được
Đừng bắt đầu bằng câu “ta đưa hết dữ liệu công ty vào AI nhé”. Hãy chọn một phạm vi nhỏ: một sản phẩm, một nhóm tài liệu và một nhóm người dùng. Mục tiêu đầu tiên không phải chatbot biết mọi thứ. Mục tiêu là biết nó trả lời đúng loại câu hỏi nào và thất bại ở đâu.
Lập bộ câu hỏi trước khi chỉnh hệ thống
Chuẩn bị một bộ câu hỏi đại diện cho việc thật: câu dễ, câu dùng từ khác tài liệu, câu cần ghép hai nguồn, câu không có đáp án và câu mà người dùng không được phép xem. Với mỗi câu, ghi đáp án mong đợi cùng tài liệu chứng minh. Đây là bộ kiểm thử, không phải bộ câu hỏi trình diễn cho sếp xem năm phút rồi cất.
Đánh giá ít nhất hai tầng. Tầng truy xuất kiểm tra hệ thống có lấy được đúng đoạn hay không. Tầng trả lời kiểm tra câu trả lời có đúng, có dựa trên đoạn được lấy và có trích dẫn chính xác không. Nếu không tách, bạn sẽ không biết lỗi nằm ở tìm kiếm, prompt hay mô hình.
Đặt tiêu chí từ chối rõ ràng
Một chatbot hữu ích phải biết nói “Tôi không tìm thấy thông tin này trong tài liệu được cấp”. Câu ấy kém hào nhoáng nhưng an toàn hơn một đoạn văn tự tin. Bạn có thể đặt ngưỡng điểm truy xuất, yêu cầu tối thiểu một nguồn phù hợp và kiểm tra xem từng ý quan trọng có bằng chứng hay chưa.
Đừng chỉ đánh giá câu văn có hay không. Hãy kiểm tra tỷ lệ lấy đúng nguồn, tỷ lệ câu trả lời bám nguồn, độ chính xác của trích dẫn, thời gian phản hồi và chi phí mỗi lượt hỏi. Phản hồi của người dùng cũng cần gắn với câu hỏi và nguồn đã dùng, nếu không nút “không hữu ích” chỉ tạo thêm một con số buồn.
Sáu lỗi RAG thường gặp và cách sửa
Tài liệu cũ vẫn đứng đầu kết quả
Thêm ngày hiệu lực và trạng thái vào metadata, loại bản hết hạn khỏi chỉ mục hoặc hạ điểm chúng. Quan trọng hơn, phải có người chịu trách nhiệm cập nhật nguồn. Tự động đồng bộ một thư mục lộn xộn chỉ giúp chỉ mục lộn xộn theo thời gian thực.
Chia đoạn làm mất ngữ cảnh
Giữ tiêu đề, đường dẫn đề mục và phần chồng lấn hợp lý giữa các đoạn. Với bảng, danh sách điều kiện hoặc mã nguồn, dùng cách chia riêng theo cấu trúc. Sau đó xem trực tiếp các đoạn được lấy về; đừng chỉ ngắm điểm tương đồng.
Tìm theo vector nhưng bỏ lỡ mã và tên riêng
Kết hợp tìm từ khóa và vector. Truy vấn “ERR-1042” cần khớp chuỗi chính xác, còn “lỗi không đăng nhập được sau khi đổi mật khẩu” lại hợp tìm theo nghĩa. Tìm kiếm lai giúp xử lý cả hai kiểu.
Chatbot trích dẫn có vẻ đúng nhưng mở ra sai đoạn
Lưu liên kết ổn định tới tài liệu và vị trí đoạn ngay từ lúc lập chỉ mục. Khi giao diện hiển thị nguồn, kiểm tra người dùng có mở được đúng chỗ không. Một trích dẫn đẹp mà dẫn về trang chủ kho tài liệu thì mới làm xong nửa việc.
Người dùng nhìn thấy nội dung không thuộc quyền của mình
Áp quyền truy cập trong bước truy xuất, trước khi nội dung được gửi cho mô hình. Microsoft nhấn mạnh người dùng và agent chỉ nên lấy nội dung đã được cấp phép. Lọc kết quả sau khi mô hình đã đọc dữ liệu là quá muộn. Nhật ký cũng cần tránh lưu nguyên văn thông tin nhạy cảm nếu không cần thiết.
Đổi mô hình liên tục nhưng chất lượng không nhúc nhích
Lấy một câu trả lời sai, mở các đoạn đã truy xuất và hỏi: đáp án có nằm trong đó không? Nếu không, sửa dữ liệu, cách chia đoạn, truy vấn hoặc xếp hạng. Nếu có mà mô hình vẫn trả lời sai, lúc ấy mới chỉnh prompt hoặc thử mô hình khác. Thứ tự chẩn đoán này tiết kiệm khá nhiều hóa đơn API.
Checklist ngắn để bắt đầu
- Chọn một bài toán có chủ sở hữu và nhóm người dùng rõ ràng.
- Chỉ nạp tài liệu đang hiệu lực; gắn ngày, nguồn và quyền truy cập.
- Chia đoạn theo cấu trúc nội dung rồi kiểm tra bằng mắt.
- Dùng tìm kiếm lai nếu dữ liệu có mã, tên riêng hoặc thuật ngữ đặc thù.
- Yêu cầu câu trả lời bám nguồn, có trích dẫn và biết từ chối.
- Tạo bộ câu hỏi chuẩn trước khi tinh chỉnh.
- Đo riêng chất lượng truy xuất và chất lượng câu trả lời.
- Thử tấn công phân quyền, prompt injection trong tài liệu và câu hỏi không có đáp án.
- Theo dõi độ trễ, chi phí, truy vấn lỗi và phản hồi người dùng.
Kết luận
Hiểu ngắn gọn, RAG là cách cho mô hình “mở tài liệu ra xem” trước khi trả lời. Giá trị của nó nằm ở nguồn dữ liệu được kiểm soát, khả năng cập nhật và đường dẫn để người dùng tự kiểm tra. Phần mô hình chỉ là một mắt xích.
Nếu đang thử RAG, hãy bắt đầu bằng một kho nhỏ và vài chục câu hỏi thật. Mở từng kết quả truy xuất, kiểm tra từng trích dẫn và vui vẻ khi hệ thống biết từ chối đúng lúc. Một câu “không tìm thấy” tử tế vẫn hơn ba đoạn văn bịa rất có phong thái.
Bạn đang muốn dùng RAG cho tài liệu kỹ thuật, quy trình nội bộ hay hỗ trợ khách hàng? Hãy chia sẻ loại dữ liệu khó xử lý nhất ở phần bình luận.
Nguồn tham khảo
