GraphRAG Walker vs 传统 RAG 对比分析
GraphRAG Walker vs 传统 RAG 对比分析
架构对比
传统 RAG:
Query → 向量检索 (Top-K 文档块) → LLM 生成答案
GraphRAG Walker:
Query → 实体提取 → 图遍历 (多跳) → 子图裁剪 → LLM 生成答案
┌─────────────────────────────────────────────────────────────────┐
│ 传统 RAG 流程 │
│ │
│ "张三的直属领导在哪个部门？" │
│ │ │
│ ▼ │
│ 向量相似度检索 ──▶ Top-5 文档块 │
│ │ │
│ │ [块1] "张三于2020年入职，担任高级工程师..." │
│ │ [块2] "技术部组织架构：部长李四，副部长王五..." │
│ │ [块3] "公司年会于12月举办..." (不相关噪声) │
│ │ [块4] "产品部负责人为赵六..." │
│ │ [块5] "张三参与了项目Alpha..." │
│ │ │
│ ▼ │
│ LLM 从 5 个块中寻找答案 │
│ 问题: 关键关系分散在不同块中，LLM 需要自己推理关联 │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ GraphRAG Walker 流程 │
│ │
│ "张三的直属领导在哪个部门？" │
│ │ │
│ ▼ │
│ 实体提取 ──▶ ["张三"] │
│ │ │
│ ▼ │
│ 图遍历 ──▶ 张三 ─[REPORTS_TO]─▶ 李四 │
│ 李四 ─[WORKS_IN]───▶ 产品部 │
│ │ │
│ ▼ │
│ 子图裁剪 ──▶ "(张三, 汇报给, 李四), (李四, 所属, 产品部)" │
│ │ │
│ ▼ │
│ LLM 基于结构化三元组直接回答 │
└─────────────────────────────────────────────────────────────────┘
核心对比
| 维度 | 传统 RAG | GraphRAG Walker |
|---|---|---|
| 检索方式 | 向量相似度匹配 | 图遍历 + 向量裁剪 |
| 数据结构 | 扁平文档块 | 结构化知识图谱 |
| 多跳推理 | 弱，依赖 LLM 从多个块中自行关联 | 强，遍历天然支持多跳 |
| 答案精确度 | 中等，可能混入噪声 | 较高，结构化三元组更精准 |
| 上下文利用 | Top-K 块，可能丢失关键上下文 | 子图按关系展开，上下文完整 |
| 可解释性 | 低，只返回文档来源 | 高，可展示推理路径（走过了哪些边） |
| 幻觉风险 | 较高，LLM 需从非结构化文本推理 | 较低，三元组明确约束了事实 |
详细优缺点分析
GraphRAG Walker 的优势
┌─────────────────────────────────────────────────────────────────┐
│ 1. 多跳推理能力 │
│ │
│ 问题: "A 公司 CEO 的母校在哪个城市？" │
│ │
│ 传统 RAG: │
│ 检索到 [块: "A公司CEO是张三"] 和 [块: "北京大学在北京"] │
│ 但两个块之间没有显式关联，LLM 需要猜测 "张三" = "北大校友" │
│ → 容易出错 │
│ │
│ GraphRAG: │
│ 张三 ─[CEO_OF]─▶ A公司 │
│ 张三 ─[GRADUATED_FROM]─▶ 北京大学 │
│ 北京大学 ─[LOCATED_IN]─▶ 北京 │
│ → 遍历路径清晰，答案确定 │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 2. 关系推理天然支持 │
│ │
│ 问题: "张三和李四是什么关系？" │
│ │
│ 传统 RAG: │
│ 需要从不同文档块中拼凑出关系，非常困难 │
│ │
│ GraphRAG: │
│ 张三 ─[REPORTS_TO]─▶ 王五 ─[MANAGES]─▶ 李四 │
│ → 张三和李四是同一直属领导下的同事关系 │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 3. 答案可追溯 │
│ │
│ 传统 RAG: │
│ "答案来源于文档块 #1234" — 用户无法理解推理过程 │
│ │
│ GraphRAG: │
│ "答案推理路径: 张三 →[汇报给]→ 李四 →[属于]→ 产品部" │
│ → 每一步都有据可查 │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 4. 上下文窗口利用率高 │
│ │
│ 传统 RAG: │
│ 5 个文档块 ≈ 2000-3000 tokens，大量是无关文本 │
│ │
│ GraphRAG: │
│ 3 个三元组 ≈ 100-200 tokens，全是关键信息 │
│ → 节省 token，降低调用成本 │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 5. 动态推理深度 │
│ │
│ 传统 RAG: │
│ 检索深度固定 (Top-K)，无法根据问题复杂度调整 │
│ │
│ GraphRAG: │
│ LLM-Guided Walker 可根据问题动态决定遍历 1 跳还是 3 跳 │
│ 简单问题少走，复杂问题多走 │
└─────────────────────────────────────────────────────────────────┘
GraphRAG Walker 的劣势
┌─────────────────────────────────────────────────────────────────┐
│ 1. 前置成本高 — 需要先建知识图谱 │
│ │
│ 传统 RAG: │
│ 文档 → 切块 → embedding → 入库 │
│ 流程简单，几小时可上线 │
│ │
│ GraphRAG: │
│ 文档 → LLM 抽取实体/关系 → 构建图谱 → 去重/消歧 → 入库 │
│ 流程复杂，图谱质量直接决定效果 │
│ 建图阶段的 LLM 调用成本也更高 │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 2. 图谱维护成本 │
│ │
│ 传统 RAG: │
│ 新文档来了 → 切块 embedding → 增量入库，简单 │
│ │
│ GraphRAG: │
│ 新文档来了 → 抽取实体关系 → 与现有图谱合并/去重/更新 │
│ 实体消歧（"张三" 是同一个人吗？）是持续痛点 │
│ 图谱越来越大后，遍历性能也会下降 │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 3. 实体抽取质量瓶颈 │
│ │
│ 整个流程依赖第一步实体抽取的准确性 │
│ │
│ 如果 LLM 抽取出错: │
│ "张三的领导是李四" 误抽为 "张三的领导是王五" │
│ → 后续遍历全错，且很难发现 │
│ │
│ 传统 RAG 不受此影响，原始文档就是原文 │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 4. 非结构化/开放性问题不擅长 │
│ │
│ 问题: "公司文化是什么？""这篇文章的写作风格如何？" │
│ │
│ 传统 RAG: │
│ 直接检索相关文档块，LLM 理解文意即可 │
│ │
│ GraphRAG: │
│ 这类问题很难建模为实体-关系-实体的三元组 │
│ 图谱覆盖不了主观性、描述性的知识 │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 5. 系统复杂度高 │
│ │
│ 传统 RAG: │
│ 组件: Embedding 模型 + 向量数据库 + LLM │
│ 3 个组件，运维简单 │
│ │
│ GraphRAG: │
│ 组件: Embedding 模型 + 向量数据库 + 图数据库 + LLM + │
│ Walker 引擎 + 实体抽取服务 + 消歧服务 + 缓存层 │
│ 8+ 个组件，调试和运维成本显著增加 │
└─────────────────────────────────────────────────────────────────┘
适用场景总结
┌──────────────────────────┬──────────────┬─────────────────┐
│ 场景 │ 传统 RAG │ GraphRAG Walker │
├──────────────────────────┼──────────────┼─────────────────┤
│ 简单事实问答 │ ✅ 够用 │ ✅ 更精准 │
│ 多跳关系推理 │ ❌ 弱 │ ✅ 强 │
│ 关系型查询(A和B的关系) │ ❌ 很弱 │ ✅ 擅长 │
│ 开放性/主观性问题 │ ✅ 擅长 │ ❌ 不擅长 │
│ 长文档理解 │ ✅ 擅长 │ ⚠️ 依赖图谱 │
│ 实时文档更新 │ ✅ 简单 │ ❌ 维护重 │
│ 答案可解释性 │ ❌ 弱 │ ✅ 强 │
│ 上线速度 │ ✅ 快 │ ❌ 慢 │
│ Token 成本 │ ⚠️ 较高 │ ✅ 较低 │
│ 系统复杂度 │ ✅ 低 │ ❌ 高 │
└──────────────────────────┴──────────────┴─────────────────┘
最佳实践：混合架构
┌─────────────────────────────────────────────────────────────────┐
│ Hybrid RAG │
│ │
│ 用户 Query │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Query Router │ (小模型或规则判断) │
│ └──┬───────┬───┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌──────┐ ┌──────────────┐ │
│ │传统 │ │ GraphRAG │ │
│ │RAG │ │ Walker │ │
│ │ │ │ │ │
│ │适合: │ │ 适合: │ │
│ │开放 │ │ 关系型 │ │
│ │问题 │ │ 多跳推理 │ │
│ └──┬───┘ └──────┬───────┘ │
│ │ │ │
│ └─────┬──────┘ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 答案合并 │ LLM 综合两个通道的结果 │
│ │ + 去重 │ │
│ └──────┬───────┘ │
│ ▼ │
│ 最终答案 │
└─────────────────────────────────────────────────────────────────┘
混合架构下：
- 关系型/多跳问题 → 走 GraphRAG Walker 通道
- 开放性/描述性问题 → 走传统 RAG 通道
- 两种都不是 → 两个通道都走，合并结果
这样既利用了 GraphRAG 的结构化推理能力，又保留了传统 RAG 对非结构化知识的覆盖。
浙公网安备 33010602011771号