Bài 35: RAG là gì? Vì sao cần nó

Sau bài này, bạn cần:

• Định nghĩa được RAG bằng một câu và bốn lý do cần nó (knowledge cutoff, private data, hallucination, citation).
• Vẽ được pipeline 2 phase Index (offline) và Query (online) với đủ thành phần.
• Liệt kê components chuẩn: document loader, text splitter, embedding model, vector DB, retriever, LLM.
• Phân biệt RAG vs fine-tuning vs long-context — biết trade-off chính của mỗi cái.
• Phân biệt naive RAG vs advanced RAG (rewriting, hybrid, reranking, HyDE, fusion).
• Biết tên các biến thể đang dùng năm 2024-2026: Agentic RAG, GraphRAG, Multi-Query, RAG-Fusion.
• Đọc được một code skeleton tối thiểu với sentence-transformers + ChromaDB.
• Biết lộ trình 7 bài của Module 6 để theo đúng thứ tự.

Đây là bài overview. Chi tiết từng thành phần sẽ deep-dive ở Bài 36-41.

Module 1-3 đã xây nền: LLM, Transformer, Hugging Face. Module 4-5 đã đi qua prompt engineering và API (OpenAI, Anthropic, streaming, cost). Đến đây bạn đã có thể gọi LLM, kiểm soát output, nhưng vẫn vướng một hạn chế khó tránh: model chỉ biết những gì có trong tham số (weight) lúc train. Mọi tri thức xuất hiện sau cutoff date, mọi tài liệu nội bộ của công ty bạn, mọi file PDF cá nhân — model không thấy.

Module 6 giải quyết bằng pattern phổ biến nhất trong LLM app prod 2023-2026: RAG. Thay vì cố nhồi tri thức vào weight (fine-tune), ta giữ tri thức ở một store ngoài, mỗi câu hỏi mới retrieve các đoạn liên quan rồi gắn vào prompt. Model làm phần ngôn ngữ; store làm phần trí nhớ. Hai phần độc lập, dễ cập nhật, dễ cite nguồn.

Module này gồm 7 bài (xem bước 27). Bài này là intro; 6 bài còn lại lần lượt đi sâu embedding, vector DB, chunking, similarity, reranking và một QA system PDF end-to-end.

Một câu: RAG là kỹ thuật cho LLM trả lời dựa trên tài liệu được lấy ra từ một knowledge base bên ngoài tại thời điểm query, thay vì chỉ dựa vào tri thức nội tại của model.

Chuỗi ba bước cốt lõi:

1. Retrieve: với câu hỏi của user, tìm trong knowledge base ra K đoạn liên quan nhất (thường K = 3-10).
2. Augment: ghép K đoạn này vào prompt như context, kèm câu hỏi gốc.
3. Generate: gửi prompt mở rộng cho LLM, model sinh câu trả lời sử dụng context.

Knowledge base có thể là: tập file PDF/Markdown/HTML nội bộ, wiki công ty, ticket Zendesk, code repository, tin tức theo ngày, log conversation, hoặc kết hợp nhiều nguồn.

RAG không thay đổi weight của LLM. Model nhận context như input thường; không có "học thêm" về mặt tham số.

Bốn vấn đề thúc đẩy RAG:

• Knowledge cutoff — mỗi model có ngày cutoff dữ liệu train. Sự kiện sau ngày đó model không biết, hoặc biết méo do generalize sai. RAG cho phép cập nhật knowledge base hàng giờ mà không retrain.
• Private / proprietary data — tài liệu công ty, file cá nhân, code repo nội bộ không có trong corpus pretrain. Không thể fine-tune trên dữ liệu nhạy cảm cho mỗi tenant. RAG giữ data ở store riêng, mỗi user / tenant chỉ thấy phần của mình.
• Hallucination — khi không biết, LLM vẫn sinh ra câu trả lời nghe có vẻ hợp lý. Ép model trả lời chỉ dựa trên context retrieve (và "Tôi không biết" nếu context không đủ) giảm hallucination — không loại bỏ hoàn toàn, nhưng đo được và giảm rõ rệt.
• Citation / traceability — RAG có sẵn list đoạn nguồn được retrieve, có thể hiển thị footnote, URL, page number. User verify được câu trả lời, đáp ứng yêu cầu compliance (legal, medical, finance).

Bốn lý do trên là motivation chính trong paper gốc (Lewis et al. 2020) và trong tài liệu LangChain / LlamaIndex.

Mọi hệ thống RAG đều chia làm hai phase chạy ở hai thời điểm khác nhau:

PHASE 1 — INDEX (offline, một lần hoặc theo lịch)
─────────────────────────────────────────────────────────
  Documents  →  Loader  →  Chunker  →  Embedder  →  Vector DB
  (PDF, MD,                (split nhỏ)  (text→vec)  (lưu vec
   HTML, ...)                                         + meta)

PHASE 2 — QUERY (online, mỗi request)
─────────────────────────────────────────────────────────
  User query  →  Embedder  →  Vector DB (top-K similar)  →

  Augmented prompt (context + question)  →  LLM  →  Response
                                                  ↘ (kèm sources)

Phase Index là phần tốn nhất một lần: parse hết tài liệu, chia chunk, gọi embedding model, ghi vào vector DB. Có thể chạy hàng đêm hoặc khi có doc mới (incremental indexing).

Phase Query là phần chạy mỗi user request: embed query, search vector DB, build prompt, gọi LLM. Latency tổng cộng thường 0.5-3s tùy stack.

Bốn bước chính:

1. Load — đọc nội dung từ nguồn. Có loader cho PDF (PyMuPDF, pdfplumber), Office, HTML, Markdown, Notion, Confluence, Slack, GitHub. Đầu ra: list document có text + metadata (path, page, url, author, date).
2. Chunk — chia mỗi document thành đoạn ~200-800 token. Lý do: embedding model có giới hạn input; chunk quá dài làm vector "loãng"; chunk quá ngắn mất context. Có nhiều chiến lược (fixed, recursive, semantic) — Bài 38 deep-dive.
3. Embed — biến mỗi chunk thành vector vài trăm chiều bằng embedding model (sentence-transformers, BGE, E5, OpenAI text-embedding-3-*, Voyage, Cohere). Vector ở gần nhau trong không gian = ngữ nghĩa gần nhau. Bài 36 deep-dive.
4. Store — ghi cặp (vector, chunk text, metadata) vào vector DB. Vector DB index để similarity search nhanh (HNSW, IVF). Bài 37 deep-dive ChromaDB.

Output cuối của phase này là một collection trong vector DB sẵn sàng search.

Bốn bước cho mỗi request:

1. Embed query — dùng cùng embedding model như lúc index để biến câu hỏi thành vector (nếu khác model → vector ở "không gian khác", retrieve sai).
2. Retrieve top-K — vector DB trả về K chunk có vector gần query nhất (cosine similarity hoặc dot product). K thường 3-10.
3. Augment prompt — build prompt template chèn K chunk làm context, kèm câu hỏi và instruction "trả lời chỉ dựa trên context" (xem bước 8).
4. Generate — gọi LLM (GPT-4o, Claude, Llama 3, ...). Trả lời + list source.

Phần advanced RAG thêm vào: query rewriting trước embed, hybrid search (semantic + keyword), rerank sau retrieve, compression context. Bài 40 deep-dive reranking.

Template tối thiểu hay dùng:

Bạn là trợ lý trả lời dựa trên CONTEXT được cung cấp.
Nếu CONTEXT không đủ để trả lời, nói "Tôi không có thông tin".
KHÔNG tự thêm thông tin ngoài CONTEXT.

CONTEXT:
[1] {chunk_1}
[2] {chunk_2}
[3] {chunk_3}

QUESTION: {user_question}

ANSWER (kèm trích dẫn [n] cho mỗi luận điểm):

Bốn yếu tố quan trọng:

• Đánh số chunk ([1], [2], ...) để model có thể cite dạng "theo [2]".
• Instruction "không có thông tin" tường minh — không có thì model vẫn hallucinate khi retrieve sai.
• Cấm tự thêm thông tin — giúp giảm mixing tri thức nội tại với context.
• Yêu cầu cite — frontend có thể parse [n] ra link nguồn thật.

Mỗi framework có template riêng (LangChain RetrievalQA, LlamaIndex QueryEngine) — bản chất giống nhau.

• 2020 — Lewis et al., Facebook AI, paper "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (arXiv 2005.11401, NeurIPS 2020). Đặt tên RAG. Kiến trúc gốc: DPR (Dense Passage Retrieval) + BART, train end-to-end.
• 2021-2022 — paper followup (FiD, REALM trước đó, Atlas), nhưng vẫn chủ yếu trong giới research.
• 10/2022 — Harrison Chase release LangChain. Cung cấp abstraction Loader, TextSplitter, Embeddings, VectorStore, Retriever, Chain — đóng gói RAG cho dev không cần đụng paper.
• 11/2022 — Jerry Liu release GPT Index, sau đổi tên LlamaIndex. Tập trung sâu hơn vào indexing strategy và query engine.
• 11/2022 — ChatGPT ra. Nhu cầu "ChatGPT trên data của tôi" bùng nổ → RAG thành pattern phổ biến cho mọi LLM app.
• 2023 — Vector DB chuyên dụng (Pinecone, Weaviate, Qdrant, ChromaDB, Milvus) trở nên ổn định production. Embedding model OpenAI text-embedding-ada-002 rồi text-embedding-3-*.
• 2024 — Advanced RAG thành chuẩn: hybrid search, reranking (Cohere Rerank), HyDE, RAG-Fusion. GraphRAG (Microsoft) cho query đa hop. Agentic RAG.
• 2025-2026 — RAG là default pattern cho 80%+ LLM app prod khi cần ground trên data riêng. Cũng có narrative đối trọng "long context có thể thay RAG" — thực tế hai cái cùng tồn tại, mỗi cái fit case riêng (bước 13).

Layer            Vai trò                                  Ví dụ
─────────────────────────────────────────────────────────────────────────────
Document loader  Đọc file → text + metadata               PyMuPDF, Unstructured,
                                                          LangChain loaders
Text splitter    Chia text thành chunk                    RecursiveCharacterTextSplitter,
                                                          MarkdownHeaderSplitter
Embedding model  text → vector                            sentence-transformers,
                                                          BGE-M3, E5, OpenAI 3-large
Vector database  Lưu vector + similarity search           ChromaDB, Qdrant, Pinecone,
                                                          Weaviate, Milvus, pgvector
Retriever        Wrapper search top-K, có thể fusion       LangChain BaseRetriever,
                                                          LlamaIndex Retriever
Reranker         Sắp xếp lại top-K theo cross-encoder      Cohere Rerank, BGE Reranker,
                                                          mxbai-rerank
LLM              Sinh câu trả lời từ context              GPT-4o, Claude, Llama 3,
                                                          Mistral, Qwen
Orchestrator     Ghép pipeline + observability            LangChain, LlamaIndex,
                                                          Haystack, custom code

Mỗi layer là một "khoảng cách" có thể đổi mà không phá phần khác — đó là điểm mạnh của RAG so với fine-tune (đổi LLM = retrain).

• Company knowledge base — chatbot trên wiki nội bộ (Confluence, Notion). Nhân viên hỏi policy, kỹ thuật, onboarding.
• Customer support — bot trả lời dựa trên FAQ, ticket cũ, doc product. Giảm thời gian phản hồi cho tier 1.
• Code search / dev assistant — index code repo + doc, trả lời "hàm X dùng ở đâu", "module Y làm gì".
• Legal / medical / finance — luật, contract, hồ sơ bệnh án, báo cáo tài chính. Yêu cầu citation chặt → fit RAG.
• Personal AI / second brain — index file PDF, note Obsidian, email; hỏi câu hỏi trên kho cá nhân.
• News / research — index tin theo ngày, paper arXiv mới, để LLM tổng hợp theo chủ đề.
• E-commerce — search sản phẩm theo mô tả tự nhiên ("áo khoác mùa thu màu be size M") thay vì filter cứng.
• Education / tutor — bot trả lời dựa trên giáo trình, sách bài tập của môn cụ thể.

Đặc điểm chung: nội dung thay đổi nhanh hoặc có scope hẹp, cần cite nguồn, không phải task generative thuần.

Trục                  RAG                              Fine-tuning
─────────────────────────────────────────────────────────────────────────────
Tri thức              Lưu ở store ngoài (dynamic)      Lưu trong weight (static)
Cập nhật              Add doc mới, re-embed (phút)     Phải retrain (giờ - ngày)
Citation              Có sẵn (từ retrieve)             Không (model không biết
                                                       câu trả lời đến từ đâu)
Hallucination         Giảm khi context tốt             Vẫn cao nếu prompt vượt
                                                       phân phối train
Phù hợp cho           Tri thức cụ thể, thay đổi        Style, format, domain
                      nhanh, cần cite                  language, behavior
Cost upfront          Thấp (chỉ embed + lưu)           Cao (GPU training)
Cost mỗi request      Cao hơn (tokens context)         Bằng base model
Data nhạy cảm         OK nếu store on-prem             Cẩn thận leak qua weight
Multi-tenant          Dễ (filter metadata)             Khó (mỗi tenant 1 model?)

Quy tắc tay nhanh: "What" (sự thật cụ thể) → RAG. "How" (giọng văn, format, behavior) → fine-tune. Cả hai cùng task → kết hợp.

Bài 47 (Module 8) sẽ deep-dive câu hỏi "khi nào fine-tune".

2024-2026 nhiều model có context window 1M+ token (Gemini 1.5/2.0, Claude Sonnet 4 1M, GPT-4.1 1M). Một câu hỏi tự nhiên: tại sao không nhồi hết tài liệu vào prompt?

Trục                  RAG                              Long context
─────────────────────────────────────────────────────────────────────────────
Token mỗi request     Chỉ top-K (~1-5K)                 Toàn bộ doc (~100K-1M)
Cost mỗi request      Thấp                              Cao (tỉ lệ với token)
Latency               Thấp (LLM xử lý ít token)         Cao (xử lý nhiều token,
                                                       attention quadratic)
Scale dữ liệu         Triệu doc OK                     Giới hạn bởi window
Quality               Tốt nếu retrieve đúng             Lost-in-the-middle: model
                                                       hay miss info ở giữa
Update                Add doc + embed                  Phải build lại prompt
Determinism           Phụ thuộc retriever              Phụ thuộc thuần model

Hiện tượng lost-in-the-middle (Liu et al. 2023, arXiv 2307.03172): với context dài, model nhớ tốt phần đầu và phần cuối, hay quên giữa. Long context không "free" về chất lượng.

Thực tế: RAG vẫn là default cho knowledge base lớn / cập nhật thường. Long context fit cho document đơn lẻ vừa phải (sách, codebase nhỏ, transcript meeting). Hai cái không loại nhau — có thể RAG-retrieve rồi đưa vào long-context model.

Naive RAG = pipeline tối giản: chunk → embed → retrieve top-K → prompt → LLM. Bắt đầu nên làm naive trước để có baseline.

Advanced RAG = thêm các bước cải thiện cả pre-retrieval và post-retrieval:

• Query rewriting / expansion — viết lại câu hỏi cho rõ hơn, bổ sung context, sinh nhiều version.
• Hybrid search — kết hợp semantic (vector) + lexical (BM25) — bước 17.
• Reranking — sau retrieve top-50 bằng vector, dùng cross-encoder rank lại top-5.
• HyDE (Hypothetical Document Embedding) — sinh ra một "câu trả lời giả" trước, embed nó thay vì embed query.
• Multi-query — sinh 3-5 paraphrase của query, retrieve từng cái, union kết quả.
• RAG-Fusion — multi-query + reciprocal rank fusion (RRF) để merge.
• Context compression — sau retrieve, dùng LLM nhỏ trích nguyên phần liên quan để giảm token.
• Agentic RAG — LLM tự quyết retrieve hay không, lặp nhiều round retrieve.

Tham khảo survey: Gao et al. 2023, "Retrieval-Augmented Generation for Large Language Models: A Survey" (arXiv 2312.10997) — chia rõ Naive, Advanced, Modular RAG.

• Chunk size sai — quá to (mất focus), quá nhỏ (mất context). Bài 38 đi sâu chiến lược chunk.
• Embedding model không match domain — model train chủ yếu trên tiếng Anh dùng cho tiếng Việt sẽ kém. Phải đánh giá theo dữ liệu của bạn.
• Không có reranking — top-K vector thuần thường có cả nhiễu; thêm reranker cải thiện đáng kể.
• Metadata bị bỏ — không lưu source/page → không cite được, không filter được (ví dụ "chỉ tìm trong doc 2026").
• Cùng embedding cho index và query nhưng khác version — vector "lệch không gian", retrieve sai.
• Không đánh giá — chỉ "feel good demo". Cần golden set Q&A + metric (Bài 58).
• Để LLM "phán" khi context không liên quan — phải bắt model trả "không có thông tin" thay vì bịa.
• Quên dedup chunk — file trùng → context lặp, LLM bias.

• HyDE (Gao et al. 2022, arXiv 2212.10496) — sinh ra câu trả lời giả định bằng LLM, embed câu trả lời này (vì câu trả lời thường "gần" doc đích hơn câu hỏi).
• Multi-Query Retriever — LLM viết 3-5 paraphrase của câu hỏi, retrieve mỗi cái, union sau dedup.
• RAG-Fusion — Multi-Query + Reciprocal Rank Fusion: mỗi version có một ranking, gộp theo công thức RRF.
• Agentic RAG — LLM đóng vai agent tự quyết khi nào retrieve, retrieve gì, có cần retrieve thêm round sau không. Liên kết chặt với Module 7 (Function Calling).
• GraphRAG (Microsoft Research 2024, arXiv 2404.16130) — thay vì chỉ vector, build knowledge graph từ doc (entity, relation), retrieve theo subgraph. Hữu ích cho query đa hop ("ai là CEO của công ty mua X năm Y").
• Self-RAG (Asai et al. 2023) — model tự sinh token reflective để quyết retrieve hay không.
• CRAG (Corrective RAG) — đánh giá chất lượng retrieve, fallback web search nếu kém.

Tên nhiều, nhưng tất cả đều xoay quanh 3 thao tác cốt lõi: retrieve, augment, generate.

Vector search (semantic) tốt cho câu hỏi diễn giải ("làm sao reset mật khẩu") nhưng kém cho keyword cụ thể, mã sản phẩm, tên function (auth_v2.reset_password). Lý do: embedding "trung bình" hóa ngữ nghĩa, token hiếm bị làm mờ.

BM25 (Best Match 25, Robertson 1994) là baseline lexical: ranking dựa trên term frequency + inverse document frequency. Match chính xác từ khoá, không "hiểu" nghĩa.

Hybrid search = chạy cả hai retriever song song, hợp nhất kết quả:

                ┌─→ Vector retrieve  (top-K_v)  ─┐
User query  ────┤                                 ├─→ Fusion (RRF / weighted)
                └─→ BM25 retrieve    (top-K_b)  ─┘     ─→ Top-K final
                                                         (có thể rerank)

Implement: ChromaDB hỗ trợ một phần; Weaviate, Qdrant, Elasticsearch + dense plugin có hybrid native. LangChain có EnsembleRetriever.

Quy tắc thực tế: hybrid gần như luôn không tệ hơn semantic thuần, thường cải thiện 5-15% recall ở top-10 cho corpus có nhiều term kỹ thuật. Cost thêm rất nhỏ.

Search engine cổ điển (Google, Elasticsearch) trả ra list link; user phải tự đọc và tổng hợp. RAG trả ra câu trả lời tổng hợp kèm trích dẫn nguồn.

Trục             Search engine               RAG
─────────────────────────────────────────────────────────────────
Output           List link / snippet         Câu trả lời tổng hợp
User effort      Đọc & tổng hợp              Đọc câu trả lời + check cite
Ranking          BM25 / PageRank + ML        Vector + (BM25) + rerank
Generation       Không có                    LLM
Cost mỗi query   Rẻ                          Cao hơn (LLM call)
Trust            Có (link gốc)               Phụ thuộc citation chuẩn không

Có thể nói: RAG = search + synthesis. Perplexity, You.com, ChatGPT Search là hiện thân của ý này ở scale web.

Search engine không chết — vẫn là foundation (BM25 trong hybrid, vector index có nguyên lý tương tự inverted index). RAG xây trên vai search.

Đánh giá RAG có hai tầng:

• Retrieval quality
  • Context Precision — trong K chunk retrieve, bao nhiêu thực sự liên quan?
  • Context Recall — trong tất cả chunk liên quan đáng có, retrieve được bao nhiêu?
• Generation quality
  • Faithfulness — câu trả lời có bám đúng context không, hay bịa thêm?
  • Answer Relevancy — câu trả lời có đúng trọng tâm câu hỏi không?

Framework hay dùng: RAGAS (Es et al. 2023), TruLens, DeepEval. Bài 58 (Module 9) deep-dive cách tính từng metric.

Bài học sớm: nếu không có golden set 30-100 Q&A, mọi thay đổi pipeline đều là cảm tính.

• Phụ thuộc retrieval — retrieve sai → context sai → câu trả lời sai. "Garbage in, garbage out".
• Cost lũy tiến — mỗi query tốn tiền embed query + tiền LLM cho context. Với 1M query/tháng cost không nhỏ.
• Latency — thêm 50-300ms cho embed + retrieve. Với app realtime cần tối ưu (cache embedding query phổ biến).
• Complexity — nhiều phần phải vận hành (vector DB, embedding service, LLM, observability). Naive RAG dễ; production RAG là một hệ thống đầy đủ.
• Multi-hop khó — câu hỏi cần kết hợp nhiều doc theo chuỗi suy luận: vector retrieval một bước thường không đủ. GraphRAG / Agentic RAG cố giải nhưng chưa hoàn hảo.
• Data drift — corpus đổi nhanh → embedding cũ lạc hậu. Phải pipeline reindex.
• Numeric / table heavy — RAG thuần text yếu với bảng số, công thức. Cần parser chuyên biệt.
• Cite không tự động đúng — model có thể cite [3] cho câu thực ra đến từ [1]; cần verification layer.

Dùng RAG khi:

• Có knowledge base lớn / cập nhật thường, cần model trả lời dựa trên nó.
• Cần citation để user verify.
• Data private không gửi lên fine-tune service được.
• Phạm vi câu hỏi rộng nhưng câu trả lời nằm trong corpus xác định.
• Yêu cầu mới phát sinh hàng ngày (sản phẩm mới, tin mới, policy mới).

Không cần RAG khi:

• Câu hỏi thuần language task không cần tri thức (dịch, tóm tắt input, format).
• Tri thức nhỏ vừa với context window → nhét thẳng vào system prompt rẻ hơn.
• Cần thay đổi cách model trả lời (style, persona) — fine-tune phù hợp hơn.
• Yêu cầu suy luận đa hop phức tạp — cân nhắc GraphRAG hoặc agent.

• Orchestration framework: LangChain (lớn nhất, abstraction nhiều), LlamaIndex (data-centric, query engine mạnh), Haystack (Deepset, có pipeline DAG rõ ràng), DSPy (Stanford, prompt as program).
• Vector database: ChromaDB (đơn giản, OSS, fit prototype), Qdrant (Rust, on-prem mạnh), Weaviate (hybrid native), Pinecone (managed cloud), Milvus (scale lớn, OSS), pgvector (extension Postgres), Redis vector, Elasticsearch dense vector.
• Embedding model: OpenAI text-embedding-3-small/large, Cohere Embed v3, Voyage AI, sentence-transformers (all-MiniLM-L6-v2 baseline), BGE-M3 (BAAI, hỗ trợ multilingual + multi-vector), E5-Mistral, Nomic Embed, jina-embeddings.
• Reranker: Cohere Rerank v3, BGE Reranker, jina-reranker, mxbai-rerank.
• Document parsing: Unstructured.io, LlamaParse, Docling (IBM), PyMuPDF, pdfplumber, marker.
• Evaluation: RAGAS, TruLens, DeepEval, Phoenix (Arize), LangSmith.
• Hosted RAG-as-a-service: Vectara, Mendable, NotebookLM API (Google), AWS Bedrock Knowledge Bases.

Bài 36-41 sẽ chọn một stack cụ thể (sentence-transformers + ChromaDB) làm baseline học; production có thể swap thoải mái.

Skeleton tối thiểu để thấy bức tranh. Mỗi đoạn sẽ được mở rộng trong các bài sau.

(a) Cài:

pip install chromadb sentence-transformers openai

(b) Index (phase 1):

import chromadb
from sentence_transformers import SentenceTransformer

embedder = SentenceTransformer("all-MiniLM-L6-v2")
client = chromadb.PersistentClient(path="./chroma_db")
col = client.get_or_create_collection("docs")

docs = [
    "RAG kết hợp LLM với knowledge base ngoài.",
    "Vector DB lưu embedding và hỗ trợ similarity search.",
    "Chunk size 200-800 token thường là điểm khởi đầu hợp lý.",
]

col.add(
    ids=[f"doc_{i}" for i in range(len(docs))],
    documents=docs,
    embeddings=embedder.encode(docs).tolist(),
)

(c) Query (phase 2):

from openai import OpenAI
llm = OpenAI()

question = "Vector DB dùng để làm gì?"
q_vec = embedder.encode([question]).tolist()

res = col.query(query_embeddings=q_vec, n_results=3)
context = "\n".join(
    f"[{i+1}] {chunk}" for i, chunk in enumerate(res["documents"][0])
)

prompt = f"""Trả lời dựa trên CONTEXT. Nếu không đủ, nói "không có thông tin".

CONTEXT:
{context}

QUESTION: {question}
ANSWER:"""

resp = llm.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": prompt}],
)
print(resp.choices[0].message.content)

Khoảng 30 dòng — đủ một RAG chạy được. Production còn thiếu: chunking thật, metadata, error handling, eval, monitoring, reranking — chính là nội dung Bài 36-41.

Layer            Component cụ thể (ví dụ)
─────────────────────────────────────────────────────────
Parse            Unstructured.io / LlamaParse / Docling
Chunk            RecursiveCharacterTextSplitter (500/50 overlap)
Embed            BGE-M3 hoặc OpenAI text-embedding-3-large
Vector DB        Qdrant cluster (on-prem) hoặc Pinecone (cloud)
Retrieve         Hybrid (dense + BM25), top-20
Rerank           Cohere Rerank v3 hoặc BGE Reranker, top-5
LLM              GPT-4o / Claude Sonnet 4 / Llama 3 70B
Orchestration    LangChain hoặc LlamaIndex
Observability    LangSmith / Phoenix / OpenTelemetry
Eval             RAGAS theo lịch CI, golden set 100-500 Q&A
Cache            Redis cho query embedding + LLM response
Deploy           FastAPI + Docker, autoscale theo QPS

Đây là pattern phổ biến năm 2025-2026, không phải "công thức duy nhất". Stack tối ưu phụ thuộc volume, độ nhạy data, budget.

Một query RAG điển hình:

Component                Cost ước tính (USD)
────────────────────────────────────────────────────
Embed query              ~$0.00001 (OpenAI 3-small, 50 token)
Vector DB query          ~$0 (self-host) đến $0.0001 (managed)
Rerank top-50            ~$0.001 (Cohere Rerank)
LLM call (3K context,    ~$0.003 (GPT-4o-mini)
500 output)              ~$0.05  (GPT-4o)
                         ~$0.10  (Claude Opus 4)
────────────────────────────────────────────────────
Tổng/query (Mini stack): ~$0.005
Tổng/query (Pro stack):  ~$0.05 – $0.10

Với 100K query/tháng: Mini stack ~$500, Pro stack ~$5-10K. Phần dominant gần như luôn là LLM call (90%+). Tối ưu cost:

• Dùng model nhỏ cho route phổ thông, model lớn chỉ cho query khó.
• Cache LLM response cho query lặp.
• Compress context (loại chunk ít liên quan, dùng LLM nhỏ trích đoạn).
• Batch nếu workload offline.

Cost phase Index thường là one-time hoặc theo lịch (vài $ cho corpus 10K doc với embedding 3-small).

• Perplexity AI — answer engine: query → web search → retrieve top URL → scrape → augment → LLM tổng hợp + cite. RAG ở scale web public.
• NotebookLM (Google) — user upload PDF/Doc, RAG trên đúng tập đó, kèm citation về page. Cho phép Audio Overview.
• GitHub Copilot Workspace / Chat — retrieve từ code repo hiện tại + doc liên quan, augment cho code suggestion / Q&A.
• ChatGPT Search — bật web RAG cho ChatGPT.
• Glean — enterprise search RAG trên SaaS nội bộ công ty (GDrive, Slack, Confluence, Jira).
• Cursor / Windsurf / Claude Code — RAG trên codebase cho dev assistant.
• You.com, Phind — alternative cho search + RAG, tập trung dev / research.
• Microsoft Copilot for Microsoft 365 — RAG trên Outlook, Word, Excel, SharePoint nội bộ.

Pattern chung: retrieve nguồn → cite nguồn → LLM tổng hợp. Khác biệt nằm ở scope (web / org / file / code) và stack.

1. Bài 35 (bài này) — RAG là gì, vì sao cần, pipeline 2 phase, overview.
2. Bài 36 — Embedding model: cách chọn (sentence-transformers, BGE, E5, OpenAI), dimension, multilingual, MTEB benchmark.
3. Bài 37 — Vector Database basic với ChromaDB cho prototype: collection, persistence, metadata filter.
4. Bài 38 — Chunking strategy: fixed, recursive, semantic; chunk size, overlap; lessons-learned.
5. Bài 39 — Similarity search và top-K retrieval: cosine vs dot vs euclidean; HNSW, IVF; trade-off accuracy/speed.
6. Bài 40 — Re-ranking: cross-encoder, Cohere Rerank, BGE Reranker; khi nào đáng dùng.
7. Bài 41 — Capstone: QA system trên PDF cá nhân — end-to-end app dùng tất cả thành phần ở trên.

Sau Module 6 sẽ là Module 7 (Function Calling) — nền cho Agentic RAG; Module 8 (Fine-tuning) — bù phần "style/behavior" mà RAG không xử lý; Module 9 — đánh giá RAG bằng RAGAS.

1. Chọn một use case cụ thể trong cuộc sống/công việc của bạn (ví dụ: hỏi đáp trên giáo trình của một môn, search note Obsidian, FAQ công ty). Viết 1 đoạn 5-10 dòng mô tả: knowledge base gồm những gì, dạng câu hỏi user sẽ hỏi, vì sao RAG fit (hoặc không fit).
2. Vẽ tay (hoặc draw.io) pipeline 2 phase Index/Query cho use case ở câu 1, đánh dấu rõ tên component cho mỗi step và đầu vào/đầu ra.
3. So sánh RAG vs Long context cho use case ở câu 1: ước tính số token nếu nhồi hết vào prompt, ước tính cost mỗi query với cả hai pattern (giá tham khảo Bài 34). Kết luận chọn cái nào.
4. Chạy skeleton code ở bước 23 trên 5-10 đoạn văn của riêng bạn (ví dụ phần intro 5 bài blog cũ). Hỏi 3 câu, in ra cả context retrieve và câu trả lời. Note lại trường hợp retrieve sai.
5. (Tùy chọn) Đọc abstract của paper Lewis et al. 2020 (arXiv 2005.11401) và Gao et al. 2023 survey (arXiv 2312.10997). Tóm tắt 5 ý chính sự khác nhau giữa Naive, Advanced, Modular RAG theo survey.