graph rag & advanced rag

Vector Search giỏi tìm kiếm sự tương đồng bề mặt, nhưng hoàn toàn mù tịt trước những mối liên hệ cấu trúc phức tạp ẩn giấu giữa các thực thể.

Năm 2023 - 2024, RAG (Retrieval-Augmented Generation) là từ khóa "cửa miệng" của mọi dự án AI doanh nghiệp. Công thức dường như rất đơn giản:

1. Lấy tài liệu PDF/Docx của công ty.
2. Cắt nhỏ thành từng đoạn (Chunking: 500 tokens).
3. Đẩy qua mô hình Embedding để tạo Vector.
4. Lưu vào Vector Database (Pinecone, Qdrant, Milvus, PgVector).
5. Khi người dùng hỏi: Tính Cosine Similarity, lấy Top\text{-}K đoạn giống nhất, nhét vào Prompt cho LLM trả lời.

Mọi thứ chạy rất mượt mà với những câu hỏi tra cứu thông tin cụ thể (factoid retrieval): "Chính sách nghỉ phép của công ty là bao nhiêu ngày?" hay "Quy trình xin cấp thẻ tín dụng gồm những bước nào?".

Nhưng khi đưa vào môi trường Production thực tế với hàng triệu trang tài liệu phức tạp, hệ thống bắt đầu lộ ra những vết nứt nghiêm trọng. Bạn hỏi:

• "Các dự án của phòng ban X trong năm qua có mối liên hệ rủi ro nào với các đối tác chuỗi cung ứng ở thị trường Châu Á?"
• "Nhân sự A và Nhân sự B cùng tham gia những sáng kiến công nghệ nào, và ai là người phê duyệt ngân sách cuối cùng?"

Hệ thống RAG truyền thống (Naive RAG) lập tức bó tay hoặc trả về câu trả lời hời hợt, "ảo giác" (hallucination), hoặc bỏ sót 80% thông tin quan trọng.

Đó chính là khởi đầu cho sự ra đời của GraphRAG — kiến trúc kết hợp giữa Đồ thị tri thức (Knowledge Graph) và Vector Search, đang tạo nên cơn sốt nghiên cứu từ Microsoft Research và cộng đồng kỹ sư AI trên toàn cầu.

Bài viết này sẽ mổ xẻ tường tận tại sao Naive RAG thất bại, bản chất toán học và kiến trúc của GraphRAG, cùng lộ trình xây dựng hệ thống Hybrid RAG chuẩn mực cho doanh nghiệp.

# tại sao vector search truyền thống (naive rag) thất bại?

Để hiểu tại sao cần GraphRAG, ta phải nhìn thẳng vào 3 giới hạn vật lý của Naive Vector Search:

1. Sự đứt gãy ngữ cảnh do Chunking (Context Fragmentation)

Khi bạn cắt tài liệu thành các khối 500 tokens, một câu chuyện mạch lạc sẽ bị "băm nát".

• Chunk 1: "Công ty Alpha ký hợp đồng trị giá 50 triệu USD với đối tác Beta."
• Chunk 87 (ở 20 trang sau): "Dự án hợp tác của Beta gặp sự cố vi phạm bản quyền phần mềm và bị đình chỉ."
• Chunk 140: "Giám đốc pháp chế của Alpha yêu cầu kiểm toán toàn bộ hợp đồng của Beta."

Khi người dùng hỏi: "Tại sao Alpha lại kiểm toán hợp đồng?", phép tính Cosine Similarity của câu hỏi với Chunk 140 có thể cao, nhưng nó hoàn toàn không có mối liên kết ngữ nghĩa trực tiếp với Chunk 1 và Chunk 87. Vector Search không có khái niệm "kết nối mắt xích" (Relationship Chaining).

2. Thất bại trước bài toán "Tổng hợp toàn cục" (Global Sensemaking)

Vector Search hoạt động dựa trên nguyên lý tìm điểm cục bộ tương đồng (Local Similarity). Nếu bạn hỏi: "Chủ đề chính xuyên suốt toàn bộ 500 bài đánh giá hiệu quả kinh doanh của tập đoàn năm 2025 là gì?"

Không có bất kỳ một Chunk đơn lẻ nào chứa câu trả lời này! Vector Search sẽ lấy ra ngẫu nhiên 5 đoạn có từ khóa "hiệu quả kinh doanh" và bỏ qua 495 đoạn còn lại. Nó không thể tổng hợp tri thức ở quy mô vĩ mô (Macro-level understanding).

3. Điểm mù của Phép đo Cosine Similarity (Surface Similarity vs Structured Truth)

Hai đoạn văn có thể có khoảng cách Cosine rất gần nhau chỉ vì chúng cùng sử dụng các từ ngữ trang trọng về luật, nhưng lại mang ý nghĩa pháp lý đối nghịch nhau. Vector chỉ hiểu sự gần gũi trong không gian ngữ nghĩa tiềm ẩn (latent semantic space), nó không hiểu chân lý cấu trúc (Structural Truth): Ai làm gì? Quan hệ thế nào? Khi nào?

# bản chất kiến trúc của graphrag: khi tri thức trở thành đồ thị

Khác với Naive RAG chỉ lưu trữ các "khối văn bản rời rạc", GraphRAG trích xuất văn bản thành một Mạng lưới thực thể và quan hệ (Entity-Relationship Graph):

Một hệ thống GraphRAG hoàn chỉnh hoạt động qua 2 giai đoạn cốt lõi:

Giai đoạn 1: Indexing & Graph Construction (Xây dựng đồ thị tri thức)

1. Source Documents Chunking: Cắt tài liệu thành các đoạn text units.
2. Entity & Relationship Extraction: Dùng LLM đóng vai trò là Information Extractor, quét qua từng đoạn để trích xuất:
   • Entities: Tên người, tổ chức, công nghệ, địa điểm, sự kiện...
   • Claims/Relationships: Mối quan hệ giữa các thực thể kèm trích dẫn văn bản minh chứng.
3. Graph Clustering (Thuật toán phân cụm Leiden):
   • Nhóm các thực thể có liên kết chặt chẽ thành các Cộng đồng tri thức (Communities) theo cấu trúc thứ bậc (Hierarchical Communities: Cụm lớn \to Cụm vừa \to Cụm nhỏ).
4. Community Summarization (Tóm tắt cộng đồng):
   • LLM viết bản tóm tắt tổng quan cho từng Cụm tri thức. Đây chính là "vũ khí bí mật" giúp GraphRAG trả lời được các câu hỏi vĩ mô mà Vector Search bó tay!

Giai đoạn 2: Dual Search Modes (Hai cơ chế truy vấn linh hoạt)

# bảng so sánh chi tiết: naive rag vs advanced rag vs graphrag

# kiến trúc thực tế: enterprise hybrid graphrag

Trong môi trường doanh nghiệp thực tế, không có một công nghệ đơn lẻ nào là "viên đạn bạc" (silver bullet). Một hệ thống vững chắc nhất chính là Hybrid Architecture kết hợp 3 lớp bảo vệ:

Ví dụ trích xuất Schema Entity & Relationship với TypeScript:

// Định nghĩa cấu trúc tri thức được trích xuất từ tài liệu
export interface ExtractedEntity {
  name: string
  type: 'PERSON' | 'ORGANIZATION' | 'PROJECT' | 'TECHNOLOGY' | 'RISK'
  description: string
  sourceChunkId: string
}
 
export interface ExtractedRelationship {
  sourceEntity: string
  targetEntity: string
  relationType: 'DEVELOPS' | 'OWNS' | 'DEPENDS_ON' | 'INVESTED_IN' | 'BLOCKED_BY'
  strength: number // 1 to 10
  contextSnippet: string
}
 
export interface KnowledgeGraphSubGraph {
  entities: ExtractedEntity[]
  relationships: ExtractedRelationship[]
}

Khi người dùng hỏi một câu hỏi phức tạp, hệ thống sẽ:

1. Trích xuất các thực thể trong câu hỏi (Named Entity Recognition - NER).
2. Query vào Neo4j hoặc NetworkX để lấy Sub-graph lân cận trong bán kính 2-hop.
3. Kết hợp các Node và Edge đó cùng với các đoạn văn bản tương đồng từ Vector Search.
4. Prompt gửi cho LLM sẽ có cấu trúc rõ ràng:
   • Facts from Graph: (Thực thể A liên kết với B qua quan hệ C).
   • Relevant Paragraphs: (Nội dung chi tiết từ văn bản).

# bài toán kinh tế & trade-offs khi triển khai graphrag

Dù GraphRAG rất mạnh, một kỹ sư kiến trúc phần mềm giỏi luôn phải cân nhắc bài toán chi phí trước khi quyết định đưa vào hệ thống:

1. Chi phí Indexing ban đầu rất lớn

Để tạo được Knowledge Graph, LLM phải đọc từng chunk tài liệu, phân tích ngữ pháp, gọi hàm trích xuất thực thể. Nếu công ty bạn có 100.000 trang tài liệu:

• Naive RAG: Chi phí Embedding chỉ khoảng 5 - 20.
• GraphRAG: Chi phí gọi LLM trích xuất thực thể và tóm tắt cộng đồng có thể lên tới 500 - 2.000!
• Giải pháp: Sử dụng các mô hình nguồn mở kích thước nhỏ nhưng tối ưu hóa trích xuất (như Qwen-2.5-7B, Llama-3.1-8B chạy local qua vLLM) cho khâu trích xuất thực thể, chỉ dùng mô hình cao cấp (Claude 3.5 Sonnet / GPT-4o) cho bước tóm tắt cuối cùng.

2. Chiến lược cập nhật dữ liệu (Graph Maintenance & Upsert)

Khi một tài liệu bị sửa đổi hoặc xóa bỏ:

• Xóa một Vector trong Vector DB rất dễ (chỉ cần xóa theo Document ID).
• Nhưng xóa trong Graph DB đòi hỏi phải dọn dẹp các cạnh quan hệ (Edges), tính toán lại trọng số và cập nhật lại bản tóm tắt cộng đồng. Cần thiết kế pipeline bất đồng bộ qua hàng đợi (Kafka / RabbitMQ) để xử lý việc này ngầm dưới nền.

# tổng kết

RAG đang tiến hóa với tốc độ chóng mặt: từ Naive RAG (tìm kiếm văn bản đơn giản) sang Advanced RAG (tìm kiếm lai kết hợp Reranking) và hiện tại là GraphRAG (tư duy dựa trên mạng lưới tri thức kết nối).

Nếu hệ thống của bạn chỉ cần đọc tài liệu FAQ ngắn, Naive RAG hoặc Hybrid Search đã là quá đủ. Nhưng nếu bạn đang xây dựng các hệ thống phân tích báo cáo tài chính, quản trị rủi ro pháp lý, nghiên cứu y khoa, hoặc kiến trúc phần mềm quy mô lớn — GraphRAG chính là chiếc chìa khóa khai mở tiềm năng thực sự của dữ liệu doanh nghiệp.

Chỉ là những ghi chép cá nhân với hy vọng mang lại chút giá trị. Nếu thấy hữu ích, đừng ngại chia sẻ cho bạn bè & đồng nghiệp nhé!

Happy coding 😎 👍🏻 🚀 🔥.