详细解释
Graph RAG（Graph Retrieval-Augmented Generation） 一句话定义：不再把文档切成独立 chunk 直接向量检索，而是先从所有文档中抽取出（实体, 关系, 实体）三元组构建知识图谱，再把用户问题转成「图谱上的游走+子图检索」，最后把子图结构 + 原始 chunk 一起送给 LLM 生成答案。普通向量 RAG 容易患上「chunk 孤岛症」——A 文档说「张三是 B 公司 CTO」，B 文档说「B 公司 2024 年营收 10 亿」，两个 chunk 向量不相似，搜「张三所在公司去年营收多少」很可能两段都搜不全；Graph RAG 因为先建立了张三→任职→B 公司→营收→10 亿的连接，两步推理直接命中。
微软 2024 年提出的 GraphRAG（首字母大写 = 微软具体实现，小写 = 泛指技术范式）是当前最主流的工程化蓝本：它不要求你提前有 Neo4j，而是先让 LLM 对每个 chunk 做「实体-关系抽取」，自动在内存里建图，再做「社区发现」（Leiden 算法把紧密相连的实体聚类成社区），最后每个社区让 LLM 生成一段「社区摘要」。用户提问时：先选和问题最相关的若干社区 → 把社区摘要 + 社区里所有三元组 + 原始 chunk 一起塞进上下文。实测在「跨 10 篇以上文档的全局聚合类问题」上，Graph RAG 的答案完整度比普通向量 RAG 高 30% 至 60%，缺点是离线建图阶段要花 5 至 10 倍 token 成本。
唯元智创 API 网关内置了「一键 Graph RAG 流水线」：给一个 S3 桶或飞书知识库地址，自动做抽取→建图→社区发现→摘要，召回阶段自动根据问题复杂度在「普通向量召回」和「图谱+向量混合召回」之间切换，复杂问题自动走 Graph，简单单文档问答走普通 RAG 降本。
三种 Graph RAG 工程形态对比
| 形态 | 图从哪来 | 适合场景 | 延迟 | 成本倍数 |
|---|---|---|---|---|
| ① 轻量共现图 | 不用 LLM 抽三元组，chunk 间「共同实体 ≥2 个」就连边，图 = 实体-chunk 二部图 | 1000 篇文档以内的中小知识库 | 和普通 RAG 几乎一样 | 建图成本 +20%，查询 +0% |
| ② 微软 GraphRAG 式社区摘要图 | LLM 抽三元组 → Leiden 社区发现 → LLM 写社区摘要 | 千至十万篇文档级，全局聚合类问题多 | 比普通 RAG 慢 30% 至 50% | 建图 +5 至 10 倍 token |
| ③ 显式企业知识图谱（Neo4j/Nebula） | 已有成熟图谱资产，RAG 检索阶段做 SPARQL/Cypher + 向量混合召回 | 金融/医疗/制造已有主数据图谱的企业 | 查询时多次跳查询慢 2 至 3 倍 | 图谱维护是长期成本，RAG 本身 +0% |
Graph RAG 相对普通向量 RAG 的两个真·优势和一个误区
两个真实优势：(1) 多跳/跨文档问题天然解决——「给我列出 2024 年所有和 A 公司合作过的、总部在上海的、员工人数超过 500 人的供应商」，普通向量 RAG 要在 10 个 chunk 里拼齐信息，漏一个条件答案就错；Graph RAG 在图上一条路径跑到底。(2) 可溯源性极强——每个答案里的事实都能指向具体的（实体, 关系, 实体）三元组，三元组再指向是从哪篇文档哪个位置抽出来的，审计链完整，B 端合规场景刚需。
一个常见误区：别以为「有了图就不需要向量检索了」。Graph RAG 在「开放式描述类问题」（如「帮我总结一下今年客户反馈里关于产品体验的主要抱怨点」）上召回质量反而比纯向量差——因为描述类问题里没有清晰实体，图谱匹配不上。生产环境正确姿势永远是「混合召回」：向量召回 Top-K、图谱召回子图、关键词 BM25 召回 Top-K，三路 Rerank 合并，三路都没命中的判定为无答案。