"A公司的供应商B的工厂位于哪个地震带？"
这类问题很容易把普通企业知识库问住。
向量检索能找到和问题语义接近的段落，比如A公司的介绍、供应商B的新闻、某个工厂地址。但真正的答案可能藏在几份文件里：A与B的供应关系在采购合同里，B的工厂位置在审计材料里，地震带信息又在另一份风险报告中。只靠相似度召回，系统可能拿到一堆相关片段，却串不起关系链。
Graph RAG要解决的正是这种“断联”。
它把文档里的公司、产品、地点、人员、事件、规则等抽成实体，再把“供应”“位于”“适用”“处罚”“隶属”等关系连成图。检索时，系统不只找相似文本，也会沿着图谱关系去查路径、找邻居、做聚合。
向量RAG为什么会卡在复杂问题上
传统RAG的流程通常是：文档切片、向量化、召回、交给大模型生成。问“某产品保修期多久”“某流程需要哪些材料”，这套方法往往够用，因为答案大多在一个片段里。
麻烦出现在跨文档问题上。
Meta Intelligence Tech的《GraphRAG完全指南》引用Gao等人在2023年的RAG综述研究，提到传统向量RAG的几个瓶颈：全局性问题、多跳推理、以及复杂关系的表达。比如用户问“所有报告中最常出现的风险因子是什么”，向量检索通常只会返回少数语义相近的chunks，很难覆盖整个语料库。再比如“供应商B的工厂位于哪个地震带”，答案依赖实体之间的关系链，而不是某一句话的相似度。
中華電信实验室的《知识图谱RAG技术介绍与探讨》也把旧有RAG的问题归纳为三类：文本区块之间缺少明确连接，复杂问题上下文不足，以及大模型可能生成看似合理但不准确的内容。
这不是向量检索没用。它的问题在于，向量相似度擅长判断“像不像”，不擅长表达“谁和谁有什么关系”。企业知识库里偏偏有大量问题需要后者：供应链追溯、法律条文适用、客户风险关联、组织权限变化、监管处罚归因。
Graph RAG多了一层“关系索引”
腾讯云知识图谱GraphRAG文档，最后更新时间为2026年4月10日，其中对GraphRAG的定义比较直接：它是将知识图谱与大语言模型结合的RAG方案，支持从非结构化文档中自动抽取实体、关系与属性，构建可推理、可演进的结构化知识图谱；在问答过程中，结合图谱关系推理与语义检索，为复杂问题提供多跳推理答案。
这句话里有几个关键词值得拆开看。
第一是实体。企业文档里最有价值的信息，往往不是整段话，而是公司、项目、合同、设备、地点、风险事件这些对象。
第二是关系。比如“公司A采购产品X”“产品X由工厂Y生产”“工厂Y位于地区Z”。关系一旦明确，问题就可以沿着路径查询。
第三是属性。时间、状态、金额、版本、适用范围、风险等级，都可能成为过滤条件。没有属性，图谱只是一张关系网；有了属性，系统才有办法回答更细的问题。
所以Graph RAG不是把向量检索推翻，而是给知识库补上一层结构化索引。模糊问题仍然适合先用向量召回；涉及实体、路径、归因和聚合的问题，则交给图谱参与。
一个更贴近企业的查询过程
还是看开头那个问题：
A公司的供应商B的工厂位于哪个地震带？
如果只做向量检索，系统可能召回三类片段：A公司的供应商名单、B公司的工厂介绍、地震带说明。它们看起来都相关，但模型需要自己猜这些片段之间的关系。
Graph RAG的处理方式会更像一次路径查询：
MATCH (a:Company)-[:HAS_SUPPLIER]->(b:Company)-[:OWNS]->(f:Factory)-[:LOCATED_IN]->(r:Region)-[:BELONGS_TO]->(z:SeismicZone)
WHERE a.name = 'A公司' AND b.name = 'B公司'
RETURN f.name, r.name, z.name
这段Cypher只是示意，重点不在语法，而在查询思路：系统要找的不是一段相似文本，而是一条从公司到供应商、再到工厂和地理风险的关系链。
如果企业知识库要求可追溯，Graph RAG还可以把每条边对应的来源文档带回来：哪份合同证明B是A的供应商，哪份审计材料记录了工厂地址，哪份风险资料说明该地区所属地震带。这样生成答案时，大模型不必自由发挥，回答也更容易被业务人员复核。
落地时别一上来就追求“大而全”
很多团队一听知识图谱，就想到漫长的建模、人工标注和持续维护。确实，图谱不是零成本。但Graph RAG在企业里未必需要从全公司知识建模开始。
更稳妥的做法，是先挑一个关系密集、问题明确的场景。比如：
- 供应链：公司、供应商、工厂、物料、地区风险之间的关系；
- 合规：业务线、监管规则、处罚事件、整改措施之间的关系；
- 法务：合同主体、条款、义务、违约事件之间的关系；
- 研发：需求、模块、缺陷、版本、负责人之间的关系。
这些场景有一个共同点：答案通常不在单个段落里，而在多个对象的连接关系里。
工程上，可以采用混合检索，而不是只押注一种方法。
向量检索负责粗召回，适合处理表达不固定的问题。图检索负责精确关系，适合处理实体路径和多跳推理。最后把图谱子图、相关文档片段和来源信息一起交给大模型生成答案。
一个简化流程可以是：
from langchain_community.graphs import Neo4jGraph
graph = Neo4jGraph(
url="bolt://localhost:7687",
username="neo4j",
password="your_password"
)
随后用模型或规则从文档中抽取三元组：
{
"entities": ["Company A", "Factory B", "Region C"],
"relationships": [
{"source": "Company A", "target": "Factory B", "type": "USES_FACTORY"},
{"source": "Factory B", "target": "Region C", "type": "LOCATED_IN"}
]
}
真正影响效果的，往往不是代码框架，而是抽取质量。实体别名要合并，关系类型要收敛，来源文档要保留。否则图谱会变成另一种噪声库：节点很多，路径很多，但业务人员不敢信。
哪些知识库值得做Graph RAG
如果知识库主要是FAQ、产品手册、客服话术，传统向量RAG通常已经够用。用户问的是单点事实，答案也能在一个或少数几个片段里找到。强行上图谱，成本可能高过收益。
Graph RAG更适合这些情况：
- 问题经常跨文档、跨系统、跨实体；
- 业务需要解释答案从哪里来；
- 查询里有明显的路径关系，比如“谁影响了谁”“哪个事件导致哪个结果”；
- 需要从一批文档中做归纳，而不是只找一段原文；
- 数据会持续变化，关系本身也需要被维护。
经济部产业技术司的科技新知文章提到，LLM通过语义匹配预测下一个词，并不是真正理解语言背后的意义；训练数据也有时间范围和领域限制。放到企业场景里，这个问题更明显。内部制度、合同、审计记录、供应商资料都在更新，大模型不可能天然知道最新事实。
RAG把外部知识接进来，Graph RAG则进一步把知识之间的连接接进来。
企业知识库的下一步，不一定是把所有文档切得更细、向量库堆得更大。很多时候，更该补的是关系：谁关联谁，依据是什么，变化发生在哪个时间点，答案能不能回到原始材料。
把这些连接补上，知识库才不只是“搜得到”，而是能沿着业务逻辑往下查。
