检索文本，还是检索关系？这可能是下一代 AI 系统的分水岭。

一、为什么普通 RAG 会撞到天花板

大多数人对 RAG（检索增强生成）的印象是这样的：

用户提问
    ↓
在文档库中检索相关文本
    ↓
返回最相关的片段
    ↓
模型基于片段生成回答

这套流程处理简单问题绰绰有余。但一旦问题变复杂，它就会露馅。

比如你问：“为什么我们三月份的销量下降了？”

RAG 会去找同时包含”销量”和”三月”这两个关键词的文档，然后把匹配到的几段文字扔给你——它找到的是文字碎片，而不是因果链条。

一个理想的答案应该长这样：

销量下降
  ← 由于产品发布延迟
      ← 由于供应商依赖问题
          ← 由于仓库故障
              ← 导致差评增加
                  ← 差评使转化率下降 23%

同样的模型，同样的数据，结果却天差地别——因为一个系统在搜索文字，另一个系统在还原真实世界的关系结构。

这正是 Microsoft、Stanford 和 Anthropic 三家机构各自独立发现的问题。也是它们不约而同转向 Graph Engineering（图工程） 的原因。

---

二、Microsoft GraphRAG：把非结构化文本变成知识图谱

Microsoft 开源了 GraphRAG（github.com/microsoft/graphrag），并给出了目前最扎实的对比数据。

它的核心流程是：

加载文档 → 切分文档 → 抽取实体与关系 → 构建图谱
   → 社区检测 → 生成社区报告 → 嵌入实体与报告
   → 本地检索 / 全局检索

Microsoft 文档中提出了一个关键洞察：普通 RAG 擅长回答局部问题（“告诉我关于某个具体实体的信息”），却处理不好全局问题（“这一万篇文档里有哪些共性主题”）。而 Graph Engineering 两者都能应对：

检索类型	场景	原理
Local Search	“三月份供应商 X 出了什么问题”	定位具体节点及其关联
Global Search	“我们所有供应商关系中的风险模式是什么”	扫描全图寻找模式

来自 GraphRAG 相关研究（应用于工业 P&ID 图纸分析的 ChatP&ID 论文）的实测数据：

• ‎准确率：比原始文档检索方式高 18%
• ‎Token 成本：比直接加载结构化文件低 85%
• ‎单任务成本：约 0.004 美元

---

三、Stanford 的理论基础：模型只是图中的一个节点

Stanford 的 DSPy 论文提出了一个关键理念：模型不是宇宙中心，而是图中的一个节点。这为 Graph Engineering 提供了理论支撑。

DSPy 把整个 AI 流水线也看作一张图：

问题 → Retriever（检索） → Reasoning（推理） → Verifier（校验） → 答案

DSPy 优化的是”处理流程图”，GraphRAG 优化的是”知识关系图”——两者的共同点是：都把模型当作更大系统里的一个组件，而不是全部答案的来源。

Stanford 的 STORM 项目更进一步：它在写下第一个字之前，先通过一系列结构化的研究步骤（收集资料、构建大纲、撰写、验证、修订）逐步构建知识图谱，每一步都由上一步发现的关系驱动。

Stanford 的另一项研究比较了 26 个开源模型在知识图谱构建任务上的表现，得出了一个反直觉但极其重要的结论：

大模型 + 差图谱 = 更差的结果
小模型 + 好图谱 = 更好的结果

好的图谱结构，胜过更大的模型。这与 Microsoft 和 Anthropic 得出的结论一致：决定输出质量的，是模型周围的系统，而不是模型本身。

---

四、为什么图结构能提升推理质量

MIT Press 发表在 TACL（Transactions of the Association for Computational Linguistics）上的研究，从科学角度解释了这一现象。

文本上下文 → 从图谱检索相关关系 → 关系记忆
    → 语言模型 → 更连贯、更准确的生成结果

核心发现：拥有显式关系结构访问权限的模型，生成的文本更连贯，逻辑错误更少。

换句话说，模型不需要从大段文字里”猜”实体之间的关系——关系已经在图谱里明确写好了，模型只需要直接调用。

清华团队的 KEPLER 项目则更进一步，将语言模型训练与知识图谱嵌入结合，让模型同时优化”语言理解”和”事实知识”两个能力：

语言模型 + 知识嵌入 + 知识图谱 = 既懂语言又懂事实的模型

---

五、Anthropic：Claude 如何嵌入图谱架构

Anthropic 没有一款叫”Graph Engineering”的产品，但 Claude 在图谱架构中扮演了三层角色。

Layer 1：Claude 从文本中抽取图谱

文档 → Claude 抽取实体与关系 → JSON 三元组
{
  "subject": "Anthropic",
  "relation": "created",
  "object": "Claude"
}
→ 知识图谱

实体抽取、关系抽取、去重、归一化、本体草拟——这些过去需要专门 NLP 流水线完成的工作，现在一次 API 调用就能搞定。

Layer 2：Claude 查询图谱

用户问题 → Claude → Cypher / SPARQL 查询
    → 知识图谱 → 查询结果 → Claude 用自然语言解释

Layer 3：MCP 作为传输层

Claude → MCP 协议 → 图数据库 → 实体与关系 → 具备完整图上下文的 Claude

MCP（Model Context Protocol）让 Claude 无需每次会话重新搭建连接，就能持续访问任意知识图谱。

真实案例：LaunchNotes

LaunchNotes 构建了一款名为 Graph 的产品，把 GitHub、Jira 和 Linear 三个系统连接起来，让 Claude 分析工程工作之间的关联。

GitHub 提交 + Jira 工单 + Linear 任务
    → 工程工作关系图
    → Claude
    → 故障检测 + 项目洞察

来自 Anthropic 官方案例的数据：

• 故障检测速度提升 最多 5 倍
• 会议时间减少约 50%
• 发布说明可在数秒内自动生成

---

六、什么是知识图谱：从概念说起

在动手搭建之前，先理解最基本的概念。

知识图谱把信息存储为三元组：

主体 → 关系 → 客体

例如：

Anthropic → 创造了 → Claude
Claude → 支持 → MCP
MCP → 连接 → 外部工具
Microsoft → 构建了 → GraphRAG
GraphRAG → 降低 Token 成本 → 85%

对比普通数据库：

普通数据库：
  公司表
  产品表
  （表之间没有显式关系）

知识图谱：
  公司 → 创造了 → 产品
  产品 → 竞争于 → 另一产品
  另一产品 → 归属于 → 另一公司
  公司 → 投资了 → 另一公司

图谱存的不只是事实，更是事实之间如何连接。这正是支撑复杂推理的关键。

---

七、完整的 Graph Engineering 流水线

步骤	内容
1. 收集原始文档	PDF、邮件、报告、数据库导出
2. 抽取实体	人物、公司、产品、事件、概念
3. 抽取关系	谁对谁做了什么、何时、为何、如何
4. 构建 Schema	定义实体类型与关系类型
5. 去重与归一化	“Microsoft Corp” 与 “MSFT” 是同一实体
6. 存入图数据库	Neo4j、Amazon Neptune 或带图扩展的 PostgreSQL
7. 构建检索层	局部检索找具体实体，全局检索找模式
8. 接入模型	Claude 通过 MCP 或直接 API 查询图谱
9. 持续更新	新文档扩展图谱，矛盾信息被标记待审核

值得说明的是：相关基准研究显示，大语言模型在抽取和归一化阶段表现优异，但零样本图谱生成目前还不足以在没有人工审核的情况下直接用于生产环境——尤其是在 Schema 设计和去重这两个环节。

---

八、驱动整条流水线的五类 Prompt

Graph Engineering 并没有抛弃 Prompt Engineering，而是把 Prompt 用在了流水线的每个具体环节。

1. 抽取阶段

提取所有组织、人物、产品和事件。
为每个实体返回：canonical_name / type / description / source
为每条关系返回：source_entity / relation_type / target_entity / evidence / confidence_score

2. 归一化阶段

比较以下实体，判断它们是：
- 同一实体
- 相关但不同的实体
- 无关实体
返回规范名称与判断理由，未有明确证据不得合并。

3. 图查询阶段

将用户问题翻译为 Cypher 查询。
仅使用 Schema 中已存在的关系类型，不得虚构标签或属性。

4. 有依据的回答阶段

仅基于检索到的图路径作答。
每个结论需标明支持节点、关系路径，明确表达不确定性，不得从相关性推断因果。

5. 图谱维护阶段

将新事实与现有图谱比较，分类为：新增 / 重复 / 矛盾 / 更新 / 不确定。
未有证据不得覆盖已有事实。

Prompt 不是 Graph Engineering 的对立面，而是它内部的执行机制。

---

九、可以落地的五个应用方向

1. 尽职调查平台：整合公司报告、创始人、投资人、法律案件、股权结构、交易记录，服务于投资基金、律所、银行、并购顾问。

2. 销售情报系统：整合联系人、公司、角色、历史邮件、客户痛点，识别决策链、常见异议、卡点所在。

3. 工程情报系统：整合 GitHub、Jira、Linear 数据，如 LaunchNotes 已验证的效果——故障检测提速 5 倍，会议时间减半。

4. 研究情报系统：整合论文、作者、机构、方法、数据集、结果，识别方法论之间的矛盾与关联。

5. 个人知识操作系统：整合笔记、邮件、日程、联系人、任务，回答”这个想法我和谁讨论过”“哪些任务卡在等某人回复”这类问题。

---

十、三条独立路径，一个共同结论

Prompt Engineering  →  怎么问出正确的问题
RAG                 →  该找哪份文档
Graph Engineering   →  有哪些实体存在
                       它们如何连接
                       哪条路径通向答案
                       某个节点变化会带来什么连锁反应

大语言模型懂词语，知识图谱懂关系。当两者结合，才能构建出真正强大的 AI 系统。

Microsoft 在 GraphRAG 的生产实践中证明了这一点——准确率提升 18%，成本下降 85%。Stanford 在 DSPy、STORM 以及规模化研究中证明了这一点。Anthropic 在 LaunchNotes 案例中证明了这一点——故障检测提速 5 倍，会议时间减少 50%。

三家机构，三条独立路径，同一个结论：

模型找到的是文字，图谱找到的是真实世界的结构。