GraphRAG 是什么
在向量检索之外，把文档里的实体与关系抽出来建成图：人、产品、条款、设备之间的连接成为可遍历的边。检索时先用问题定位到涉及实体，再沿关系扩一到两跳取出子图，把子图转成文本片段，与向量召回的段落一起送进模型。它擅长两类问题：需要多跳串联的，以及需要在整批语料上做全局综述的。代价是构建与维护成本高，而抽取质量直接决定了它的上限。
基本信息
| 构建方式 | 用模型或规则抽取实体与关系，写入图数据库，如 Neo4j |
|---|---|
| 检索方式 | 问题先定位实体，再沿关系扩一跳或两跳取子图 |
| 优势场景 | 多跳问答与全局综述类问题，向量检索在这些场景容易断链 |
| 主要代价 | 抽取与人工校验成本高，文档更新后需要增量维护图 |
| 抽取质量 | 实体消歧与关系类型设计是决定效果的关键环节 |
| 与向量关系 | 互补而非替代，常见做法是按问题类型路由或两者结果合并 |
典型使用场景
- 多跳问答：答案需要串联多个事实，例如某人的上级还负责哪些项目
- 组织与股权关系查询：层级、关联方、实际控制人这类结构化关系
- 合同与制度条款引用链：条款互相引用，单靠文本相似度难以理清
- 故障根因分析：设备、组件、告警之间的关联关系便于逐跳排查
- 全局综述问题：需要跨整个语料概括主题脉络，而非找到某一个片段
子图检索示例
子图检索示例
MATCH (e:Entity {name: $name})-[r]-(n:Entity)
RETURN e.name, type(r), n.name, r.weight
LIMIT 50;
// 取回子图后转成文本片段，与向量召回的段落一起送入模型
// 扩跳数控制在一到两跳：跳数越多噪声越大，提示词也越长
// 高权重关系优先返回，避免弱关联把上下文挤满环节与质量关键
| 环节 | 主要成本 | 质量关键点 |
|---|---|---|
| 实体与关系抽取 | 模型调用与人工抽检 | 抽取提示词的类别定义是否覆盖业务术语 |
| 实体消歧 | 人工核对与规则维护 | 同一实体不同写法必须归并，否则图被切碎 |
| 关系类型设计 | 前期设计投入 | 类型过细难抽取，过粗则失去区分度 |
| 图更新 | 增量抽取与校验 | 文档变更后图未更新，答案会停留在旧关系上 |
| 子图转文本 | 上下文长度 | 只保留与问题相关的路径，避免整张子图塞进提示词 |
GraphRAG 不替代向量检索：常见且经济的组合是「向量召回段落补事实，图谱补关系」，再按问题类型决定走哪条路径，全部走图谱会让简单问答的成本成倍上升。
落地先从一个小范围语料做起：抽取提示词、消歧规则与关系类型在真实数据上的表现往往和预想差距很大，先验证抽取质量再谈规模化。