“这段条款明明在文档里，为什么模型还是答偏了？”
很多 RAG 项目都会走到这一步：文档切片、向量化、入库，检索链路看起来没问题；但一旦问题里出现多个条件、时间限制、上下级关系，答案就开始不稳定。
原因不复杂。向量检索找的是语义相似片段，它擅长回答“哪段话和问题最像”。但企业知识库里的很多问题，并不只是找相似文本。
比如用户问：“投保人有高血压且吸烟，三年后理赔规则怎么计算？”系统可能能召回“高血压”“吸烟”“理赔”相关段落，却未必能把这些条件和条款之间的关系串起来。传统 RAG 的短板就在这里：文本被切成块以后，实体之间的关系、因果和时序很容易断掉。
博客园文章《GraphRAG：当 RAG 遇上知识图谱，信息检索从此不一样了》提到，微软在 2024 年 7 月开源了 GraphRAG，GitHub 项目 microsoft/graphrag 已超过 31K Star。它受到关注，不是因为又换了一个检索框架，而是因为它把 RAG 的检索对象从“文本片段”扩展到了“实体关系”。
向量库不是没用，是边界很清楚
传统 RAG 的基本流程很直接：把文档切块，生成 embedding，存进向量数据库。用户提问后，系统用相似度找出相关片段，再交给大模型生成答案。
这条链路在 FAQ、制度查询、单段事实定位上很好用。问题出在三类场景：
- 全局总结：例如“《跨越鸿沟》这本书整体讲了什么，请写一份总结”；
- 多跳问题：答案需要经过多个实体或条件才能得到；
- 关系推理：问题重点不是某句话，而是 A、B、C 之间的关系。
CSDN 上的 GraphRAG 实战文章也提到，传统 RAG 在复杂关系推理、总结性问题和多跳问题上表现不佳。原因正是文本分块之后，信息之间的关系和因果可能被切断。
这不是简单调大 topK、换 embedding 模型就能彻底解决的事。向量库仍然负责语义召回，但它很难天然知道“谁隶属于谁”“哪个条件触发哪条规则”“某个事件发生在另一个事件之后”。
GraphRAG补的是“关系”这一层
GraphRAG 的思路，是在原有 RAG 之外增加一层知识图谱。
知识图谱里存的不是一段段文本，而是实体和关系。常见形式是三元组：
(投保人)-[患有]->(高血压)
(投保人)-[存在习惯]->(吸烟)
(吸烟)-[影响]->(保费上浮规则)
(保单)-[包含]->(免责条款)
这样做之后，系统回答问题时就不只是在文本里找相似内容，还能沿着关系路径查找相关事实。
悦数图关于 GraphRAG 企业落地的文章中提到，GraphRAG 用知识图谱替代或补充纯向量检索，让 AI 不只找到“相似的文本”，还能沿着关系路径推理出关联事实。这个判断比“GraphRAG 全面替代向量库”更准确：多数工程实践里，两者更像分工协作。
一个比较实用的结构是：
- 向量检索负责召回原文片段，补充细节和上下文；
- 图谱检索负责确认实体、关系和路径；
- 大模型负责把两边结果组织成自然语言答案。
也就是说，向量库给材料，知识图谱给骨架。
迁移时先别急着重建全部知识库
从传统 RAG 切到 GraphRAG，难点通常不在“接一个图数据库”，而在前面的结构化过程。
第一步是从文档中抽取实体和关系。可以让 LLM 先做粗抽取，再用规则或人工审核校验。保险、法律、财务这类场景尤其需要 schema 约束，否则图谱里会混入大量含义不稳定的节点和边。
例如在保险条款里，可以先限定节点类型：
投保人、被保险人、受益人、疾病、免责条款、理赔条件、保费规则
再限定关系类型：
适用于、触发、排除、影响、隶属于、发生于
如果直接让模型自由抽取，图谱看起来会很丰富，但检索时反而难用。工程上更稳妥的做法，是先把关系类型收窄，覆盖最常见、最有价值的问题。
一个更贴近工程的查询流程
GraphRAG 的查询通常会同时走两条路。
第一条是向量检索。系统根据用户问题召回相关文本片段，比如保单条款、制度原文、合同段落。这部分解决“原文依据在哪里”。
第二条是图谱检索。系统识别问题中的实体，再到图谱里查关系路径。比如问题里出现“高血压”“吸烟”“三年后”，图谱检索要做的是找出这些条件分别连接到哪些条款、规则和限制。
如果使用 Neo4j 这类图数据库，关系查询可能会写成 Cypher。下面只是示意：
MATCH (p:Policy)-[:COVERS]->(c:Condition)
WHERE c.name = 'Hypertension'
RETURN p
真正上线时，查询语句通常不会这么简单。还要处理同义词、实体消歧、关系方向、权限过滤，以及召回结果和原文证据的对齐。
这也是 GraphRAG 容易被低估的地方。它不是“把 RAG 换成知识图谱”，而是要多维护一套结构化知识层。
适合先试的场景
GraphRAG 不适合一上来就覆盖整家公司所有文档。更现实的切入点，是选一个关系明确、问题高频、答案需要可追溯的场景。
例如：
- 内部规章制度问答；
- 合同条款与责任关系查询；
- 供应链上下游关系查询；
- 财务报表中的主体、科目和关联关系分析；
- 医疗场景中病史、用药禁忌和检查结果之间的关联查询。
这些场景有一个共同点：用户问的不是“哪段文字相关”，而是“这些条件合在一起意味着什么”。
在这类问题上，纯向量 RAG 容易把相关段落找出来，却不一定能稳定还原关系链。GraphRAG 的价值，就是把这条关系链显式化。
成本主要在维护，不在演示
GraphRAG 做 demo 不难。难的是长期维护。
知识图谱不是一次构建就结束的资产。业务规则会变，产品条款会更新，组织架构会调整，合同和制度也会不断新增。如果图谱更新跟不上，系统反而会给出“看似有依据但已经过期”的答案。
比较可控的做法，是把图谱维护纳入数据流程：
- 新文档进入后先做实体和关系抽取；
- 抽取结果按 schema 校验；
- 高风险关系由人工审核；
- 入库后保留来源文本，方便追溯；
- 定期检查孤立节点、重复实体和冲突关系。
这套流程听起来不如“接入一个大模型”轻巧，但企业级问答系统真正要解决的，往往不是模型会不会说，而是答案能不能被验证。
该不该上 GraphRAG，看问题类型
如果你的知识库主要回答单点事实，比如“报销流程是什么”“某个接口怎么调用”，传统 RAG 仍然够用。把切片、召回、重排和提示词做好，收益可能更直接。
如果问题经常涉及多实体、多条件、多层级关系，GraphRAG 就值得考虑。尤其在金融、法律、医疗、供应链这类场景里，答案不仅要相关，还要能解释路径。
更稳妥的迁移方式，是在现有向量 RAG 旁边加一小块图谱能力，而不是推倒重来。先挑一个垂直场景，把实体类型和关系类型定义清楚，验证它是否真的改善了多跳问题和关系型问题。
GraphRAG 的核心不是新名词，而是一个朴素判断：企业知识不只是一堆相似文本，很多时候是一张关系网。RAG 要继续往业务深处走，迟早要处理这张网。
