RAG là gì? Retrieval-Augmented Generation — khi AI biết tra cứu tài liệu

RAG — viết tắt của Retrieval-Augmented Generation — là kỹ thuật kết hợp khả năng sinh ngôn ngữ của LLM với bước tra cứu tài liệu thực tế trước khi trả lời, giúp AI không còn phải "đoán mò" từ trí nhớ tham số cố định. Bài viết này giải thích toàn bộ kiến trúc RAG từng bước, cách xây dựng, so sánh với fine-tuning và ứng dụng trong doanh nghiệp.

RAG là gì?

RAG (Retrieval-Augmented Generation) là phương pháp bổ sung kiến thức cho mô hình ngôn ngữ lớn bằng cách tự động tra cứu tài liệu liên quan rồi đưa nội dung đó vào prompt trước khi mô hình sinh câu trả lời. Thay vì chỉ dựa vào kiến thức được "nướng cứng" vào tham số trong quá trình huấn luyện, mô hình RAG có thêm một nguồn thông tin bên ngoài — linh hoạt, cập nhật được và kiểm chứng được.

Cách ví dễ hiểu nhất: hãy nghĩ đến kỳ thi mở sách (open-book exam). Một sinh viên thi đóng sách phải nhớ hết trong đầu — dễ nhầm, dễ bịa. Sinh viên thi mở sách được phép tra giáo trình trước khi trả lời — câu trả lời chính xác hơn, có nguồn gốc rõ ràng hơn. RAG biến LLM từ "thi đóng sách" thành "thi mở sách".

Vấn đề RAG giải quyết

Trước khi hiểu RAG hoạt động ra sao, cần nắm ba điểm đau mà nó nhắm đến.

Hallucination — AI bịa thông tin

LLM sinh văn bản bằng cách dự đoán token tiếp theo dựa trên xác suất. Khi không có đủ thông tin trong tham số, mô hình vẫn có thể tự tin sinh ra câu trả lời hoàn toàn sai — một hiện tượng gọi là hallucination. Trong môi trường doanh nghiệp, điều này gây ra rủi ro nghiêm trọng: báo cáo sai, tư vấn pháp lý không chính xác, hỗ trợ kỹ thuật gây lỗi.

Knowledge cutoff — Kiến thức bị đóng băng

Mọi LLM đều có ngưỡng thời gian huấn luyện (cutoff). Sau ngày đó, mô hình không biết gì về các sự kiện, quy định, hoặc sản phẩm mới. Với doanh nghiệp, tài liệu nội bộ (hợp đồng, chính sách, catalog sản phẩm) thay đổi liên tục — huấn luyện lại mô hình mỗi khi có bản cập nhật là không khả thi về chi phí và thời gian.

Kiến thức riêng của doanh nghiệp không có trong mô hình

Dữ liệu nội bộ (tài liệu kỹ thuật nội bộ, lịch sử chăm sóc khách hàng, báo cáo kinh doanh) không bao giờ xuất hiện trong tập huấn luyện công khai. LLM không thể biết những gì chưa từng được đọc.

Kiến trúc RAG từng bước

Hệ thống RAG điển hình chia làm hai giai đoạn: indexing (nạp và lập chỉ mục tài liệu) chạy offline, và retrieval + generation (truy hồi và sinh) chạy online khi người dùng hỏi.

Giai đoạn 1 — Indexing (offline)

Bước 1: Nạp tài liệu (Document Loading) Tài liệu từ nhiều nguồn (PDF, Word, trang web, database, Confluence, Notion...) được đọc vào và chuẩn hóa về dạng văn bản thuần.

Bước 2: Chunking — Chia nhỏ tài liệu Tài liệu dài được cắt thành các đoạn nhỏ hơn gọi là chunk. Đây là bước quan trọng nhất trong RAG — chunk quá dài gây nhiễu, chunk quá ngắn mất ngữ cảnh. Thông thường dùng 256–512 token mỗi chunk, với overlap 10–20% để không đứt mạch ý.

Bước 3: Embedding — Tạo vector Mỗi chunk được đưa qua mô hình embedding (ví dụ text-embedding-3-large của OpenAI, embedding-001 của Google) để chuyển thành vector số thực nhiều chiều. Các đoạn có nghĩa tương đồng sẽ có vector gần nhau trong không gian.

Bước 4: Lưu vào vector database Cặp (chunk text, vector) được lưu vào vector database như Pinecone, Weaviate, Qdrant, hoặc pgvector — sẵn sàng để tìm kiếm.

Giai đoạn 2 — Retrieval + Generation (online)

Bước 5: Câu hỏi người dùng được embed Khi người dùng đặt câu hỏi, câu hỏi đó cũng được chạy qua cùng mô hình embedding để tạo query vector.

Bước 6: Truy hồi top-k chunk Vector database tìm k chunk có vector gần nhất với query vector nhất (thường k = 3–10), dùng cosine similarity hoặc dot product.

Bước 7: Ghép vào prompt (Context Augmentation) Các chunk được truy hồi được ghép vào prompt trước câu hỏi của người dùng, tạo thành một prompt đầy đủ ngữ cảnh.

Bước 8: LLM sinh câu trả lời LLM nhận prompt đã được bổ sung tài liệu và sinh ra câu trả lời — có căn cứ, có nguồn gốc rõ ràng.

 1[Prompt mẫu]
 2
 3Bạn là trợ lý hỗ trợ kỹ thuật. Hãy trả lời câu hỏi dựa trên tài liệu sau:
 4
 5--- TÀI LIỆU ---
 6{chunk_1}
 7{chunk_2}
 8{chunk_3}
 9--- HẾT TÀI LIỆU ---
10
11Câu hỏi: {user_question}
12Trả lời ngắn gọn, chính xác. Nếu tài liệu không đủ thông tin, hãy nói rõ.

Embedding và Vector Database — Giải thích đơn giản

Embedding là gì?

Hãy tưởng tượng một bản đồ ngữ nghĩa: từ "chó" và "mèo" nằm gần nhau vì đều là thú cưng; từ "ngân hàng" (tài chính) và "ngân hàng" (bờ sông) nằm xa nhau dù cùng mặt chữ. Embedding là kỹ thuật biểu diễn văn bản thành tọa độ trên bản đồ ngữ nghĩa đó — dưới dạng vector hàng nghìn chiều.

Mô hình embedding được huấn luyện trên hàng tỷ cặp câu tương đồng để học cách đặt vector: câu "Sản phẩm bị lỗi nguồn" và "Máy không lên điện" sẽ nằm gần nhau, kể cả khi không dùng từ nào giống nhau.

Vector Database là gì?

Vector database là công cụ tìm kiếm được xây dựng đặc biệt cho dữ liệu vector. Không giống SQL tìm kiếm bằng điều kiện bằng/lớn hơn/nhỏ hơn, vector database tính độ tương đồng giữa query vector và mọi vector trong kho, rồi trả về k kết quả gần nhất. Thuật toán ANN (Approximate Nearest Neighbor) như HNSW giúp tìm kiếm cực nhanh ngay cả với hàng triệu vector.

Cách xây dựng RAG hiệu quả

Chunking strategy

Chunking là nơi quyết định chất lượng RAG nhiều nhất. Một số chiến lược phổ biến:

• Fixed-size chunking: cắt theo số token cố định, đơn giản nhưng có thể đứt câu giữa chừng.
• Sentence / paragraph chunking: cắt theo ranh giới câu hoặc đoạn văn — ngữ cảnh tự nhiên hơn.
• Recursive chunking: thử cắt theo đoạn lớn trước, nếu quá dài mới cắt nhỏ hơn — giữ được cấu trúc tài liệu.
• Semantic chunking: dùng embedding để tự phát hiện điểm chuyển ý, cắt tại đó — chất lượng cao nhất nhưng tốn kém hơn.

Re-ranking — Cải thiện chất lượng top-k

Bước truy hồi vector ban đầu ưu tiên tốc độ (ANN), đôi khi trả về chunk liên quan nhưng chưa đủ chính xác. Re-ranker (như Cohere Rerank hay cross-encoder) đọc lại từng cặp (query, chunk) và chấm điểm chi tiết hơn, sắp xếp lại danh sách trước khi đưa vào prompt. Re-ranking cải thiện đáng kể độ chính xác nhưng thêm latency ~100–300ms.

Điều chỉnh số lượng top-k

k lớn hơn nghĩa là nhiều ngữ cảnh hơn cho LLM — nhưng cũng làm prompt dài hơn, tốn token hơn, và đôi khi gây "lost in the middle" (LLM bỏ qua thông tin giữa prompt dài). Thực nghiệm thường bắt đầu với k=5, sau đó điều chỉnh theo chất lượng câu trả lời thực tế.

RAG vs Fine-tuning — So sánh thực tiễn

Ứng dụng thực tế của RAG

Chatbot hỏi-đáp tài liệu nội bộ

Đây là use case phổ biến nhất: nhân viên có thể hỏi trực tiếp về chính sách công ty, quy trình vận hành, hướng dẫn kỹ thuật — thay vì lục tìm thủ công trong hàng trăm file. Hệ thống truy hồi đúng đoạn tài liệu và sinh câu trả lời ngắn gọn, có trích dẫn.

Hỗ trợ khách hàng tự động

Chatbot chăm sóc khách hàng được nạp toàn bộ FAQ, catalog sản phẩm, chính sách bảo hành. Khi khách hỏi về một lỗi cụ thể, hệ thống tìm đúng hướng dẫn xử lý và trả lời chính xác — không còn phải lập trình thủ công mọi kịch bản.

Tra cứu pháp lý và y tế

Trong lĩnh vực cần độ chính xác cao như pháp lý hoặc y tế, RAG cho phép AI tham chiếu đến văn bản pháp quy, protocol điều trị cụ thể — và quan trọng là có thể hiển thị nguồn để người dùng kiểm chứng.

Phân tích dữ liệu doanh nghiệp với RAG

RAG không chỉ giới hạn ở văn bản tĩnh. Kết hợp với pipeline dữ liệu lớn như Apache Spark để xử lý và cập nhật corpus theo lô, hoặc tích hợp qua API để hệ thống RAG tự động pull dữ liệu mới từ các nguồn khác nhau, là hướng triển khai thực tế trong doanh nghiệp.

Các doanh nghiệp muốn nhanh chóng khai thác insight từ báo cáo kinh doanh nội bộ có thể sử dụng RAG kết hợp với nền tảng phân tích như AlgoData — nơi dữ liệu thị trường và vận hành đã được tổ chức sẵn để đưa vào pipeline truy hồi.

Hạn chế của RAG

RAG không phải là viên đạn bạc. Một số hạn chế cần lưu ý:

Chất lượng phụ thuộc hoàn toàn vào chất lượng tài liệu nạp vào. "Garbage in, garbage out" — nếu tài liệu nguồn lỗi thời, mâu thuẫn hoặc viết kém, câu trả lời của RAG cũng sẽ kém.

Khó xử lý câu hỏi tổng hợp. Các câu hỏi cần tổng hợp thông tin rải rác trên nhiều tài liệu hoặc suy luận nhiều bước khó giải quyết bằng top-k retrieval đơn giản. Advanced RAG (multi-hop retrieval, HyDE, query decomposition) được phát triển để giải quyết hạn chế này.

Latency tăng thêm. Mỗi request cần thêm bước embedding query + vector search + (tùy chọn) re-ranking trước khi gọi LLM. Tổng cộng có thể thêm 200–500ms cho hệ thống phản hồi nhanh.

Chi phí token tăng. Prompt dài hơn do ngữ cảnh được nhồi vào nghĩa là tốn nhiều token hơn mỗi lượt, trực tiếp ảnh hưởng chi phí khi scale.

Kết luận: RAG là bước tiến thực dụng nhất để đưa LLM vào môi trường doanh nghiệp — biến một mô hình ngôn ngữ mạnh nhưng thiếu ngữ cảnh thành trợ lý thực sự biết tra cứu tài liệu của tổ chức, trả lời chính xác và có thể kiểm chứng nguồn.

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