Tìm hiểu về Retrieval-Augmented Generation (RAG)
1. RAG là gì và vai trò của nó?
Retrieval-Augmented Generation (RAG) là một kỹ thuật kết hợp giữa truy xuất thông tin và sinh ngôn ngữ tự nhiên để giúp mô hình ngôn ngữ lớn, như LLM, tạo ra câu trả lời chính xác hơn, có căn cứ hơn và phù hợp hơn với ngữ cảnh thực tế.
Thay vì chỉ dựa vào kiến thức đã được học trong quá trình huấn luyện, hệ thống RAG sẽ tìm kiếm thng tinô liên quan từ nguồn dữ liệu bên ngoài, sau đó đưa phần thông tin đó vào prompt để mô hình sinh câu trả lời.
Vai trò quan trọng nhất của RAG là giảm hiện tượng hallucination (tình trạng mô hình tạo ra câu trả lời nghe có vẻ hợp lý nhưng thực tế lại sai hoặc không có nguồn kiểm chứng). Ngoài ra, RAG còn giúp hệ thống AI có thể làm việc với dữ liệu nội bộ, dữ liệu chuyên ngành hoặc dữ liệu mới mà mô hình chưa từng được huấn luyện.
Ví dụ, nếu xây dựng chatbot hỗ trợ nhân viên trong công ty, ta không thể kỳ vọng LLM mặc định biết tất cả tài liệu nội bộ, quy trình nhân sự, chính sách bảo mật hay hướng dẫn vận hành. Với RAG, các tài liệu đó được lưu trong một kho tri thức, sau đó hệ thống sẽ truy xuất phần liên quan khi người dùng đặt câu hỏi.
Các thành phần chính của hệ thống RAG
Một hệ thống RAG có thể được chia thành hai module chính:
-
Retrieval module: chịu trách nhiệm tìm kiếm và lấy ra các đoạn thông tin liên quan nhất từ nguồn dữ liệu dựa trên câu hỏi của người dùng. Đây là phần giúp hệ thống xác định thông tin nào cần được cung cấp cho LLM làm ngữ cảnh trước khi trả lời.
-
Generation module: chịu trách nhiệm dùng câu hỏi của người dùng cùng với thông tin đã truy xuất để sinh ra câu trả lời tự nhiên, mạch lạc và có căn cứ.
Ngoài hai module chính, một hệ thống RAG thực tế thường có thêm các bước tiền xử lý như thu thập dữ liệu, chia nhỏ tài liệu, tạo embedding, lưu vào vector database, đánh giá chất lượng truy xuất và kiểm soát đầu ra.
Quy trình hoạt động tổng quát của RAG
Quy trình cơ bản của RAG như ảnh sau:
Điểm cốt lõi ở đây là LLM không còn trả lời hoàn toàn dựa trên trí nhớ của mô hình, mà trả lời dựa trên thông tin được truy xuất tại thời điểm người dùng đặt câu hỏi.
2. Chi tiết về Retrieval
Retrieval là phần rất quan trọng trong RAG, vì chất lượng câu trả lời phụ thuộc trực tiếp vào chất lượng thông tin được truy xuất. Nếu retrieval lấy sai tài liệu, thiếu tài liệu hoặc lấy quá nhiều thông tin nhiễu, generation module rất khó tạo ra câu trả lời tốt.
Thu thập và chuẩn hóa dữ liệu
Trước khi có thể truy xuất, hệ thống cần xây dựng một kho tri thức. Dữ liệu có thể đến từ nhiều nguồn như tài liệu kỹ thuật, bài viết, tài liệu sản phẩm, email, log hỗ trợ khách hàng, cơ sở dữ liệu quan hệ, file Markdown, PDF hoặc trang web.
Ở bước này, dữ liệu nên được làm sạch và chuẩn hóa. Ví dụ, cần loại bỏ nội dung trùng lặp, header/footer không cần thiết, ký tự lỗi, quảng cáo, menu điều hướng hoặc những phần không mang nhiều giá trị ngữ nghĩa. Dữ liệu đầu vào càng sạch thì kết quả truy xuất càng ổn định.
Chunking: chia nhỏ tài liệu
LLM và hệ thống embedding thường không xử lý toàn bộ tài liệu dài cùng lúc. Vì vậy, tài liệu cần được chia thành các đoạn nhỏ hơn, gọi là chunks.
Nếu chunk quá ngắn, nó có thể thiếu ngữ cảnh. Nếu chunk quá dài, nó có thể chứa nhiều thông tin không liên quan, làm giảm độ chính xác khi truy xuất. Kích thước chunk thường phụ thuộc vào loại tài liệu, mô hình embedding, độ dài context window của LLM và mục tiêu ứng dụng.
Một số chiến lược chunking phổ biến gồm chia theo số lượng token, chia theo đoạn văn, chia theo tiêu đề, chia theo cấu trúc Markdown hoặc chia theo đơn vị ngữ nghĩa. Với tài liệu kỹ thuật, chia theo heading thường hiệu quả hơn chia cứng theo độ dài, vì nó giữ được cấu trúc logic của nội dung. Ba chiến lược chunking phổ biến nhất — fixed-size, recursive, và semantic — mỗi loại phù hợp với một loại dữ liệu và mục tiêu khác nhau.
So sánh nhanh
| Tiêu chí | Fixed-size | Recursive | Semantic |
|---|---|---|---|
| Tốc độ xử lý | Rất nhanh | Nhanh | Chậm (cần embedding từng câu) |
| Chi phí compute | Thấp | Thấp | Cao |
| Tôn trọng ngữ nghĩa | Không | Một phần (theo cấu trúc hình thức) | Có (dựa trên độ tương đồng thực sự) |
| Độ đồng đều kích thước chunk | Rất đều | Khá đều | Không đều |
| Độ phức tạp triển khai | Rất đơn giản | Đơn giản–trung bình | Phức tạp hơn |
Embedding
Embedding là quá trình chuyển văn bản thành vector số học. Các đoạn văn có ý nghĩa gần nhau sẽ có vector nằm gần nhau trong không gian vector. Nhờ đó, hệ thống có thể tìm kiếm theo ý nghĩa thay vì chỉ khớp từ khóa.
Ví dụ, câu hỏi "Làm sao đặt lại mật khẩu?" có thể truy xuất được tài liệu có nội dung "Hướng dẫn reset password", dù hai câu không hoàn toàn giống nhau về mặt từ vựng. Đây là ưu điểm lớn của semantic search.
Chất lượng embedding model ảnh hưởng mạnh đến chất lượng retrieval. Với hệ thống đa ngôn ngữ hoặc tiếng Việt, cần chọn embedding model hỗ trợ tốt ngôn ngữ mục tiêu. Nếu dữ liệu thuộc lĩnh vực đặc thù như y tế, luật, tài chính hoặc kỹ thuật, có thể cần đánh giá nhiều mô hình embedding khác nhau trước khi triển khai.
Vector Database
Vector database là nơi lưu trữ và tìm kiếm các embedding. Khi người dùng gửi câu hỏi, hệ thống tạo embedding cho câu hỏi đó, sau đó tìm các vector gần nhất trong cơ sở dữ liệu.
Một số vector database phổ biến gồm Milvus, Qdrant, Chroma và FAISS. Ngoài vector, mỗi chunk thường đi kèm metadata như tên tài liệu, đường dẫn nguồn, ngày cập nhật, loại tài liệu, quyền truy cập hoặc chủ đề. Metadata giúp lọc kết quả tốt hơn, đặc biệt trong hệ thống doanh nghiệp.
Ví dụ, nếu người dùng thuộc phòng nhân sự, hệ thống có thể ưu tiên hoặc giới hạn tìm kiếm trong nhóm tài liệu nhân sự. Nếu tài liệu có phiên bản, hệ thống có thể chỉ lấy bản mới nhất để tránh trả lời dựa trên thông tin cũ.
Similarity Search và Hybrid Search
Cách truy xuất phổ biến nhất là similarity search, tức tìm các vector gần nhất với vector của câu hỏi. Các độ đo thường dùng gồm cosine similarity, dot product hoặc Euclidean distance.
So sánh 3 độ đo tương đồng vector
| Độ đo | Công thức (ý tưởng) | Đo cái gì | Khi nào dùng |
|---|---|---|---|
| Cosine similarity | Góc giữa 2 vector (bỏ qua độ dài) | Hướng của vector có giống nhau không | Khi chỉ quan tâm ngữ nghĩa/hướng, không quan tâm độ dài vector (phổ biến nhất cho text embedding) |
| Dot product | Tổng tích từng thành phần của 2 vector | Vừa hướng vừa độ lớn (magnitude) | Khi model embedding đã chuẩn hóa sẵn, hoặc muốn vector "mạnh" (magnitude lớn) được ưu tiên hơn |
| Euclidean distance | Khoảng cách hình học giữa 2 điểm trong không gian | Khoảng cách tuyệt đối, không quan tâm hướng | Khi vị trí thực trong không gian có ý nghĩa (ít dùng cho text embedding, phổ biến hơn ở dữ liệu số/hình ảnh) |
Lưu ý khi chọn:
- Với text embedding (kiểu bạn đang dùng cho tài liệu lưu trữ), cosine similarity là lựa chọn mặc định phổ biến nhất vì embedding thường mang thông tin ngữ nghĩa qua hướng vector, không phải độ dài.
- Nếu embedding model đã chuẩn hóa vector về độ dài 1 (unit vector) thì cosine similarity và dot product cho kết quả tương đương — lúc đó nên chọn dot product vì tính toán nhanh hơn (không cần chia chuẩn hóa mỗi lần so sánh).
- Qdrant hỗ trợ cả 3 độ đo này khi khai báo collection (
Distance.COSINE,Distance.DOT,Distance.EUCLID), và không thể đổi độ đo sau khi đã tạo collection — cần chọn đúng ngay từ đầu.
Tuy nhiên, semantic search không phải lúc nào cũng đủ. Trong nhiều trường hợp, người dùng hỏi bằng mã sản phẩm, tên API, số hiệu lỗi hoặc thuật ngữ nội bộ. Khi đó, keyword search truyền thống lại rất hữu ích. Vì vậy, nhiều hệ thống RAG hiện đại sử dụng hybrid search, kết hợp semantic search và keyword search để tăng độ chính xác.
Ví dụ, với câu hỏi "Lỗi E102 trong service billing là gì?", hệ thống cần khớp chính xác "E102" và "billing", đồng thời vẫn hiểu ngữ cảnh tổng thể của câu hỏi. Hybrid search thường phù hợp hơn semantic search thuần túy trong các trường hợp như vậy.
Reranking
Sau khi retrieval lấy ra một tập kết quả ban đầu, hệ thống có thể dùng reranker để sắp xếp lại các tài liệu theo mức độ liên quan. Retrieval ban đầu thường ưu tiên tốc độ và khả năng tìm rộng, trong khi reranking tập trung vào đánh giá sâu hơn giữa câu hỏi và từng đoạn văn.
Cách làm này thường gọi là two-stage retrieval. Giai đoạn đầu lấy nhiều ứng viên, ví dụ top 20 hoặc top 50. Giai đoạn hai dùng reranker chọn ra top 3 đến top 5 đoạn phù hợp nhất để đưa vào prompt.
Reranking đặc biệt hữu ích khi kho dữ liệu lớn, câu hỏi phức tạp hoặc có nhiều đoạn tài liệu gần giống nhau.
3. Generation
Generation là giai đoạn LLM tạo câu trả lời dựa trên câu hỏi của người dùng và các đoạn thông tin được retrieval module cung cấp. Nếu retrieval là bước "tìm tài liệu", generation là bước "đọc tài liệu và diễn giải câu trả lời".
Prompt Augmentation
Trong RAG, prompt không chỉ chứa câu hỏi của người dùng mà còn chứa context được truy xuất. Một prompt đơn giản có thể có cấu trúc như sau:
Bạn là trợ lý trả lời dựa trên tài liệu được cung cấp.
Câu hỏi:
{user_question}
Ngữ cảnh:
{retrieved_context}
Yêu cầu:
- Chỉ trả lời dựa trên ngữ cảnh.
- Nếu ngữ cảnh không có thông tin, hãy nói rằng chưa đủ dữ liệu.
- Trả lời rõ ràng, ngắn gọn và có trích dẫn nguồn nếu có.
Thiết kế prompt tốt giúp mô hình giảm suy diễn ngoài tài liệu. Với các ứng dụng yêu cầu độ tin cậy cao, prompt nên yêu cầu mô hình nêu rõ khi không tìm thấy đủ thông tin thay vì cố gắng trả lời.
Grounded Generation
Một câu trả lời tốt trong RAG cần được "grounded", tức có căn cứ trong tài liệu đã truy xuất. Điều này khác với việc LLM tự tạo câu trả lời dựa trên xác suất ngôn ngữ.
Ví dụ, nếu tài liệu nói rằng chính sách hoàn tiền là 14 ngày, mô hình không nên trả lời là 30 ngày chỉ vì đó là chính sách phổ biến ở nhiều nơi. Câu trả lời phải bám vào context được cung cấp.
Trích dẫn nguồn
Một điểm mạnh của RAG là có thể cung cấp nguồn tham khảo đi kèm câu trả lời. Mỗi chunk nên lưu metadata về tài liệu gốc, như tên file, URL, tiêu đề mục hoặc số trang. Khi generation tạo câu trả lời, hệ thống có thể hiển thị nguồn để người dùng kiểm chứng.
Trích dẫn nguồn không chỉ tăng độ tin cậy mà còn giúp debug hệ thống. Nếu câu trả lời sai, ta có thể kiểm tra xem lỗi đến từ retrieval lấy sai tài liệu hay generation diễn giải sai.
Kiểm soát hallucination
Dù RAG giúp giảm hallucination, nó không loại bỏ hoàn toàn vấn đề này. LLM vẫn có thể diễn giải quá mức, kết hợp sai nhiều đoạn context hoặc trả lời vượt ra ngoài tài liệu.
Một số biện pháp kiểm soát gồm:
- Yêu cầu mô hình chỉ dùng context.
- Giới hạn định dạng câu trả lời.
- Thêm bước kiểm chứng sau generation.
- Yêu cầu trích dẫn từng luận điểm quan trọng.
- Thiết lập ngưỡng độ tin cậy cho retrieval — nếu điểm liên quan của tài liệu quá thấp, hệ thống nên từ chối trả lời hoặc yêu cầu người dùng cung cấp thêm thông tin.
4. Cách tối ưu hóa RAG
Tối ưu hóa RAG không chỉ là chọn một vector database tốt hay một LLM mạnh. RAG là một pipeline gồm nhiều thành phần, vì vậy cần tối ưu từ dữ liệu, chunking, embedding, retrieval, prompt, generation đến đánh giá.
Tối ưu dữ liệu đầu vào
Dữ liệu là nền tảng của RAG. Nếu dữ liệu lỗi thời, trùng lặp, thiếu cấu trúc hoặc chứa nhiều nhiễu, hệ thống khó tạo ra kết quả tốt.
Cần có quy trình cập nhật dữ liệu định kỳ, loại bỏ tài liệu cũ, đánh dấu phiên bản, chuẩn hóa format và kiểm soát quyền truy cập. Với tài liệu doanh nghiệp, metadata cũng rất quan trọng vì nó cho phép lọc theo phòng ban, thời gian, sản phẩm hoặc cấp quyền.
Tối ưu chunking
Chunking nên được điều chỉnh dựa trên dữ liệu thực tế. Không nên mặc định dùng một kích thước chunk cho mọi loại tài liệu. Tài liệu hỏi đáp ngắn, tài liệu kỹ thuật dài, hợp đồng pháp lý và API documentation có cấu trúc rất khác nhau.
Một hướng thực tế là thử nhiều cấu hình chunk size và chunk overlap, sau đó đánh giá bằng tập câu hỏi kiểm thử. Chunk overlap giúp giữ ngữ cảnh giữa hai đoạn liền kề, nhưng nếu overlap quá nhiều sẽ làm tăng chi phí lưu trữ và gây trùng lặp kết quả.
Tối ưu embedding model
Không có embedding model tốt nhất cho mọi trường hợp. Cần đánh giá embedding model trên chính dữ liệu và câu hỏi của hệ thống. Với dữ liệu tiếng Việt, nên kiểm tra khả năng hiểu đồng nghĩa, thuật ngữ chuyên ngành, viết tắt và câu hỏi không dấu nếu ứng dụng có khả năng gặp tình huống này.
Một số tiêu chí đánh giá gồm recall@k, precision@k, MRR, nDCG và chất lượng câu trả lời cuối cùng. Trong thực tế, chỉ số retrieval tốt chưa chắc đã đảm bảo câu trả lời tốt, nhưng retrieval kém gần như chắc chắn làm generation kém.
Dùng Hybrid Search
Hybrid search kết hợp semantic search và lexical search, giúp hệ thống xử lý tốt cả câu hỏi theo ý nghĩa lẫn câu hỏi chứa keyword chính xác. Đây là kỹ thuật rất hữu ích với dữ liệu kỹ thuật, mã lỗi, tên sản phẩm, tên hàm, số hợp đồng hoặc thuật ngữ nội bộ.
Dùng Reranking
Reranking thường là một trong những cách cải thiện RAG hiệu quả nhất. Thay vì đưa thẳng top-k kết quả từ vector search vào prompt, hệ thống lấy nhiều kết quả hơn, sau đó dùng reranker chọn lại các đoạn tốt nhất.
Cách này giúp giảm nhiễu trong context, cải thiện độ chính xác và tận dụng context window hiệu quả hơn.
Query Rewriting
Người dùng không phải lúc nào cũng đặt câu hỏi rõ ràng. Query rewriting dùng LLM hoặc rule-based system để viết lại câu hỏi thành dạng dễ truy xuất hơn.
Ví dụ, câu hỏi "cái này deploy sao?" có thể được viết lại thành "Hướng dẫn deploy ứng dụng lên môi trường production". Với hội thoại nhiều lượt, query rewriting còn có thể bổ sung ngữ cảnh từ các câu trước để biến câu hỏi ngắn thành câu hỏi đầy đủ.
Context Compression
Khi retrieval trả về nhiều tài liệu, không phải tất cả nội dung đều cần đưa vào prompt. Context compression giúp rút gọn hoặc lọc context trước khi gửi cho LLM. Điều này giúp giảm chi phí token, giảm nhiễu và tăng khả năng mô hình tập trung vào thông tin quan trọng.
Đánh giá hệ thống RAG
Một hệ thống RAG nghiêm túc cần có bộ câu hỏi đánh giá. Mỗi câu hỏi nên có câu trả lời kỳ vọng và nguồn tài liệu đúng. Khi thay đổi embedding model, chunk size, reranker hoặc prompt, ta có thể chạy lại bộ đánh giá để biết thay đổi đó có thật sự cải thiện hệ thống hay không.
Có thể đánh giá ở hai mức:
- Mức retrieval: đo xem hệ thống có tìm đúng tài liệu hay không.
- Mức generation: đo xem câu trả lời cuối cùng có đúng, đầy đủ, dễ hiểu và có căn cứ hay không.
Monitoring sau triển khai
Sau khi đưa vào production, cần theo dõi log câu hỏi, tài liệu được truy xuất, câu trả lời, phản hồi người dùng, latency và chi phí. RAG không phải hệ thống cấu hình một lần rồi bỏ đó. Khi dữ liệu thay đổi và hành vi người dùng thay đổi, pipeline cũng cần được điều chỉnh.
Kết luận
RAG là một trong những kiến trúc quan trọng nhất để xây dựng ứng dụng AI dựa trên LLM trong thực tế. Bằng cách kết hợp retrieval và generation, RAG giúp mô hình trả lời dựa trên dữ liệu cụ thể, cập nhật và có thể kiểm chứng.
Tuy nhiên, RAG không đơn giản chỉ là "đưa tài liệu vào vector database rồi hỏi LLM". Một hệ thống RAG tốt cần dữ liệu sạch, chunking hợp lý, embedding phù hợp, retrieval chính xác, reranking hiệu quả, prompt rõ ràng và quy trình đánh giá liên tục.
Nếu được thiết kế tốt, RAG có thể trở thành nền tảng cho nhiều ứng dụng như chatbot nội bộ, trợ lý chăm sóc khách hàng, tìm kiếm tài liệu thông minh, phân tích tri thức doanh nghiệp và hệ thống hỏi đáp chuyên ngành.
All rights reserved
