企业知识库里有两类问题，看起来只差几个字，底层检索方式却完全不同。
“公司差旅报销标准是什么”，通常找到对应制度段落就能回答。“A公司与B公司签署的合同中，违约金条款是否引用了另一份协议”，则要先确认公司、合同、条款和协议之间的关系。只按文本相似度召回，很可能找到措辞接近的条款，却把两份合同拼到一起。
这正是向量RAG容易暴露短板的地方：文本相似，不代表实体相同；段落相关，也不代表关系成立。
向量检索卡住的，往往是关系链
台湾经济部产业技术司的技术解析提到，大型语言模型通过语义匹配预测后续词语，同时受到训练数据时间范围和领域边界的限制。向量RAG在外部知识库中补充了检索能力，但主要依据仍是语义相似度。
这套方法很适合回答政策说明、产品介绍和操作手册类问题。用户输入一段自然语言，系统从文档中找出意思相近的文本块，再交给模型组织答案。
关系型问题则多了一步。比如：
- 编号EQ-203的设备由哪些工程师维修过？
- 每次维修更换了什么零件？
- 某位员工的直属上级是谁，其审批权限覆盖哪些采购类别？
- 一份合同中的条款引用了哪些附件或历史协议？
这些问题需要沿着“设备—维修记录—工程师—零件”或“合同—条款—附件”的路径查询。向量库可以找回相关段落，却不会天然验证路径是否真实存在。
IBM对GraphRAG的介绍指出，微软研究院在2024年推出GraphRAG，重点解决私有数据和结构化数据中的关系建模问题。它把实体及其连接写入图结构，让检索从“哪些文字相似”扩展到“哪些对象确实有关联”。
两条检索链路，各自处理擅长的问题
企业知识库没必要把全部查询都送进图数据库。更稳妥的做法，是保留向量检索，再增加图检索和路由层。
向量链路继续处理语义搜索，例如查找制度条款、相似案例和相关说明。图链路负责实体关系、多跳路径、组织层级、供应链连接以及带时间条件的关联查询。遇到既要找文本、又要核对关系的问题，两条链路可以先后执行，再合并结果。
一套常见流程是：
- 先判断问题属于语义型、关系型还是混合型。
- 语义型问题直接进入向量数据库。
- 关系型问题先识别实体，再生成Cypher等图查询语句。
- 混合型问题先召回文本，从文本中识别实体，再向图中扩展关系。
- 合并两路结果，保留原文位置和关系路径，交给模型生成答案。
微软的GraphRAG开源项目已经把索引构建、查询和提示词调优拆成独立模块。图存储可以选择Neo4j；已有PostgreSQL体系的团队，也可以评估Apache AGE。向量层可使用Qdrant、Milvus或Weaviate。
另一种路线是采用LightRAG等同时包含图检索和向量检索的框架。AI-Compass整理的GraphRAG生态资料还列出了微软GraphRAG、蚂蚁KAG、LightRAG和Fast-GraphRAG等项目。选型时应先看数据结构和查询类型，框架数量本身没有参考价值。
图谱能不能用，取决于索引怎么建
混合架构最费工的部分通常在查询之前。原始文档需要分块、生成向量，还要抽取实体、关系和时间属性。后者经常需要调用大模型，成本和错误也集中在这里。
第一步是先定实体模型。合同知识库至少要区分公司、合同、条款、附件和签署时间；设备知识库则可能包含设备、工程师、维修记录和零件。如果一开始只让模型自由抽取，图中很快会出现大量含义接近、名称不同的节点。
实体别名尤其容易出问题。同一家公司在文档里可能被写成“甲方”“委托方”或简称。没有归一规则，这些名称会变成互不连接的实体。查询时即使找对了合同，也可能沿着错误节点继续扩展。
时间字段也要进入关系模型。合同的签订、变更和终止，设备的维修和零件更换，都有明确时间范围。如果图查询没有过滤时间，历史关系会和当前关系一起返回。
因此，索引阶段至少要保存三类信息：
- 文本块及其原始文档位置；
- 标准化后的实体ID和别名；
- 关系类型、来源以及适用时间。
文档更新后，还要同步处理旧节点和旧关系。只新增、不清理，图谱会逐渐积累已经失效的连接。删除文档时，也不能只删向量库中的文本块，还要检查由该文档建立的实体和关系是否仍有其他来源。
查询路由不要交给一个大提示词
不少实现把意图判断、实体识别、图查询生成和答案生成塞进同一个提示词。链路虽然短，出了问题却很难定位：究竟是实体识别错了、Cypher写错了，还是召回内容不够？
更容易维护的方式是把步骤拆开：
def route_query(question):
intent = classify(question)
if intent == "semantic":
return vector_search(question, top_k=8)
if intent == "relational":
entities = extract_entities(question)
cypher = generate_cypher(entities, graph_schema)
graph_result = run_graph_query(cypher)
return fetch_source_chunks(graph_result)
vector_chunks = vector_search(question, top_k=5)
entities = extract_entities(question, vector_chunks)
graph_result = graph_expand(entities, depth=2)
return rerank(vector_chunks + graph_result)
意图分类可以先用规则或小型分类模型完成。真正需要重点监控的是实体识别和图查询生成，因为这两步直接决定系统会不会连错对象。
图查询结果还应回到原始文本。知识图谱负责确认关系，文档片段负责提供可引用的依据。最终答案最好同时保留文档来源和关系路径，方便用户复核。
先按问题类型评测，别只看平均分
判断是否需要GraphRAG，可以先整理现有系统的错误案例。如果答案错误主要来自分块不合理、召回数量不足或排序不准，应先修正向量检索。如果错误集中在同名实体、跨文档引用、组织层级和多跳关系，才有必要增加图检索。
评测集也应分开设计：
- 语义查找：能否找到正确制度或说明段落；
- 单实体查询：能否准确识别人名、公司、设备和产品；
- 关系查询：能否确认两个实体之间的直接连接；
- 多跳查询：能否沿两层以上关系找到目标；
- 时间查询：能否排除已经失效的历史关系；
- 同名实体：能否避免把不同对象合并。
这种分组比单一准确率更有用。它能直接说明图检索补上了哪类能力，也能发现哪些普通问题被错误地送入图链路，徒增延迟和成本。
田攀在2026年4月发布的架构评论中提到，截至2025年，生产环境采用图检索的企业不到15%。这组数据来自该作者的观察，适合用来理解部署现状，不宜当作所有行业的统一结论。文章指出的另一个现象更值得注意：纯向量RAG的错误往往不明显，系统能够正常返回内容，问题藏在实体和关系被错误拼接的过程中。
权限和更新，比检索算法更早进入生产问题
图谱把跨文档关系连接起来后，权限边界也会变得复杂。某个用户可能有权读取合同正文，却无权查看合同关联的客户、人员或其他部门数据。因此，访问控制应在图查询和向量召回阶段同时生效，不能等内容进入模型后再处理。
每个节点、关系和文本块都需要保留来源与权限标记。查询图谱时先过滤可见范围，再做关系扩展；查询向量库时也使用相同的租户、部门或角色条件。
混合架构真正增加的工作量，主要落在数据治理上：实体如何命名，关系如何定义，历史版本怎样清理，权限如何继承。工具可以完成索引和查询，却无法替团队决定“合同变更”与“合同续签”是不是同一种关系。
如果知识库主要用于找制度、搜文档，向量检索配合合理分块和重排序通常已经够用。只有当业务问题开始稳定地涉及实体核对、跨文档引用和多跳关系时，GraphRAG才会带来清晰收益。此时接入图检索，解决的是已经出现的关系错误，而不是为架构再添一个新名词。
