LLM không biết dữ liệu riêng của công ty bạn và hay bịa (hallucinate). RAG (Retrieval-Augmented Generation) giải quyết: lấy đúng đoạn tài liệu liên quan rồi đưa vào prompt để model trả lời có căn cứ. Đây là kỹ năng được tuyển nhiều nhất.
RAG hoạt động thế nào
Tai lieu -> chia nho (chunk) -> tao embedding -> luu vector DB
Cau hoi -> tao embedding -> tim k chunk gan nhat -> nhet vao prompt -> LLM tra loi
Embedding biến văn bản thành vector số; văn bản nghĩa gần nhau thì vector gần nhau. "Tìm gần nhất" = tìm đoạn tài liệu liên quan nhất tới câu hỏi.
Ví dụ tối giản
from openai import OpenAI
import numpy as np
client = OpenAI()
docs = ["Chinh sach hoan tien trong 7 ngay.",
"Gio lam viec 8h-17h tu T2-T6.",
"Bao hanh san pham 12 thang."]
def embed(t):
return client.embeddings.create(
model="text-embedding-3-small", input=t).data[0].embedding
doc_vecs = [embed(d) for d in docs]
def search(q, k=1):
qv = np.array(embed(q))
sims = [np.dot(qv, np.array(d)) for d in doc_vecs]
idx = int(np.argmax(sims)) # k=1 cho don gian
return docs[idx]
ctx = search("Toi muon tra hang thi sao?")
# ctx -> "Chinh sach hoan tien trong 7 ngay."
Đoạn ctx này được nhét vào system prompt: "Chỉ trả lời dựa trên: {ctx}". Model giờ trả lời đúng chính sách thật, không bịa.
Chunking — nơi quyết định chất lượng RAG
Chia tài liệu sai là nguyên nhân số 1 khiến RAG kém:
- Chunk quá to -> lẫn nhiều thông tin thừa, model bị nhiễu.
- Chunk quá nhỏ -> mất ngữ cảnh, câu bị cắt giữa chừng.
- Khuyến nghị: 300-800 token/chunk, có overlap ~50-100 token để không mất ngữ cảnh ở ranh giới.
- Chunk theo cấu trúc (theo mục, tiêu đề) tốt hơn cắt cứng theo số ký tự.
Khung tư duy "chất lượng RAG"
Khi RAG trả lời sai, soi theo thứ tự:
- Retrieval đúng chưa? In ra các chunk lấy được — nếu chunk không chứa câu trả lời thì lỗi ở tìm kiếm/chunking, không phải ở model.
- Chunk có đủ ngữ cảnh không? Nếu bị cắt cụt -> chỉnh chunking.
- Prompt có ràng buộc "chỉ dựa trên tài liệu" không? Thiếu -> model tự bịa thêm.
- Có yêu cầu trích nguồn không? Buộc model nêu nguồn giúp phát hiện bịa.
Các bước xây RAG production
- Thu thập & làm sạch tài liệu (bỏ header/footer rác).
- Chunk có cấu trúc + overlap; lưu metadata (nguồn, mục).
- Tạo embedding, lưu vào vector DB (Chroma, Qdrant, pgvector).
- Truy hồi top-k (k=3-5), có thể thêm bước rerank.
- Prompt buộc "chỉ dựa trên ngữ cảnh, nếu không có thì nói không biết".
- Buộc model trích nguồn cho mỗi câu trả lời.
- Xây tập eval: 20-30 câu hỏi có đáp án đúng để đo trước/sau khi chỉnh.
Khi nào KHÔNG cần RAG
RAG không phải cây đũa thần. Nếu tài liệu nhỏ (vài trang) và cố định, đôi khi nhét thẳng vào prompt đơn giản và chính xác hơn. RAG chỉ thật sự cần khi kho tài liệu lớn (vượt context window) hoặc thay đổi thường xuyên. Đừng dựng cả vector DB cho một trang FAQ.
RAG + agent: kết hợp sức mạnh
Trong hệ thống thật, RAG thường là một tool trong tay agent, không phải toàn bộ hệ thống. Ví dụ agent CSKH có tool search_docs(query) (chính là RAG) bên cạnh get_order(), create_ticket(). Agent tự quyết khi nào cần tra tài liệu, khi nào gọi database. Đây là kiến trúc phổ biến trong sản phẩm doanh nghiệp:
Cau hoi -> agent loop -> chon: search_docs? get_order? -> tra loi co trich nguon
Đo chất lượng RAG bằng con số
Đừng chỉnh RAG theo cảm tính. Xây tập eval nhỏ và đo hai chỉ số:
- Retrieval hit rate: bao nhiêu % câu hỏi mà chunk đúng nằm trong top-k truy hồi.
- Answer accuracy: bao nhiêu % câu trả lời cuối đúng so với đáp án chuẩn.
Checklist RAG
- [ ] In được các chunk truy hồi để debug.
- [ ] Chunk có overlap và giữ ngữ cảnh.
- [ ] Prompt cấm bịa, cho phép trả lời "không biết".
- [ ] Có trích nguồn.
- [ ] Có tập eval đo cả retrieval hit rate lẫn answer accuracy.
- [ ] Đã tự hỏi: bài toán này có thật sự cần RAG không?
Sai lầm thường gặp
- Đổ model to hơn khi RAG sai, trong khi lỗi nằm ở retrieval/chunking.
- Không cho phép "không biết" -> model bịa khi tài liệu thiếu.
- Bỏ trích nguồn -> không ai kiểm chứng được, mất niềm tin ở môi trường doanh nghiệp.
- Không có eval -> chỉnh mò, không biết tốt lên hay xấu đi.