# RAG là gì? Cách AI tra cứu tài liệu của bạn trước khi trả lời, và vì sao hay truy xuất sai

URL: https://opcaios.org/blog/rag-la-gi
Ngày: 2026-11-02
Cập nhật: 2026-10-25
Tác giả: Lê Quốc Nghĩa
Chuyên mục: Hướng dẫn

RAG là gì? RAG (Retrieval-Augmented Generation, tạo sinh được tăng cường bằng truy xuất) là phương pháp lấy thông tin liên quan từ một kho tri thức rồi đưa vào lời nhắc gửi cho mô hình AI, để câu trả lời dựa trên dữ liệu thật của bạn thay vì chỉ dựa vào trí nhớ của mô hình. Khái niệm do Patrick Lewis và cộng sự đặt ra trong bài báo công bố ngày 22/5/2020 (nhận đăng ở NeurIPS 2020). Bài này giải thích RAG là gì, các bước hoạt động, khi nào không cần RAG, vì sao truy xuất hay sai và cách khắc phục theo số liệu của Anthropic, cách chọn cơ sở dữ liệu vector và mô hình nhúng cho tiếng Việt, và kinh nghiệm thật của OPCAIOS khi tự dựng tìm kiếm ngữ nghĩa bằng pgvector.

![Sơ đồ RAG: tài liệu được cắt đoạn, nhúng và lưu vào cơ sở dữ liệu vector; câu hỏi được nhúng, truy xuất các đoạn gần nhất rồi đưa cho mô hình trả lời kèm nguồn](https://opcaios.org/images/blog/rag-la-gi/so-do.webp)
*RAG gồm hai nửa: chuẩn bị kho tri thức (cắt, nhúng, lưu) và trả lời (nhúng câu hỏi, truy xuất, sinh). Sơ đồ: OPCAIOS.*

## RAG là gì và vì sao ra đời?

RAG là phương pháp kết hợp hai loại bộ nhớ: bộ nhớ trong tham số của mô hình và bộ nhớ ngoài có thể tra cứu. Bài báo gốc của Patrick Lewis và cộng sự (arXiv:2005.11401, công bố ngày 22/5/2020) nêu ba vấn đề của mô hình ngôn ngữ lớn, theo tóm tắt (đọc ngày 23/10/2026):

1. Khả năng truy cập và thao tác chính xác kiến thức trong tham số còn hạn chế.
2. Việc nêu nguồn cho quyết định chưa giải quyết được.
3. Việc cập nhật kiến thức cũng chưa giải quyết được.

Nhóm tác giả đề xuất mô hình sinh đã huấn luyện trước, kèm một chỉ mục vector dày của Wikipedia. Mô hình truy cập chỉ mục bằng bộ truy xuất thần kinh. Họ báo cáo kết quả tốt nhất ở ba tác vụ hỏi đáp miền mở (NeurIPS 2020). Ngoài ra, ở các tác vụ sinh ngôn ngữ, mô hình RAG tạo ra ngôn ngữ cụ thể, đa dạng và đúng sự thật hơn mô hình chỉ dùng tham số. Hiểu đơn giản như một kỳ thi mở sách: ví dụ, thay vì bắt mô hình nhớ mọi thứ, bạn cho mô hình lật đúng trang tài liệu trước khi trả lời.

## RAG hoạt động qua những bước nào?

RAG là quy trình gồm hai phần: chuẩn bị kho tri thức và trả lời khi có câu hỏi. Theo hướng dẫn của Anthropic (đọc ngày 23/10/2026), các bước như sau:

**Chuẩn bị (làm một lần, cập nhật khi tài liệu đổi):**
1. Cắt kho tài liệu thành các đoạn (chunk) nhỏ, thường không quá vài trăm token.
2. Dùng mô hình nhúng (embedding) chuyển mỗi đoạn thành vector mã hoá ý nghĩa.
3. Lưu các vector vào cơ sở dữ liệu cho phép tìm theo độ tương đồng ngữ nghĩa.

**Khi có câu hỏi:**
4. Nhúng câu hỏi thành vector.
5. Tìm các đoạn gần nhất với câu hỏi (top k).
6. Thêm các đoạn đó vào lời nhắc gửi cho mô hình sinh.
7. Mô hình trả lời dựa trên các đoạn đó, tốt nhất kèm nguồn để người dùng kiểm tra.

Ví dụ, OPCAIOS dùng pgvector trong PostgreSQL làm cơ sở dữ liệu vector.

| Thành phần | Vai trò | Ví dụ |
|---|---|---|
| Bộ cắt đoạn | Chia tài liệu thành đơn vị truy xuất | Theo tiêu đề, đoạn văn, vài trăm token |
| Mô hình nhúng | Biến văn bản thành vector | multilingual-e5-small (384 chiều) |
| Cơ sở dữ liệu vector | Tìm đoạn gần nhất | pgvector trong PostgreSQL |
| Bộ xếp hạng lại (tuỳ chọn) | Lọc lại top đoạn theo mức liên quan | Mô hình reranker |
| Mô hình sinh | Viết câu trả lời từ các đoạn | Claude, GPT, Gemini |

## Khi nào không cần RAG?

Bạn không cần RAG khi kho tri thức đủ nhỏ để đưa toàn bộ vào lời nhắc. Anthropic nói nếu kho dưới 200.000 token (khoảng 500 trang), bạn có thể nhét cả kho vào lời nhắc mà không cần RAG. Với bộ nhớ đệm lời nhắc (prompt caching), theo Anthropic, độ trễ giảm hơn 2 lần và chi phí giảm tới 90% (đọc ngày 23/10/2026). Khi kho lớn hơn cửa sổ ngữ cảnh, RAG là giải pháp phổ biến. Ví dụ giả định: một doanh nghiệp nhỏ có 40 trang quy trình nội bộ nên thử đưa cả bộ tài liệu vào lời nhắc trước, rồi mới tính tới RAG. Ngoài ra, hãy chọn đơn giản trước, vì nhiều doanh nghiệp nhỏ có bộ tài liệu đủ nhỏ để bắt đầu mà không cần RAG. Về chi phí theo mức dùng, xem [Nên chọn model AI nào?](/blog/chon-model-ai).

## Vì sao RAG hay truy xuất sai, và khắc phục thế nào?

RAG truy xuất sai là khi bước tìm đoạn không đưa đúng đoạn liên quan cho mô hình. Có hai nguyên nhân chính, theo Anthropic (đọc ngày 23/10/2026) và theo bài "Contextual Retrieval" (Anthropic 2024). Thứ nhất, RAG truyền thống làm mất ngữ cảnh khi cắt đoạn: một đoạn như "doanh thu tăng 3% so với quý trước" không cho biết công ty nào, quý nào, nên bị truy xuất sai. Thứ hai, mô hình nhúng giỏi bắt ý nghĩa nhưng có thể bỏ lỡ khớp chính xác: với câu hỏi "Error code TS-999" mô hình có thể tìm nội dung về mã lỗi nói chung mà bỏ sót đúng "TS-999". Ba cách khắc phục:

1. **Kết hợp BM25 với tìm theo vector:** BM25 là hàm xếp hạng dựa trên khớp từ, hiệu quả với mã định danh và thuật ngữ kỹ thuật.
2. **Contextual Retrieval:** thêm một đoạn ngữ cảnh ngắn do mô hình viết vào đầu mỗi đoạn trước khi nhúng.
3. **Xếp hạng lại (reranking):** lấy nhiều ứng viên rồi lọc lại, vừa tốt hơn vừa giảm chi phí và độ trễ.

### Số liệu thử nghiệm của Anthropic cho thấy gì?

Theo số liệu của Anthropic (bài "Contextual Retrieval", 19/9/2024), đo bằng tỉ lệ truy xuất hỏng, tức tỉ lệ đoạn liên quan không nằm trong 20 đoạn đầu: Contextual Embeddings giảm 35%, từ 5,7% xuống 3,7%. Kết hợp Contextual Embeddings và Contextual BM25 giảm 49%, từ 5,7% xuống 2,9%. Thêm xếp hạng lại giảm 67%. Anthropic ước tính chi phí tạo ngữ cảnh một lần khoảng $1,02 cho mỗi triệu token tài liệu khi dùng bộ nhớ đệm lời nhắc. Đây là kết quả trên các bộ dữ liệu của họ (mã nguồn, tiểu thuyết, bài báo khoa học), nên hãy đo lại trên dữ liệu của bạn; chính Anthropic cũng khuyên luôn chạy đánh giá với trường hợp riêng.

## Chọn cơ sở dữ liệu vector như thế nào?

Nếu đã dùng PostgreSQL, pgvector là lựa chọn gọn nhất cho cơ sở dữ liệu vector. Đó là tiện ích mã nguồn mở thêm tìm kiếm vector vào Postgres, theo README của pgvector (đọc ngày 23/10/2026). Tiện ích lưu vector cạnh dữ liệu khác và hỗ trợ tìm chính xác lẫn gần đúng. Các khoảng cách gồm L2, tích vô hướng, cosine, L1, Hamming và Jaccard. Bạn cũng giữ được ưu điểm của Postgres như ACID, khôi phục theo thời điểm và JOIN. Có hai loại chỉ mục gần đúng:

1. **HNSW:** tạo đồ thị nhiều tầng, có tốc độ và độ chính xác tốt hơn nhưng dựng chậm hơn và tốn bộ nhớ hơn. Loại này không cần dữ liệu có sẵn để tạo chỉ mục.
2. **IVFFlat:** dựng nhanh hơn, nhưng cần có dữ liệu trước khi tạo chỉ mục.

Chỉ mục gần đúng đánh đổi một ít độ chính xác lấy tốc độ, nên kết quả có thể khác khi thêm chỉ mục. Ví dụ, nếu bạn đã dùng Supabase thì đó là PostgreSQL sẵn có; xem [Supabase là gì?](/blog/supabase-la-gi).

## Mô hình nhúng nào cho tiếng Việt?

Mô hình nhúng cho tiếng Việt nên là mô hình đa ngôn ngữ, và bạn cần kiểm tra bằng dữ liệu của mình. Một ví dụ là multilingual-e5-small của tổ chức intfloat trên Hugging Face, kèm báo cáo kỹ thuật của Liang Wang và cộng sự. Theo thẻ mô hình trên Hugging Face (đọc ngày 23/10/2026), mô hình có 12 lớp, kích thước nhúng 384, hỗ trợ 94 ngôn ngữ và dùng giấy phép MIT. Có một chi tiết kỹ thuật dễ sai: thẻ mô hình yêu cầu mỗi văn bản đầu vào phải bắt đầu bằng "query: " hoặc "passage: ", kể cả với văn bản không phải tiếng Anh. Cụ thể, dùng "query: " cho câu hỏi và "passage: " cho đoạn tài liệu. Nếu quên tiền tố, chất lượng truy xuất giảm mà hệ thống không báo lỗi. OPCAIOS dùng chính mô hình này cho tìm kiếm ngữ nghĩa nội bộ, như mô tả ở mục kinh nghiệm bên dưới.

## Làm sao đánh giá một hệ thống RAG?

Hãy tách đánh giá thành hai phần: truy xuất có lấy đúng đoạn không, và câu trả lời có đúng và có nguồn không. Cách làm thực tế:

1. Tạo bộ 30 đến 100 câu hỏi thật kèm đoạn tài liệu đúng cho từng câu.
2. Đo xem đoạn đúng có nằm trong top k không (recall@k, như Anthropic dùng với k = 20).
3. Đọc thủ công mẫu câu trả lời: có bịa không, có dẫn đúng nguồn không.
4. Lặp lại mỗi khi đổi cách cắt đoạn, mô hình nhúng hoặc lời nhắc.

## Rủi ro và lưu ý bảo mật khi dùng RAG

Rủi ro của RAG là mô hình vẫn có thể trả lời sai hoặc lộ dữ liệu, vì RAG giảm chứ không loại bỏ lỗi. Năm điểm cần giữ trước khi đưa RAG cho người dùng thật:

- **Phân quyền ở bước truy xuất:** chỉ truy xuất những tài liệu người hỏi được phép xem; nếu đưa tài liệu nội bộ vào chung một kho, người không có quyền có thể thấy qua câu trả lời.
- **Nội dung truy xuất là dữ liệu, không phải mệnh lệnh:** một tài liệu có thể chứa câu cố tình điều khiển mô hình (prompt injection); xem nguyên tắc trong [MCP là gì?](/blog/mcp-la-gi).
- **Dữ liệu cá nhân:** cân nhắc việc đưa dữ liệu khách hàng vào kho và vào lời nhắc gửi cho nhà cung cấp mô hình.
- **Tài liệu lỗi thời:** kho phải được cập nhật; đoạn cũ sẽ cho câu trả lời cũ.
- **Hiển thị nguồn:** luôn cho người dùng thấy đoạn tài liệu đã dùng để họ kiểm chứng.

## Kinh nghiệm của OPCAIOS: tìm kiếm ngữ nghĩa bằng pgvector

OPCAIOS đã dựng phần truy xuất của RAG cho khu quản trị nội bộ: tìm kiếm ngữ nghĩa trên dự án, công việc, thảo luận, phiếu hỗ trợ, tài liệu hướng dẫn, khách hàng, trao đổi với khách và cơ hội bán hàng. Bảng lưu các đoạn có cột vector 384 chiều trong PostgreSQL với pgvector, chỉ mục HNSW dùng khoảng cách cosine; văn bản được nhúng bằng mô hình multilingual-e5-small chạy trong một dịch vụ riêng chỉ nghe nội bộ, có tiền tố "query: " và "passage: "; nội dung được băm để chỉ nhúng lại khi bản ghi thay đổi, và mỗi lần lập chỉ mục có giới hạn số đoạn. Nếu dịch vụ nhúng chưa cấu hình, khu quản trị tự quay về tìm theo từ khoá. Dữ liệu được lập chỉ mục chỉ là dữ liệu nội bộ của khu quản trị. Đây là nửa "truy xuất" (R): chúng tôi dùng để tìm đúng bản ghi, chưa dựng chatbot tự viết câu trả lời từ các đoạn đó, và chưa công bố số liệu độ chính xác. Ở tầng bộ nhớ của hệ thống AIOS, tài liệu và tri thức lớn cũng được lưu trong cơ sở dữ liệu vector theo cấu trúc tài liệu, đoạn và vector, để agent tra cứu.

## Bắt đầu xây RAG như thế nào?

1. **Xác định câu hỏi và tài liệu:** chọn một nhóm tài liệu và 30 câu hỏi thật.
2. **Thử không RAG trước:** nếu tài liệu nhỏ, đưa vào lời nhắc cùng bộ nhớ đệm.
3. **Cắt đoạn theo ý nghĩa:** theo tiêu đề và đoạn văn, vài trăm token, có tiêu đề nguồn gắn kèm.
4. **Chọn mô hình nhúng đa ngôn ngữ** và cơ sở dữ liệu vector có sẵn (như pgvector).
5. **Thêm tìm theo từ khoá và xếp hạng lại** nếu đo thấy truy xuất bỏ sót.
6. **Hiển thị nguồn, phân quyền, đo lường** trước khi cho người dùng thật dùng. Muốn tự động hoá bước cập nhật kho, xem [n8n](/blog/n8n-la-gi) hoặc [Make](/blog/make-la-gi).

Đọc thêm: [Cách tạo Chatbot AI tự học tài liệu nội bộ (RAG) bằng Dify và Supabase](/blog/chatbot-ai-rag-dify-supabase).

## Câu hỏi thường gặp

### RAG là gì?
Là phương pháp lấy thông tin liên quan từ kho tri thức và đưa vào lời nhắc để mô hình AI trả lời dựa trên dữ liệu thật, thường kèm nguồn. Khái niệm xuất phát từ bài báo của Lewis và cộng sự năm 2020.

### RAG khác fine-tuning thế nào?
RAG đưa kiến thức vào lúc hỏi bằng cách tra cứu và có thể cập nhật bằng cách đổi tài liệu, còn fine-tuning thay đổi tham số của mô hình. RAG hợp với kiến thức thay đổi và cần nêu nguồn.

### Có cần RAG khi tài liệu ít không?
Không nhất thiết. Anthropic nói nếu kho dưới 200.000 token (khoảng 500 trang), bạn có thể đưa toàn bộ vào lời nhắc và dùng bộ nhớ đệm để nhanh và rẻ hơn.

### Vì sao RAG trả lời sai dù có tài liệu?

RAG trả lời sai dù có tài liệu thường là do truy xuất hỏng, tức bước tìm không đưa đúng đoạn cho mô hình. Có ba lý do hay gặp. Đầu tiên, đoạn bị mất ngữ cảnh khi cắt, chẳng hạn một đoạn chỉ ghi "doanh thu tăng 3%" mà không nói công ty nào. Tiếp theo, mô hình nhúng bỏ lỡ khớp chính xác như mã lỗi hay tên riêng. Cuối cùng, đoạn đúng không nằm trong top k. Kết hợp BM25, Contextual Retrieval và xếp hạng lại giúp giảm lỗi này: theo Anthropic, truy xuất hỏng giảm 49% với Contextual Embeddings cộng Contextual BM25 và giảm 67% khi thêm xếp hạng lại, trên các bộ dữ liệu của họ (đọc ngày 23/10/2026). Hãy đo lại trên dữ liệu của bạn trước khi tin các con số này.

### Làm RAG tiếng Việt cần lưu ý gì?
Dùng mô hình nhúng đa ngôn ngữ, kiểm tra với câu hỏi thật, và tuân thủ yêu cầu tiền tố của mô hình (như "query: " và "passage: " với E5). Muốn học cách xây hệ thống AI dùng dữ liệu riêng, xem [khoá đào tạo ứng dụng AI](/services/dao-tao-ung-dung-ai) của OPCAIOS.

*Nguồn: bài báo "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (arXiv:2005.11401, NeurIPS 2020); bài "Contextual Retrieval" của Anthropic (19/9/2024); README của pgvector; thẻ mô hình intfloat/multilingual-e5-small trên Hugging Face; đọc trực tiếp ngày 23/10/2026. Số liệu của Anthropic là trên bộ dữ liệu thử nghiệm của họ. Kinh nghiệm triển khai là của OPCAIOS, không kèm số liệu độ chính xác.*