RAG là gì?
RAG, viết tắt của Retrieval-Augmented Generation (tạo sinh có truy xuất), là cách cho model AI tra cứu một nguồn dữ liệu trước khi trả lời. Thay vì chỉ dựa vào kiến thức học được lúc huấn luyện, ứng dụng tìm các đoạn tài liệu liên quan tới câu hỏi, đưa chúng vào prompt, rồi yêu cầu model trả lời dựa trên các đoạn đó.
Có thể hình dung như thi được mở sách: model vẫn là người viết bài, nhưng được lật đúng trang tài liệu trước khi viết. Thuật ngữ RAG xuất hiện trong một bài báo của nhóm Facebook AI Research (nay thuộc Meta) năm 2020, và nay là cách phổ biến để xây chatbot hỏi đáp theo tài liệu nội bộ, trợ lý chăm sóc khách hàng hay công cụ tra cứu quy trình.
Vì sao cần RAG?
Một LLM dù mạnh vẫn có những giới hạn mà RAG giải quyết được:
- Không biết dữ liệu riêng của bạn: quy trình nội bộ, hợp đồng, tài liệu sản phẩm hay lịch sử hỗ trợ khách hàng không nằm trong dữ liệu huấn luyện.
- Có mốc kiến thức: model không biết điều xảy ra sau thời điểm dừng huấn luyện, trong khi tài liệu của bạn có thể đổi hằng tuần.
- Có thể bịa thông tin: khi không có dữ kiện trong tay, model vẫn viết ra câu nghe hợp lý. Đưa đúng đoạn tài liệu vào prompt và dặn model chỉ trả lời theo đó giúp giảm lỗi này, đồng thời cho phép trích dẫn nguồn để người đọc tự kiểm.
- Cập nhật nhẹ: tài liệu đổi thì chỉ cần cập nhật kho tra cứu, không phải huấn luyện lại model.
RAG hoạt động thế nào?
Một hệ thống RAG có hai giai đoạn. Giai đoạn chuẩn bị chạy một lần và chạy lại khi tài liệu đổi; giai đoạn trả lời chạy mỗi khi có câu hỏi:
- Thu thập tài liệu: file PDF, Word, trang wiki nội bộ, dữ liệu từ cơ sở dữ liệu hay phần mềm quản lý khách hàng.
- Chia nhỏ (chunking): cắt tài liệu thành các đoạn vài trăm tới vài nghìn token, thường cho các đoạn chồng lên nhau một chút để không mất ý ở chỗ cắt.
- Tạo embedding cho từng đoạn bằng một model embedding, rồi lưu vào vector database kèm thông tin đi theo như tên file, ngày cập nhật, ai được xem.
- Khi có câu hỏi, tạo embedding cho câu hỏi bằng đúng model embedding đó rồi tìm các đoạn có nghĩa gần với câu hỏi, thường lấy khoảng 5 tới 20 đoạn.
- Xếp hạng lại (rerank) nếu cần, để chỉ giữ các đoạn thật sự trả lời được câu hỏi.
- Ghép các đoạn tìm được vào prompt cùng lời dặn, ví dụ “chỉ trả lời theo tài liệu dưới đây, ghi rõ nguồn, không có thông tin thì nói không biết”, rồi gửi cho LLM để viết câu trả lời.
Embedding và vector database là gì?
Embedding là cách biến một đoạn chữ thành một dãy số (vector), thường vài trăm tới vài nghìn chiều, sao cho các đoạn có nghĩa gần nhau thì vector cũng nằm gần nhau. Nhờ vậy, câu hỏi “quên mật khẩu thì làm sao” vẫn tìm ra đoạn “hướng dẫn khôi phục tài khoản”, dù hai câu không có chữ nào trùng nhau.
Vector database là nơi lưu các vector này và tìm nhanh những vector gần với vector của câu hỏi. Nếu đã dùng PostgreSQL, tiện ích pgvector là cách bắt đầu gọn; ngoài ra có các hệ chuyên dụng như Qdrant, Milvus, Weaviate, Pinecone, Chroma.
Hai lưu ý: tài liệu và câu hỏi phải dùng cùng một model embedding, đổi model embedding thì phải tạo lại embedding cho toàn bộ tài liệu. Tìm theo nghĩa lại hay bỏ sót mã sản phẩm, số hiệu văn bản, tên riêng, nên nhiều hệ thống kết hợp thêm tìm theo từ khoá (hybrid search).
RAG, fine-tuning hay gửi cả tài liệu trong prompt?
Có ba cách cho model dùng kiến thức của bạn, mỗi cách hợp một hoàn cảnh:
- Gửi cả tài liệu trong prompt: nhiều model hiện nay có cửa sổ ngữ cảnh 1 triệu token, nên bộ tài liệu nhỏ có thể gửi kèm luôn, không cần dựng hệ thống. Đổi lại, lần hỏi nào cũng tốn token cho cả bộ tài liệu, và model có thể bỏ sót chi tiết nằm giữa văn bản dài.
- RAG: hợp khi kho tài liệu lớn hơn cửa sổ ngữ cảnh, đổi thường xuyên, cần trích dẫn nguồn hoặc cần phân quyền ai được xem tài liệu nào. Mỗi lần hỏi chỉ gửi vài đoạn liên quan nên tốn ít token hơn.
- Fine-tuning (huấn luyện thêm): đổi cách model viết, như giọng văn, định dạng đầu ra hay cách phân loại. Fine-tuning không hợp để nạp dữ kiện thay đổi thường xuyên, vì dữ kiện đổi là phải huấn luyện lại.
- Ba cách dùng chung được: ví dụ fine-tuning để model viết đúng giọng thương hiệu, RAG để lấy dữ kiện mới cho từng câu hỏi.
Những lỗi hay gặp khi làm RAG
Phần lớn câu trả lời sai của hệ thống RAG đến từ khâu tìm tài liệu, không phải từ model:
- Chia đoạn không hợp: đoạn quá ngắn thì mất ngữ cảnh, quá dài thì lẫn nhiều ý và tốn token. Chia theo cấu trúc tài liệu (đề mục, điều khoản) thường cho kết quả tốt hơn cắt theo số ký tự.
- Tìm sai đoạn: câu hỏi dùng chữ khác tài liệu, hoặc hỏi về mã số, tên riêng. Kết hợp tìm theo từ khoá, cho model viết lại câu hỏi trước khi tìm, hoặc thêm bước rerank.
- Kho tra cứu cũ: tài liệu đã sửa nhưng chưa tạo lại embedding, model trả lời theo bản cũ. Cần cập nhật theo lịch hoặc ngay khi tài liệu đổi.
- Lộ tài liệu: không lọc theo quyền thì nhân viên có thể hỏi ra tài liệu họ không được xem. Lưu quyền xem cùng mỗi đoạn và lọc trước khi đưa vào prompt.
- Model vẫn bịa khi thiếu dữ kiện: dặn rõ rằng không có thông tin thì nói không biết; cách viết lời dặn có ở bài prompt là gì.
- Không đo chất lượng: chuẩn bị một bộ câu hỏi mẫu kèm đáp án đúng, chạy lại mỗi lần đổi cách chia đoạn, model embedding hay prompt.
RAG trong các công cụ AI quen thuộc
Nhiều sản phẩm bạn đang dùng làm đúng việc này: Gemini Notebook (tên mới của NotebookLM) trả lời theo bộ tài liệu bạn đưa vào, kèm trích dẫn; Perplexity tìm trên web rồi tóm tắt kèm nguồn; coding agent tìm trong mã nguồn những file liên quan trước khi sửa code.
Kiểu mới hơn gọi là agentic RAG: thay vì tìm một lần theo câu hỏi, AI agent tự quyết định khi nào cần tìm, tìm ở đâu và tìm thêm nếu kết quả chưa đủ. Để agent nối được với Google Drive, Notion hay cơ sở dữ liệu của bạn, chuẩn phổ biến hiện nay là MCP.
Tự làm RAG cần những gì?
Một bản RAG đơn giản gồm năm phần:
- Đoạn mã đọc và chia nhỏ tài liệu; thư viện như LangChain hay LlamaIndex có sẵn các bước này.
- Một model embedding, gọi qua API hoặc model mở tự chạy.
- Một vector database, như pgvector nếu đã dùng PostgreSQL.
- Một LLM để viết câu trả lời, gọi qua API. Phần lớn thư viện RAG gọi model theo chuẩn OpenAI, nên đổi model chỉ cần đổi base URL và tên model; xem bài OpenAI-compatible API là gì.
- Một bộ câu hỏi mẫu để đo chất lượng trước khi đưa cho người dùng.
Gọi model viết câu trả lời bằng một API key
Bước viết câu trả lời là bước tốn token nhiều trong RAG, vì mỗi câu hỏi gửi kèm các đoạn tài liệu tìm được. STEYG Code cho một API key gọi được Claude, GPT, DeepSeek, GLM và Qwen theo chuẩn OpenAI, trả trước bằng VND và không bao giờ bị tính quá số tiền đã trả. Cách ước lượng số token mỗi lần hỏi có ở bài 1 triệu token là bao nhiêu chữ, cách mua có ở bài mua API Claude, GPT thanh toán bằng VND.
Câu hỏi thường gặp
RAG là viết tắt của gì?
RAG là Retrieval-Augmented Generation, tạm dịch là tạo sinh có truy xuất: ứng dụng tìm tài liệu liên quan trước, rồi model AI viết câu trả lời dựa trên tài liệu đó.
RAG khác fine-tuning thế nào?
RAG đưa dữ kiện vào prompt lúc hỏi, nên cập nhật được ngay khi tài liệu đổi và trích dẫn được nguồn. Fine-tuning huấn luyện thêm model để đổi cách viết, định dạng hay cách phân loại, không hợp để nạp dữ kiện thay đổi thường xuyên.
Model có cửa sổ ngữ cảnh 1 triệu token thì còn cần RAG không?
Với bộ tài liệu nhỏ, gửi kèm cả tài liệu trong prompt là đủ và đơn giản hơn. RAG vẫn cần khi kho tài liệu lớn hơn cửa sổ ngữ cảnh, khi muốn giảm số token mỗi lần hỏi, hoặc khi cần phân quyền ai được xem tài liệu nào.
Không biết lập trình có dùng được RAG không?
Tự dựng hệ thống thì cần lập trình. Nếu chỉ cần hỏi đáp theo tài liệu của mình, có thể dùng công cụ có sẵn như Gemini Notebook (NotebookLM) hoặc tải file vào Project của ChatGPT, Claude hay Perplexity.