跳到主要内容

知识图谱与 GraphRAG — 当相似性不够用

这一章讲三件事: 向量搜索在哪三类查询上结构性失灵; 知识图谱(knowledge graph,KG)是什么、怎么建、查询期怎么用; 以及 Microsoft GraphRAG 这个容易混淆的专名到底指什么。 读完你会拿到一张「要不要上 KG」的六条决策清单—— 书里的默认答案是:不上,除非清单上至少四个「是」。

1. 顶层全景:概率性检索的三类死穴​

向量搜索处理的是概率与相似,不是确定性事实。书里列出它结构性失灵的三类查询1:

死穴书里的例子为什么向量搜索答不了
时限事实「2022 年 10 月 Twitter 的 CEO 是谁?」嵌入把过去与现在糊在一起,可能返回 Musk/Dorsey/Agrawal 中任何一个
多约束交集「哪些药同时与 warfarin 和葡萄柚汁相互作用?」检回的块各自与单个约束相关,未必有同时覆盖两者的
多跳链「2014 年由也导演了《盗梦空间》的人执导的电影,主演是谁?」向量能搜到 Inception 和 Nolan,但把 Nolan→Interstellar→McConaughey 连成链,模型不可靠

agent 可以靠分解子查询绕过(第 12 章),本章问的是另一个方向: 不用 agent,把知识本身组织成图,能不能直接答?2

  向量搜索:问「相似吗?」── 嵌入空间里的距离
  图查询:  问「怎么连着?」── 沿已知事实走路径

  Inception ──DIRECTED──▶ Nolan ──DIRECTED──▶ Interstellar ──ACTED_IN──▶ McConaughey

  图说:同一个问题,两种世界观。本章主走查:电影知识图谱上,
  「Royale with Cheese」那句台词怎么被精确地归因到演员与电影。

2. 核心原理(一):图、查询语言与本体​

知识图谱把知识存成节点(实体:Movie、Person、Genre、Character, 各带属性)与边(关系:DIRECTED、ACTED_IN、HAS_GENRE……)。 图数据库是 NoSQL 的一种,代表有 Neo4j、Amazon Neptune、Kuzu、TigerGraph3。

查询语言两种,都用同一个例子就能看懂——「查《Oppenheimer》的导演」4:

  Cypher(Neo4j 起家,直观):
     MATCH (p:Person)-[:DIRECTED]->(m:Movie {title: "Oppenheimer"})
     RETURN p.name            → Christopher Nolan

  SPARQL(W3C 标准,RDF 三元组库的语言,「较不直观但精确」):
     triple = 主语/谓语/宾语;SELECT ?personName WHERE { … }

ontology(本体)与 schema 的区分会反复用到:本体是领域的形式化抽象 ——「现实的规则」:人可以 DIRECT 电影,电影不能 DIRECT 人,电影必须有发行年; schema 是本体在数据库层的实现:Movie 节点有 release_year 属性、Integer 类型。 在 RAG 里,本体帮模型理解数据逻辑,schema(以文本形式交给模型) 让它能生成正确的图查询5。

3. 核心原理(二):建一张电影图​

书里的完整走查用两个数据源:IMDb 非商业数据集(已验证的 「who/what/when」:人、电影、类型)与 MovieSum(HuggingFace 上的剧本语料, 提供对白与场景文本)6。

建图过程里最有教育意义的一步,是行话叫 NER(named entity recognition)的那一步。

NER 的中文是命名实体识别:从文本里抽出人名、角色名等实体的任务。剧本有个惯例: 角色名全大写。于是用正则抓全大写的名字——仍然一堆错(抓进 THE、AND、 WITH、HIM 这种词)。

只好再加启发式——不保证对、但省事的经验法则:名字至少出现 3 次才算、 删掉常见词名单7。书里借这一步说了一句重要的话: 「建和维护 KG 需要领域专长;企业数据(合同、工单、日志)比剧本乱得多。」8

建出来的关系网:(Chunk)-[:MENTIONS]->(Character)、 (Character)-[:APPEARS_IN]->(Movie)、(Person)-[:DIRECTED]->(Movie)、 (Character)-[:PORTRAYED_BY]->(Person)……9

4. 核心原理(三):查询期的两种用法​

用法一:chunk enrichment(块增强)——主走查​

向量搜索检回的块常常有「thin reference」(稀薄引用:错拼的名字、 代词 he)缺上下文。块增强的做法:向量搜索先找块,再拿块里的实体去图里查一圈, 把结构化上下文连同块一起给模型10。

  查询:「Which actor said, 'They call it a Royale with Cheese,'
        and what movie was this in?」(这句台词谁说的、出自哪部电影)

  ① 向量搜索:精确找到《低俗小说》那段对白块(JULES 与 VINCENT 的对话)
     ——但块里没有电影名,也没有演员名
  ② 图查询:Character「Vincent」→ PORTRAYED_BY → John Travolta;
     → APPEARS_IN → Pulp Fiction
  ③ 把「知识上下文包」与块一起给模型 → 百分百确定地回答

KG 在这里的角色是高保真的 context provider:给向量检索结果加注结构与元数据11。

用法二:hybrid-graph retrieval(混合图检索)​

让模型把自然语言翻译成 Cypher(text-to-Cypher):先拿到图的 schema 当「词汇与语法」,再生成查询语句。书里的走查:「GoldenEye 里有哪些角色? 哪些与 Bond 互动过?」——生成的 Cypher 沿 APPEARS_IN 收齐角色, 再沿 Chunk 的 MENTIONS 找与 Bond 同现的角色。对照实验:只给向量块, 模型答「I cannot answer」;加上图块,完整答出角色名单与互动关系12。 书里还引了 HippoRAG 框架的结果:多跳问答基准上比标准 RAG 高约 20%13。

怎么选​

书里给了清晰的分工14:

chunk enrichmenthybrid-graph
世界观metadata-first:向量有效,只是块缺上下文discovery-first:问题本身是结构/关系型的
风险低(按块 ID 查图,亚毫秒)text-to-Cypher 会幻觉出非法语法,要超时与重试
适合MVP 起步关系型查询成主流时

嵌入存哪也是架构决策:放图库内(单事务、单一真相源,但向量与图遍历抢内存) vs 独立向量库 + chunk_id 回查(检索与图独立扩展,但两库要同步)15。

5. 核心原理(四):自动建图与 GraphRAG​

自动建图三步与一个深坑​

  • 实体识别:抽出「Apple=组织、Steve Jobs=人」;
  • 关系抽取:「Apple was founded by Steve Jobs」→ 三元组 (Apple, FOUNDED_BY, Steve Jobs);
  • 实体链接(entity linking):「Apple Inc.」「苹果」「造 iPhone 的公司」 → 归并到同一个节点16。

一个 LLM 可以替代多个专用 NLP 模型直接输出三元组,但书里诚实地标注: 「纯 LLM 抽取仍然嘈杂且依赖领域」;生产上是混合策略:LLM 提议 + 确定性启发式(正则管 ID/日期)+ 经典 NLP 验证 + 关键实体人工复核17。

实体链接是最深的坑,书里的例子极直观:IBM Inc. / International Business Machines Corp. / I.B.M.;Tylenol / acetaminophen;以及同一台手机的三种写法 (iPhone 15 Pro 256GB / Apple iPhone 15 Pro (256) / IP15PRO-256-BLK)18。 链接管线:归一化(Corp./Corporation 统一)→ 候选生成(Jaro-Winkler 等 字符串距离缩小比对空间)→ 低置信交给人工。这个任务在文献里的名字是 record linkage19。而一个相关失败模式叫 entity explosion(实体爆炸): 「007」「James Bond」「Bond」被建成了三个没合并的节点20。

书里的警告数字:「超过 50% 的知识图谱项目失败」(作者与专家对话的估计) ——技术原因是低估实体链接的复杂度,另一原因是想「建模一切」 而非用例驱动21。替代路径:买标准本体与许可实体数据(金融的 FIBO、 Dun & Bradstreet 的 D-U-N-S 号、LSEG 的 PermID、医疗的 DrugBank) ——等于把供应商数百万小时的实体链接工作买下来,你的任务缩小成 「把内部乱数据链接到规范实体」22。

GraphRAG:一个容易被泛用的专名​

先澄清术语:有人拿「GraphRAG」泛指一切图辅助 RAG;本书特指微软研究院的 方案,它面向的是另一类查询——sensemaking(意义建构)查询,也叫 QFS(query-focused summarization,查询聚焦摘要):「所有 007 电影的主要主题 是什么?」要的是基于全语料全局视图的综合答案,不是检索几个片段23。

三步24:

  ① 建图:LLM 从语料自动抽实体与关系(无预定义 schema)
  ② community detection(社区发现):用图算法找稠密连通的簇——
     每个簇是一个核心主题;LLM 为每个社区生成多层级摘要
  ③ 查询:找最相关的社区摘要 → 每个摘要生成部分答案 →
     再一次调用综合成最终答案

成本与耗时书里给了实测:20 部电影的样本索引费 $6.32, 全量 1,800 部估计 $560+;M4 Mac 笔记本上 20 部跑了约 45 分钟 (每个块要几十次顺序 LLM 调用)25。查询分 local_search(自底向上, 沿边扩散,适合具体细节)与 global_search(自顶向下,综合全图, 适合高层次问题)——「全部剧本的主题与叙事模式」走的就是后者, 答案带社区报告编号引用26。

主要缺点:前期预处理成本;不适合快速变化的语料(社区摘要要重算)、 延迟敏感场景、要求逐字引用的场景(社区报告是有损综合)、 以及简单事实查询(「X 的价格?」没有 ROI)27。

补充(不在书里,依据我们的 frontier 书架):微软 GraphRAG 的索引管线与 社区摘要有源码级拆解。依据: shelf=ai-frontier-reference/graphrag#03-communities-and-reports.md 事实=该章拆解了社区发现与报告生成的实现。

补充(不在书里,依据我们书架上的《Essential GraphRAG》):本书书堆里另有一本 GraphRAG 专精书,从零手写了整套管道。依据: shelf=ai-book-reference/essential-graphrag#08-graphrag-indexing.md 事实=该章逐段拆解微软 GraphRAG 索引期的实体/关系抽取与摘要合并,正是上文第①步「LLM 自动抽实体建图」的展开。

6. 核心原理(五):图基础设施与六条决策清单​

图数据库三类部署:传统服务器/集群(Neo4j、TigerGraph——属性图常内存受限, 性能取决于「热图」能否装进 RAM)、托管云(Neo4j AuraDB、Amazon Neptune)、 嵌入式库(Kuzu、DuckDB——数据库就是应用进程内的一个文件,适合 <10-20GB 只读场景)28。

运营两条硬经验:ETL 是最被低估的成本——大图构建包单事务不可行, 要用 MERGE(先查存在再写入,天然幂等)+ 每千节点分批提交, 接受 eventual consistency(最终一致)29;过期事实别删,打 tombstone (墓碑标记:人离职了,WORKS_AT 边不删,加 status:"inactive", 查询时过滤——保住历史)30。

最后是那张决策清单——至少四个「是」才值得上 KG31:

  1. factual failure:评测里反复出现标准/混合 RAG 稳定失败的多跳/时限/强约束查询?
  2. grounding necessity:需要 100% 确定性接地(法务合规、医疗剂量)?
  3. available assets:有可借力的本体资产(许可 KG/标准本体)?
  4. data connectivity:数据的价值在关系(企业层级、供应链)而非文档内容?
  5. long-term ownership:有团队能长期负责图建模、schema 演化、复杂 ETL?
  6. business ROI:准确率收益绑定明确业务结果?

实践路径:多数团队从标准 RAG 起步,用第 11 章的评测找出准确率不足的 问题查询,再针对这些试点 KG/GraphRAG32。

7. 作者的判断与证据​

  • 「50% 项目失败」是作者转述的专家估计,不是统计研究——当警示读,不当数据读;
  • HippoRAG 的 20% 提升有论文出处;
  • 六条清单是作者的经验框架,与全书「先用评测说话」的主线一致;
  • GraphRAG 的成本数字($6.32/$560、45 分钟)是真实跑出来的,可信度高。

8. 边界与局限​

  • 本章的图全是电影领域——格式可预测的「最佳情形」;作者明言企业数据是 「非结构化暗数据的迷宫」;
  • text-to-Cypher 的生产化(幻觉语法、注入风险)只点到超时与重试;
  • 图谱与权限的交叉(节点/关系级 RBAC)只有一句提及;
  • 「别低估 vanilla RAG」是本章隐含的另一面:方向性准确的上下文, 对通用问答常常已经够好33。

9. 可带走的​

  1. 向量搜索三死穴:时限事实、多约束交集、多跳链——它们需要的是「走路径」不是「找相似」;
  2. KG = 节点 + 边;Cypher 直观、SPARQL 精确;本体管「现实的规则」,schema 管数据库实现;
  3. 查询期两用:chunk enrichment(低风险起步)与 hybrid-graph(关系型查询);
  4. 实体链接是最深的坑:一物多名;许可数据(D-U-N-S/PermID)是买别人链接好的成果;
  5. GraphRAG 是专名:微软的 QFS 方案,面向 sensemaking;前期成本高,场景窄而深;
  6. ETL 用 MERGE + 分批,过期事实打墓碑不删;
  7. 六条清单凑够四个「是」再上 KG;否则用评测找失败查询,定点试点;
  8. 「超过 50% 的 KG 项目失败」——低估实体链接、想建模一切,是两大死因。

10. 原文地图​

主题原书章原文位置
三类死穴Chapter 9text/121-ch09-chapter-9-knowledge-enhanced-rag.txt:17(搜「CEO of Twitter」) · :28(搜「warfarin」) · :39(搜「Inception」)
节点与边、走路径Chapter 9text/121-ch09-chapter-9-knowledge-enhanced-rag.txt:60(搜「nodes」)
Cypher 与 SPARQLHow Do You Search a Knowledge Graph?text/122-fm-how-do-you-search-a-knowledge-graph.txt:7(搜「Cypher」) · :67(搜「SPARQL」)
本体 vs schemaOntologies Versus Schemastext/123-fm-ontologies-versus-schemas.txt:7(搜「ontology」)
IMDb+MovieSum、NER 启发式Building a Knowledge Graph for Moviestext/124-fm-building-a-knowledge-graph-for-movies.txt:77(搜「IMDb」) · :19(搜「uppercase」) · :64(搜「GoldenEye」)
chunk enrichment 走查Using the Knowledge Graph at Query Timetext/125-fm-using-the-knowledge-graph-at-query-time.txt:14(搜「Royale with Cheese」)
hybrid-graph、HippoRAGUsing the Knowledge Graph at Query Timetext/125-fm-using-the-knowledge-graph-at-query-time.txt:172(搜「HippoRAG」)
两用法选择与嵌入存哪Choosing Between Enrichment and Hybrid Retrievaltext/126-fm-choosing-between-enrichment-and-hybrid-retrieval.txt:7(搜「metadata-first」) · :78(搜「chunk_id」)
实体爆炸Choosing Between Enrichment and Hybrid Retrievaltext/126-fm-choosing-between-enrichment-and-hybrid-retrieval.txt:69(搜「entity explosion」)
自动建图三步、IBM 例、JaroAutomating Knowledge Graph Constructiontext/127-fm-automating-knowledge-graph-construction.txt:12(搜「entity identification」) · :48(搜「IBM」) · :82(搜「Jaro」)
50% 失败、FIBO、许可数据Leveraging Standard Ontologies…text/128-fm-leveraging-standard-ontologies-and-knowledge-gra.txt:4(搜「50%」) · :10(搜「FIBO」)
GraphRAG 三步与成本GraphRAGtext/129-fm-graphrag.txt:4(搜「sensemaking」) · :49(搜「6.32」) · :106(搜「local_search」)
图基础设施The Graph Database Infrastructuretext/130-fm-the-graph-database-infrastructure.txt:33(搜「Kuzu」) · :61(搜「MERGE」)
更新模式Graph Update Patterns and Evolutiontext/131-fm-graph-update-patterns-and-evolution.txt:16(搜「Debezium」) · :37(搜「tombstone」)
六条清单The Accuracy/Cost Trade-offtext/132-fm-the-accuracy-cost-trade-off.txt:20(搜「factual failure」) · :4(搜「vanilla RAG」)

Footnotes​

  1. 出处:「Chapter 9. Knowledge-Enhanced RAG」第 10-39 段(text/121-ch09-chapter-9-knowledge-enhanced-rag.txt:17,搜「CEO of Twitter」;:28,搜「warfarin」;:39,搜「Inception」)。 ↩

  2. 出处:「Chapter 9」第 44 段(text/121-ch09-chapter-9-knowledge-enhanced-rag.txt:44,搜「agent」)。 ↩

  3. 出处:「How Do You Search a Knowledge Graph?」第 4-7 段(text/122-fm-how-do-you-search-a-knowledge-graph.txt:7,搜「Cypher」)。 ↩

  4. 出处:「How Do You Search a Knowledge Graph?」第 17-103 段(text/122-fm-how-do-you-search-a-knowledge-graph.txt:50,搜「Oppenheimer」)。 ↩

  5. 出处:「Ontologies Versus Schemas」第 7-13 段(text/123-fm-ontologies-versus-schemas.txt:7,搜「ontology」)。 ↩

  6. 出处:「Building a Knowledge Graph for Movies」第 27-38 段(text/124-fm-building-a-knowledge-graph-for-movies.txt:77,搜「IMDb」)。 ↩

  7. 出处:「Building a Knowledge Graph for Movies」第 19-58 段(text/124-fm-building-a-knowledge-graph-for-movies.txt:19,搜「uppercase」)。 ↩

  8. 出处:「Building a Knowledge Graph for Movies」第 58 段(text/124-fm-building-a-knowledge-graph-for-movies.txt:58,搜「domain expertise」)。 ↩

  9. 出处:「Building a Knowledge Graph for Movies」第 64-83 段(text/124-fm-building-a-knowledge-graph-for-movies.txt:64,搜「GoldenEye」)。 ↩

  10. 出处:「Using the Knowledge Graph at Query Time」第 1-14 段(text/125-fm-using-the-knowledge-graph-at-query-time.txt:14,搜「Royale with Cheese」)。 ↩

  11. 出处:「Using the Knowledge Graph at Query Time」第 75 段(text/125-fm-using-the-knowledge-graph-at-query-time.txt:75,搜「context provider」)。 ↩

  12. 出处:「Using the Knowledge Graph at Query Time」第 88-170 段(text/125-fm-using-the-knowledge-graph-at-query-time.txt:90,搜「GoldenEye」)。 ↩

  13. 出处:「Using the Knowledge Graph at Query Time」第 172 段(text/125-fm-using-the-knowledge-graph-at-query-time.txt:172,搜「HippoRAG」)。补充(不在书里,依据我们的 frontier 书架):HippoRAG 的拆解见 shelf=ai-frontier-reference/hipporag;事实=docs/hipporag 目录存在。 ↩

  14. 出处:「Choosing Between Enrichment and Hybrid Retrieval」第 8-65 段(text/126-fm-choosing-between-enrichment-and-hybrid-retrieval.txt:7,搜「metadata-first」),原书 Table 9-1。 ↩

  15. 出处:「Choosing Between Enrichment and Hybrid Retrieval」第 78-81 段(text/126-fm-choosing-between-enrichment-and-hybrid-retrieval.txt:81,搜「chunk_id」)。 ↩

  16. 出处:「Automating Knowledge Graph Construction」第 7-24 段(text/127-fm-automating-knowledge-graph-construction.txt:12,搜「entity identification」)。 ↩

  17. 出处:「Automating Knowledge Graph Construction」第 33-36 段(text/127-fm-automating-knowledge-graph-construction.txt:36,搜「noisy」)。 ↩

  18. 出处:「Automating Knowledge Graph Construction」第 42-60 段(text/127-fm-automating-knowledge-graph-construction.txt:48,搜「IBM」)。 ↩

  19. 出处:「Automating Knowledge Graph Construction」第 71-91 段(text/127-fm-automating-knowledge-graph-construction.txt:82,搜「Jaro」)。 ↩

  20. 出处:「Choosing Between Enrichment and Hybrid Retrieval」第 69 段(text/126-fm-choosing-between-enrichment-and-hybrid-retrieval.txt:69,搜「entity explosion」)。 ↩

  21. 出处:「Leveraging Standard Ontologies and Knowledge Graphs」第 4 段(text/128-fm-leveraging-standard-ontologies-and-knowledge-gra.txt:4,搜「50%」)。 ↩

  22. 出处:「Leveraging Standard Ontologies and Knowledge Graphs」第 10-22 段(text/128-fm-leveraging-standard-ontologies-and-knowledge-gra.txt:10,搜「FIBO」)。 ↩

  23. 出处:「GraphRAG」第 4 段(text/129-fm-graphrag.txt:4,搜「sensemaking」)。 ↩

  24. 出处:「GraphRAG」第 10-28 段(text/129-fm-graphrag.txt:20,搜「community detection」)。 ↩

  25. 出处:「GraphRAG」第 49-84 段(text/129-fm-graphrag.txt:49,搜「6.32」)。 ↩

  26. 出处:「GraphRAG」第 101-205 段(text/129-fm-graphrag.txt:106,搜「local_search」)。 ↩

  27. 出处:「GraphRAG」第 208-236 段(text/129-fm-graphrag.txt:208,搜「upfront」)。 ↩

  28. 出处:「The Graph Database Infrastructure」第 7-40 段(text/130-fm-the-graph-database-infrastructure.txt:33,搜「Kuzu」)。 ↩

  29. 出处:「The Graph Database Infrastructure」第 49-66 段(text/130-fm-the-graph-database-infrastructure.txt:61,搜「MERGE」)。 ↩

  30. 出处:「Graph Update Patterns and Evolution」第 30-37 段(text/131-fm-graph-update-patterns-and-evolution.txt:37,搜「tombstone」)。CDC 监听数据库日志的方案(Debezium)见同文件第 16 段。 ↩

  31. 出处:「The Accuracy/Cost Trade-off」第 16-52 段(text/132-fm-the-accuracy-cost-trade-off.txt:20,搜「factual failure」)。 ↩

  32. 出处:「The Accuracy/Cost Trade-off」第 80 段(text/132-fm-the-accuracy-cost-trade-off.txt:80,搜「evaluation」),五架构对照为原书 Table 9-2。 ↩

  33. 出处:「The Accuracy/Cost Trade-off」第 4 段(text/132-fm-the-accuracy-cost-trade-off.txt:4,搜「vanilla RAG」)。 ↩