四 第四生产力NOTES ON AI & ENGINEERING

技术思考2026-09-16 · 16 分钟阅读

RAG 和知识图谱 RAG：什么时候该从“找段落”升级到“找关系”？

企业做 RAG，容易遇到一种落差。

文档都切好了，向量库也建好了，演示时问什么都能搜到。

一到真实业务，问题却变成：“哪些订单同时受到三条规则影响？”“合同、付款和审批之间是什么关系？”

系统找得到相关文字，却答不出对象之间的关系，也说不清这条关系来自哪一版资料。

我先把判断摆在这里：普通 RAG 先解决“证据在哪里”，知识图谱 RAG 再解决“证据之间如何关联”。

知识图谱 RAG 不天然更高级。

它还需要本体、实体对齐、冲突处理、增量更新和评测。如果问题只是查一条政策，建图反而增加成本。

先分开几个词

RAG 的经典定义，是把模型参数记忆和外部非参数化记忆结合起来。原始论文用稠密向量索引检索 Wikipedia 片段。

原始论文

普通 RAG 主要检索相似片段。

知识图谱 RAG 额外使用实体、关系、属性、路径、图查询或社区摘要来组织上下文。

Microsoft GraphRAG 是其中一个具体实现。它从文本抽取实体和关系，做社区检测和摘要，再提供 Local、Global、DRIFT 搜索。

Microsoft Research

GraphRAG 不是所有知识图谱 RAG 的同义词，KRAG 也不是统一标准名词。更准确的说法是：

知识图谱 RAG，是让检索过程能够使用显式结构的一组架构。

什么时候普通 RAG 已经够用？

如果用户问“退款政策里签收后几天可以申请”，或“这份合同的验收条款是什么”，核心是定位证据、保留上下文和给出引用，普通 RAG 往往更直接。

回答不准时，不要马上上图谱。

先确认根因：是切块、召回、重排做得不好，还是问题确实需要跨文档关系。

先看一个问题：为什么 Top-k 找到了，却还是答不出来？

下面是一个假设场景，不对应任何客户项目。

企业里有四份材料：

编号 材料 关键内容
D1 采购合同 C-018 供应商甲，交付周期 14 天；2025 年 7 月 1 日起改为 21 天
D2 促销政策 P-07 交付周期超过 20 天的订单，需要人工复核
D3 订单工单 O-128 供应商写成“甲供应链”，预计交付 23 天
D4 订单系统 O-128 当前状态为“待发货”，金额和权限以系统为准

业务问题是：“当前哪些订单同时受到合同变更和 P-07 影响？我能不能让 Agent 自动通知客户？”

普通向量 RAG 可能先召回 D3，因为它出现了“23 天”和“订单”。

它也可能召回 D1，因为里面有“供应商甲”和“交付周期”。

但 D2 的“超过 20 天”是另一份政策，D3 的“甲供应链”又没有和 D1 的“供应商甲”自动对齐。

模型即使读到了三段文字，也必须自己完成实体合并、时间判断、规则匹配和权限判断。任何一步靠猜，答案都可能变成“这批订单大概需要复核”。

图谱增强的检索路径会更明确：

flowchart LR
    Q[问题：哪些订单受两条规则影响] --> V[向量检索：找到 O-128]
    V --> E[实体对齐：甲供应链=供应商甲？]
    E --> C[合同 C-018：交付周期 21 天]
    E --> P[政策 P-07：超过 20 天需复核]
    C --> T[时间过滤：2025-07-01 后生效]
    P --> R[原文证据：政策条款]
    T --> S[业务 API：订单当前状态]
    R --> A[回答：列出订单、路径与证据]
    S --> A

这里有三个边界。

图负责把对象和关系串起来，原文负责证明条款，订单 API 负责当前状态。

Agent 是否可以发通知，还要由权限策略决定。图谱没有替代 RAG，也没有替代业务系统。

RAG 和知识图谱 RAG，怎么选？

先按问题结构分，不要按数据库产品分：

问题 优先方案 需要重点验证的东西
单文档、单条款、语义解释 普通 RAG 召回、重排、引用是否准确
多文档、多跳关系、实体去重 混合 RAG + 图扩展 实体对齐、路径完整性、时间过滤
全库主题、趋势和群落摘要 GraphRAG Global/社区摘要 社区划分、摘要新鲜度、全局覆盖
金额、库存、状态、权限 业务 API/SQL/规则 + RAG 查询结果、权限和事务一致性
依赖、影响范围、路径 图查询/KG-RAG + 原文 路径是否可解释、边是否有来源

MultiHop-RAG 的数据集把问题设计成需要多份证据才能回答，研究者发现普通 RAG 在这类任务上表现不理想。

但它的答案主要是 yes/no、实体名和时间关系，不能直接当成企业效果预测。MultiHop-RAG

STaRK 把文本描述和实体关系放进同一个半结构化检索任务，覆盖商品、论文和精准医疗三个领域。

它提醒我们：真实查询往往同时有“文字条件”和“关系条件”，只测纯文本或纯图都会漏掉一半问题。

STaRK（NeurIPS 2024）

知识图谱 RAG 其实有三种接法

第一种是图扩展片段。

KG²RAG 先用语义检索找种子片段，再沿知识图谱扩展邻近片段，并把结果重新组织成连贯上下文。

图在这里更像“检索导航”，最终回答仍然依赖文本证据。KG²RAG

第二种是图社区检索。

Microsoft GraphRAG 的 Local Search 从实体向邻居展开，Global Search 则在社区报告上做全局归纳，DRIFT Search 还会用社区信息生成后续问题。

它们适合的查询粒度不同，不应只用一个“GraphRAG 准确率”概括。GraphRAG 查询方法

第三种是结构化查询与语义层。

当问题是“某合同当前生效的付款条件是什么”，更稳妥的路径可能是 SPARQL、Cypher 或 SQL 先返回结构化事实，再让模型解释；文档 RAG 只补充条款原文。

AWS 的参考架构把候选抽取放在 Lexical Graph，把通过本体和校验的事实放入 Semantic Layer，并保留到原文片段的 provenance 链路。

AWS Semantic Layer 指南

订单状态、余额、库存和审批状态本来就在事务系统里，不该从旧文档里“检索”。

实体和关系由谁构建？

这是比“用哪个向量库”更值得先回答的问题。实体抽取、实体对齐、关系抽取、本体约束，是四件不同的工作。

责任分工可以这样定：业务负责人定义对象、关系、口径和约束。

知识工程落成 schema、字典、映射和版本流程；LLM 提出候选。

规则、来源交叉验证和人工审核决定哪些候选能进入正式图；运行团队负责更新、冲突、回滚和质量监控。

拿上面的 D1 举例，模型生成的候选不应直接写成一条“事实边”，而应先保留成一条可审查记录：

subject: 供应商甲（候选实体）
predicate: contract_delivery_days
object: 21
valid_from: 2025-07-01
source: D1 / 合同 C-018 / 第 12 页
extracted_by: llm-extractor-v3
confidence: 0.83
status: candidate
needs_review: true

审核人要确认“供应商甲”是否对应主数据中的 SUP-001，21 天是否覆盖全部订单，旧值 14 天是否已失效。只有这些问题有答案，候选边才有资格进入检索图。

W3C 的 RDF 用资源、属性和值表达三元组，OWL 用类和约束表达更复杂的语义。

SHACL 则可以把“交付周期必须是整数”“一份合同只能有一个当前生效值”这类约束写成可验证的形状。

RDF 1.1｜OWL 2｜SHACL

业务人员不一定要写 RDF，但必须回答“这个关系在业务上是什么意思”。把定义完全交给模型，得到的往往是一张语言通顺、业务含义不稳定的图。

纯文本能不能直接让 LLM 建图？

可以，但只能当候选生成器。

例如文本写着：“华东区的供应商甲在 2025 年 7 月，将交付周期从 14 天改为 21 天。”

LLM 可以抽出实体、属性、旧值、新值和变更时间，生成候选关系，但它不能单独决定这句话对应哪个主数据实体。

入库前还要确认：实体是否已在主数据中存在？21 天何时生效？旧值是否失效？原文在哪一页？系统是否冲突？

2023 年一项覆盖多个数据集的研究发现，GPT-4 在知识图谱构建任务上可以提供帮助，但更适合作为推理辅助，而不是无约束的 few-shot 信息抽取器。

LLMs for Knowledge Graph Construction and Reasoning

Microsoft GraphRAG 的索引也不是“一次 prompt 建完图”。标准方法分开处理实体、关系、摘要、声明和社区报告；FastGraphRAG 则用名词短语和共同出现近似关系。

GraphRAG indexing methods

官方文档估计，标准 GraphRAG 的图抽取约占索引成本的 75%；FastGraphRAG 更便宜，但图的噪声更大。这是该实现的工程估计，不是所有企业项目的通用比例。

因此，建图至少经过：

flowchart LR
    A[文本/表格/日志] --> B[切分与来源定位]
    B --> C[本体与字段约束]
    C --> D[LLM候选抽取]
    D --> E[实体规范化与对齐]
    E --> F[关系/时间/冲突校验]
    F --> G[来源、版本、置信度]
    G --> H[图索引+向量索引]
    H --> I[混合检索与回答]

LLM 可以参与本体草拟、候选抽取、别名发现和冲突解释，但不能成为最终事实裁判。

最容易被低估的环节：实体对齐

实体对齐错一次，后面所有邻居和社区都可能被污染。“客户 A”“A 公司”“A 集团”是否合并，通常要结合主数据、合同主体和业务负责人确认。

知识图谱构建综述也把实体链接、对齐、冲突处理和更新列为正式任务。

ACM Computing Surveys 综述

所以我不建议“先让 LLM 自动建一张大图，再慢慢清洗”。规模一大，错误合并就会变成隐形债务。

图谱增强，不等于模型可以随便推理

图谱可以帮助检索关系，但图谱里的错误关系也会被放大。

G-Retriever 把图问答建模成检索子图，再让模型在相关节点和边上回答。

它用 Prize-Collecting Steiner Tree 选择一个尽量小、又能连接问题节点的子图，目标是减少无效节点和边，而不是把整张图塞进上下文。G-Retriever

这些论文没有证明“图越大越好”：子图过大有噪声，摘要过旧会传播旧事实。

我的判断是：图谱的价值在结构化证据，不在替模型制造新的事实。

金额、权限、库存、订单状态和时间生效，仍应由业务 API、数据库或规则引擎校验。图谱不能把候选边凭空变成事实。

来源、时间和引用必须是一等数据

同一关系可能来自不同日期、系统和权限范围。只保存“节点—边”，不保存来源、时间和版本，图谱很快会变成无法解释的静态网。

W3C PROV-O 提供了描述来源和派生关系的模型。企业至少要记录关系来源、抽取模型、审核者、生效时间和替代版本。

PROV-O

还要区分“引用正确”和“引用真的支撑了答案”。

一项 2024 年研究在其测试设置下发现，带引用的答案中最多有 57% 的引用缺乏 citation faithfulness。

也就是说，模型可能先凭参数记忆生成，再事后找一段看起来相关的材料来解释。Correctness is not Faithfulness

最终答案必须能回到原文或系统记录：图谱缩短路径，来源承担证据，引用还要真正参与生成过程。

评测不能只看一个“准确率”

RAG 的问题可能出在召回，也可能出在生成。

ARES 把评测拆成 context relevance、answer faithfulness 和 answer relevance，并用少量人工标注校准自动评估器；RAGChecker 则进一步提供检索和生成模块的细粒度诊断指标。

ARES｜RAGChecker

对知识图谱 RAG，我会把评测表拆成五列：

层次 要问的问题 例子
片段召回 必要原文是否被找到？ D1、D2、D3 是否都出现
实体对齐 名字是否合并正确？ “甲供应链”是否对应 SUP-001
路径完整 关系链是否缺边？ 订单→供应商→合同→政策
证据可信 回答是否真的由证据支持？ 引用条款是否支撑“需复核”
工程代价 每次回答和每次更新要付出什么？ 延迟、索引调用、人工审核量

这样才能知道“图谱有效”到底是哪一层有效。否则，答案分数上升了，却可能是模型更会猜，或者上下文塞得更多，并不能证明实体和关系建对了。

什么时候不要上知识图谱 RAG？

下面几类情况，先把普通 RAG 做好更划算：

  1. 文档量不大，问题大多是单段落查找；
  2. 对象、关系和命名还没有统一；
  3. 没有增量同步、失效和回滚机制；
  4. 真正要查的是交易状态、金额和权限；
  5. 没有真实问题证明图谱能增加价值。

图谱成本还包括本体、抽取、对齐、冲突处理、更新、权限和评测。

小规模试点怎么做？

不要先建全公司的知识图谱。选一个真实问题簇，准备 20—50 个已知答案的问题，做三组对照：普通 RAG、混合 RAG 加图扩展、图查询/GraphRAG。

保持模型、上下文预算和来源权限一致，把问题按结构分层：20 个单条款问题、20 个跨文档关系问题、10 个全局主题问题。

每个问题提前登记答案、必要证据片段、实体 ID、关系路径和允许的“不知道”条件。

然后评估：

  • 召回是否覆盖必要证据；
  • 多跳关系是否完整；
  • 实体是否合并错或拆错；
  • 答案能否回到原文和结构化记录；
  • 新旧版本冲突是否识别；
  • 引用是否真的支持答案，而不是事后贴上去；
  • 延迟、索引成本和维护量是否接受。

如果图谱只让简单 FAQ 多绕一层，却没有改善关系问题，就不要扩大。只有当它稳定提高关系证据覆盖、实体对齐和路径完整性，才值得沉淀为业务知识资产。

我会把结论压缩成一句话：

RAG 先找证据，知识图谱 RAG 再找关系；但谁定义关系、谁确认事实、谁承担更新责任，永远不能由模型单独决定。

下一步只做一件事：拿一类真实问题做 RAG 与知识图谱 RAG 的对照评测，再决定要不要建更大的图。

参考资料

  1. Lewis 等：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks，NeurIPS 2020。
  2. Edge 等：From Local to Global: A Graph RAG Approach to Query-Focused Summarization，2024。
  3. Microsoft Research：Project GraphRAG。
  4. Microsoft GraphRAG：Indexing Methods。
  5. Microsoft GraphRAG：Local Search。
  6. Microsoft GraphRAG：Global Search。
  7. Zhu 等：Knowledge Graph-Guided Retrieval Augmented Generation，NAACL 2025。
  8. Gutierrez 等：HippoRAG，2024。
  9. Guo 等：LightRAG，2024。
  10. He 等：G-Retriever，2024。
  11. Zhong 等：A Comprehensive Survey on Automatic Knowledge Graph Construction，ACM Computing Surveys 2023。
  12. Bian：LLM-empowered Knowledge Graph Construction: A Survey，2025。
  13. Zhu 等：LLMs for Knowledge Graph Construction and Reasoning，2023。
  14. W3C RDF 1.1 Primer、OWL 2 Primer、PROV-O。
  15. AWS Prescriptive Guidance：Creating RAG Solutions for Healthcare。
  16. Microsoft GraphRAG：Query Overview。
  17. Tang 与 Yang：MultiHop-RAG，2024。
  18. Wu 等：STaRK: Benchmarking LLM Retrieval on Textual and Relational Knowledge Bases，NeurIPS 2024。
  19. Saad-Falcon 等：ARES，2023。
  20. Ru 等：RAGChecker，2024。
  21. Wallat 等：Correctness is not Faithfulness in RAG Attributions，2024。
  22. W3C SHACL。
  23. AWS Semantic Layer Data Layer。
  24. Min 等：Efficient Knowledge Graph Construction and Retrieval from Unstructured Text for Large-Scale RAG Systems，2025，预印本。