上一篇文章里我们讨论了 RAG 如何处理复杂问题。一个重要结论是真实用户的问题往往不是简单的一句话事实查询。有些问题需要 Query Rewrite有些问题需要多查询召回有些问题需要拆分成多个子问题还有一些问题需要多步检索。这些方法可以让普通 RAG 从“简单问答”走向“复杂问题处理”。但继续往前走会遇到一个更明显的边界很多问题的答案并不只藏在某个 Chunk 里而是藏在实体和关系之间。比如这个项目和哪些系统有关 哪些部门共同参与了这个流程 某个风险点影响了哪些业务线 这几份制度之间有什么冲突 某个客户的问题在过去哪些案例里出现过这类问题不是简单找一个片段就能解决。它需要系统理解“谁和谁有关”“关系是什么”“这些关系如何组成一个更大的结构”。这就是 GraphRAG 被重新关注的原因。这篇文章就讨论一个问题GraphRAG 是什么为什么知识图谱又回来了。普通 RAG 擅长什么先看普通 RAG 的基本思路。文档入库时系统会把文档解析、切分成 Chunk然后做 Embedding写入向量数据库。用户提问时系统把问题向量化再从向量数据库里找相似 Chunk。流程大概是文档 ↓ 切分 Chunk ↓ Embedding ↓ 向量检索 ↓ 返回相关片段 ↓ 模型生成答案这个方式很适合局部问题。比如试用期员工能不能休年假 ERR_1024 表示什么 POST /orders 的 quantity 参数是否必填 报销申请需要提前几天提交这些问题通常可以在某个段落、某个表格、某个接口说明或某份制度里找到答案。普通 RAG 的优势是实现相对简单。可以快速接入非结构化文档。适合文档片段定位。对局部事实问答效果不错。和向量数据库、关键词检索、Rerank 容易结合。所以普通 RAG 不是过时方案。它仍然是大多数知识库问答系统的基础。问题在于普通 RAG 的检索单位通常是 Chunk。它擅长找“相关片段”但不擅长理解“全局关系”。普通 RAG 的边界在哪里普通 RAG 面对关系型问题时会遇到几个典型问题。第一答案分散在多个文档里。比如用户问Alpha 项目涉及哪些系统和部门相关信息可能分散在项目立项文档、系统架构说明、权限申请记录、会议纪要和运维手册里。任何单个 Chunk 都不完整。第二问题关注的是关系而不是片段内容。比如数据平台部负责哪些系统 这些系统依赖哪些外部接口这类问题的核心不是某段文字而是实体之间的连接。第三用户想要全局总结。比如当前知识库里有哪些高频风险点 哪些业务流程最容易和权限问题相关普通 RAG 往往只能召回局部片段很难稳定做全局聚合。第四实体名称可能在不同文档里不一致。比如同一个系统可能被写成订单系统 Order Service 订单中心 OMS如果没有实体归一化普通检索很容易把它们当成不同对象。第五关系需要多跳推理。比如哪个部门负责会影响订单导出的接口系统可能需要先找到“订单导出接口”再找到它所属系统再找到系统负责人或部门。这不是一个相似 Chunk 就能解决的。这些问题说明普通 RAG 更像是在文档海里找片段。而关系型问题需要在知识网络里找路径。这就是 GraphRAG 想解决的部分。GraphRAG 到底是什么GraphRAG 可以理解为把图结构引入 RAG让系统不仅能检索文本片段也能利用实体、关系和社区结构来回答问题。它不是简单把图数据库接到大模型。更准确地说GraphRAG 通常会做几件事。第一从文档中抽取实体。比如系统订单系统、支付系统、库存系统 部门数据平台部、财务部、运营部 人员负责人、审批人、维护人 文档制度、接口说明、项目文档 业务对象订单、发票、库存、权限第二从文档中抽取关系。比如订单系统 依赖 支付系统 数据平台部 负责 报表系统 报销制度 适用于 财务部 接口 A 调用 接口 B 审批流程 包含 主管审批第三把实体和关系组织成图。图里有节点和边。节点可以是系统、部门、文档、流程、接口、人员、项目。边表示它们之间的关系。第四基于图做检索。用户提问时系统不只检索 Chunk也可以检索相关实体、邻居节点、关系路径、子图或社区摘要。第五把图检索结果和文本 Chunk 一起交给模型。模型基于结构化关系和原始证据生成答案。一个简化流程是文档解析 ↓ 实体抽取 ↓ 关系抽取 ↓ 图谱构建 ↓ 用户问题 ↓ 图检索 Chunk 检索 ↓ Rerank ↓ Prompt 生成答案所以 GraphRAG 的核心不是“用了图数据库”。它的核心是让 RAG 能够利用知识之间的结构关系。为什么知识图谱又回来了知识图谱不是新概念。早在大模型流行之前很多企业就做过知识图谱、实体关系抽取、图数据库和语义网络。那为什么现在又被重新提起原因有几个。第一大模型让实体和关系抽取更容易。过去做知识图谱往往需要大量规则、标注、领域词典和人工维护。现在大模型可以辅助从非结构化文档中抽取实体和关系。虽然仍然需要校验但起步成本降低了。第二RAG 暴露了普通 Chunk 检索的边界。当用户只问局部事实时普通 RAG 够用。但当用户开始问跨文档、跨系统、跨部门的问题时单纯 Chunk 检索会吃力。第三企业知识本身就是关系网络。企业里的知识不是孤立段落。系统之间有依赖部门之间有协作流程之间有前后关系制度之间有适用范围。如果只按 Chunk 管理知识就会丢掉很多结构。第四大模型需要更可靠的外部结构。大模型擅长生成和归纳但不擅长稳定维护复杂关系。图结构可以给它提供更明确的关系约束。第五复杂问答需要更强的可解释性。GraphRAG 可以展示实体、关系和路径。比如Alpha 项目 - 订单系统 - 支付接口 - 财务部这种路径比单纯返回几个 Chunk 更容易解释。所以知识图谱不是“突然又火了”。它是因为 RAG 进入复杂场景后被重新需要了。GraphRAG 适合什么问题GraphRAG 不应该被理解成普通 RAG 的全面替代。它更适合特定类型的问题。第一类是实体关系问题。比如某个系统依赖哪些服务 这个项目涉及哪些部门 这个客户关联了哪些历史工单这类问题的核心是实体之间的连接。第二类是跨文档关联问题。比如这些制度之间有没有冲突 某个流程在不同文档里是怎么描述的答案可能分散在多份文档里需要对齐和比较。第三类是全局总结问题。比如当前知识库里高频问题集中在哪些业务模块 哪些系统是依赖最多的关键节点这类问题需要全局视角而不是局部片段。第四类是风险传播问题。比如如果支付系统异常会影响哪些业务流程这需要沿着依赖关系查找影响范围。第五类是组织知识梳理。比如数据平台部负责哪些系统、接口和审批流程这类问题天然适合图结构。第六类是复杂研究型问题。比如在大量报告、论文、项目文档中分析主题、实体、事件之间的关系。GraphRAG 在这些场景里更有优势。因为它不只是找文本而是在找结构。GraphRAG 不适合什么问题GraphRAG 有价值但不是所有问题都应该上 GraphRAG。第一简单事实问答不一定需要。比如ERR_1024 表示什么直接关键词检索或普通 RAG 可能更快。第二单文档定位不一定需要。比如报销申请需要提前几天提交如果答案就在制度文档里普通 RAG 足够。第三接口字段查询不一定需要。比如quantity 参数是否必填这类问题更依赖精确检索、版本过滤和字段表格解析。第四数据质量很差时不要急着上。如果原始文档混乱、重复、过期、命名不统一图谱抽取会被污染。第五关系不稳定的场景要谨慎。如果业务关系频繁变化而图谱更新跟不上就会产生过期关系。第六没有评估能力时不要盲目上。GraphRAG 链路更复杂。如果没有测试集和日志很难判断它到底提升了效果还是只是增加了复杂度。所以 GraphRAG 的原则是在关系型问题明显存在时引入。不要为了“高级”而引入。GraphRAG 的工程链路一个可落地的 GraphRAG 链路大致可以分为两个阶段。第一阶段是离线构建。原始文档 ↓ 文档解析 ↓ 文档切分 ↓ 实体抽取 ↓ 关系抽取 ↓ 实体归一化 ↓ 图谱构建 ↓ 图谱索引和摘要第二阶段是在线问答。用户问题 ↓ 问题理解 ↓ 识别相关实体 ↓ 图检索 ↓ Chunk 检索 ↓ 合并证据 ↓ Rerank ↓ Prompt 回答这里有几个关键模块。第一实体抽取。系统要知道文档里出现了哪些重要对象。第二关系抽取。系统要知道这些对象之间有什么关系。第三实体归一化。同一个对象的不同叫法要合并。比如订单系统 Order Service OMS如果不归一化图会碎掉。第四证据回链。图谱里的关系不能只是孤立结论。每条关系最好能追溯到原始文档或 Chunk。第五图检索策略。不同问题需要不同检索方式。比如按实体找邻居按路径找关系按社区找摘要。第六和普通 RAG 结合。GraphRAG 不应该只返回图节点。最终回答仍然需要原始文本证据支撑。所以图检索和 Chunk 检索要结合。实体抽取和关系抽取的风险GraphRAG 最容易被低估的风险是抽取质量。如果实体抽错后面都会错。如果关系抽错图谱会制造错误结构。比如文档写的是订单系统调用库存系统查询库存。如果关系被抽成库存系统调用订单系统方向就反了。再比如文档写的是支付系统异常可能影响订单支付状态同步。如果被抽成支付系统一定导致订单系统异常关系强度就被夸大了。所以关系抽取要注意关系方向。关系类型。关系强度。时间范围。版本范围。来源证据。是否为确定事实。是否只是可能影响。这也是为什么 GraphRAG 需要工程化评估。不能只看图谱构建出来了没有。还要看抽取是否准确、关系是否可追溯、答案是否真的变好。权限和更新也会更复杂普通 RAG 已经需要处理权限。GraphRAG 会让权限问题更复杂。因为图谱会把不同文档里的实体和关系连接起来。如果用户只能访问一部分文档系统就不能通过图关系泄露他无权访问的信息。比如用户无权查看某个项目文档但图谱里存在项目 A - 使用 - 内部系统 B如果回答中暴露了这个关系就可能越权。所以 GraphRAG 也需要权限控制。可以考虑节点权限。边权限。来源文档权限。查询时权限过滤。回答时来源过滤。更新也很重要。企业文档会变化。系统关系会变化。组织架构会变化。图谱如果不更新就会保留过期关系。所以 GraphRAG 需要增量更新机制。比如文档变化后重新解析变化文档 重新抽取实体和关系 更新相关节点和边 标记旧关系失效 保留版本记录否则图谱会逐渐变成历史快照而不是当前知识。GraphRAG 和普通 RAG 应该怎么组合实际工程里不建议把 GraphRAG 和普通 RAG 对立起来。更合理的是组合。可以按问题类型选择不同路径。比如简单事实问题 - 普通 RAG 接口字段问题 - 关键词检索 Metadata Filter 关系型问题 - GraphRAG 全局总结问题 - GraphRAG 社区摘要 复杂排障问题 - Multi-hop Retrieval GraphRAG也可以并行检索用户问题 ↓ 普通 Chunk 检索 ↓ 图谱实体检索 ↓ 关系路径检索 ↓ 合并证据 ↓ Rerank ↓ Prompt 回答这样做的好处是普通 RAG 提供原文证据。GraphRAG 提供关系结构。Rerank 负责选择最有用的证据。Prompt 负责约束模型基于证据回答。这比单独依赖某一种检索方式更稳。一个简单例子假设知识库里有几段资料。资料 1 订单系统负责订单创建、订单查询和订单状态管理。 资料 2 订单系统在支付环节调用支付系统完成扣款。 资料 3 支付系统由财务技术组维护。 资料 4 支付系统异常会影响订单支付状态同步。普通 RAG 如果用户问支付系统异常会影响哪些订单能力谁负责维护可能召回资料 2 和资料 4。但要回答“谁负责维护”还需要资料 3。GraphRAG 可以形成关系订单系统 - 调用 - 支付系统 支付系统 - 由...维护 - 财务技术组 支付系统异常 - 影响 - 订单支付状态同步然后回答支付系统异常会影响订单支付状态同步。订单系统在支付环节依赖支付系统因此订单支付相关能力可能受影响。支付系统由财务技术组维护。这里的答案不是来自单个 Chunk而是来自关系组合。这就是 GraphRAG 的典型价值。落地建议如果你准备尝试 GraphRAG可以按下面顺序推进。第一先确认是否真的有关系型问题。不要一上来就建大图谱。先收集用户问题看是否存在大量跨文档、跨实体、全局总结和关系追踪问题。第二选择一个小范围试点。比如只针对某个业务域、某个系统集群或某类文档做图谱。第三定义实体类型。先不要抽取所有东西。可以先定义系统 部门 接口 流程 制度 项目 风险点第四定义关系类型。比如负责 依赖 调用 适用于 包含 影响 属于 引用第五保留来源证据。每个实体和关系最好能回到原始文档。第六处理实体归一化。否则同一个对象会被拆成多个节点。第七加入权限和版本控制。不要让图谱成为越权泄露通道。第八和普通 RAG 一起评估。比较普通 RAG、GraphRAG 和混合方案在真实问题上的效果。总结普通 RAG 擅长从局部文档片段中找答案。GraphRAG 更擅长处理实体、关系、路径和全局结构。当问题只是简单事实查询时普通 RAG 往往更轻量。当问题涉及跨文档关联、实体关系、全局总结和影响分析时GraphRAG 会更有价值。GraphRAG 不是简单接一个图数据库也不是普通 RAG 的全面替代。它的核心是把文档里的实体和关系结构化让系统能够基于知识网络进行检索和回答。但 GraphRAG 的工程成本也更高。实体抽取、关系抽取、实体归一化、权限控制、版本更新和评估都需要认真设计。更合理的方向是让普通 Chunk RAG 和 GraphRAG 组合起来。普通 RAG 提供原文证据GraphRAG 提供关系结构Rerank 负责选择上下文Prompt 负责约束回答。从这个角度看GraphRAG 不是噱头。它是在 RAG 进入复杂知识网络场景后对普通 Chunk 检索能力的一种补充。下一篇文章可以继续讨论 Agentic RAG。因为当检索步骤不再固定时我们会需要让系统根据任务动态决定什么时候检索、检索什么以及是否需要再次检索。