Lời mở đầu

• Tiếp nối phần 1, chúng ta sẽ cùng trao đổi tiếp tại phần 2 này nhé

4. 💡 LightRAG — Dual-Level Graph Retrieval

Reference:

Guo et al. (HKUST), "LightRAG: Simple and Fast Retrieval-Augmented Generation", arXiv:2410.05779, Oct 2024 GitHub: HKUDS/LightRAG (22k+ stars)

Ý tưởng cốt lõi

Vấn đề của RAG truyền thống: Vector search tìm được các đoạn text "ngữ nghĩa gần" nhưng không hiểu mối quan hệ giữa các entities. Ví dụ:

• Hỏi: "Mối quan hệ giữa công ty A và CEO B ảnh hưởng thế nào đến sản phẩm C?"
• Vector search tìm được docs về A, về B, về C riêng lẻ — nhưng không thấy mối liên hệ tam giác A-B-C

LightRAG tích hợp knowledge graph với vector embeddings và implement Dual-Level Retrieval:

Cấu trúc index:

Văn bản → Extract (entities, relations) → Knowledge Graph
                                        ↓
                               Nodes: entities (người, tổ chức, khái niệm, sự kiện)
                               Edges: relations (CEO_of, produces, causes, related_to...)
                               
Mỗi node/edge → Vector embedding (cho semantic search)

Dual-Level Retrieval:

Query người dùng
    ↓
┌─────────────────────────────────────────┐
│ LOW-LEVEL: Tìm entities/facts cụ thể    │
│   → Vector search trên node embeddings  │
│   → Tìm exact entities liên quan        │
│   → Lấy các facts trực tiếp            │
└─────────────────────────────────────────┘
        +
┌─────────────────────────────────────────┐
│ HIGH-LEVEL: Tìm patterns/themes tổng quát│
│   → Vector search trên community-level  │
│   → Tìm clusters of related knowledge   │
│   → Lấy context rộng hơn               │
└─────────────────────────────────────────┘
        ↓
Merge & Deduplicate → Context cho LLM

Chiến lược này mình có từng tham khảo repo, thì cơ bản chưa thấy khác GraphRAG nhiều lắm, bản thân cảm nhận giống như 1 bản GraphRAG mini. Nếu mọi người từng điều tra sâu nó thì cho mình xin thêm insights nhé.

So sánh với các giải pháp khác:

5. 🗺️ GraphRAG — Microsoft's Graph-Based RAG

Reference:

Edge et al. (Microsoft Research), "From Local to Global: A Graph RAG Approach to Query-Focused Summarization", arXiv:2404.16130, Apr 2024 Open Source: microsoft/graphrag

Mình có một bài viết chi tiết ở đây, bạn đọc có thể tham khảo kỹ hơn nhé: https://viblo.asia/p/graphrag-mot-su-nang-cap-moi-cua-rag-truyen-thong-chang-EoW4oXRBJml (Mình nhớ không nhầm nó đã có thêm 1 chiến lược retrieval mới là Drift search thì phải)

6. 🌳 RAPTOR — Recursive Tree Summarization (Tháng 1/2024)

Reference:

Sarthi et al. (Stanford), "RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval", arXiv:2401.18059, Jan 2024 Code: github.com/parthsarthi03/raptor

Ý tưởng cốt lõi

Vấn đề của chunk-based RAG: Standard RAG chia văn bản thành các chunk ~100-500 tokens rồi embed. Khi query, tìm top-k chunks gần nhất.

Câu hỏi: "Điều gì dẫn Cinderella đến happy ending?" → Cần hiểu toàn bộ arc của câu chuyện từ đầu đến cuối → Top-k chunks chỉ chứa các đoạn rời rạc → không trả lời được

Đây cũng là một vấn đề mà rất nhiều người gặp phải nếu triển khai standard RAG hoặc GraphRAG mà chỉ local search (không build community + global search vì rất tốn kém)

RAPTOR xây dựng cây tóm tắt đệ quy (recursive summary tree):

Stage Indexing — Xây dựng cây từ dưới lên:

Step 1: Chunk văn bản thành ~100 token chunks (leaf nodes)
        Embed bằng SBERT (multi-qa-mpnet-base-cos-v1)

Step 2: Clustering với Gaussian Mixture Models (GMM) + UMAP
        - Dùng UMAP để giảm chiều embedding trước (giải quyết curse of dimensionality)
        - GMM với Bayesian Information Criterion để tìm số clusters tối ưu
        - KEY INSIGHT → Soft clustering: 1 chunk có thể thuộc NHIỀU clusters!
          (Vì 1 đoạn text thường liên quan đến nhiều chủ đề)
        - Average cluster size: ~6.7 nodes/cluster

Step 3: Summarize mỗi cluster bằng LLM → tạo parent nodes
        - gpt-3.5-turbo được dùng để summarize
        - Compression ratio trung bình: 72%
          (summary ~131 tokens thay cho ~6.7 × 86 = ~577 tokens)
        - Hallucination rate trong summary: chỉ ~4%, không lan truyền lên parent

Step 4: Lặp lại Step 2-3 trên các parent nodes
        → Tiếp tục cho đến khi không thể cluster thêm
        → Kết quả: cây nhiều tầng với root là bản tóm tắt toàn bộ

Ví dụ cấu trúc cây với sách 100 trang:

Root (1 node): Tóm tắt toàn bộ cuốn sách
    ↓
Level 3 (5 nodes): Tóm tắt từng phần lớn
    ↓
Level 2 (30 nodes): Tóm tắt từng chương
    ↓
Level 1 (150 nodes): Tóm tắt nhóm đoạn văn liên quan
    ↓
Level 0 / Leaves (500 nodes): Các chunk gốc 100 tokens

Stage Querying — 2 chiến lược:

1. Tree Traversal (top-down, cứng nhắc hơn):

Query → embed → cosine similarity với Root → chọn top-k
→ Đi xuống child nodes → cosine similarity → top-k
→ Tiếp tục đến leaf level → concatenate tất cả nodes được chọn

2. Collapsed Tree (recommended — hiệu quả hơn):

Query → embed → FLATTEN tất cả nodes ở MỌI level thành 1 list
→ Cosine similarity với tất cả nodes
→ Chọn nodes cho đến đủ token budget (default 2000 tokens)

Tại sao Collapsed Tree tốt hơn? Vì nó tự động chọn đúng cấp độ granularity cho từng câu hỏi. Câu hỏi chi tiết → tự nhiên chọn leaf nodes; câu hỏi tổng quát → tự nhiên chọn summary nodes — thay vì phải traverse theo cấu trúc cứng.

Điểm sáng chính

Kết quả thực nghiệm cụ thể (từ paper):

Chi tiết kỹ thuật nổi bật:

• Linear scaling: Build time và token cost đều scale tuyến tính với độ dài document — tested trên Apple M1 16GB với docs từ 12,500 đến 78,000 tokens
• 18–57% nodes retrieved đến từ non-leaf levels (tùy dataset và retriever) — chứng tỏ cây tóm tắt thực sự được sử dụng
• Scalability: Cost thêm ~30-40% so với plain vector RAG nhưng đổi lại quality improvement lớn

Ví dụ minh họa rõ nhất (từ paper — Cinderella test):

• Query: "Cinderella find a happy ending như thế nào?"
• DPR chỉ retrieve được đoạn lúc Cinderella đi dự vũ hội (chi tiết đầu) → GPT-4 nói "không đủ thông tin"
• RAPTOR retrieve được summary của toàn bộ arc câu chuyện → GPT-4 trả lời đầy đủ

Ứng dụng thực tế

• LlamaIndex: tích hợp RaptorPack và RaptorRetriever — sử dụng rộng rãi

7. 🎭 HyDE — Hypothetical Document Embeddings

Reference:

Gao et al. (CMU + Stanford), "Precise Zero-Shot Dense Retrieval without Relevance Labels", arXiv:2212.10496, Dec 2022

Ý tưởng cốt lõi

Vấn đề cơ bản của dense retrieval: Embedding models được train để tìm các text "semantically similar". Nhưng câu hỏi và câu trả lời có linguistic distribution rất khác nhau:

Query:    "Tại sao bầu trời màu xanh?"     → interrogative, ngắn
Document: "Hiện tượng tán xạ Rayleigh..."   → declarative, dài

Dù semantically related, embedding của chúng không gần nhau trong vector space vì cấu trúc ngôn ngữ khác. Đây là asymmetric semantic gap.

HyDE giải quyết bằng cách đổi từ query-to-document search → document-to-document search:

Truyền thống:
embed(query) → cosine_similarity với embed(docs) → kết quả

HyDE:
query → LLM.generate("viết một đoạn văn trả lời câu hỏi này")
     → hypothetical_doc
     → embed(hypothetical_doc) → cosine_similarity với embed(docs) → kết quả

Tại sao hoạt động được?

• embed(hypothetical_doc) và embed(real_doc) đều là declarative text về cùng chủ đề → cùng distribution → gần nhau trong vector space
• embed(query) là interrogative text → distribution khác → xa hơn trong vector space
• Từ góc độ cá nhân đánh giá (chưa áp dụng thực tế), phương án này khá đáng để thử với các bài toán domain rõ ràng, công khai thì thường các mô hình LLM hiện đại (tối thiểu như gpt-4o) cũng đã được training với dữ liệu này rồi. Thì việc sinh ra 1 đoạn văn giả định trả lời cho query với domain biết trước thì sẽ có xác suất liên quan khá cao với tài liệu trong RAG indexing

Vector Space hình dung:
    [real_doc về tán xạ Rayleigh]
           ↑↑ gần nhau ↑↑
    [hypothetical_doc "Rayleigh scattering làm bầu trời xanh vì..."]
    
    ↕↕ xa nhau ↕↕
    
    [query "tại sao bầu trời xanh?"]

Implementation đầy đủ:

# Cơ bản
def hyde_retrieve(query, top_k=5):
    prompt = f"""Hãy viết một đoạn văn ngắn như thể trả lời câu hỏi sau.
    Dù không chắc chắn, hãy viết giống như một tài liệu thực sự:
    
    Câu hỏi: {query}
    Đoạn văn:"""
    
    hypothetical = llm.generate(prompt, max_tokens=200)
    hyp_embedding = encoder.encode(hypothetical)
    return vector_db.search(hyp_embedding, top_k=top_k)

# Nâng cao: Multiple Hypotheses (robust hơn với câu hỏi mơ hồ)
def hyde_multi_retrieve(query, n=5, top_k=5):
    hypotheses = [llm.generate(prompt(query)) for _ in range(n)]
    embeddings = [encoder.encode(h) for h in hypotheses]
    avg_embedding = np.mean(embeddings, axis=0)  # average embeddings
    return vector_db.search(avg_embedding, top_k=top_k)

Điểm sáng chính

Kết quả thực nghiệm (BEIR benchmark, MS-MARCO):

• Với InstructGPT + Contriever: đạt performance competitive với fine-tuned dense retrievers mà không cần bất kỳ labeled training data nào
• Vượt BM25 trên đa số BEIR tasks
• Hiệu quả nhất với: query ngắn (<10 words), query mơ hồ/abstractive, domain-specific queries

So sánh chi tiết:

Hạn chế quan trọng:

• Thêm 1 LLM call → tăng latency ~200-500ms và cost
• Nếu LLM generate hypothetical doc sai hoàn toàn (hallucinate) → embedding bị lệch hướng → kết quả tệ hơn baseline
• Với high-resource settings (retriever đã fine-tuned tốt), HyDE improvement nhỏ hơn

Ứng dụng thực tế

• LangChain: built-in HypotheticalDocumentEmbedder — 1 trong những techniques được dùng nhiều nhất
• LlamaIndex: HyDEQueryTransform — thường combine với reranking như Cohere Rerank
• Được dùng rộng rãi khi: không có budget fine-tune retriever, user queries ngắn/mơ hồ, domain mới chưa có training data

Tổng kết

• Kết hợp cả phần 1 và 2, có lẽ từ phía bản thân mình cũng đã đảo qua được các nội dung mà thời gian tới sẽ đi sâu hơn vào các dự án thực tế. Đến từ cả kiến trúc và cả từng module nhỏ lẻ, đều là các phương án đáng để thử. Mong rằng bài viết cũng giúp ích cho mọi người với các bài toán RAG sắp gặp phải. Cảm ơn mọi người đã đọc đến đây nha