Home Resume Blog LinkedIn

RAG - Retrieval-Augmented Generation: Kiến trúc truy xuất tri thức cho ứng dụng AI

Posted on: 4/13/2026 5:12:04 PM

Table of contents

  1. RAG - Retrieval-Augmented Generation: Kiến trúc truy xuất tri thức cho ứng dụng AI
    1. Mục lục
    2. 1. Giới thiệu: Tại sao cần RAG?
      1. RAG vs Fine-tuning vs Prompt Engineering
    3. 2. Kiến trúc tổng quan RAG Pipeline
      1. 2.1. Indexing Pipeline
      2. 2.2. Query Pipeline
    4. 3. Embedding - Biểu diễn ngữ nghĩa dữ liệu
      1. 3.1. Lựa chọn Embedding Model
        1. Mẹo chọn Embedding Model
    5. 4. Chunking Strategies - Nghệ thuật chia nhỏ tài liệu
      1. 4.1. Fixed-size Chunking
      2. 4.2. Recursive Character Splitting
      3. 4.3. Semantic Chunking
      4. 4.4. Agentic Chunking
        1. Lưu ý quan trọng về Chunk Size
    6. 5. Vector Database - Nền tảng lưu trữ và tìm kiếm
      1. 5.1. So sánh Vector Databases phổ biến
      2. 5.2. Thuật toán HNSW (Hierarchical Navigable Small World)
        1. Khi nào dùng pgvector?
    7. 6. Retrieval - Chiến lược truy xuất thông tin
      1. 6.1. Dense Retrieval (Semantic Search)
      2. 6.2. Sparse Retrieval (Keyword Search)
      3. 6.3. Hybrid Search - Kết hợp tốt nhất
        1. Best practice: Luôn dùng Hybrid Search
    8. 7. Reranking - Tinh chỉnh kết quả tìm kiếm
      1. 7.1. Bi-encoder vs Cross-encoder
      2. 7.2. Reranking Models phổ biến
    9. 8. Generation - Sinh câu trả lời có ngữ cảnh
      1. 8.1. RAG Prompt Template
      2. 8.2. Citation và Grounding
        1. Kỹ thuật giảm hallucination trong Generation
    10. 9. Advanced RAG Patterns
      1. 9.1. Query Transformation
      2. 9.2. Corrective RAG (CRAG)
      3. 9.3. Self-RAG
      4. 9.4. Agentic RAG
        1. Khi nào dùng Advanced RAG?
    11. 10. Đánh giá chất lượng RAG (RAGAS)
      1. 10.1. Các Metrics quan trọng
      2. 10.2. End-to-End Evaluation Flow
        1. Xây dựng Evaluation Dataset
    12. 11. Triển khai Production: Bài học thực chiến
      1. 11.1. Kiến trúc Production-Ready
      2. 11.2. Caching Strategy
      3. 11.3. Monitoring và Observability
      4. 11.4. Những sai lầm phổ biến
        1. Top 5 sai lầm khi triển khai RAG
    13. 12. Kết luận và hướng phát triển
      1. Xu hướng RAG trong 2026-2027
        1. Tài nguyên tham khảo
RAG - Retrieval-Augmented Generation: Kiến trúc truy xuất tri thức cho ứng dụng AI | AnhTu.dev

RAG - Retrieval-Augmented Generation: Kiến trúc truy xuất tri thức cho ứng dụng AI

13/04/2026 | ~25 phút đọc | AnhTu.dev
RAG Vector Database LLM Embedding AI Engineering

1. Giới thiệu: Tại sao cần RAG?

Large Language Models (LLMs) như GPT-4, Claude, Gemini đã thay đổi hoàn toàn cách chúng ta tương tác với AI. Tuy nhiên, chúng có một hạn chế cốt lõi: knowledge cutoff - mọi kiến thức bị đóng băng tại thời điểm training. Khi bạn hỏi về dữ liệu nội bộ công ty, tài liệu kỹ thuật mới nhất, hay thông tin real-time, LLM sẽ "bịa" ra câu trả lời - hiện tượng gọi là hallucination.

RAG (Retrieval-Augmented Generation) là kiến trúc giải quyết chính xác vấn đề này: thay vì chỉ dựa vào bộ nhớ của model, hệ thống sẽ tìm kiếm thông tin liên quan từ nguồn dữ liệu bên ngoài, rồi đưa vào context để LLM sinh câu trả lời chính xác, có căn cứ.

86% ứng dụng AI enterprise sử dụng RAG (2026)
3-5x giảm hallucination so với vanilla LLM
~40% tiết kiệm chi phí so với fine-tuning
Real-time cập nhật tri thức không cần re-train

RAG vs Fine-tuning vs Prompt Engineering

Prompt Engineering: Tối ưu cách đặt câu hỏi - đơn giản nhưng giới hạn bởi context window.
Fine-tuning: Train lại model với dữ liệu riêng - tốn kém, chậm cập nhật, dễ catastrophic forgetting.
RAG: Kết hợp tìm kiếm + sinh nội dung - linh hoạt, cập nhật real-time, có nguồn trích dẫn.

2. Kiến trúc tổng quan RAG Pipeline

Một hệ thống RAG hoàn chỉnh gồm hai pipeline chính: Indexing Pipeline (offline) và Query Pipeline (online). Hiểu rõ từng thành phần sẽ giúp bạn thiết kế hệ thống tối ưu cho từng use case.

graph LR subgraph Indexing["📥 Indexing Pipeline (Offline)"] A["Documents\nPDF, Web, DB"] --> B["Chunking\nChia nhỏ tài liệu"] B --> C["Embedding\nModel"] C --> D["Vector\nDatabase"] end subgraph Query["🔍 Query Pipeline (Online)"] E["User Query"] --> F["Query\nEmbedding"] F --> G["Semantic\nSearch"] D --> G G --> H["Reranker"] H --> I["LLM +\nContext"] I --> J["Response\n+ Citations"] end style A fill:#0f3460,stroke:#fff,color:#fff style B fill:#0f3460,stroke:#fff,color:#fff style C fill:#e94560,stroke:#fff,color:#fff style D fill:#4CAF50,stroke:#fff,color:#fff style E fill:#ff9800,stroke:#fff,color:#fff style F fill:#e94560,stroke:#fff,color:#fff style G fill:#4CAF50,stroke:#fff,color:#fff style H fill:#9C27B0,stroke:#fff,color:#fff style I fill:#e94560,stroke:#fff,color:#fff style J fill:#0f3460,stroke:#fff,color:#fff

Hình 1: Kiến trúc tổng quan RAG Pipeline - từ indexing đến query

2.1. Indexing Pipeline

Đây là giai đoạn chuẩn bị dữ liệu, thường chạy offline hoặc theo batch:

  • Document Loading: Thu thập tài liệu từ nhiều nguồn (PDF, HTML, database, API, Confluence, Notion...)
  • Chunking: Chia tài liệu thành các đoạn nhỏ (chunks) với kích thước phù hợp
  • Embedding: Chuyển đổi mỗi chunk thành vector số học (embedding vector) bằng model chuyên dụng
  • Storage: Lưu trữ embedding vectors vào vector database để tìm kiếm nhanh

2.2. Query Pipeline

Đây là luồng xử lý real-time khi người dùng đặt câu hỏi:

  • Query Embedding: Chuyển câu hỏi thành vector bằng cùng embedding model
  • Retrieval: Tìm kiếm top-K chunks có vector gần nhất (semantic similarity)
  • Reranking: Sắp xếp lại kết quả bằng cross-encoder để tăng độ chính xác
  • Generation: Đưa chunks được chọn vào prompt, LLM sinh câu trả lời có nguồn trích dẫn

3. Embedding - Biểu diễn ngữ nghĩa dữ liệu

Embedding là quá trình chuyển đổi text thành vector số học trong không gian nhiều chiều, sao cho các đoạn text có ý nghĩa tương tự sẽ nằm gần nhau. Đây là nền tảng cốt lõi của mọi hệ thống RAG.

graph LR A["''Redis là in-memory database''"] --> B["Embedding\nModel"] B --> C["[0.12, -0.45, 0.78, ..., 0.33]\n1536 dimensions"] D["''Cơ sở dữ liệu lưu trên RAM''"] --> E["Embedding\nModel"] E --> F["[0.11, -0.43, 0.79, ..., 0.31]\n1536 dimensions"] C -.- |"cosine similarity = 0.94"| F style A fill:#0f3460,stroke:#fff,color:#fff style D fill:#0f3460,stroke:#fff,color:#fff style B fill:#e94560,stroke:#fff,color:#fff style E fill:#e94560,stroke:#fff,color:#fff style C fill:#4CAF50,stroke:#fff,color:#fff style F fill:#4CAF50,stroke:#fff,color:#fff

Hình 2: Embedding chuyển text thành vector - câu đồng nghĩa có vector gần nhau

3.1. Lựa chọn Embedding Model

ModelDimensionsMax TokensĐặc điểm
text-embedding-3-large30728191OpenAI, chất lượng cao, hỗ trợ giảm dimensions
voyage-3-large102432000Voyage AI, context dài, retrieval-optimized
Cohere embed-v41024128000Multimodal, context cực dài, hỗ trợ binary quantization
BGE-M310248192Open source, multi-lingual, multi-granularity
nomic-embed-text7688192Open source, nhẹ, phù hợp self-hosted

Mẹo chọn Embedding Model

Nếu dữ liệu tiếng Việt, ưu tiên BGE-M3 hoặc Cohere embed-v4 vì hỗ trợ multi-lingual tốt. Nếu cần tốc độ và chi phí thấp, nomic-embed-text chạy local là lựa chọn hợp lý. Luôn benchmark trên chính dữ liệu của bạn trước khi quyết định.

4. Chunking Strategies - Nghệ thuật chia nhỏ tài liệu

Chunking là bước quan trọng bậc nhất trong pipeline RAG. Chunk quá nhỏ sẽ mất ngữ cảnh, chunk quá lớn sẽ chứa nhiều noise và tốn token. Không có công thức chung - bạn cần thử nghiệm trên chính dữ liệu của mình.

4.1. Fixed-size Chunking

Chia tài liệu thành các đoạn có kích thước cố định (ví dụ 512 tokens) với một phần overlap:

// Fixed-size chunking với overlap
chunk_size = 512 tokens
chunk_overlap = 64 tokens

Document: [===========|=========|===========]
Chunk 1:  [===========|__]
Chunk 2:           [__|=========|__]
Chunk 3:                     [__|===========]

Ưu điểm: Đơn giản, dễ implement, chunk size đồng nhất. Nhược điểm: Có thể cắt giữa câu hoặc giữa ý.

4.2. Recursive Character Splitting

Chia theo hierarchy: paragraph → sentence → word. Ưu tiên giữ nguyên cấu trúc tự nhiên của văn bản:

separators = ["\n\n", "\n", ". ", " ", ""]
// Thử chia theo paragraph trước
// Nếu chunk vẫn quá lớn, chia theo câu
// Tiếp tục cho đến khi đạt kích thước mong muốn

4.3. Semantic Chunking

Sử dụng embedding để xác định ranh giới ngữ nghĩa. Khi cosine similarity giữa hai câu liên tiếp giảm đột ngột, đó là điểm chia chunk:

graph TD A["Câu 1: Giới thiệu Redis"] --> B["Câu 2: Redis lưu dữ liệu trên RAM"] B --> C["Câu 3: Tốc độ đọc/ghi rất nhanh"] C -.->|"Similarity giảm mạnh"| D["Câu 4: Kafka là message broker"] D --> E["Câu 5: Kafka dùng cho event streaming"] subgraph Chunk1["Chunk 1: Redis"] A B C end subgraph Chunk2["Chunk 2: Kafka"] D E end style A fill:#0f3460,stroke:#fff,color:#fff style B fill:#0f3460,stroke:#fff,color:#fff style C fill:#0f3460,stroke:#fff,color:#fff style D fill:#e94560,stroke:#fff,color:#fff style E fill:#e94560,stroke:#fff,color:#fff

Hình 3: Semantic Chunking - chia tài liệu dựa trên ranh giới ngữ nghĩa

4.4. Agentic Chunking

Sử dụng LLM để quyết định cách chia chunk thông minh hơn. Model sẽ đọc tài liệu và xác định các đơn vị ngữ nghĩa hoàn chỉnh:

// Prompt cho LLM:
"Hãy chia tài liệu sau thành các đoạn,
mỗi đoạn chứa MỘT chủ đề/ý hoàn chỉnh.
Đánh dấu ranh giới bằng [SPLIT]"

Lưu ý quan trọng về Chunk Size

Chunk size phụ thuộc vào loại dữ liệu: tài liệu kỹ thuật nên dùng chunk 512-1024 tokens, FAQ/Q&A có thể dùng chunk nhỏ 128-256 tokens, legal documents cần chunk lớn hơn 1024-2048 tokens để giữ nguyên ngữ cảnh pháp lý. Luôn kèm metadata (tiêu đề section, trang, nguồn) vào mỗi chunk.

5. Vector Database - Nền tảng lưu trữ và tìm kiếm

Vector Database là thành phần lưu trữ embedding vectors và hỗ trợ tìm kiếm Approximate Nearest Neighbor (ANN) với tốc độ cực nhanh, ngay cả trên hàng triệu vectors.

5.1. So sánh Vector Databases phổ biến

DatabaseKiểuIndexĐặc điểm nổi bật
PineconeCloud-nativeProprietaryFully managed, serverless, dễ dùng nhất
WeaviateOpen sourceHNSWHybrid search, GraphQL API, modules ecosystem
QdrantOpen sourceHNSWRust-based, nhanh, filtering mạnh, payload storage
ChromaDBOpen sourceHNSWNhẹ, embedded mode, tốt cho prototyping
pgvectorExtensionIVFFlat/HNSWPostgreSQL extension, không cần DB riêng
MilvusOpen sourceIVF/HNSW/DiskANNScale lớn, distributed, GPU-accelerated

5.2. Thuật toán HNSW (Hierarchical Navigable Small World)

Đây là thuật toán ANN phổ biến nhất trong các vector databases hiện tại. HNSW xây dựng một cấu trúc đồ thị nhiều tầng:

graph TD subgraph Layer2["Layer 2 (Sparse - Navigation)"] A2["Node A"] --> B2["Node E"] end subgraph Layer1["Layer 1 (Medium)"] A1["Node A"] --> C1["Node C"] C1 --> E1["Node E"] A1 --> E1 end subgraph Layer0["Layer 0 (Dense - All Nodes)"] A0["A"] --> B0["B"] B0 --> C0["C"] C0 --> D0["D"] D0 --> E0["E"] A0 --> C0 C0 --> E0 B0 --> D0 end A2 -.-> A1 B2 -.-> E1 A1 -.-> A0 C1 -.-> C0 E1 -.-> E0 style A2 fill:#e94560,stroke:#fff,color:#fff style B2 fill:#e94560,stroke:#fff,color:#fff style A1 fill:#ff9800,stroke:#fff,color:#fff style C1 fill:#ff9800,stroke:#fff,color:#fff style E1 fill:#ff9800,stroke:#fff,color:#fff style A0 fill:#4CAF50,stroke:#fff,color:#fff style B0 fill:#4CAF50,stroke:#fff,color:#fff style C0 fill:#4CAF50,stroke:#fff,color:#fff style D0 fill:#4CAF50,stroke:#fff,color:#fff style E0 fill:#4CAF50,stroke:#fff,color:#fff

Hình 4: Cấu trúc HNSW - tìm kiếm từ layer thưa đến layer dày

Quá trình tìm kiếm bắt đầu từ layer trên cùng (ít node nhất), di chuyển đến node gần query nhất, rồi "xuống" layer dưới và tiếp tục. Độ phức tạp tìm kiếm chỉ O(log N) thay vì O(N) của brute-force.

Khi nào dùng pgvector?

Nếu bạn đã dùng PostgreSQL và dataset dưới 5 triệu vectors, pgvector là lựa chọn thực dụng nhất - không cần thêm infrastructure. Với dataset lớn hơn hoặc yêu cầu latency thấp, chuyển sang Qdrant hoặc Milvus.

6. Retrieval - Chiến lược truy xuất thông tin

Retrieval là bước quyết định chất lượng toàn bộ hệ thống RAG. Nếu tìm sai tài liệu, LLM không thể sinh câu trả lời đúng - "Garbage in, garbage out".

Sử dụng embedding vectors để tìm kiếm theo ngữ nghĩa. Query và documents được chuyển thành vectors, tìm theo cosine similarity hoặc dot product:

// Semantic search
query_vector = embed("Làm sao tối ưu performance Redis?")
results = vector_db.search(
    vector=query_vector,
    top_k=10,
    metric="cosine"
)

Ưu điểm: Hiểu ngữ nghĩa, tìm được paraphrase. Nhược điểm: Yếu với keyword chính xác, entity names, mã số.

Dựa trên TF-IDF hoặc BM25, tìm kiếm theo từ khóa chính xác:

// BM25 search
results = bm25_index.search("Redis SET command timeout")
// Tốt cho: exact match, technical terms, error codes

Ưu điểm: Chính xác với keyword, tên riêng, mã lỗi. Nhược điểm: Không hiểu ngữ nghĩa, synonyms.

6.3. Hybrid Search - Kết hợp tốt nhất

Hybrid Search kết hợp cả Dense và Sparse retrieval, sau đó dùng Reciprocal Rank Fusion (RRF) để merge kết quả:

graph LR Q["User Query"] --> D["Dense Retrieval\n(Semantic)"] Q --> S["Sparse Retrieval\n(BM25)"] D --> R["Reciprocal Rank\nFusion (RRF)"] S --> R R --> T["Top-K\nResults"] style Q fill:#ff9800,stroke:#fff,color:#fff style D fill:#e94560,stroke:#fff,color:#fff style S fill:#0f3460,stroke:#fff,color:#fff style R fill:#9C27B0,stroke:#fff,color:#fff style T fill:#4CAF50,stroke:#fff,color:#fff

Hình 5: Hybrid Search kết hợp semantic và keyword search

// Reciprocal Rank Fusion
RRF_score(d) = Σ 1/(k + rank_i(d))

// Ví dụ: document D có rank 2 trong dense, rank 5 trong sparse
// k = 60 (constant)
// RRF = 1/(60+2) + 1/(60+5) = 0.0161 + 0.0154 = 0.0315

Trong thực tế production, Hybrid Search gần như luôn tốt hơn chỉ dùng semantic hoặc keyword search đơn lẻ. Các vector databases như Weaviate, Qdrant, Milvus đều hỗ trợ hybrid search built-in.

7. Reranking - Tinh chỉnh kết quả tìm kiếm

Retrieval trả về top-K candidates, nhưng thứ tự có thể chưa tối ưu. Reranker là model chuyên dụng đánh giá lại mức độ liên quan giữa query và từng document, sắp xếp lại chính xác hơn.

7.1. Bi-encoder vs Cross-encoder

Đặc điểmBi-encoder (Retrieval)Cross-encoder (Reranking)
InputQuery và Document encode riêng biệtQuery + Document encode cùng nhau
Tốc độNhanh - vectors tính trướcChậm - phải tính lại cho mỗi cặp
Chất lượngTốt cho recallRất tốt cho precision
Use caseStage 1: Tìm top 50-100 candidatesStage 2: Chọn top 3-5 từ candidates

7.2. Reranking Models phổ biến

  • Cohere Rerank 3.5: API cloud, chất lượng cao nhất, hỗ trợ multi-lingual
  • bge-reranker-v2-m3: Open source, multi-lingual, chạy local được
  • cross-encoder/ms-marco-MiniLM-L-12-v2: Nhẹ, nhanh, tốt cho English
  • Jina Reranker v2: Open source, hỗ trợ code và multilingual
// 2-stage retrieval + reranking
candidates = hybrid_search(query, top_k=50)
reranked = reranker.rank(query, candidates, top_n=5)
context = format_context(reranked)
response = llm.generate(query, context)

8. Generation - Sinh câu trả lời có ngữ cảnh

Bước cuối cùng: đưa retrieved context vào prompt và để LLM sinh câu trả lời. Prompt engineering ở bước này cực kỳ quan trọng.

8.1. RAG Prompt Template

SYSTEM_PROMPT = """
Bạn là trợ lý AI chuyên trả lời câu hỏi dựa trên tài liệu được cung cấp.

QUY TẮC:
1. CHỈ trả lời dựa trên thông tin trong [CONTEXT] bên dưới
2. Nếu thông tin không đủ, nói rõ "Tôi không tìm thấy thông tin về vấn đề này trong tài liệu"
3. Trích dẫn nguồn bằng [Source: tên_tài_liệu]
4. Trả lời ngắn gọn, chính xác, có cấu trúc

[CONTEXT]
{retrieved_chunks}
[/CONTEXT]
"""

USER_PROMPT = "{user_question}"

8.2. Citation và Grounding

Một hệ thống RAG tốt phải có citation - trích dẫn nguồn cho mỗi thông tin trong câu trả lời. Điều này giúp người dùng:

  • Verify: Kiểm tra lại thông tin từ nguồn gốc
  • Trust: Tăng độ tin cậy của câu trả lời
  • Debug: Phát hiện khi retrieval sai hoặc context thiếu

Kỹ thuật giảm hallucination trong Generation

1) Yêu cầu LLM chỉ dùng thông tin trong context ("closed-book"). 2) Dùng chain-of-thought: LLM giải thích logic trước khi trả lời. 3) Thêm instruction "Nếu không chắc chắn, hãy nói không biết". 4) Set temperature thấp (0.0-0.3) cho factual queries.

9. Advanced RAG Patterns

Naive RAG (query → retrieve → generate) hoạt động tốt cho nhiều use case, nhưng có giới hạn. Các pattern nâng cao giải quyết những vấn đề phức tạp hơn.

9.1. Query Transformation

Cải thiện chất lượng retrieval bằng cách biến đổi query trước khi tìm kiếm:

  • Query Rewriting: LLM viết lại query rõ ràng hơn ("Redis chậm" → "Nguyên nhân khiến Redis response time cao và cách tối ưu performance")
  • HyDE (Hypothetical Document Embedding): LLM sinh ra một "câu trả lời giả", dùng embedding của câu trả lời đó để tìm kiếm
  • Step-back Prompting: Từ câu hỏi cụ thể, tạo câu hỏi tổng quát hơn để tìm context rộng hơn
  • Sub-query Decomposition: Tách câu hỏi phức tạp thành nhiều câu hỏi nhỏ, tìm kiếm từng cái

9.2. Corrective RAG (CRAG)

Thêm bước đánh giá chất lượng của retrieved documents trước khi đưa vào LLM:

graph TD A["User Query"] --> B["Retrieval"] B --> C{"Quality\nEvaluator"} C -->|"Relevant"| D["Generate\nwith Context"] C -->|"Ambiguous"| E["Web Search\n+ Retrieval"] C -->|"Irrelevant"| F["Web Search\nOnly"] E --> D F --> D D --> G["Response"] style A fill:#ff9800,stroke:#fff,color:#fff style B fill:#0f3460,stroke:#fff,color:#fff style C fill:#e94560,stroke:#fff,color:#fff style D fill:#4CAF50,stroke:#fff,color:#fff style E fill:#9C27B0,stroke:#fff,color:#fff style F fill:#9C27B0,stroke:#fff,color:#fff style G fill:#4CAF50,stroke:#fff,color:#fff

Hình 6: Corrective RAG - đánh giá và tự sửa chữa kết quả retrieval

9.3. Self-RAG

Self-RAG cho phép LLM tự quyết định khi nào cần retrieval và tự đánh giá output:

  • Retrieve token: LLM quyết định "có cần tìm thêm thông tin không?"
  • ISREL: Đánh giá "document này có liên quan không?"
  • ISSUP: Kiểm tra "câu trả lời có được hỗ trợ bởi document không?"
  • ISUSE: Đánh giá "câu trả lời có hữu ích cho user không?"

9.4. Agentic RAG

Kết hợp RAG với AI Agent - agent có khả năng lập kế hoạch, sử dụng nhiều tool, và iteratively tìm kiếm cho đến khi có đủ thông tin:

graph LR A["User Query"] --> B["AI Agent\n(Planner)"] B --> C["Tool: Vector Search"] B --> D["Tool: SQL Query"] B --> E["Tool: Web Search"] B --> F["Tool: API Call"] C --> G["Agent\nReasoning"] D --> G E --> G F --> G G -->|"Cần thêm info"| B G -->|"Đủ info"| H["Final\nResponse"] style A fill:#ff9800,stroke:#fff,color:#fff style B fill:#e94560,stroke:#fff,color:#fff style C fill:#4CAF50,stroke:#fff,color:#fff style D fill:#4CAF50,stroke:#fff,color:#fff style E fill:#4CAF50,stroke:#fff,color:#fff style F fill:#4CAF50,stroke:#fff,color:#fff style G fill:#0f3460,stroke:#fff,color:#fff style H fill:#4CAF50,stroke:#fff,color:#fff

Hình 7: Agentic RAG - AI Agent với nhiều công cụ tìm kiếm

Khi nào dùng Advanced RAG?

Naive RAG đủ cho: FAQ bot, document Q&A đơn giản, knowledge base cơ bản. Advanced RAG cần khi: câu hỏi phức tạp multi-hop, dữ liệu từ nhiều nguồn khác nhau, yêu cầu độ chính xác cao (y tế, pháp lý, tài chính), hoặc khi naive RAG cho kết quả không đạt yêu cầu.

10. Đánh giá chất lượng RAG (RAGAS)

Không thể cải thiện những gì không đo lường được. RAGAS (Retrieval Augmented Generation Assessment) là framework đánh giá chất lượng RAG phổ biến nhất, với các metrics chuyên biệt.

10.1. Các Metrics quan trọng

MetricĐo gìCông thức
Context PrecisionRetrieved chunks có thực sự liên quan?Relevant chunks / Total retrieved chunks
Context RecallĐã tìm được đủ thông tin cần thiết?Relevant retrieved / Total relevant in DB
FaithfulnessCâu trả lời có đúng với context?Supported claims / Total claims in answer
Answer RelevancyCâu trả lời có đúng ý câu hỏi?Semantic similarity (answer, question)

10.2. End-to-End Evaluation Flow

// Sử dụng RAGAS framework
from ragas import evaluate
from ragas.metrics import (
    context_precision,
    context_recall,
    faithfulness,
    answer_relevancy
)

result = evaluate(
    dataset=eval_dataset,  # questions + ground_truth + contexts + answers
    metrics=[
        context_precision,
        context_recall,
        faithfulness,
        answer_relevancy,
    ],
)
print(result)
# {''context_precision'': 0.87, ''context_recall'': 0.82,
#  ''faithfulness'': 0.91, ''answer_relevancy'': 0.89}

Xây dựng Evaluation Dataset

Bắt đầu với 50-100 câu hỏi thực tế từ users. Mỗi câu cần: question, ground_truth answer, và expected source documents. Dùng LLM để sinh thêm synthetic questions, nhưng luôn có human review. Chạy eval sau mỗi thay đổi pipeline (chunk size, model, retrieval strategy).

11. Triển khai Production: Bài học thực chiến

Xây dựng RAG prototype thì dễ, nhưng đưa lên production là một câu chuyện hoàn toàn khác. Dưới đây là những bài học quan trọng từ thực tế.

11.1. Kiến trúc Production-Ready

graph TD subgraph Client["Client Layer"] A["Web App / API"] end subgraph Gateway["API Gateway"] B["Rate Limiter\n+ Auth"] end subgraph RAG["RAG Service"] C["Query Router"] D["Retrieval Service"] E["Reranker Service"] F["Generation Service"] end subgraph Storage["Data Layer"] G["Vector DB\n(Qdrant)"] H["Cache\n(Redis)"] I["Document Store\n(S3/MinIO)"] end subgraph Observability["Observability"] J["Tracing\n(LangSmith)"] K["Metrics\n(Prometheus)"] L["Logging\n(ELK)"] end A --> B B --> C C --> D D --> G D --> H E --> F D --> E F --> A C --> J D --> J F --> J D --> K F --> K style A fill:#0f3460,stroke:#fff,color:#fff style B fill:#ff9800,stroke:#fff,color:#fff style C fill:#e94560,stroke:#fff,color:#fff style D fill:#e94560,stroke:#fff,color:#fff style E fill:#e94560,stroke:#fff,color:#fff style F fill:#e94560,stroke:#fff,color:#fff style G fill:#4CAF50,stroke:#fff,color:#fff style H fill:#4CAF50,stroke:#fff,color:#fff style I fill:#4CAF50,stroke:#fff,color:#fff style J fill:#9C27B0,stroke:#fff,color:#fff style K fill:#9C27B0,stroke:#fff,color:#fff style L fill:#9C27B0,stroke:#fff,color:#fff

Hình 8: Kiến trúc RAG Production với caching, observability, và scaling

11.2. Caching Strategy

RAG pipeline có nhiều điểm có thể cache để giảm latency và chi phí:

  • Embedding Cache: Cache embedding vectors của các query phổ biến (Redis với TTL 24h)
  • Retrieval Cache: Cache kết quả tìm kiếm cho exact query match
  • Semantic Cache: Cache response cho các query có semantic similarity cao (> 0.95) với query đã trả lời
  • LLM Response Cache: Cache toàn bộ response cho identical prompts

11.3. Monitoring và Observability

Các metrics cần monitor trong production:

  • Retrieval latency: P50, P95, P99 của thời gian tìm kiếm (target: < 100ms)
  • End-to-end latency: Tổng thời gian từ query đến response (target: < 3s)
  • Retrieval relevance: % queries có ít nhất 1 relevant chunk trong top-5
  • Hallucination rate: % responses chứa thông tin không có trong context
  • User satisfaction: Thumbs up/down ratio, follow-up question rate

11.4. Những sai lầm phổ biến

Top 5 sai lầm khi triển khai RAG

1) Chunk size cố định cho mọi loại tài liệu - mỗi loại document cần chunk strategy riêng.
2) Không có reranking - retrieval recall cao nhưng precision thấp, LLM nhận quá nhiều noise.
3) Bỏ qua metadata filtering - kết hợp vector search với metadata filter (date, source, category) tăng precision đáng kể.
4) Không monitor hallucination - thiếu hệ thống đánh giá tự động chất lượng response.
5) Thiếu data pipeline - documents cập nhật nhưng index không được refresh, dẫn đến câu trả lời outdated.

12. Kết luận và hướng phát triển

RAG không chỉ là một kỹ thuật - nó đã trở thành kiến trúc tiêu chuẩn cho mọi ứng dụng AI enterprise cần làm việc với dữ liệu riêng. Từ chatbot nội bộ, hệ thống hỗ trợ khách hàng, đến công cụ phân tích tài liệu pháp lý - RAG là nền tảng.

Xu hướng RAG trong 2026-2027

Q1-Q2 2026
Long-context models + RAG: Models với context 1M+ tokens không thay thế RAG mà bổ sung - dùng long context cho reranked results thay vì chỉ top-5 chunks.
Q2-Q3 2026
Multimodal RAG: Tìm kiếm và truy xuất không chỉ text mà cả images, tables, charts, audio - Cohere embed-v4 và Google multimodal embeddings dẫn đầu.
Q3-Q4 2026
Graph RAG: Kết hợp knowledge graphs với vector search - Microsoft GraphRAG cho phép reasoning trên quan hệ giữa entities, không chỉ similarity.
2027
Autonomous RAG Agents: AI agents tự tối ưu pipeline - tự chọn chunking strategy, tự tune retrieval parameters, tự đánh giá và cải thiện chất lượng liên tục.

Nếu bạn đang bắt đầu với RAG, hãy bắt đầu đơn giản: chunking cơ bản + embedding model tốt + hybrid search + reranker. Đo lường bằng RAGAS, rồi iterate. Đừng over-engineer từ đầu - hầu hết giá trị đến từ việc làm đúng những thứ cơ bản.

Tài nguyên tham khảo

Các bài viết liên quan trên anhtu.dev:
- Agentic AI Architecture - Thiết kế kiến trúc hệ thống AI đa tác nhân
- MCP - Giao thức Kết nối Vạn năng cho Hệ thống AI Multi-Agent

AnhTu.dev - anhtu.dev | 13/04/2026

Bài viết được tổng hợp và phân tích từ nhiều nguồn tài liệu kỹ thuật. Nội dung mang tính tham khảo chuyên sâu.

© 2026 anhtu.dev - All rights reserved.

© 2026 - anhtu.dev. All Rights Reserved. - Designed by Anh Tú

Disclaimer: The opinions expressed in this blog are solely my own and do not reflect the views or opinions of my employer or any affiliated organizations. The content provided is for informational and educational purposes only and should not be taken as professional advice. While I strive to provide accurate and up-to-date information, I make no warranties or guarantees about the completeness, reliability, or accuracy of the content. Readers are encouraged to verify the information and seek independent advice as needed. I disclaim any liability for decisions or actions taken based on the content of this blog.