RAG là gì?
Retrieval-Augmented Generation (RAG) là kiến trúc AI kết hợp hai bước: (1) truy xuất thông tin liên quan từ cơ sở dữ liệu vector, rồi (2) sinh câu trả lời dựa trên ngữ cảnh đã truy xuất. Ý tưởng ra đời năm 2020 bởi Lewis et al. (Meta/Facebook AI) trong bài báo “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, nhằm giải quyết nhược điểm “hallucination” của LLM — mô hình nói dối khi không biết hoặc không nhớ chính xác.
Trước RAG, người ta phải fine-tune LLM với dữ liệu mới — tốn kém, không linh hoạt, dễ lỗi thời. Sau RAG: chỉ cần cập nhật vector database, LLM giữ nguyên — linh hoạt, chi phí thấp, luôn up-to-date.
Cách hoạt động
- Indexing (offline): Chia tài liệu thành chunk (100-1000 tokens), embedding qua model (OpenAI text-embedding-3, BGE, GTE), lưu vào vector DB (Pinecone, Weaviate, Qdrant, Chroma, pgvector). Mỗi chunk kèm metadata (nguồn, trang, ngày, tác giả) để filter sau này.
- Retrieval (online): Khi user query → embedding query → similarity search top-k chunks (thường k=3-5) dùng cosine similarity hoặc dot product.
- Generation: Gộp query + retrieved chunks vào prompt → LLM sinh câu trả lời có trích dẫn nguồn. Prompt thường dạng: “Dựa vào ngữ cảnh sau: [chunk1] [chunk2] … Hỏi: [question]
Ba loại RAG chính
Naive RAG (vanilla)
Pipeline đơn giản: index → retrieve → generate. Phù hợp tài liệu ổn định, ít thay đổi. Nhược điểm: không xử lý tốt câu hỏi phức tạp, thứ tự thông tin không tối ưu, dễ bỏ qua context quan trọng nếu chunk boundary không may.
Advanced RAG
- Chunking chiến lược: RecursiveCharacterTextSplitter (ngưỡng ký tự), Sentence Splitter (ngưỡng câu), hay Semantic Chunking (embedding distance > threshold). Mỗi loại phù hợp loại tài liệu khác nhau.
- Re-ranking: Dùng cross-encoder (BGE-reranker, Cohere Rerank) sau initial retrieval để tinh chỉnh top-k — cải thiện precision đáng kể.
- Hybrid search: Kết hợp BM25 (keyword) + vector search — tăng recall cho tên riêng, mã số, thuật ngữ chuyên ngành, giảm false positive.
- Query transformation: HyDE (Hypothetical Document Embedding), multi-query, step-back prompting để cải thiện retrieval — đặc biệt hữu ích cho câu hỏi mơ hồ hoặc thiếu thông tin.
Modular / Agentic RAG
Dùng agent framework (LangGraph, LlamaIndex) để agent tự quyết định: khi nào cần retrieve, query nào nên dùng, có cần lặp retrieve không. Agent có thể sử dụng tools (calculator, search API) và reasoning multi-step. LangGraph, LlamaIndex đều hỗ trợ agentic RAG.
Vector database lựa chọn
| Vector DB | Đặc điểm | Use case | Giao diện |
|---|---|---|---|
| Pinecone | Managed, serverless, scale tự động | Production nhanh, không cần ops | REST API, SDK |
| Weaviate | Open source, modules built-in (OpenAI, Cohere, BERT) | Self-host, hybrid search | GraphQL, REST |
| Qdrant | Rust, high performance, gRPC/REST | High throughput, edge deployment | REST, gRPC |
| Chroma | Python-native, lightweight, open source | Prototype, local dev | Python API |
| pgvector | PostgreSQL extension, SQL native | Team đã có Postgres, không muốn thêm infra mới | SQL |
Best practices thực tế
- Chunk size: 256-512 tokens cho Q&A, 1024-2048 cho tài liệu dài. Không quá 2048 vì embedding model thường có context limit ~512 tokens hiệu quả nhất. Thử nghiệm để tìm sweet spot cho dataset cụ thể.
- Overlap: 10-20% overlap giữa chunk để không mất ngữ cảnh biên — tránh cắt giữa câu hoặc đoạn quan trọng.
- Metadata filter: Thêm metadata (source, date, author, category) để filter retrieval — giảm noise, tăng relevance. Ví dụ: chỉ tìm trong tài liệu năm 2024-2025.
- Citation: Luôn trả về source URL/page — tăng trust, dễ audit, cho phép user kiểm tra nguồn.
- Evaluation: Dùng RAGAS, TruLens, hay custom test set để đo recall@k, faithfulness, answer relevancy. CI/CD pipeline cho knowledge base updates.
Thách thức phổ biến
- Hallucination vẫn xảy ra: Nếu retrieved chunks không đủ hoặc không liên quan, LLM vẫn có thể “bịa” thông tin — cần confidence scoring hoặc fallback để LLM nói “tôi không biết”.
- Latency: Embedding + search + generation có thể chạy 2-10s — cần cache (Redis), async, hoặc smaller model (DistilBERT embedding) để giảm thời gian.
- Cost: Embedding API (OpenAI) + vector DB hosting + LLM inference — có thể cao với traffic lớn. Tối ưu: dùng open-source embedding model (BGE, GTE) và self-hosted vector DB.
- Data freshness: Tài liệu cập nhật cần re-index — cần pipeline CI/CD cho knowledge base (Airflow, Kubeflow) để tự động rebuild khi source thay đổi.
Khi nào nên dùng RAG
Dùng RAG khi câu trả lời cần dựa trên dữ liệu nội bộ (knowledge base, tài liệu nội bộ, FAQ), khi dữ liệu thay đổi thường xuyên (tin tức, bảng giá, sách giá sàn), hoặc khi cần trích dẫn nguồn (y tế, tài chính, pháp luật). Không dùng RAG nếu LLM đã biết sẵn kiến thức cần thiết (knowledge nằm trong training data) — tốn chi phí retrieval không cần thiết, latency thừa.
Kết luận
RAG là cầu nối giữa LLM static knowledge và dữ liệu động. Với vector DB ngày càng dễ dùng (managed, open source), RAG đã trở thành default pattern cho enterprise AI — chatbot hỗ trợ khách hàng, tìm kiếm nội bộ, công cụ phân tích tài liệu, y tế chẩn đoán phụ trợ. Để tối ưu: chọn chunking strategy phù hợp loại dữ liệu, hybrid search thay vì pure vector, re-ranking cross-encoder, và đo lường liên tục với RAGAS. RAG không phải silver bullet, nhưng là best practice hiện tại cho “LLM có kiến thức chính xác + có trích dẫn”.
Nguồn tham khảo: Lewis et al. RAG paper (2020), Pinecone Vector Database Guide, Qdrant Articles, Weaviate Transformers Module, RAGAS evaluation framework, TruLens.
