第19章 GraphRAG：实体、关系与图检索

"A chunk-based RAG sees documents. A graph-based RAG sees relationships." — 2024 年后 RAG 领域的新分野

本章要点

• 传统 chunk RAG 擅长"找到相关段落"、不擅长回答跨实体关系和多跳推理问题
• GraphRAG 把知识组织成 实体 + 关系 + 社区 的图结构——检索时走图遍历
• 三种主流方案：Microsoft GraphRAG（全局社区摘要）、LightRAG（本地 + 全局双路）、Neo4j + LLM 合体（传统图 DB + embedding）
• 工程成本：索引阶段比 chunk RAG 贵 10-50 倍（LLM 抽取实体和关系）、在线检索成本相似
• GraphRAG 不是替代 chunk RAG——是补充，在全局性问题（"整个文档集说了什么""最重要的三个主题")和多跳关系上价值显著

19.1 传统 RAG 的盲区

chunk-based RAG 能回答：

• "什么是企业版 SSO？"（单跳事实）
• "SSO 价格是多少？"（单跳事实）

不能很好回答：

• "企业版 SSO 和专业版 SSO 有什么区别？"（两个实体对比）
• "哪些功能是企业版独有、专业版没有？"（集合运算）
• "这份产品手册整体讲了什么？"（全局主题）
• "这个产品问题可能影响哪些下游模块？"（多跳因果）

原因：chunk RAG 的检索是局部的——每个 chunk 独立打分、没有跨 chunk 的关系建模。回答"A 和 B 的区别"需要同时找到 A 和 B 的相关 chunk 并对比——传统 RAG 偶尔做对、做不稳定。

GraphRAG 的解法：在索引阶段用 LLM 从文档里抽出实体和关系、构建知识图谱；检索阶段不只是找 chunk、还遍历图。

19.2 GraphRAG 的核心组件

一个完整的 GraphRAG 系统包含：

• 实体抽取：LLM 从每个 chunk 抽出实体（人、产品、概念、地点）
• 关系抽取：LLM 同时抽出实体间关系（"SSO 属于 企业增强包"、"企业版 包含 专业版功能"）
• 图构建：把所有实体和关系合并成一张大图
• 社区发现：用图聚类算法找出实体集群（讨论同主题的实体集合）
• 社区摘要：对每个社区用 LLM 写一段总结
• 混合检索：query 时同时查向量 + 图 + 社区

19.3 Microsoft GraphRAG

Microsoft 2024 年开源的 GraphRAG 是影响最大的 GraphRAG 实现。核心创新：层次化社区摘要。

Local Search vs Global Search

• Local Search：针对具体实体的问题——先找实体节点、在邻居里召回、送 LLM 回答。类似传统 RAG 但以实体为中心
• Global Search：针对全局性问题——把 query 分发给所有社区摘要、每个摘要各自生成部分答案、最后合并成全局答案

Global Search 是 chunk RAG 做不到的能力——传统 top-k 拿不到"全量"信息。

社区发现：Leiden 算法

Microsoft 用 Leiden（Traag et al. 2019）做图聚类——每个社区是一组紧密相关的实体。层次化：

• Level 0：粗粒度大社区（几十个实体）
• Level 1：中等社区
• Level 2：细粒度小社区（几个实体）

不同 query 复杂度走不同层次——全局问题用 Level 0、具体问题用 Level 2。

效果和成本

Microsoft 的论文和技术博客展示：

• 在全局性问题上（"这个数据集整体讲了什么"）准确率显著高于 naive RAG
• 在多跳关系问题上 recall 提升 10-20 点
• 索引成本 是 naive RAG 的 10-50 倍（主要 LLM 抽取实体和关系）

这是 GraphRAG 的核心权衡——离线算力换在线查询质量。

19.4 LightRAG：更轻量的变体

LightRAG（arXiv:2410.05779，HKU 2024）是对 Microsoft GraphRAG 的简化：

• 不做层次社区发现——只用 entity + relation
• 检索时双路：low-level（直接查询 entity 节点）+ high-level（相关 entity 合起来的子图作为 context）
• 索引成本比 Microsoft GraphRAG 降 30-50%、效果接近

LightRAG 的开源实现简单——代码量比 Microsoft 少一半、集成 neo4j 或 NetworkX 都行。

适合：想体验 GraphRAG 但预算紧、数据规模中等的项目。

19.5 用 Neo4j + 向量 DB 组合

另一条路：不用新框架，直接在 Neo4j 图数据库上加 embedding 检索。

Neo4j 5+ 原生支持 vector index——可以在图节点上挂向量。架构：

• 文档解析 + 分块（第 5-6 章）
• LLM 抽实体 + 关系（同 GraphRAG）
• 实体作 Neo4j node、关系作 edge、chunk 作 (:Chunk) 节点连到相关实体
• chunk embedding 建向量 index

Cypher 查询例子：

// 找和"企业版 SSO"相关的 chunk，通过实体多跳扩展
MATCH (c:Chunk)-[:MENTIONS]->(e:Entity {name: '企业版 SSO'})
MATCH (e)-[:RELATED_TO*1..2]->(e2:Entity)
MATCH (c2:Chunk)-[:MENTIONS]->(e2)
WHERE c.embedding <=> $query_vec > 0.7
RETURN c, c2
LIMIT 20

这种"Cypher + vector"的混合查询支持复杂图 + 语义的组合——传统 RAG 做不到。

适合：团队已有 Neo4j 基础、想复用图数据库能力；对新组件学习成本敏感的。

19.6 实体和关系抽取

整条 GraphRAG 的质量根本上取决于实体/关系抽取的质量。

Prompt 工程

典型抽取 prompt：

从下面的文本中抽取实体和关系。

实体类型：产品、功能、角色、组件、概念
关系类型：包含、属于、依赖、对比、替代、影响

输出 JSON:
{
  "entities": [{"name": "...", "type": "...", "description": "..."}],
  "relations": [{"source": "...", "target": "...", "type": "...", "desc": "..."}]
}

文本：{chunk}

Microsoft GraphRAG 的实际 prompt 几百行——每个实体要求抽出 name / type / description / claims（关于实体的独立断言）。信息密度高、LLM 输出也更可用。

实体对齐

同一个实体在不同 chunk 里可能有不同名字——"Enterprise 版"、"企业版"、"Ent edition"。需要实体对齐（entity resolution）：

• 精确匹配 + 规则：小写、去空格、别名表
• embedding 相似度：相似 > 0.9 视为同实体
• LLM 仲裁：LLM 看几个候选、判断是否同一实体

实体对齐做不好——图里一个实体变成几个副本、连接不上、图变支离破碎。这是 GraphRAG 工程的主要难点之一。

关系去重

"SSO 属于企业版" 和 "企业版包含 SSO" 是同一关系的两个方向表达。构图前要归一化：统一方向、统一关系类型名。

实体抽取的质量评估

抽取质量是 GraphRAG 的上限。三个指标做离线评估：

• Entity Precision：抽出的实体里、真正是目标类型的比例（不是误抽的普通名词）
• Entity Recall：应该抽出的实体中、被抽到的比例（漏抽率反面）
• Relation F1：关系的三元组 (source, target, type) 精确匹配的 F1

构造 gold set：挑 20-50 份代表性 chunk、人工标准答案抽实体 + 关系、和 LLM 结果对比。典型质量阈值：Entity F1 > 0.85、Relation F1 > 0.75 可上线。低于此继续 prompt 调优或换模型。

Prompt 迭代的技巧

抽取 prompt 的调优有几个固定操作：

• 逐步给例子：初版 prompt → 跑 10 条看错 → 把错改对作为 few-shot 加回 prompt → 再跑 → 迭代
• 明确边界：LLM 经常抽出"企业"、"系统"这类过于笼统的实体。prompt 加明确排除项："不要抽出诸如'公司''系统''东西'等过于笼统的词"
• 输出 JSON schema：pydantic 的 JSON schema 比自由文本指令更稳健
• 温度 0：抽取是结构化任务、temperature=0 最稳定、不要用 sampling

19.7 什么问题适合 GraphRAG

判断当前项目是否该上 GraphRAG，问几个问题：

场景	chunk RAG	GraphRAG
FAQ 问答	✓	不值得
产品文档问答	✓	部分值得
"整个文档集讲了什么"	✗	✓
法律条文多条款关联	一般	✓
研究文献元分析	一般	✓
代码库多模块关系	部分	✓
客服工单归类	✓	不需要
企业内员工/项目关系	✗	✓

规则：单跳事实问题用 chunk RAG、全局性/多跳/关系型问题用 GraphRAG。多数生产项目两者并用——按 query 类型路由（第 15 章的 routing）。

19.8 GraphRAG 的成本和工程

索引成本

以 1000 篇 × 5000 字的文档集为例：

• 分块：20000 chunk
• LLM 抽实体：每 chunk 一次调用、用 Haiku 级模型约 $20
• LLM 抽关系：同上
• 社区摘要：几十到几百个社区、每个一次调用、约 $10
• 总索引成本：约 $50-100（vs chunk RAG 约 $5 embedding 成本）

规模越大差距越大。1 亿 token 的企业知识库用 Microsoft GraphRAG 索引可能 $10000+。

在线检索成本

在线检索本身不比 chunk RAG 贵多少——图遍历 + 向量检索组合延迟 30-100ms、LLM 推理一次。Global Search 例外——要对多个社区各生成一次部分答案，成本 ×N。

增量更新

图的增量更新比 chunk 索引复杂：

• 新加 chunk → 抽实体 → 可能产生新实体或新关系
• 新实体要做 entity resolution（和已有合并还是独立）
• 新关系可能影响社区结构 → 社区需要重算
• 社区摘要可能过时 → 需要重写

多数 GraphRAG 实现不做细粒度增量——定期全量重建（类似第 8 章 §8.6 的周期性重建）。

19.9 RAPTOR：另一条路径

讨论 GraphRAG 时常被一起提的是 RAPTOR（arXiv:2401.18059，Stanford 2024）——不是图、是递归树。

思路：

• 把所有 chunk 做层次聚类、底层是原 chunk、上层是聚类后的摘要
• 递归往上、每层用 LLM 总结下层、直到顶层几十个摘要覆盖全部
• 检索时同时查所有层——具体问题命中底层 chunk、全局问题命中高层摘要

RAPTOR 和 GraphRAG 的对比：

维度	GraphRAG	RAPTOR
结构	图（实体 + 关系）	树（层次摘要）
索引成本	高（每 chunk 抽实体关系）	中（每层聚类 + 摘要）
检索	图遍历 + 向量	多层并行向量
强项	多跳关系	全局性问题
弱项	成本 / 实体对齐	细粒度事实

多数生产场景里 RAPTOR 比 GraphRAG 更快上手——不需要实体对齐这个头号难点。如果你只需要"全局概括"能力、不需要"关系推理"、RAPTOR 是更经济的选择。

更多新路线

2024-2026 年类似思路的新研究：

• HippoRAG（arXiv:2405.14831）：模拟海马体的 personalized PageRank + 向量
• GraphReader：不预建图、query 时 LLM 实时遍历
• LightRAG（本章 §19.4）的持续演化

这些路线都在探索"结构化 + 语义"的不同折中。生产系统不必追最新——等某条路线有 6-12 个月的社区验证再采用。

19.10 GraphRAG 的可观测性

和 chunk RAG 不同的专门指标：

• entity_count / relation_count：图规模、看增长趋势
• avg_entity_degree：每个实体的平均邻居数、反映图的密度
• orphan_entity_rate：没有任何关系的孤立实体比例、应 < 5%
• community_count_by_level：各层次社区数量、Leiden 发现的结构是否稳定
• global_search_coverage：Global 问题检索到多少社区、过少说明社区摘要漏信息

图质量的人工评估：随机抽 100 条关系、人工判断对不对。这是 GraphRAG 的底线质量门槛。

19.11 GraphRAG 和 Knowledge Graph 的关系

传统 Knowledge Graph（KG）和 GraphRAG 有继承也有差异：

维度	传统 KG	GraphRAG
构建	人工为主 / 规则抽取	LLM 自动抽取
关系类型	预定义 schema（关系 ≤ 100 种）	开放、LLM 自由发现
规模	企业级几十万实体	可扩展到几百万实体
更新	手动为主	LLM 自动
查询	结构化 SPARQL / Cypher	自然语言
准确性	高（人工保证）	中（LLM 抽取有错）

GraphRAG 是 "用 LLM 自动化降低 KG 构建成本" 的实验——牺牲一点准确性换规模和速度。对企业来说、有一张不完美但覆盖大的图、胜过一张完美但只覆盖小部分的图。

19.12 GraphRAG 的争议

GraphRAG 社区有几个持续争议：

争议 1：真的比 hybrid RAG 强吗

部分研究者用对等条件对比——把 chunk RAG + 好的 rerank + 好的 query rewrite 组合起来、很多任务上和 Microsoft GraphRAG 打平。GraphRAG 的价值可能主要在全局问题，对 local 问题未必值得。

争议 2：索引成本值不值得

索引 $10000+ 的成本只有对大企业、高价值知识库才值得。中小项目用 hybrid RAG 性价比更高。

争议 3：长 context + prompt caching 是否取代

long context（第 16 章）让"一次性把整个文档集送进 LLM"成为可能。配合 prompt caching 成本可控。一些场景下这比 GraphRAG 简单。

结论：GraphRAG 是工具、不是答案

没有"应该用 GraphRAG"的普适结论——要看具体问题类型、规模、预算。实操建议：

• 先跑 hybrid RAG、看哪类问题是瓶颈
• 如果瓶颈是全局 / 多跳 / 关系型、考虑 GraphRAG
• 小规模先试 LightRAG / LLM-driven Neo4j
• 大规模再上 Microsoft GraphRAG

19.13 GraphRAG 的实操入门路径

很多团队看到 Microsoft GraphRAG 就直接"上最复杂的"——结果成本超预算、效果没达到预期。理性的入门路径是分阶段验证。

阶段 1：评估是否需要

先看业务里的 badcase——有多少是多跳 / 全局 / 关系型问题？

• < 10% → 继续优化 chunk RAG、不用 GraphRAG
• 10-30% → 考虑 LightRAG 轻量方案

• 30% → 值得上 Microsoft GraphRAG

不要"听说 GraphRAG 好就上"——先量化收益来源。

阶段 2：小规模 POC

选 1000-5000 份代表性文档、用 LightRAG 跑一次完整 pipeline。关注：

• 实体抽取质量（人工抽 100 条看对不对）
• Local search 对具体问题答对率 vs chunk RAG
• Global search 对全局问题答对率 vs chunk RAG
• 总索引成本（美元）和时间

POC 结果决定要不要扩规模。

阶段 3：生产化

POC 效果好再上 Microsoft GraphRAG 全量：

• 选好 LLM（抽取用 Haiku 级、社区摘要用 Sonnet 级）
• 建立实体对齐规则 + 同义词表
• 规划增量更新策略（定期重建 vs 局部更新）
• 把 Local / Global 两种检索路径都接入业务
• 监控图质量指标（entity count、avg degree、orphan rate 等）

阶段 4：和 chunk RAG 并存

生产 GraphRAG 几乎永远和 chunk RAG 并存——query router 按类型分发（第 15 章）。具体问题走 chunk RAG、全局 / 多跳走 GraphRAG。一套 RAG 里两条路径、按需路由。

19.14 图的演化管理与错误溯源

GraphRAG 上线后很快会碰到两个"第二天问题"：图会随时间失效（实体改名、关系废除、新实体进入），以及 GraphRAG 答错时比 chunk RAG 更难排查（错误可能来自抽取 / 对齐 / 图遍历 / 社区摘要里任何一环）。这两件事不处理、GraphRAG 很快就从"更聪明"变成"更难维护"。

图随时间演化的三种变化

• 实体演化：产品"专业版"被重命名为"Pro 版"。旧 chunk 提 "专业版"、新 chunk 提 "Pro 版"——是同一实体的两个时态
• 关系失效："A 模块依赖 B 库" 在 2025 年成立、2026 年 A 模块重构后不再依赖——旧 chunk 和新 chunk 里的关系相冲突
• 新实体进入：新产品 / 新功能 / 新人员不断上线——图必须容纳、且不能产生"看似相同的独立实体"

不处理这些演化、图会越来越脏、最终答案里夹杂过时的关系断言。

三种演化管理策略

策略 A：定期全量重建

最简单粗暴——每周或每月清空图、全部重新抽取。

• 优点：永远和文档最新状态一致、无需复杂版本逻辑
• 缺点：成本高（每次重建数千到数万美元）、重建期间查询不可用
• 适合：文档量中等、业务变化快、预算允许

策略 B：时间戳化的边

每条关系带 valid_from / valid_to 时间戳。查询时按当前时间过滤。

MATCH (a)-[r:DEPENDS_ON]->(b)
WHERE r.valid_from <= date() AND (r.valid_to IS NULL OR r.valid_to > date())
RETURN a, r, b

• 优点：历史查询可用（"2025 年 6 月时 A 依赖什么"）、增量更新友好
• 缺点：LLM 抽取要给出时间戳或用 chunk 的 publish_date 代理、复杂度增加
• 适合：有明确时间语义的领域（法律条款、合同版本、产品迭代）

策略 C：版本化 snapshot

整张图定期拍快照、保留 N 个版本。查询默认走最新、可指定历史版本。

• 优点：能做"对比两个时间点的知识图"分析、回滚快
• 缺点：存储成本翻倍以上
• 适合：合规需求强的领域（金融、法律、医疗）

多数生产项目混合：每月全量重建作主路径 + 关键实体带时间戳作微调。

GraphRAG 错误溯源的五层回路

当 GraphRAG 答错、问题可能出在任何一环。一套系统性的排查顺序：

层级	检查项	工具 / 做法
L1：抽取	抽取结果漏了或抽错某实体/关系？	翻抽取日志、对比原 chunk
L2：对齐	同一实体被当成两个？或不同实体被合并？	查实体 resolution 历史
L3：图结构	关键关系是否在图里？方向是否正确？	Cypher 查实体的邻居列表
L4：检索	query 路由到对的路径（local/global）了吗？召回的社区对不对？	看 retrieval trace
L5：生成	context 有足够证据但 LLM 没用上？	看 prompt 和 output

80% 的 GraphRAG 错答在 L2（实体对齐）——"看起来答的是一个实体其实是另一个"、或"看似无关的两个实体其实应该合并"。

调试必备的三个日志字段

每次 GraphRAG 查询 trace 至少记录：

• 抽取来源：查询涉及的每个实体/关系是从哪个 chunk 抽出来的（source_chunk_id + line_range）
• 对齐历史：这个实体节点是由哪些别名 / 原始出现合并而来（resolved_from: [...]）
• 检索路径：query 走了 local / global 哪条路、命中哪些社区

没这三个字段、GraphRAG 错答基本无法定位——只能靠"重建图重跑一次看是否复现"，效率极低。

错误的优先级：先修哪些

GraphRAG 错答按业务影响分三档：

• 高优先级：事实错（把 A 的属性说成 B 的）—— 可能涉及合规、必须立刻修
• 中优先级：关系缺失（该关联没关联上）—— 功能降级但不危险
• 低优先级：无关关系被召回（答案有噪声）—— 影响体验、可累积修

修单个错不一定值得——如果一类错是抽取 prompt 问题、改 prompt 比改图更经济。调试完要回到源头改，不要只改表现。

19.15 混合 RAG：GraphRAG 与 chunk RAG 的路由与融合

§19.13 入门路径最后一步是 "GraphRAG 和 chunk RAG 并存"——这不是说同时部署两个系统就完事。如何让每次查询走对的路径、两路结果如何融合、失败时如何兜底——这是 GraphRAG 上线后的实际工程挑战，前 14 节没展开。

三种混合模式

路由式：最常见。Query classifier 识别类型、事实型走 chunk RAG、全局型/多跳型走 GraphRAG。延迟最低、成本可控、但依赖 classifier 准确率。

串联式：chunk RAG 先召回 top-k 作为"锚点 chunk"、从锚点提取实体、在 graph 里扩展多跳邻居、最终把 chunk + 图扩展合并送 LLM。适合"先找到起点再探索关系"的场景（复杂产品问题排查、研究文献综述）。

并行式：两路独立跑、各自 top-k、用 RRF（第 13 章）融合。recall 最高、但 GraphRAG 的延迟和成本不可忽略、每次都跑浪费严重——通常只在用户显式要求"深度答案"时启用。

Query classifier 的设计

路由的核心是 classifier。输入 query、输出 chunk | graph | both。三种实现：

• 规则 + 模板：识别关键词（"整体""对比""关系""原因""哪些"）匹配到 graph 类；默认走 chunk。简单、零延迟、覆盖 50-70% 常见 query
• 小模型分类器：用 distilbert 等小模型二分类、训练数据来自历史 query + 人工标注。accuracy 85-92%、延迟 5-10ms
• LLM 判断：直接问 LLM "这个 query 是否需要图推理？"。最灵活但 +200-400ms，不适合高 QPS

生产推荐：规则优先覆盖常见模式、小模型处理剩余、LLM 兜底极端长尾。三层叠加成本可控。

回退机制

混合 RAG 的任一路径都可能失败——GraphRAG 服务宕了、classifier 误判、graph 没相关实体。三级降级：

• L1 路径失败：如 GraphRAG 超时或 error rate > 5%、新请求自动降级到 chunk RAG、带 warning tag
• L2 结果为空：GraphRAG 选的路径但召回为空、自动退到 chunk RAG 重跑
• L3 质量过低：GraphRAG 返回的答案 grounding 分数 < 0.5、触发 chunk RAG 二次验证、取置信高的一路输出

降级代价是延迟翻倍（失败路径 + 成功路径）——但比"给用户一个错答案"好。

性能基线对比

混合 RAG 的典型性能表现（真实 RAG 项目的公开数据、近似）：

模式	延迟 (P50)	延迟 (P99)	单次成本	覆盖 query 比例
纯 chunk RAG	800ms	2s	$0.015	75%
纯 GraphRAG	2.5s	8s	$0.08	60%
路由式混合	900ms	3s	$0.02	90%
串联式混合	2s	5s	$0.04	92%
并行式混合	2.5s	6s	$0.06	95%

路由式是性价比最高的混合策略——以 chunk RAG 为主、遇到 graph 类型才切换、延迟和成本只略升、recall 覆盖面接近并行式。

可观测性的特殊要求

混合 RAG 的监控要分路径拆、否则平均指标掩盖单路问题：

• classifier_accuracy_per_type：classifier 对各类 query 的判准率
• route_p99_latency by route：chunk / graph 各自的 P99
• downgrade_rate：从 L1 → L2 → L3 降级的触发频率
• per_route_cost_share：chunk RAG 和 GraphRAG 在总成本里的占比、和预算对比
• answer_quality_by_route：按路径分的答对率、哪路拉低了整体

没有分路径视图、出问题时只知道"整体质量降了"、无法归因到具体路径。

评估混合 RAG

评估要针对每类 query 跑对应路径的 gold set、不能混在一起跑。典型做法：

• gold_chunk_rag：纯事实类 query、只用 chunk RAG 评估
• gold_graphrag：多跳/全局类 query、只用 GraphRAG 评估
• gold_mixed：真实流量分布采样、走完整混合 pipeline 评估

最终业务看 gold_mixed——它反映真实用户体验。分路径 gold 用于 debug。

常见坑

• 只监控整体 recall：混合 RAG 整体 recall 好看、其实 chunk 那路掉了 5 点、被 graph 那路拉起来、下次 graph 也掉时就崩
• classifier 训练集偏斜：用历史 query 训 classifier、但历史 query 分布和未来流量不同、尤其新产品上线后
• GraphRAG 降级后没告警：GraphRAG 持续 failing、系统在自动降级 chunk RAG、但团队不知道、GraphRAG 等于白建
• 并行式打不住成本：默认并行跑两路、流量上来成本三倍、没有路由 / 降级的保护

何时真的需要混合

和 §19.7 呼应——并不是所有 RAG 都要混合。判断是否值得：

• chunk RAG 已跑通且稳定 6+ 个月 → 可以考虑加 GraphRAG
• badcase 归因显示 "多跳 / 全局" 类占比 > 15% → 值得加
• 团队有 ML + 运维能力维护两条路径 → 否则复杂度压过收益
• 业务能承受 +20-50% 的 RAG 基础设施成本

满足这四条才上混合。否则先把 chunk RAG 做到极致、比过早上 GraphRAG 收益高。

19.16 Community 摘要的质量工程：global search 的命根

§19.3 Microsoft GraphRAG 的核心创新是 community 摘要 + global search——对"整个文档集说了什么"这类问题、比 chunk RAG 强一个数量级。但这套机制的命根是 community 摘要的质量。摘要写得差、global search 就只是"另一种普通检索"、失去 GraphRAG 的独特价值。这一节把摘要这一步的工程细节讲清楚——它往往被低估、但却决定 global search 能否真正"全局"。

Community 摘要是什么

• 一个 community 是一组紧密相关的实体（关系密度高）
• 每个社区的 摘要 是 LLM 根据这些实体 + 关系生成的 200-500 字描述
• Global search 时 query 对所有社区摘要跑向量检索、每个命中的社区各自产生部分答案、最后汇总

摘要是社区的"自然语言门面"——全局查询看的是摘要、不是原始实体关系。摘要好、global search 能抓到"整份数据的宏观脉络"；摘要差、抓到的是"几十个无关的一句话"。

好摘要的四个特征

• 信息密度高：200-500 字里涵盖 5-15 个核心实体和它们的关系、不堆砌琐碎
• 主题聚焦：一段摘要讲一个主题、不是实体列表串联
• 可检索性强：摘要里出现的关键词符合用户 query 的表达——便于向量和 BM25 召回
• 层次感：Level-0 摘要是高层概括、Level-2 摘要是具体事实——不同 query 命中不同层

写不出这四点的摘要等于没写。

层次化摘要的组织

Microsoft GraphRAG 用 Leiden 算法的多层次社区——每一层都生成摘要、query 按复杂度命中不同层：

Level-0 (粗): 本文档集涉及 AI 基础设施、包括向量库、LLM、Agent 架构三大主题...
Level-1 (中): 向量库部分涵盖 Qdrant、Milvus、pgvector 三款方案的选型...
Level-2 (细): Qdrant 是 Rust 实现、支持 HNSW 索引、适合百万级...

三层摘要对应三类 query：

• "这份数据整体讲什么" → 命中 Level-0
• "向量库有哪些选择" → 命中 Level-1
• "Qdrant 的索引算法" → 命中 Level-2

Prompt 设计

社区摘要的 prompt 是 GraphRAG 里写得最多的 prompt——几百行不夸张。核心要素：

你是一个技术领域的分析师。下面是一组紧密相关的实体和关系、请写一段
200-400 字的摘要、描述这些实体涉及的主题。

要求：
1. 用概括的语言、不要罗列实体名
2. 重点突出：核心主题、关键实体间的关系、这个主题的代表性发现
3. 避免冗余：同一实体不重复提、同一关系只说一次
4. 保留可检索的关键词：实体名、技术术语、产品名

实体:
{entities}

关系:
{relations}

示例好摘要:
{few_shot_good_examples}

示例坏摘要（不要这样写）:
{few_shot_bad_examples}

输出 JSON: {"summary": "...", "key_topics": [...], "core_entities": [...]}

Few-shot 示例是关键——LLM 对"好摘要"的直觉没经过这个 prompt 是不一致的。人工标 5-10 个好坏例子、LLM 能稳定学到。

评估摘要质量

评估社区摘要的独立指标（不是 global search 最终答对率、是摘要本身）：

• Coverage：社区里的核心实体 / 关系是否都被提及、人工抽检比例
• Conciseness：摘要长度 / 信息量比例、超长低密度摘要扣分
• Topic coherence：多个评估员读摘要能否一致识别主题
• Retrievability：用模拟 query 检索、摘要能否被命中

人工抽检 100 个摘要、评这四维——摘要质量低于阈值触发重新生成。

摘要的更新策略

图在变（§19.14）、摘要也要跟着变。两种更新策略：

• 完全重生成：图结构变了、所有摘要重写。成本高（每个社区一次 LLM 调用）、但质量最好
• 增量更新：只对变化大的社区重写、小变化的保留。典型触发：社区实体数变化 > 20% 或关系数变化 > 30%

生产推荐：每月一次完全重建 + 日级增量——平衡成本和质量。

摘要的常见坑

• 摘要过短：50 字的摘要没信息——向量检索命中率低、无法覆盖社区全貌
• 摘要像实体列表："涉及 A、B、C、D、E 实体"——LLM 偷懒、没有抽象、没有主题
• Level-0 摘要不够高层：应该是"全数据集概览"、写成"某具体主题"——global 命中效果差
• 没有层次区分：三层摘要写得一样、层次化没起作用
• 摘要不更新：数据变了摘要没变、global search 答的是过期信息

摘要 vs RAPTOR 的异曲同工

§19.9 讲过 RAPTOR 的递归层次摘要——其实和 GraphRAG 的社区摘要结构同构：

• RAPTOR：用层次聚类组织、从 chunk 层层向上摘要
• GraphRAG：用图社区聚类组织、从实体层层向上摘要

两者都在解决同样的问题："对大规模数据的宏观理解"。选哪个看：

• 有明确实体关系结构 → GraphRAG 社区摘要
• 主要是非结构化文本 → RAPTOR 层次摘要
• 两者结合：高层用 RAPTOR 聚类、低层用 GraphRAG 关系——极少数大项目会试

摘要质量的投入产出

Microsoft GraphRAG 的 community 摘要成本占整个索引成本的 20-30%——不是小数目。但这笔钱花得对：

• 好摘要让 global search 真正"全局"
• 好摘要让人工审核员能用简短时间理解每个社区
• 好摘要是 GraphRAG 相对 chunk RAG 的核心差异化

省摘要钱 = 失去 GraphRAG 的独特价值 = 不如直接用 chunk RAG。所以要么认真做摘要质量、要么不上 GraphRAG——中间态是浪费。

19.17 Ontology 设计：实体和关系类型的体系建构

§19.6 讨论了实体抽取的 prompt 工程——但跳过了一个上游决策：实体和关系应该有哪些类型？这叫 ontology（本体论）。看起来抽象、但实际是 GraphRAG 最关键的 upfront 决策——ontology 错了、后续所有抽取 / 检索 / 归因都偏了。传统 KG 项目在 ontology 上投入巨大——GraphRAG 让这块变轻了（LLM 能学），但不等于不重要。

Ontology 是什么

在 GraphRAG 里、ontology 是：

• 实体类型清单：哪些类型是实体（人、组织、产品、概念、地点、事件……）
• 关系类型清单：实体间有哪些关系（属于、包含、依赖、对比、替代、影响……）
• 约束规则：哪些类型间可以有哪些关系（"人" 可以 "属于" "组织"、但不能 "包含" "产品"）

三种 ontology 路线

路线 A：开放 ontology（Open）

LLM 自由生成实体和关系类型、不预定义：

• 优点：灵活、覆盖新概念
• 缺点：同义类型冗余（"依赖" 和 "需要" 被 LLM 视为不同关系）、图质量低

Microsoft GraphRAG 默认路线。

路线 B：预定义 ontology（Closed）

业务专家提前定义所有实体 / 关系类型、LLM 只能从列表选：

• 优点：一致性高、可复用
• 缺点：新概念覆盖不到、设计成本高

传统 KG / 法律 / 医疗领域常用。

路线 C：混合 ontology（Hybrid）

预定义核心类型 + 允许 LLM 生成长尾类型、定期合并进核心：

• 优点：兼顾覆盖和一致性
• 缺点：实现复杂、需要持续维护

2024+ GraphRAG 的推荐路线。

粒度决策

Ontology 的粒度是核心取舍：

粒度	实体类型示例	优点	缺点
粗	实体 / 概念 / 关系	简单、稳定	区分度低
中	人 / 组织 / 产品 / 事件 / 概念	平衡	普适
细	CEO / 客户 / 员工 / 部门 / 产品线 / SKU	业务贴合	维护重

经验：10-30 个实体类型 + 15-30 个关系类型是甜点。少于 10 过粗、超过 50 过细。

领域特化

不同领域的 ontology 差异巨大：

技术文档：

• 实体：产品、组件、技术术语、错误码
• 关系：依赖、替代、兼容、弃用

法律：

• 实体：法律条款、案例、当事人、法院
• 关系：引用、反驳、修正、适用于

医疗：

• 实体：疾病、症状、药品、治疗、基因
• 关系：引起、治疗、副作用、拮抗

金融：

• 实体：公司、产品、人员、市场、指标
• 关系：持股、合作、竞争、上下游

起步时可以参考领域已有的 KG schema（如医疗的 SNOMED-CT、法律的 Legal RDF）——别从零设计。

设计流程

构建 ontology 的推荐流程：

1. 业务 workshop：3-5 位领域专家、列出关键实体和关系
2. 初版规范：50 个实体 + 30 个关系、写成表格或 RDF
3. LLM 辅助扩展：让 LLM 对样本文档抽取、对比预定义列表、补充遗漏
4. 试跑验证：小样本 100 篇文档、跑抽取、人工审查一致性
5. 迭代：根据抽取结果调整列表（合并同义、拆分过粗）
6. 固化 v1：投入生产、监控

初版 2-4 周完成。后续每季度 review 一次。

Ontology 的演化

业务在变、ontology 也要变：

• 新产品上线：加新产品实体类型
• 法规更新：加新关系类型
• 同义识别："依赖" 和 "需要" 合并为一个

版本化很重要——每次变更带版本号、旧图带旧版本 tag、新抽取用新版本、查询时可指定版本。

{
    "ontology_version": "v2.3",
    "entity_types": [...],
    "relation_types": [...],
    "changelog": [
        {"ver": "v2.3", "change": "合并 '依赖' 和 '需要' 为 'depends_on'"},
        {"ver": "v2.2", "change": "新增实体类型 '合规要求'"}
    ]
}

Ontology 的约束规则

除了列表、约束让图质量更高：

constraints:
  - source_type: Person
    relation: works_at
    target_type: Organization  # 只允许人 -工作于- 组织
  
  - source_type: Product
    relation: depends_on
    target_type: [Product, Technology]  # 产品可依赖产品或技术
  
  - source_type: Person
    relation: contains  # 禁止人 "包含" 某对象
    target_type: null

LLM 抽取时违反约束 → 该关系被拒绝 / 标为 pending review。

实体对齐 (entity resolution) 的上游

§19.6 讲过实体对齐——但好的 ontology 能大幅减少对齐需求：

• 预定义类型让同类实体走同一 resolution rule
• "企业版" 和 "Enterprise" 通过产品类型的 alias 表快速合并
• LLM 在预定义类型下更容易识别 "这是同一个实体"

这就是ontology 和实体对齐的协同——共同决定图质量。

Ontology 的 prompt 注入

把 ontology 注入 LLM 抽取 prompt：

请从文本中抽取实体和关系。

允许的实体类型：
- 产品（Product）
- 功能（Feature）
- 技术（Technology）
- 公司（Company）

允许的关系类型：
- 包含（contains）: 产品 → 功能
- 依赖（depends_on）: 产品 → 技术 / 产品
- 开发（developed_by）: 产品 → 公司

请严格按列表选、不要自由创造。

文本：{chunk}

LLM 按列表抽、类型一致性显著提升。

Ontology 的反模式

• 太细：50+ 实体类型、LLM 无法稳定分类、一致性反而差
• 太粗：5 个类型、区分度不足、检索精度低
• 不更新：业务变了 ontology 没跟、抽取偏差累积
• 没有约束规则：类型有但 LLM 乱连、图质量差
• 英中混用：类型名混用中英、"Person" 和 "人" 指同一类但对不上

Ontology 的投入回报

构建 + 维护 ontology 的投入：

• 初版：2-4 人周
• 维护：每季度 1-2 人天
• 和 LLM 抽取联动：prompt 里加 ontology 约束、几行代码

收益：

• 抽取一致性从 70% 提到 90%+
• 实体对齐成本降 50%+
• Community 检测质量提升
• 下游查询的归因明确

先投 ontology、再优化抽取 prompt——顺序反了事倍功半。

19.18 GraphRAG 的专门评估：普通 eval 框架不够

§20 的评估框架基于 chunk RAG 设计——对 GraphRAG 部分适用、部分不够。GraphRAG 有三层独有的质量（抽取质量、图结构质量、社区摘要质量）——每层都需要专门评估。ragas / trulens 等工具都不覆盖这些——必须自建。这节给 GraphRAG 评估的专门方法。

为什么普通 eval 不够

普通 eval 只测最终答案——GraphRAG 要分层评估找到根因。

实体抽取的评估

Gold set 构造：

[
  {
    "text": "企业版支持 SSO 和 LDAP、由身份团队维护",
    "expected_entities": [
      {"name": "企业版", "type": "product"},
      {"name": "SSO", "type": "feature"},
      {"name": "LDAP", "type": "feature"},
      {"name": "身份团队", "type": "team"}
    ]
  }
]

指标：

• Entity Precision：抽出的实体里、对的比例
• Entity Recall：应抽的实体里、抽到的比例
• Type Accuracy：类型标对的比例

目标：三者都 > 85%。

关系抽取的评估

关系是三元组 (subject, predicate, object)：

[
  {
    "text": "企业版支持 SSO 和 LDAP、由身份团队维护",
    "expected_relations": [
      {"s": "企业版", "p": "supports", "o": "SSO"},
      {"s": "企业版", "p": "supports", "o": "LDAP"},
      {"s": "身份团队", "p": "maintains", "o": "企业版"}
    ]
  }
]

指标：

• Relation F1：三元组精确匹配
• Relation 方向：s 和 o 是否颠倒（常见错误）

Relation F1 > 75% 就不错——比 entity 难、不要苛求。

图结构质量

图本身的统计指标：

• 节点数 / 边数：量级、和预期对比
• 平均度：每个节点平均连几条边、太低说明图稀疏
• Orphan rate：孤立节点（度 = 0）比例、应 < 5%
• 最大连通分量占比：图是否一个大块还是碎成多个小块
• 度分布：是否 power law（少数节点高度连接、多数节点少连接）

不健康的图：

• Orphan rate 20%：很多实体"孤立"、说明抽取或 resolution 漏了
• 最大连通分量 < 50%：图太碎、global search 覆盖低

Community 摘要的评估

§19.16 讨论过——指标：

• Coverage：摘要覆盖社区核心实体的比例
• Conciseness：信息密度 = 关键点 / 总字数
• Topic coherence：读摘要能否一致识别主题（人工或 LLM-judge）
• Retrievability：模拟 query 检索社区摘要的命中率

每月抽样 50-100 个社区做人工 review。

Global search 的评估

Global search 的 gold set 和普通 query 不同——要 全局性问题：

[
  {
    "query": "这个产品集合的整体架构思路是什么",
    "expected_themes": ["分布式", "事件驱动", "多租户"],
    "expected_top_level_communities": ["架构概览", "核心服务"]
  }
]

指标：

• Theme coverage：答案提到的核心主题数 / 期望数
• Cross-community consistency：多个社区的贡献在答案里协调吗
• Depth vs breadth 平衡：答案既概览又有关键细节

普通 recall 不适用——全局问题没有单一 gold chunk。

Multi-hop 推理的评估

GraphRAG 的卖点之一——多跳推理：

[
  {
    "query": "影响企业版 SSO 升级的上下游团队有哪些",
    "expected_reasoning_chain": [
      "企业版 SSO -> 由 身份团队 维护",
      "身份团队 -> 依赖 基础设施团队 的 IAM 服务",
      "企业版 SSO -> 影响 客户成功团队 的 onboarding 流程"
    ],
    "expected_entities": ["身份团队", "基础设施团队", "客户成功团队"]
  }
]

指标：

• Multi-hop correctness：推理链是否正确
• Relevant entity recall：应出现的实体出现比例
• No spurious entities：没出现不相关实体

Multi-hop 是 GraphRAG 和 chunk RAG 最大差异——专项评估才能测出价值。

和 chunk RAG 的对比评估

GraphRAG 的核心问题："比 chunk RAG 好多少"——必须双系统对比：

def compare_gr_and_chunk(gold_set):
    results = {"graphrag": [], "chunk_rag": []}
    for query in gold_set:
        gr_answer = graphrag.query(query)
        cr_answer = chunk_rag.query(query)
        
        gr_score = evaluate(gr_answer, query.expected)
        cr_score = evaluate(cr_answer, query.expected)
        
        results["graphrag"].append(gr_score)
        results["chunk_rag"].append(cr_score)
    
    # 按 query 类型分桶看
    for qtype in ["fact", "multi-hop", "global"]:
        gr_mean = mean(r for r, q in zip(results["graphrag"], gold_set) if q.type == qtype)
        cr_mean = mean(r for r, q in zip(results["chunk_rag"], gold_set) if q.type == qtype)
        print(f"{qtype}: GraphRAG={gr_mean:.2f}, ChunkRAG={cr_mean:.2f}, Diff={gr_mean-cr_mean:+.2f}")

典型结果：

• Fact queries: GraphRAG 0.85 vs ChunkRAG 0.87（GraphRAG 略差）
• Multi-hop: GraphRAG 0.72 vs ChunkRAG 0.43（GraphRAG 大胜）
• Global: GraphRAG 0.78 vs ChunkRAG 0.35（GraphRAG 大胜）

按 query 类型分析才看出 GraphRAG 的真实价值——整体均值可能被某类拉平。

评估的资源投入

GraphRAG 评估比普通 RAG 重：

• Gold set 构造：500-2000 条多类型、2-4 人周
• 人工 review（社区摘要 / 多跳）：每月 2-3 人天
• 自动化 pipeline：2-3 人周

高门槛——是否值得投看 GraphRAG 对业务多重要。不投入评估的 GraphRAG 几乎一定失败——因为没数据证明比 chunk RAG 好、团队无法说服自己坚持投入。

评估的运营节奏

• Daily：gold set 自动回归、抓 regression
• Weekly：per-query-type 细分指标趋势
• Monthly：社区摘要抽样人工 review
• Quarterly：Gold set 扩充、cover 新 badcase

这个节奏让 GraphRAG 质量可控演化——不是"投入后放任"。

评估工具链

自建工具（ragas / trulens 不支持 graph）：

• Entity/relation evaluator：基于 gold set 的精确匹配
• Graph stats dashboard：Grafana 看图指标
• Community summary reviewer：UI 让人工 review
• GR vs ChunkRAG comparison UI：对比两系统对同一 query 的答复

初期建 2-3 人月。看似多——GraphRAG 没这些等于盲跑。

GraphRAG 评估的反模式

• 只测最终答案：好答案也可能是 chunk RAG 的功劳、不是 graph 的
• 不分 query 类型：fact / multi-hop / global 混在一起、均值掩盖差异
• 忽略图结构：最终答案好但图质量差、长期不可持续
• 不对比 chunk RAG：不知道 GraphRAG 有没有意义
• Gold set 太小：100 条 gold 的结论不够信

GraphRAG 是否值得的最终 check

GraphRAG 上线半年后、用评估数据回答：

• Multi-hop / global query 占业务的比例？（> 15% 才值）
• GraphRAG 在这些 query 上比 chunk RAG 好多少？（> 20 点 recall/NDCG 才值）
• 投入的人力和成本是否可持续？
• 业务侧是否感知到质量提升？

四项都 yes——继续。某项 no——考虑退回纯 chunk RAG、专注做好 hybrid。

不要"试了 GraphRAG 就必须留着"——评估数据说话。

19.19 知识图谱的可视化与人工编辑

前面讲了 GraphRAG 的抽取 / 评估 / 运营——但一个被忽视的工程：让人能看、能改 graph。GraphRAG 的 graph 是 LLM 抽出来的、不完美——需要人工 review 和 fix。可视化 + 人工编辑界面是这个过程的基础设施——没它、人工治理成本高、质量提升慢。这节讲 knowledge graph 的 UI 工程。

为什么需要可视化

没可视化——graph 是抽象数据结构、人无法有效 interact。

可视化工具选型

几种选择：

• Neo4j Browser：Neo4j 自带、最成熟、交互好
• Gephi：专业图可视化、学术界主流
• Cytoscape：科学研究用、灵活但陡峭
• D3.js / vis.js 自建：完全自定义、投入大
• 商业工具：Linkurious / Graphistry、企业级

推荐：Neo4j Browser 作起点（不管后端是不是 Neo4j、Cypher 导出就能用）、大规模后自建。

可视化的核心功能

必备：

• 节点和边的渲染：实体点、关系边、按类型着色
• 交互：点击节点展开邻居、拖拽、缩放
• 搜索：按名字找实体、定位
• 筛选：按类型 / 属性 filter
• 局部视图：以某实体为中心、显示 N 跳邻居（防整图爆炸）

高级：

• 社区着色：不同 community 不同颜色
• 时间轴：图随时间变化的 playback
• 对比模式：两版 graph 的 diff
• 热力图：被检索频率高的节点放大

人工编辑的典型场景

场景 1：修错抽取

LLM 把 "企业版" 和 "企业用户" 识别为同一实体——明显错。人工：

• 打开 "企业版" 节点、看它的 alias 列表
• 移除 "企业用户"
• 创建新 "企业用户" 节点

场景 2：补遗漏关系

抽取漏了 "企业版 → 依赖 → SSO 模块" 这条关系。人工：

• 找到两个节点
• 拖拽连接
• 标关系类型

场景 3：合并重复实体

"企业版" 和 "企业 版"（多个空格）被当成两个实体。人工：

• 选中两个节点
• 点 "merge"
• 选 primary 名、其他作 alias

场景 4：拆分过度合并

LLM 把 "iPhone 15" 和 "iPhone 16" 都归为 "iPhone"——粒度太粗。人工：

• 选中节点
• 点 "split"
• 按属性分到不同节点

人工编辑的版本控制

Graph 像代码——改动要 track：

{
  "edit_id": "edit-abc",
  "timestamp": "2026-04-25T10:00",
  "editor": "alice@example.com",
  "action": "merge_entities",
  "before": ["entity-456", "entity-789"],
  "after": "entity-456",
  "reason": "duplicate entities from LLM extraction"
}

每个编辑记：

• 谁编辑的
• 什么时候
• 什么动作（create/update/delete/merge/split）
• before / after 状态
• 理由

类似 git commit——可追溯、可回滚。

和自动抽取的协同

人工编辑不是替代 LLM 抽取——是协同：

• Pipeline 1：LLM 从新文档抽取（覆盖大多数）
• Pipeline 2：人工 review 争议 case（每月几百条）
• Pipeline 3：人工编辑修 bug（每周几十条）

三者合流到同一个 graph——但要处理冲突：

• LLM 抽出 "企业版 → 依赖 → SSO"
• 人工改成 "企业版 → 使用 → SSO"
• 后续 LLM 从新文档再抽 "企业版 → 依赖 → SSO"——覆盖人工编辑？

解决：

• 人工编辑优先：打标签 manually_edited: true、自动抽取不覆盖
• Conflict resolution：定期 review 冲突、人工判决
• 训 LLM prompt：把人工修正反馈到 prompt、下次抽得准

审批流程

不是任何人都能编辑关键 graph：

• 内部 graph（消费级）：团队成员都能编辑
• 生产关键 graph：双人 review + approval
• 合规敏感 graph（医疗 / 法律）：专家审批 + 审计

大改动走流程——不能随便改。

编辑 UI 的工程

UI 实现建议：

• Web app：React / Vue、前端渲染 graph
• 和后端解耦：UI 调 Graph API（增删改查实体 / 关系）
• 实时协作：多人同时看 / 编辑（类似 Figma）
• 搜索和过滤：大规模 graph 必须能找到目标

构建复杂 UI 要 1-3 人月——但持续用几年、ROI 高。

和 GraphRAG 评估的联动

§19.18 讲了 GraphRAG 评估——可视化和编辑 UI 是评估的实施工具：

• Badcase 归因到某个错误节点 / 边
• UI 里立即看到、立即改
• 改完重跑 eval 看改进

没 UI——评估发现问题后不知道怎么改、改不快。

治理的组织责任

Graph 治理涉及：

• Graph owner：定治理策略、批准重要变更
• Domain experts：提供领域知识、审 review
• Engineers：工具、pipeline
• Compliance：审 audit、合规要求

各角色协作——graph 是团队工作、不是 LLM 一家之言。

可视化的隐私

Graph 里含敏感信息——可视化也要考虑隐私：

• 权限控制：谁能看 graph、谁只能看子图
• 脱敏：非授权人员看的 graph 里、PII 要 mask
• 审计：谁看了 graph 的哪部分

内部工具也有合规要求——不能"内部就随便看"。

大规模 graph 的可视化挑战

千万实体的 graph——不能全部渲染：

• 局部视图：每次只显示几百个节点
• 聚合视图：缩放时聚合成 community
• 搜索优先：用户搜索驱动、不是"打开就全图"
• 分层采样：按重要性采样显示

不做这些——浏览器会挂、用户体验差。

Interactive vs static

两种模式：

• Interactive：探索、实时查询、拖拽编辑（日常用）
• Static export：PDF / PNG 快照、发邮件 / 写报告

两者都要支持——专业用户要 interactive、管理层要 static。

开源工具生态

2026 年的 graph 可视化工具：

• Neo4j Bloom：Neo4j 商用可视化、功能强
• Memgraph Lab：Memgraph 的 UI
• Graphviz：老牌、static 图
• Graphistry：GPU 加速大图
• ObservableHQ 模板：D3 基础的交互图

选型看规模 / 预算 / 定制需求——没"银弹"。

可视化的 ROI

建 graph 可视化工具的投入：

• 基础功能：1-2 人月
• 协作 / 审批：1 人月
• 持续维护：每季度 1 人周

收益：

• 人工编辑效率 × 5-10
• 业务理解 graph 价值
• 事故响应快
• 合规审计顺

小团队用 Neo4j Browser 够用、大团队投自建。

一个反模式：只有技术人能看

很多 GraphRAG 项目的 graph 只有工程师看得懂——Cypher 查询、命令行。业务方看不到——价值不被认可。

好工程：给业务方也能用的 UI——不需要懂 Cypher、只需要懂自己的业务。

可视化和文档治理的连接

Graph 里的某个实体错——实际是某份文档描述错。可视化里：

• 点击节点
• 显示 "这个实体来自哪些文档"
• 链接到文档
• 业务方看到、去修文档

这是 graph 层的可视化驱动文档层的治理——闭环。

Graph UI 的未来

AI 协助 graph 编辑：

• 自然语言编辑："把企业版和专业版归为兄弟关系"—— AI 执行
• 异常检测 UI：AI 标红可能错误的节点/边
• 建议合并：AI 发现重复、建议用户 review

这些方向在 2025-2026 年逐步成熟——值得关注。

作 GraphRAG 成熟度的标志

能独立维护 graph 可视化 + 编辑工具的团队 vs 只靠 LLM 自动抽取的团队：

• 前者：graph 质量持续提升、业务认可
• 后者：graph 质量停在 LLM 初始水平、业务侧怀疑

投资 UI 工具 = 投资 GraphRAG 的长期价值。

19.20 跨书关联：图与向量的融合

图检索和向量检索的融合是 2024-2026 年 IR 领域的热点。传统向量 DB（Qdrant、Milvus）也开始加图能力、图 DB（Neo4j、ArangoDB）也加向量能力。两条路线正在融合。

《LangGraph 设计与实现》讨论的 agent graph 和本章的 knowledge graph 是两种不同的图——一个是控制流图（agent 怎么决策）、一个是数据图（知识怎么组织）。大型 AI 系统里两者并存：agent 在 knowledge graph 上"游走"查询、做推理决策。

19.21 本章小结

1. chunk RAG 不擅长全局 / 多跳 / 关系型问题、GraphRAG 补这个短板
2. GraphRAG 核心组件：实体抽取 / 关系抽取 / 图构建 / 社区发现 / 社区摘要 / 混合检索
3. Microsoft GraphRAG 是 SOTA 但索引贵；LightRAG 是轻量替代；Neo4j + vector 是复用现有栈的方案
4. 实体对齐是工程核心难点——做不好图支离破碎
5. 适用判断：单跳事实用 chunk RAG、全局 / 多跳 / 关系型用 GraphRAG
6. 多数项目不需要 GraphRAG——先跑 hybrid RAG 看瓶颈再决定
7. GraphRAG 是 LLM 自动化降低传统 KG 构建成本的实验

下两章讲 RAG 评估和成本延迟优化——进入第六部分生产化话题。