RAG là gì?
RAG (Retrieval-Augmented Generation, tạm dịch: sinh văn bản có tăng cường truy xuất) là kỹ thuật cho mô hình ngôn ngữ lớn (LLM) tìm các đoạn tài liệu liên quan trong kho dữ liệu của bạn, rồi dùng chính các đoạn đó làm căn cứ để soạn câu trả lời. Nhờ vậy, câu trả lời bám vào quy trình, chính sách, hợp đồng của doanh nghiệp thay vì chỉ dựa vào những gì mô hình đã học, và có thể kèm trích dẫn để người dùng kiểm tra lại.
Thuật ngữ này xuất phát từ bài báo của Patrick Lewis và cộng sự (Facebook AI Research, University College London, New York University) công bố năm 2020 tại hội nghị NeurIPS. Nhóm tác giả chỉ ra rằng mô hình ngôn ngữ lưu tri thức trong tham số nhưng khó truy cập và cập nhật tri thức đó một cách chính xác, đồng thời việc cung cấp nguồn gốc (provenance) cho câu trả lời vẫn là bài toán mở. Giải pháp của họ là kết hợp “bộ nhớ tham số” (mô hình sinh văn bản) với “bộ nhớ phi tham số” là một chỉ mục vector của Wikipedia, truy cập qua một bộ truy xuất thần kinh. Theo bài báo, mô hình RAG tạo ra văn bản cụ thể, đa dạng và đúng sự thật hơn so với mô hình chỉ dùng tham số.
Ngày nay, “RAG” được hiểu rộng hơn định nghĩa gốc: mọi hệ thống truy xuất tài liệu rồi đưa vào ngữ cảnh của LLM để trả lời. Ứng dụng phổ biến nhất trong doanh nghiệp là trợ lý tri thức nội bộ: nhân viên hỏi bằng ngôn ngữ tự nhiên, hệ thống trả lời dựa trên sổ tay nhân sự, quy trình vận hành, tài liệu sản phẩm, biên bản họp… và chỉ ra đoạn văn bản làm căn cứ.
RAG hoạt động như thế nào: 6 bước từ tài liệu đến câu trả lời
Một hệ thống RAG có hai luồng: luồng nạp dữ liệu (chạy khi tài liệu thay đổi) và luồng hỏi đáp (chạy mỗi khi có câu hỏi). Sáu bước dưới đây là khung chung; mỗi bước đều có lựa chọn kỹ thuật ảnh hưởng trực tiếp đến chất lượng.
1. Nạp tài liệu (ingest)
Kết nối nguồn dữ liệu (ổ chia sẻ, wiki, hệ thống quản lý văn bản, email, phần mềm nghiệp vụ), trích xuất văn bản từ PDF, Word, bảng tính, ảnh scan. Ở bước này cần giữ lại siêu dữ liệu: tên tài liệu, phiên bản, ngày hiệu lực, phòng ban sở hữu và đặc biệt là danh sách quyền truy cập. Dữ liệu bẩn ở đầu vào sẽ thành câu trả lời sai ở đầu ra, nên đây là lúc áp dụng nguyên tắc quản trị dữ liệu.
2. Chia nhỏ (chunking)
Tài liệu được cắt thành các đoạn (chunk) đủ nhỏ để tìm chính xác nhưng đủ lớn để giữ nghĩa. Anthropic lưu ý rằng kích thước, ranh giới và độ chồng lấn của chunk đều ảnh hưởng đến hiệu quả truy xuất. Một vấn đề thường gặp là chunk mất ngữ cảnh: câu “doanh thu tăng 3% so với quý trước” vô nghĩa nếu không biết của công ty nào, quý nào. Kỹ thuật Contextual Retrieval của Anthropic xử lý việc này bằng cách thêm một đoạn giải thích ngữ cảnh ngắn vào đầu mỗi chunk trước khi tạo embedding và chỉ mục từ khóa.
3. Tạo embedding
Mỗi chunk được mô hình embedding chuyển thành một vector số biểu diễn ý nghĩa, rồi lưu vào cơ sở dữ liệu vector. Câu hỏi của người dùng cũng được chuyển thành vector theo cùng mô hình để so sánh độ tương đồng.
4. Truy xuất (retrieve)
Hệ thống tìm các chunk gần với câu hỏi nhất. Tìm kiếm ngữ nghĩa (vector) giỏi bắt diễn đạt khác nhau cùng ý, nhưng có thể bỏ sót khớp chính xác như mã hợp đồng, số hiệu văn bản; tìm kiếm từ khóa BM25 thì ngược lại. Vì vậy nhiều hệ thống dùng tìm kiếm lai (hybrid) và thêm bước xếp hạng lại (reranking). Trong thử nghiệm của Anthropic, kết hợp Contextual Embeddings với Contextual BM25 giảm tỷ lệ truy xuất thất bại trong top-20 chunk 49% (từ 5,7% xuống 2,9%), và thêm reranking giảm 67% (xuống 1,9%). Đây là kết quả trên bộ dữ liệu của họ; bạn cần đo lại trên dữ liệu của mình.
5. Sinh câu trả lời (generate)
Các chunk được chọn được đưa vào prompt cùng câu hỏi và chỉ dẫn rõ ràng: chỉ trả lời dựa trên tài liệu đã cung cấp, nói “không tìm thấy” khi tài liệu không đủ, không suy diễn quy định.
6. Trích dẫn (cite)
Câu trả lời gắn liên kết tới tài liệu và đoạn văn bản gốc. Trích dẫn giúp người dùng tự kiểm chứng, giúp đội vận hành phát hiện tài liệu lỗi thời, và là nền tảng để đưa con người vào vòng kiểm duyệt với các câu hỏi rủi ro cao (xem Human-in-the-loop).
RAG, fine-tuning hay ngữ cảnh dài: nên chọn cách nào?
Ba cách phổ biến để “dạy” LLM tri thức doanh nghiệp giải quyết những vấn đề khác nhau. Fine-tuning thay đổi tham số mô hình, phù hợp để dạy văn phong, định dạng hay một kỹ năng lặp lại, nhưng không phải cách tốt để cập nhật dữ kiện thay đổi hằng tuần. Ngữ cảnh dài (long context) đưa toàn bộ tài liệu vào prompt: Anthropic gợi ý rằng nếu kho tri thức nhỏ hơn khoảng 200.000 token (khoảng 500 trang), có thể đưa toàn bộ vào prompt thay vì xây RAG. Khi kho tài liệu lớn, thay đổi thường xuyên và có phân quyền, RAG thường là lựa chọn thực tế hơn.
- Có thể kết hợp: RAG để lấy dữ kiện, fine-tuning nhẹ để thống nhất giọng văn, ngữ cảnh dài để đọc trọn một hợp đồng sau khi đã truy xuất đúng hợp đồng đó.
| Tiêu chí | RAG | Fine-tuning | Ngữ cảnh dài |
|---|---|---|---|
| Cập nhật tri thức | Cập nhật chỉ mục, không cần huấn luyện lại | Phải huấn luyện lại | Thay tài liệu trong prompt |
| Trích dẫn nguồn | Tự nhiên, theo chunk được truy xuất | Khó, tri thức nằm trong tham số | Có thể, nhưng phải yêu cầu rõ |
| Phân quyền theo người dùng | Lọc được ở bước truy xuất | Không phù hợp | Phải tự lọc tài liệu trước khi đưa vào |
| Quy mô kho tài liệu | Lớn, hàng nghìn tài liệu trở lên | Không phụ thuộc kho | Giới hạn bởi cửa sổ ngữ cảnh |
| Phù hợp nhất cho | Hỏi đáp trên tài liệu thay đổi, nhiều nguồn | Văn phong, định dạng, kỹ năng chuyên biệt | Kho nhỏ, ít thay đổi, cần đọc trọn văn bản |
Những lưu ý riêng khi làm RAG tiếng Việt
Phần lớn hướng dẫn RAG được viết cho tiếng Anh. Với tài liệu tiếng Việt, có bốn điểm cần kiểm tra kỹ.
Tách từ và tokenization
Trong tiếng Việt, dấu cách phân tách âm tiết chứ không phải từ: “quản lý”, “hợp đồng” là từ ghép hai âm tiết. Một số mô hình tiếng Việt yêu cầu tách từ trước; ví dụ, VinAI ghi rõ rằng với văn bản thô chưa tách từ, phải chạy bộ tách từ (như RDRSegmenter trong VnCoreNLP) trước khi đưa vào PhoBERT. Các mô hình đa ngữ như BGE-M3 thì nhận văn bản thô. Điều quan trọng là xử lý nhất quán: tài liệu và câu hỏi phải đi qua cùng một quy trình tiền xử lý, kể cả với chỉ mục BM25.
Dấu thanh và chuẩn hóa Unicode
Người dùng hay gõ không dấu hoặc sai dấu, còn tài liệu có thể được mã hóa Unicode dựng sẵn hoặc tổ hợp, hai cách nhìn giống nhau nhưng khác nhau ở cấp byte. Nên chuẩn hóa Unicode (ví dụ NFC) cho cả tài liệu và câu hỏi, và thử nghiệm riêng với các câu hỏi không dấu trong bộ đánh giá.
Văn bản trộn Việt – Anh
Tài liệu doanh nghiệp Việt Nam thường trộn thuật ngữ tiếng Anh (KPI, onboarding, SLA, tên phần mềm) và viết tắt nội bộ. Tìm kiếm từ khóa giúp bắt chính xác các thuật ngữ này, còn mô hình embedding đa ngữ giúp câu hỏi tiếng Việt tìm được đoạn tiếng Anh và ngược lại. Một bảng từ điển viết tắt nội bộ, dùng để mở rộng câu hỏi, thường mang lại hiệu quả rõ.
Chọn mô hình embedding
Đừng chọn mô hình chỉ dựa trên bảng xếp hạng tiếng Anh. Các nhà nghiên cứu Việt Nam đã chỉ ra rằng tiếng Việt từng thiếu benchmark truy xuất chuẩn, và gần đây mới có những bộ như VN-MTEB (41 bộ dữ liệu, 6 nhóm tác vụ, xây dựng bằng cách dịch có kiểm soát chất lượng từ MTEB) hay Vietnamese Context Search (VCS). Một số lựa chọn thường được cân nhắc: BGE-M3 (đa ngữ, hơn 100 ngôn ngữ, đầu vào tới 8.192 token, hỗ trợ cả truy xuất dense, sparse và multi-vector); các mô hình tinh chỉnh cho tiếng Việt như AITeamVN/Vietnamese_Embedding (tinh chỉnh từ BGE-M3 trên khoảng 300.000 bộ ba câu hỏi – tài liệu đúng – tài liệu sai); hoặc API embedding thương mại. Cách chắc chắn nhất là dựng bộ 100–200 câu hỏi thật của doanh nghiệp và đo recall trên chính dữ liệu đó trước khi chốt.
Phân quyền tài liệu: truy xuất phải tôn trọng quyền truy cập
Rủi ro lớn nhất của trợ lý tri thức nội bộ không phải là trả lời sai, mà là trả lời đúng cho sai người: một nhân viên hỏi về chính sách lương và nhận được đoạn trích từ bảng lương chi tiết. Nếu tất cả tài liệu được đưa vào một chỉ mục chung, LLM không có cách nào biết ai được xem gì.
Nguyên tắc là lọc theo quyền ngay ở bước truy xuất (permission-aware retrieval), trước khi bất kỳ đoạn văn nào đến được LLM:
- Lưu danh sách quyền (người dùng, nhóm, phòng ban) của tài liệu gốc làm siêu dữ liệu cho từng chunk.
- Khi có câu hỏi, xác định danh tính người hỏi qua hệ thống đăng nhập hiện có và áp bộ lọc quyền vào truy vấn vector và từ khóa.
- Đồng bộ quyền định kỳ hoặc theo sự kiện: khi một người chuyển phòng ban hay nghỉ việc, quyền trong chỉ mục phải thay đổi theo.
- Không dựa vào prompt kiểu “đừng tiết lộ thông tin mật”; prompt không phải cơ chế kiểm soát truy cập.
- Ghi nhật ký câu hỏi, tài liệu được truy xuất và câu trả lời để phục vụ kiểm tra nội bộ.
Đánh giá chất lượng: đo truy xuất và đo độ bám nguồn
Một bản demo trả lời trôi chảy chưa chứng minh được gì. Hãy tách đánh giá thành hai lớp, vì lỗi ở mỗi lớp cần cách sửa khác nhau:
- Truy xuất (retrieval recall): với mỗi câu hỏi trong bộ kiểm thử, đoạn tài liệu đúng có nằm trong top-k kết quả không? Anthropic dùng chính chỉ số này (tỷ lệ thất bại trong top-20) để so sánh các kỹ thuật. Thư viện Ragas cung cấp các chỉ số Context Recall và Context Precision.
- Độ bám nguồn (groundedness/faithfulness): mọi khẳng định trong câu trả lời có được tài liệu truy xuất hỗ trợ không? Theo tài liệu Ragas, Faithfulness là tỷ lệ số khẳng định được ngữ cảnh hỗ trợ trên tổng số khẳng định, từ 0 đến 1.
- Hành vi từ chối: khi tài liệu không có câu trả lời, hệ thống có nói “không tìm thấy” thay vì bịa không?
- Phân quyền: bộ kiểm thử phải có câu hỏi từ tài khoản không đủ quyền để chắc chắn tài liệu mật không bị trả về.
Ví dụ minh họa: dựng bộ đánh giá đầu tiên
Một phòng nhân sự thu thập 150 câu hỏi nhân viên đã thực sự hỏi trong năm qua, ghi kèm tài liệu và đoạn văn chứa câu trả lời đúng, thêm 20 câu không có đáp án trong tài liệu và 20 câu hỏi từ tài khoản không đủ quyền. Mỗi lần đổi mô hình embedding, kích thước chunk hay prompt, đội chạy lại toàn bộ và so sánh các chỉ số với lần trước. (Đây là ví dụ minh họa, không phải số liệu từ dự án thực tế.)
Bảo vệ dữ liệu cá nhân khi xây RAG
Tài liệu nội bộ thường chứa dữ liệu cá nhân: hồ sơ nhân viên, thông tin khách hàng, email. Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 được Quốc hội ban hành ngày 26/6/2025 và có hiệu lực từ 01/01/2026, cùng Nghị định 356/2025/NĐ-CP quy định chi tiết (thay thế Nghị định 13/2023/NĐ-CP), nên việc lập chỉ mục, gửi đoạn văn tới mô hình AI và lưu nhật ký đều cần được xem xét dưới góc độ luật này. Xem tổng quan tại bài Luật Bảo vệ dữ liệu cá nhân 2025.
Ở góc độ kỹ thuật, một số biện pháp nên cân nhắc ngay từ thiết kế:
- Tối thiểu hóa: chỉ nạp những nguồn thực sự cần cho mục đích của trợ lý; loại bỏ hoặc che dữ liệu cá nhân không cần thiết trước khi lập chỉ mục.
- Xác định rõ nơi dữ liệu được xử lý và lưu trữ (chỉ mục vector, nhà cung cấp mô hình, nhật ký), đặc biệt khi dùng dịch vụ đặt ở nước ngoài.
- Hỗ trợ xóa: khi một tài liệu hay dữ liệu của một người cần xóa, chunk, embedding và bản sao trong nhật ký cũng phải được xóa.
- Phối hợp với bộ phận pháp chế để đánh giá tác động xử lý dữ liệu trước khi đưa vào vận hành.
Lộ trình triển khai trợ lý tri thức nội bộ
Cách an toàn là bắt đầu hẹp, đo được, rồi mở rộng. Lộ trình dưới đây phù hợp với hầu hết doanh nghiệp vừa và lớn:
- Chọn một phạm vi hẹp có giá trị rõ: ví dụ hỏi đáp chính sách nhân sự, hoặc tài liệu hỗ trợ kỹ thuật cho một dòng sản phẩm.
- Kiểm kê nguồn tài liệu, chủ sở hữu, độ mới và quyền truy cập; dọn tài liệu trùng lặp, lỗi thời.
- Dựng bộ đánh giá từ câu hỏi thật trước khi viết dòng code đầu tiên.
- Xây bản thử nghiệm với tìm kiếm lai, phân quyền và trích dẫn; so sánh 2–3 mô hình embedding trên bộ đánh giá.
- Thử nghiệm với nhóm người dùng nhỏ, có kênh báo lỗi và người duyệt cho câu hỏi rủi ro cao.
- Thiết lập vận hành: đồng bộ tài liệu, đồng bộ quyền, theo dõi chỉ số, chạy lại bộ đánh giá sau mỗi thay đổi.
- Mở rộng sang phòng ban khác, và khi đã ổn định, cân nhắc để trợ lý trở thành một công cụ của AI Agent trong quy trình lớn hơn (xem mô hình vận hành với AI Agent).
EYC có thể hỗ trợ gì
Mảng Nghiên cứu & AI ứng dụng của EYC cùng doanh nghiệp đánh giá bài toán, dựng bộ đánh giá trên dữ liệu thật và xây bản thử nghiệm RAG có phân quyền; phần hạ tầng dữ liệu và triển khai được phối hợp với nhóm đám mây và dữ liệu. Phạm vi, cam kết vận hành và bàn giao được xác định theo thỏa thuận trong hợp đồng. Bạn có thể liên hệ EYC để trao đổi về trường hợp cụ thể.
Câu hỏi thường gặp
RAG là gì, viết tắt của từ gì?
RAG là Retrieval-Augmented Generation, tức sinh văn bản có tăng cường truy xuất. Thuật ngữ được giới thiệu trong bài báo của Lewis và cộng sự tại NeurIPS 2020.
RAG có loại bỏ hoàn toàn việc AI “bịa” thông tin không?
Không. RAG giảm rủi ro bằng cách buộc câu trả lời dựa trên tài liệu và kèm trích dẫn, nhưng mô hình vẫn có thể diễn giải sai hoặc truy xuất nhầm đoạn. Vì vậy cần đo độ bám nguồn, cho phép hệ thống trả lời “không tìm thấy” và có người duyệt với câu hỏi rủi ro cao.
Khi nào nên dùng RAG thay vì fine-tuning?
Khi bạn cần trả lời dựa trên dữ kiện thay đổi thường xuyên, cần trích dẫn nguồn hoặc cần phân quyền theo người dùng. Fine-tuning phù hợp hơn để dạy văn phong, định dạng hay kỹ năng lặp lại. Hai cách này có thể kết hợp: RAG lấy dữ kiện, fine-tuning nhẹ thống nhất giọng văn.
Mô hình embedding nào tốt cho tiếng Việt?
Không có lựa chọn đúng cho mọi trường hợp. Các mô hình đa ngữ như BGE-M3 và các mô hình tinh chỉnh cho tiếng Việt đều đáng thử; benchmark như VN-MTEB giúp lọc sơ bộ, nhưng quyết định cuối nên dựa trên recall đo trên bộ câu hỏi thật của doanh nghiệp.
Kho tài liệu nhỏ có cần RAG không?
Có thể không. Anthropic gợi ý rằng nếu kho tri thức dưới khoảng 200.000 token (khoảng 500 trang), có thể đưa toàn bộ vào prompt. RAG trở nên cần thiết khi kho lớn hơn, thay đổi thường xuyên hoặc cần phân quyền.