GraphRAG 与知识图谱：当「多跳问题」难住向量检索时

一个向量检索答不好的问题

问 RAG 系统：「A 公司的 CEO 的母校是哪所？」

库里有两篇文档：一篇介绍 A 公司，提到「CEO 是张三」；另一篇是张三的访谈，提到「他毕业于某大学」。人扫一眼就能串起来，向量检索却常常翻车。

这不是工程没做好的锅，而是向量检索的天然短板。它的匹配逻辑是「问题与单块的相似度」，而任何一块都回答不了这个问题：公司那块不含「母校」，人物那块不含「A 公司」。两块各自与原问题的相似度都不高，top-k 里未必同时出现；即便都捞到了，模型也未必把两段信息串成一条链。

像这样需要跨文档串联两步以上事实的问题，叫多跳问题（multi-hop）。每多一跳，「单个块与原问题高度相似」的概率就再衰减一次：第一跳的块（张三是 CEO）与「母校」这个查询词几乎无关，第二跳的块（毕业于某大学）与「A 公司」无关——两块在各自的检索里都不占优。检索漏掉任何一块，答案链就断了。

GraphRAG 的思路：把关系显式存下来

GraphRAG（微软在公开论文中提出的方法族）的出发点：既然「关系」是向量表示的弱项，就把关系显式地抽出来存好。

**第一步，建图。**用 LLM 对全量语料做实体与关系抽取：识别「A 公司」「张三」「某大学」这类实体，抽出「张三—任职于—A 公司」「张三—毕业于—某大学」这类三元组，汇成一张知识图谱（Knowledge Graph，用节点表示实体、边表示关系的结构化网络）。

**第二步，沿图检索。**问题来了先定位起点实体，再沿关系边游走，把相关子图带回来——「A 公司 → CEO → 张三 → 母校 → 某大学」，图上走两步就到，不依赖任何单块与原问题的相似度。多跳在图上是结构问题，不是相似度问题。

**第三步，社区摘要——回答全局问题用。**对图做社区检测（把联系紧密的实体聚成簇），让 LLM 给每个社区生成一份摘要；更大的簇还能再聚成更高层社区、生成更高层摘要，形成一座金字塔。回答「这批文档整体在讨论什么主题」「这几百篇报告的共同趋势」这类全局归纳问题时，用这些摘要作答，而不是拿一堆碎块去拼——全局性问题恰恰是单块相似度检索最无力的题型。

两类适用问题

成本账：图不是白来的

• 构建期贵：实体与关系抽取要对全量语料逐篇跑 LLM，调用密集、token 消耗大；抽取质量还依赖提示词打磨与人工校对，语料越多这笔账越重。
• 更新重：向量库加一篇新文档就是一次插入；图还要做实体对齐（「张总」与「张三」是不是同一人）、关系冲突消解、子图增量更新，维护成本明显高于向量库。
• 查询要克制：图游走的延迟与扇出（每个节点连出多少条边）相关，一个节点几十条边、走两三跳就是上千候选，不设预算就容易越走越大、越问越慢。

务实的分层策略

1. **默认不上图。**绝大多数场景，向量检索 + 混合检索 + 重排序（前三篇的配方）已经覆盖绝大部分查询。
2. 确有需求再上图：问题里多跳明显（组织架构、供应链、人物关系网）、关系密集的领域（合规、情报、医疗档案）才值得付这个成本。
3. 混合方案是常见折中：向量粗召回锁定起点文档，再在图上扩展一两跳补全关联——不必全量建图，也能吃到多跳收益。
4. 先量化，再动工：用评测集（见评测篇）统计多跳类问题的 recall@k，拿数字证明「检索真的不行」，再为这一类问题引入图的复杂度；改造之后，同一套评测集继续验证收益。

要点小结：多跳问题让单块相似度检索逐跳失灵；GraphRAG 用实体关系图把「跳」变成图上游走，用社区摘要回答全局归纳；代价是构建与维护显著更重。这也是全系列的收束：切块、检索、重排、评测，先把每层的基础工程做扎实并量化验证，复杂武器只在数据说话时才请出场。