跳到主要内容

MS GraphRAG 的索引(Index)期 — 把文本抽成带摘要的图

这一章讲三件事: 微软 GraphRAG 与第 07 章「白盒建图」的本质区别; 索引期前半段的三个动作(切块、抽取、合并摘要)各自的机制与参数依据; 大图上会撞上的规模问题(super node、超长社区)和书里给的对策。 本书用《奥德赛》当跑道的例子,每个数都来自这次实跑。

1. 顶层全景:一条两阶段的管道​

微软的 GraphRAG(出自 2024 年的论文,Edge 等)1和第 07 章做的是同一件事的两条路线: 把非结构化文本变成知识图谱。区别在「厚」:第 07 章的图只存干净的字段 (日期、金额、当事人),微软的图每个节点和关系都拖着一份自然语言描述, 而且建完图还有第二阶段——把图切成社区、给每个社区写报告(第 09 章讲)。

  索引期(本章)                       检索期(第 10 章)
  ──────────────                     ──────────────
  文本 → 分块 → 抽实体/关系(带描述)   
      → 同名合并成实体摘要            global search:吃社区报告
      → 社区检测(第 09 章)    ──→    local search:吃实体邻域+原文块
      → 社区摘要(第 09 章)

  图说:索引期是「预计算」——把以后检索要用的料,提前烧成结构+摘要。

这一章覆盖索引期的前半:分块、抽取、合并摘要。

2. 两个先行的决定,影响全管道​

决定一:实体类型清单​

实体类型不是抽完再分,而是抽取前就要定死——清单直接写进抽取提示, 并且塑造下游一切:抽取、链接、摘要的质量都受它影响2。 通用三件套是人、组织、地点;领域可以加自己的:《奥德赛》跑道就加了 GOD(神)、EVENT、CREATURE(怪物)、WEAPON_OR_TOOL(神器)3。

书里顺带交代了类型边界的模糊性:PERSON、GOD 界限清楚; EVENT 就难说——一次战斗是 EVENT,整场特洛伊战争也是 EVENT; LOCATION 可以是国家、城市、城里的一个地方。模糊不致命,反而给 LLM 留了弹性, 但你要知道这是在用「分类的一致性」换「覆盖的宽度」4。

决定二:chunk 大小——越小抽得越全,越贵​

书里引了论文的实验:同一批文本,600 / 1200 / 2400 token 三种块, 600 的块抽出的实体引用最多,2400 最少——块越小,LLM 看得越细5。 另一个加码手段是 self-reflection 迭代(论文里叫 gleaning, 我们书架上的微软 GraphRAG 拆解也是这个名字):对同一段文本多抽几遍, 每遍补上前一遍漏掉的——迭代次数越多,检出越多6。

代价一目了然:块越小、迭代越多,LLM 调用次数越多,索引越烧钱。 书里的选择:1000 词、重叠 40,一个折中值7。

3. 抽取:分隔符模板 + 结构化输出​

抽取提示借自论文附录,结构分三步:① 抽实体——每个实体给 名字、类型、描述(该实体的属性和活动的综合描述); ② 从已抽实体里找明显相关的一对对,给描述和关系强度分数(数值); ③ 全部塞进一个列表,用约定的分隔符——起分隔作用的记号——隔开,最后打上一个「抽完了」的收尾记号8。

  ("entity"⟦奥德修斯⟧⟦PERSON⟧⟦伊萨卡之王,特洛伊战争的主角…⟧)
  ("relationship"⟦奥德修斯⟧⟦帕拉斯/雅典娜⟧⟦女神是他的护佑者…⟧⟦9⟧)

  图说:⟦⟧处原书用可配置的分隔符占位。每条记录一行,LLM 输出的
  自由文本被「格式约定」钉住,后处理才解析得动。强度分和括号内容为演示。

注意两个设计:实体先抽全、再配对——关系只在已抽出的实体之间找, 省得关系挂到不存在的节点上;关系带强度分,这个分数后面检索排序时要用。

4. 主走查:ORESTES 的六条描述怎么变成一条​

书里的跑道是《奥德赛》,只处理第一卷。数字先摆出来: 24 卷书,平均 6515 token(最小 4459、最大 10760),按 1000 词切块; 第一卷抽得 66 个实体、182 条关系——而且书里明说这个数每次跑都会变 (LLM 是概率性的)9。

关键机制在后面:同一个实体在多个 chunk 里被反复抽到,每次带一条描述。 看 ORESTES(俄瑞斯忒斯)的六条描述10:

  ① Orestes 是 Agamemnon 之子,杀了 Aegisthus
  ② Orestes 是被寄望为父复仇的人
  ③ Orestes 因弑 Aegisthus 为父报仇而受称赞
  ④ Orestes 是 Agamemnon 之子,杀了 Aegisthus(与①重复)
  ⑤ ⑥ 又是②③的重复

  ——六条有重复、无矛盾,合起来恰好保住了全部关键事实

如果放任六条并存,图会又脏又冗余。合并动作再调一次 LLM,提示词(prompt,发给模型的整套指令)的要点:把一个(或一对)实体的全部描述拼成一条综合描述; 有矛盾要消解成连贯版本;用第三人称;写明实体名11。 合并后 ORESTES 只剩一条:[「Agamemnon 之子,以杀死 Aegisthus 为父复仇而著称; 不负众望完成复仇」]12。

关系同样处理:同一对实体可能有多条关系(多次互动、每次一条)。 书里数了抽出的关系对之最:Telemachus(忒勒马科斯)与 Minerva(密涅瓦/雅典娜) 之间 14 条关系——女神换着化身给他引路、给他壮胆、让他想念父亲; 合并成一条摘要,讲清「密涅瓦是他寻父路上的神佑导师」13。

这一步做完,索引期的「厚图」成型:每个节点一条摘要,每个关系一条摘要。 它和第 07 章那张干净的白盒图是两种物种——这里存的是压缩过的自然语言, 天然适合再喂回 LLM。

5. 作者的判断与证据​

  • 「块越小抽得越全」有实验背书(论文的三种块大小对比)5, 是本章唯一有数据支撑的调参结论;
  • 66 实体/182 关系「每次跑会变」——书里主动承认不确定性,没有把单次结果当定论9;
  • super node 风险:大图上,某些实体(书里举雅典:若处理全部古希腊史料) 会积累压倒性数量的关系与描述;不做排序/过滤,摘要输出会过长、 甚至塞不进提示词14。同类问题在社区层也一样:社区太大要按相关性选材15;
  • 层级与规模:论文用分层社区(多层粒度),本书图小,只做单层, 书里明确交代了这个简化16。

判断(我们的,不是书里的): 索引期的本质是用查询期的钱换查询期的能力—— 每个实体几十次 LLM 调用、每对关系再合并、每个社区再写报告, 都是「回答之前」的开销。这决定了 GraphRAG 的适用边界:资料库相对稳定、 问题面向全局归纳时才划算;资料天天变、问题全是「某条款是什么」的点查, 第 03 章的向量检索便宜得多。我们的微软 GraphRAG 源码拆解同样强调索引烧钱、 建议先小数据试跑。 如果错,会错在: 如果后续索引成本大幅下降(小模型蒸馏(把大模型的本事压进小模型)、增量更新成熟), 这条边界会外移——但「资料高频变更 + 纯点查」的组合仍不划算。

6. 边界与局限​

  • 本书只跑了一卷《奥德赛》:66 实体的玩具图上,很多规模问题 (super node、社区爆炸)只能以框注形式警告,不能实测演示;
  • 抽取的正确性没有校验:LLM 会漏抽、错抽、张冠李戴,书里没有给 抽取质量的评估方法(评测思路在第 11 章,但那里评的是答案,不是图);
  • 实体消解缺位:与第 07 章呼应——同名实体靠「名字字符串一致」合并, 「Ulysses/Odysseus」这种同实体的两个译名,书里没有处理, 图里会是两个节点(这个观察是我们的,书里没有点破);
  • 类型清单定死后,清单外的实体类型整本漏掉——书里把它当作前提而非缺陷, 但用的时候要记得这是可配置的窄化2;
  • gleaning 只引了结论(迭代越多检出越多),书里没有实现迭代逻辑6。

7. 可带走的​

  1. MS GraphRAG 的图是「厚图」:每个实体、每条关系都带自然语言摘要—— 这是它与干净白盒图(第 07 章)的本质区别;
  2. 实体类型清单先于抽取定死,并塑造整条下游;
  3. chunk 越小抽得越全(600 优于 2400);gleaning 式多轮补抽再加码——都是拿钱换覆盖;
  4. 抽取模板三段式:实体(名/型/描述)→ 关系对(描述/强度分)→ 分隔符打包;
  5. 同名多描述 → LLM 合并成一条;矛盾要消解、第三人称、写明实体名;
  6. 关系也合并:同一对实体的多次互动合成一条摘要,为检索省上下文;
  7. 大图的两处规模暗礁:super node(实体关系爆多)与大社区, 对策都是排序选材,不是硬塞;
  8. 索引期是预计算:先想清楚「我的资料库稳不稳、问题全不全局」再决定烧不烧这个钱。

8. 原文地图​

主题原书章原文位置
两阶段与图 7.17.1 Dataset selectiontext/16-ch07-01-7-1-dataset-selection.txt:3(搜「Figure 7.1」)
实体类型先定、影响下游7.1 Dataset selectiontext/16-ch07-01-7-1-dataset-selection.txt:20(搜「must be defined in advance」) · text/16-ch07-01-7-1-dataset-selection.txt:25(搜「shapes the entire」)
选《奥德赛》的理由7.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:4(搜「The Odyssey to evaluate」)
24 卷 token 统计7.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:61(搜「6,515」)
chunk 越小抽得越多7.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:82(搜「smaller chunk sizes」)
self-reflection 迭代7.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:84(搜「self-reflection」)
1000 词/重叠 407.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:89(搜「1,000-word」)
抽取提示三步7.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:112(搜「Identify all entities」)
关系强度分7.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:126(搜「relationship_strength」)
实体类型清单7.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:146(搜「meaningful entities」)
EVENT/LOCATION 模糊7.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:158(搜「more ambiguous」)
66 实体 182 关系、会变7.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:230(搜「66 entities」)
ORESTES 六条描述7.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:246(搜「Agamemnon」)
Telemachus×Minerva 14 条7.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:271(搜「total of」)
合并摘要提示7.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:303(搜「contradictions」)
ORESTES 合并结果7.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:365(搜「avenging」)
Telemachus–Minerva 摘要7.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:432(搜「crucial role」)
super node 框注7.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:447(搜「super nodes」)
只做单层社区的简化7.2 Graph indexingtext/17-ch07-02-7-2-graph-indexing.txt:497(搜「hierarchical nature」)
大社区框注7.3 Graph retrieverstext/18-ch07-03-7-3-graph-retrievers.txt:25(搜「too large」)

Footnotes​

  1. 出处:「7.1 Dataset selection」第 3 段(text/16-ch07-01-7-1-dataset-selection.txt:3,搜「Figure 7.1」)。图 7.1 来自 Edge 等 2024(CC BY 4.0 授权);该论文即《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》。补充(不在书里):书末参考文献未给这篇的 URL,arXiv 编号 2404.16130。来源:https://arxiv.org/abs/2404.16130(查阅于 2026-08-27)。 ↩

  2. 出处:「7.1 Dataset selection」第 20 段(text/16-ch07-01-7-1-dataset-selection.txt:20,搜「must be defined in advance」)与第 25 段(text/16-ch07-01-7-1-dataset-selection.txt:25,搜「shapes the entire」)。原文:实体类型可配置、必须预先定义;选择塑造下游抽取、链接与摘要质量。 ↩ ↩2

  3. 出处:「7.2 Graph indexing」第 146 段(text/17-ch07-02-7-2-graph-indexing.txt:146,搜「meaningful entities」)。七类:PERSON、ORGANIZATION、LOCATION、GOD、EVENT、CREATURE、WEAPON_OR_TOOL。 ↩

  4. 出处:「7.2 Graph indexing」第 158 段(text/17-ch07-02-7-2-graph-indexing.txt:158,搜「more ambiguous」)。原文:EVENT 可以是一次动作也可以是整场战争;LOCATION 可以是国家、城市或城里一处具名地点;一致性更难,但也给 LLM 更多弹性。 ↩

  5. 出处:「7.2 Graph indexing」第 82 段(text/17-ch07-02-7-2-graph-indexing.txt:82,搜「smaller chunk sizes」)。原文:图 7.2 中 600-token 块的曲线始终最高、2400 最低;小块让 LLM 检出更多实体。 ↩ ↩2

  6. 出处:「7.2 Graph indexing」第 84 段(text/17-ch07-02-7-2-graph-indexing.txt:84,搜「self-reflection」)。原文:self-reflection 迭代=对同一文档追加抽取遍数,所有块大小下都会检出更多实体引用。「gleaning 是论文与微软实现中的叫法」这一点,依据我们的前沿框架书架对微软 GraphRAG 的拆解:补充(不在书里,依据我们的 frontier 书架):多轮补抽在源码与论文里叫 gleaning,思路是再抽一遍并追问「还有吗」。依据: shelf=ai-frontier-reference/graphrag#02-graph-extraction.md 事实=该拆解将 gleaning 描述为「让 LLM 再抽一遍、再问还有吗」的多轮补抽技巧,用于解决单遍抽不全的问题。 ↩ ↩2

  7. 出处:「7.2 Graph indexing」第 89 段(text/17-ch07-02-7-2-graph-indexing.txt:89,搜「1,000-word」)。原文:按空白切分、1000 词上限、重叠 40 词。 ↩

  8. 出处:「7.2 Graph indexing」第 112 段(text/17-ch07-02-7-2-graph-indexing.txt:112,搜「Identify all entities」)与第 126 段(text/17-ch07-02-7-2-graph-indexing.txt:126,搜「relationship_strength」)。原文:实体抽名字、类型(来自给定清单)、综合描述;关系对抽描述与强度分;输出用分隔符格式化。完整提示还含 few-shot 示例,书里略去。 ↩

  9. 出处:「7.2 Graph indexing」第 230 段(text/17-ch07-02-7-2-graph-indexing.txt:230,搜「66 entities」)与第 61 段(text/17-ch07-02-7-2-graph-indexing.txt:61,搜「6,515」)。原文:66 实体、182 关系,数字随执行而变;24 卷平均 6515 token、最小 4459、最大 10760。 ↩ ↩2

  10. 出处:「7.2 Graph indexing」第 246 段(text/17-ch07-02-7-2-graph-indexing.txt:246,搜「Agamemnon」)。六条描述中②③④⑤⑥的具体内容见第 247-251 段;中文转写是我们对英文描述的复述。 ↩

  11. 出处:「7.2 Graph indexing」第 303 段(text/17-ch07-02-7-2-graph-indexing.txt:303,搜「contradictions」)。原文:把同一实体(对)的多条描述拼成一条综合描述;矛盾要消解成连贯版本;用第三人称并写明实体名。 ↩

  12. 出处:「7.2 Graph indexing」第 365 段(text/17-ch07-02-7-2-graph-indexing.txt:365,搜「avenging」)。方括号内容是该英文摘要的中文转写。 ↩

  13. 出处:「7.2 Graph indexing」第 271 段(text/17-ch07-02-7-2-graph-indexing.txt:271,搜「total of」)与第 432 段(text/17-ch07-02-7-2-graph-indexing.txt:432,搜「crucial role」)。原文:关系最多的实体对是 Telemachus 与 Minerva,共 14 条;合并后的摘要讲密涅瓦在忒勒马科斯寻父途中提供指引与保护。 ↩

  14. 出处:「7.2 Graph indexing」第 447 段(text/17-ch07-02-7-2-graph-indexing.txt:447,搜「super nodes」)。原文:处理全部古希腊史料时,雅典这样的节点会积累巨量关系与描述;没有排序机制,摘要会过长甚至塞不进提示;需要过滤/排序策略。 ↩

  15. 出处:「7.3 Graph retrievers」第 25 段(text/18-ch07-03-7-3-graph-retrievers.txt:25,搜「too large」)。原文:社区太大时,全部实体与关系塞进摘要提示会超 token 限制或产出过长摘要;要按相关性选取。 ↩

  16. 出处:「7.2 Graph indexing」第 497 段(text/17-ch07-02-7-2-graph-indexing.txt:497,搜「hierarchical nature」)。原文:论文用 Louvain 的分层性质捕捉多粒度社区;本书图小,只做单层,跳过分层。 ↩