GraphRAG 实战架构：实体抽取、社区发现和查询模式

从 TextUnit、实体关系抽取、社区发现、Global Search、Local Search 到 DRIFT Search，拆解 GraphRAG 的生产级实现路径。

GraphRAG 不是“给 RAG 加一个图数据库”。它的价值在于把文档集合中的实体、关系和主题社区显式化，让系统能回答跨文档综合、全局归纳和关系推理类问题。

工程判断

如果问题主要是“在某份文档里找答案”，Hybrid RAG 更简单；如果问题是“跨很多文档总结结构、关系和趋势”，GraphRAG 才值得引入。

架构总览

GraphRAG 的索引链路通常比普通 RAG 更重。它不仅要切块和向量化，还要抽实体、抽关系、建图、聚类社区、生成社区摘要。每一步都会引入成本和误差。

索引层设计

层级	产物	作用
TextUnit	带来源、页码、标题、权限的文本单元	作为抽取和引用的最小证据。
Entity	人、组织、产品、系统、指标、概念	支撑实体定位和关系扩展。
Relationship	实体之间的边和关系描述	支撑多跳问题和关系推理。
Community	图上的主题社区	支撑全局归纳和主题摘要。
Report	社区摘要和关键证据	降低查询时遍历全图的成本。

TextUnit：GraphRAG 的最小证据

TextUnit 不等于普通 chunk。普通 chunk 主要服务召回；TextUnit 还要服务实体抽取、关系抽取和引用回放。

{
  "id": "tu_1024",
  "document_id": "architecture-review-2026",
  "section": "Storage Layer",
  "text": "The object store keeps original files while the vector index stores derived embeddings.",
  "source": "architecture-review.md",
  "permissions": ["team:platform"],
  "created_at": "2026-07-06"
}

一个常见错误是先抽实体再补来源。生产系统应该反过来：先确保 TextUnit 可追溯，再从 TextUnit 派生实体和关系。

实体与关系抽取

抽取阶段要关注三个问题：一致性、去重、置信度。

实体抽取不只识别名词，还要识别实体类型、别名、上下文和来源。比如 RAG 可以是技术概念，也可能是某个内部项目名。

关系抽取要保留关系类型和证据句。不要只存 A -> B，要存为什么存在这条边，以及来自哪个 TextUnit。

去重需要别名表、embedding 相似度和规则共同工作。OpenAI、Open AI、OpenAI Inc. 可能是同一实体，也可能在不同语境中不是。

社区发现

社区发现的目标是把大图分成多个主题簇。每个社区可以生成一份 summary report，用来回答全局问题。

社区报告不是最终答案，而是查询时的中间索引。它应该保留：主题、关键实体、关键关系、证据 TextUnit、摘要版本和更新时间。

三种查询模式

模式	适合问题	检索对象
Global Search	“这批文档整体说明了什么？”	Community Reports
Local Search	“某个实体和哪些概念相关？”	Entity neighborhood
DRIFT / Hybrid	“问题既需要局部证据又需要全局背景”	Reports + TextUnits + Graph

Global Search

Global Search 适合全局总结。比如：

过去半年 RAG 系统最主要的质量问题是什么？

这类问题不适合只召回 Top-K chunk，因为答案可能分散在很多文档中。更好的方式是先检索相关社区报告，再让模型在报告和证据 TextUnit 上综合。

Local Search

Local Search 适合围绕实体展开。比如：

GraphRAG 和 Hybrid Retrieval 在我们的知识库架构中分别解决什么问题？

系统可以先定位 GraphRAG、Hybrid Retrieval 两个实体，再扩展邻居实体和关系，最后补充原始 TextUnit 作为引用。

更新策略

GraphRAG 最大的工程成本在更新。普通 RAG 更新一个文档只需要重切块、重 embedding；GraphRAG 还可能影响实体、关系、社区和报告。

文档变更后，先定位受影响 TextUnit。

只对受影响 TextUnit 重新抽实体和关系。

合并实体和关系时保留版本号。

如果社区结构变化小，只重写受影响社区报告。

定期离线重建全图，校正长期漂移。

什么时候不要用 GraphRAG

场景	原因
文档少、结构简单	普通 Hybrid RAG 成本更低。
主要问题是精确查找	BM25 + reranker 更直接。
数据更新非常频繁	图和社区报告维护成本高。
没有评测集	很难判断 GraphRAG 是否真的更好。

实用结论

GraphRAG 是一种“用更重索引换更强综合能力”的架构。先把 TextUnit、权限、引用和评测做好，再考虑实体关系和社区报告；否则图会变成一个很贵但不可验证的黑盒。

讨论

继续讨论这篇笔记

有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。

GraphRAG 实战架构：实体抽取、社区发现和查询模式

继续讨论这篇笔记

On this page