GraphRAG 的论文和官方文档里检索这块讲得最细的通常是 Global Search 和 Local Search 两条线前者靠社区摘要做全局问答后者靠实体邻域做局部问答。但真把代码翻一遍、把索引产物拆开看你会发现实际可用的检索模式远不止这两个——Local 和 DRIFT 这两个词经常被混着用甚至有人以为 DRIFT 就是 Local 的别名。这篇就把这两个模式从索引结构、检索路径、适用问题类型三个层面拆开讲最后给一份我自己的使用判断表方便你在具体项目里直接对号入座。1. 先把 Local 和 DRIFT 放回 GraphRAG 的检索版图里1.1 为什么论文只重点讲了两条线GraphRAG 那篇论文的核心贡献是用 LLM 从文本里抽实体和关系再对实体图做社区划分最后为每个社区生成摘要。围绕这个索引产物论文重点验证的是两类查询一类是这个数据集整体在讲什么这种全局性问题走社区摘要另一类是某个具体实体相关的细节这种局部性问题走实体邻域。Global 和 Local 这两个名字就是这么来的。但论文的篇幅是有限的它要论证的是这套索引比朴素 RAG 强而不是把所有检索姿势都列全。所以像 DRIFT 这种在工程实现里才逐渐成型的模式论文里基本没展开。你在官方仓库的检索代码里能看到它但文档里往往只有一两句话带过这就导致很多人第一次看到 DRIFT 时完全不知道它和 Local 差在哪。1.2 Local 检索到底在检索什么Local 检索的输入是一个具体问题比如张三在这份材料里负责什么。它的处理链路大致是这样从问题里识别出关键实体通常是名词短语比如张三。拿这个实体名去实体表里做匹配找到对应的实体节点。以这个节点为中心向外扩展一跳或多跳把关联的实体、关系、以及这些实体所在的文本单元text unit都捞出来。把这些候选内容按相关性排序、截断拼成上下文喂给 LLM。这里有个容易被忽略的点Local 检索的局部是相对于整张知识图谱而言的不是说它只能回答很短的问题。只要你的问题能锚定到一个或几个实体上它就能沿着图往外爬把相关的一大片内容都拉进来。所以它适合的是有明确锚点、但答案可能散落在多处的问题。1.3 DRIFT 检索的定位差异DRIFT 这个词在不同项目里含义不完全一样但在 GraphRAG 语境下它通常指的是一种先做局部检索再根据初步结果动态扩展查询的模式。你可以把它理解成 Local 的一个增强版Local 是一次性把邻域捞出来就完事DRIFT 则是先捞一轮看看捞出来的内容够不够回答问题如果不够就基于已有内容生成新的查询方向再捞一轮。这个差异听起来很小但实际效果差别很大。Local 的问题在于如果你的初始实体识别偏了或者问题本身需要跨多个不直接相连的实体才能回答它捞出来的内容就会不全。DRIFT 通过检索-评估-再检索的循环能在一定程度上弥补这个缺陷。1.4 两者在索引依赖上的共同点与分歧共同点是Local 和 DRIFT 都依赖同一套索引产物实体表、关系表、文本单元表、社区报告。它们都不需要重新跑一遍索引都是在已有产物上做检索。分歧在于对索引的使用方式。Local 主要用实体表和关系表做邻域扩展文本单元表用来取原文。DRIFT 除了这些还会更频繁地用到社区报告因为当它需要判断当前捞到的内容够不够时社区报告提供了一个更高层的语义摘要能帮它判断还缺什么。2. Local 检索的完整链路拆解2.1 实体识别这一步的坑实体识别看起来简单实际是最容易出问题的一步。GraphRAG 默认用的是 LLM 来做实体抽取但检索时的实体识别和索引时的实体抽取是两回事。索引时是从大段文本里抽实体检索时是从一个短问题里抽实体。短问题里往往没有完整的上下文LLM 可能会把苹果识别成水果而你的知识库里苹果其实是一家公司。我自己的做法是在检索前加一层实体归一化。具体来说先把问题里的候选实体抽出来然后拿这些候选去实体表里做模糊匹配看知识库里实际存在哪些相近的实体名。如果匹配不上再考虑用别名表或者同义词表做映射。这一步不做Local 检索的召回率会明显偏低。2.2 邻域扩展的深度怎么定邻域扩展的深度是个需要调的参数。深度为 1 时只捞直接相连的实体和关系深度为 2 时会再往外扩一层。深度越大召回的内容越多但噪声也越多而且上下文长度会迅速膨胀。我的经验是对于事实型问题深度 1 通常够用对于某件事的来龙去脉这类问题深度 2 更合适。但不要盲目上深度 3因为到了第三层很多实体和原问题的关联已经非常弱了塞进上下文只会干扰 LLM。这里有个实用的判断方法扩展完之后看捞出来的文本单元数量。如果超过 20 个基本就该考虑截断或者降深度了。因为大多数 LLM 的有效上下文虽然能到 128k但真正能利用好的信息量是有限的塞太多反而会稀释关键信息。2.3 文本单元的排序与截断策略捞出来的文本单元不能直接按图遍历顺序塞给 LLM得排序。排序的依据通常有几个维度与中心实体的图距离、文本单元本身的长度、以及文本单元和问题的语义相似度。我一般会用图距离优先、语义相似度次之的策略。具体做法是先按图距离分桶距离 1 的排前面距离 2 的排后面同一桶内再按语义相似度排。截断的时候优先保留距离近的距离远的如果超出预算就丢掉。注意截断时不要简单按 token 数硬切最好按文本单元的边界切。因为一个文本单元往往是一个完整的段落或句子硬切会破坏语义完整性LLM 读起来会更费劲。2.4 一个 Local 检索的实际例子假设你的知识库是一份公司内部的项目文档问题是XX 项目的技术选型是谁定的。第一步实体识别会抽出XX 项目这个实体。第二步去实体表里找到XX 项目节点。第三步扩展一跳可能会捞到技术选型、负责人、决策会议这些关联实体以及它们之间的边。第四步把这些实体对应的文本单元捞出来排序后拼成上下文。如果文档里明确写了XX 项目的技术选型由李四在 3 月评审会上拍板那 Local 检索大概率能答对。但如果文档里分散在三处一处写项目背景一处写评审会纪要一处写李四的职责说明那 Local 检索能不能答对就取决于这三处是否都能通过图路径关联到XX 项目这个中心实体。如果关联不上就会漏。3. DRIFT 检索的动态扩展机制3.1 DRIFT 的核心循环长什么样DRIFT 的典型流程可以概括成四步用初始问题做一轮 Local 检索拿到第一批候选内容。把候选内容和原问题一起交给 LLM让它判断这些内容够不够回答问题。如果不够让 LLM 基于已有内容生成新的查询方向比如还需要了解 XX 方面的信息。用新方向再做一轮检索把新捞到的内容合并进来重复第 2 步。这个循环可以跑多轮但实际项目中跑两到三轮就够了。再多了收益递减而且延迟会明显上升。3.2 判断够不够这一步怎么设计这一步是 DRIFT 的关键也是最难做好的地方。判断逻辑不能太松否则第一轮就认为够了DRIFT 退化成 Local也不能太严否则会无限循环。我的做法是给 LLM 一个明确的判断框架让它从三个维度评估覆盖度问题涉及的每个子问题是否都有对应内容、一致性捞到的内容之间有没有矛盾、具体度有没有足够的具体事实来支撑回答。三个维度里只要有一个明显不足就触发下一轮检索。这个判断框架的好处是它把模糊的够不够拆成了可操作的维度LLM 的判断会更稳定。实测下来比单纯问够不够的准确率高不少。3.3 新查询方向是怎么生成的新查询方向的生成本质上是让 LLM 做一次缺口分析。它会看原问题和已有内容找出哪些信息还缺然后把这些缺口转成新的检索关键词或实体名。这里有个技巧不要让 LLM 直接生成自然语言问题而是让它生成实体名或关键词列表。因为后续检索还是要走实体匹配这条路生成自然语言问题还得再做一次实体识别多一道工序就多一层误差。直接生成实体名能直接拿去实体表里匹配链路更短。3.4 DRIFT 在什么场景下明显优于 LocalDRIFT 的优势场景是问题本身需要多跳推理但跳与跳之间的实体没有直接边。比如问和 XX 项目用同一套技术栈的还有哪些项目这个问题需要先找到 XX 项目的技术栈再去找用了这套技术栈的其他项目。如果知识库里没有技术栈这个中间实体Local 检索一跳根本找不到其他项目而 DRIFT 可以在第一轮捞到技术栈相关信息后生成技术栈名称作为新查询方向第二轮就能找到其他项目。反过来如果问题本身锚点很明确、答案就在一个邻域内DRIFT 相比 Local 没有明显优势反而多了一轮 LLM 调用延迟更高。所以不是所有场景都值得上 DRIFT。4. 两种模式在索引产物上的使用差异4.1 实体表和关系表的使用方式对比Local 对实体表和关系表的使用是以中心实体为锚做广度优先扩展。它假设问题能锚定到一个明确的实体然后从这个实体出发去捞邻域。DRIFT 对这两张表的使用更灵活。它第一轮可能也是从某个实体出发但后续轮次可能不再依赖单一中心实体而是根据缺口分析的结果去实体表里做更宽泛的匹配。比如第一轮锚定的是XX 项目第二轮可能直接去匹配技术栈相关的所有实体不再局限于 XX 项目的邻域。这个差异意味着DRIFT 对实体表的查询模式更多样实现上需要支持更灵活的查询接口不能只做给定实体名查邻域这一种。4.2 社区报告在两种模式里的角色Local 检索基本不用社区报告它走的是实体邻域这条路。社区报告是 Global 检索的主战场。DRIFT 会用社区报告但用法和 Global 不同。Global 是直接把社区报告当上下文喂给 LLM 做全局总结DRIFT 是把社区报告当导航图用来判断当前捞到的内容覆盖了哪些社区、还缺哪些社区。这个用法下社区报告不需要全文塞进上下文只需要它的摘要和关键词用来做覆盖度判断。4.3 文本单元的去重与合并两种模式都会遇到文本单元重复的问题。同一个文本单元可能通过多条图路径被捞到如果不去重上下文里会出现重复内容浪费预算还干扰 LLM。去重的方法很简单用文本单元的 ID 做唯一键就行。但合并的时候要注意如果同一个文本单元在不同轮次被捞到它的相关性评分可能不同合并时应该取最高分而不是简单覆盖。5. 参数调优与性能权衡5.1 邻域深度与召回率的权衡前面提过邻域深度这里展开说一下怎么定量评估。你可以准备一批测试问题每个问题都有标准答案然后分别用深度 1、2、3 跑一遍看召回率和准确率的变化。我的实测数据是深度从 1 到 2召回率通常能提升 15% 到 25%准确率基本持平或略升从 2 到 3召回率提升不到 10%但准确率开始下降因为噪声变多了。所以深度 2 通常是个甜点值。当然这个数据跟你的知识库密度有关。如果知识库本身很稀疏实体之间边很少那深度 2 可能也捞不到多少东西这时候可以考虑放宽匹配条件而不是盲目加深度。5.2 DRIFT 轮数与延迟的权衡DRIFT 每多一轮就多一次 LLM 调用加一次检索。延迟的增加是线性的但效果的提升是递减的。我的建议是如果对延迟敏感DRIFT 最多跑两轮如果对延迟不敏感、更看重答案质量可以跑三轮。超过三轮基本没有意义因为到那时候要么已经捞全了要么就是知识库里根本没有相关信息再捞也捞不出来。5.3 上下文预算的分配不管是 Local 还是 DRIFT最后都要把内容拼成上下文。上下文预算怎么分配直接影响 LLM 的回答质量。我的分配策略是问题本身占 5%实体和关系描述占 20%文本单元占 60%剩余 15% 留给 LLM 的推理空间。文本单元是大头因为它包含原始信息实体和关系描述是辅助帮 LLM 理解结构留推理空间是为了避免上下文太满导致 LLM 没地方思考。6. 一份可直接对号入座的使用判断6.1 什么时候用 Local 就够了问题里有明确的实体名且这个实体在知识库里存在。答案大概率在某个实体的邻域内不需要跨多个不相关实体。对延迟敏感希望一次检索就出结果。知识库的图结构比较稠密实体之间边多一跳就能捞到不少内容。6.2 什么时候该上 DRIFT问题需要多跳推理且跳与跳之间的实体没有直接边。问题比较开放初始实体识别可能不准需要多轮修正。对答案质量要求高愿意用延迟换效果。知识库里有社区报告且报告质量不错能用来做覆盖度判断。6.3 两种模式都不适合的情况如果问题本身是纯全局性的比如这份材料整体在讲什么那 Local 和 DRIFT 都不合适应该走 Global 检索。Global 直接拿社区报告做总结比在实体邻域里绕一圈高效得多。还有一种情况是知识库里根本没有相关信息。这时候不管用哪种模式都捞不到东西。与其让 LLM 硬答不如在检索阶段就加一个无相关内容的判断直接返回知识库中未找到相关信息避免幻觉。6.4 混合使用的思路实际项目里我经常把 Local 和 DRIFT 做成可切换的甚至做成自动路由先用一个轻量分类器判断问题类型如果是简单事实型走 Local如果是复杂推理型走 DRIFT。这个分类器不需要很复杂用几个规则加一个小模型就能做成本很低但能明显提升整体效率。7. 实操中容易踩的几个坑7.1 实体名大小写和别名问题知识库里的实体名可能是XX项目问题里写的是XX 项目中间有空格或者xx项目小写。如果不做归一化匹配就会失败。我的做法是在实体表里额外存一列归一化后的名字匹配时先归一化再查。7.2 关系方向被忽略图里的边是有方向的但很多实现在做邻域扩展时只按节点扩展忽略了边的方向。这会导致捞到一些方向相反的关系比如张三负责 XX和XX 负责张三被混在一起。虽然 LLM 通常能分辨但会增加它的负担。建议在扩展时保留方向信息拼上下文时也标注清楚。7.3 社区报告过期如果你更新了知识库但没重新生成社区报告DRIFT 用社区报告做覆盖度判断时就会基于过期信息导致判断失准。所以每次更新知识库后记得把社区报告也重新跑一遍。7.4 上下文里的实体描述太长有些实体的描述字段很长直接塞进上下文会占掉大量预算。我的做法是对实体描述做截断只保留前 200 个字符或者用 LLM 先做一次摘要。这样能在不损失太多信息的前提下省下不少预算给文本单元。8. 从检索模式反推索引设计8.1 实体粒度决定了检索的上限如果你索引时把实体抽得太粗比如把XX 项目的技术选型整个当成一个实体那检索时就没法沿着技术选型这个维度去做更细的匹配。反过来如果抽得太细实体数量爆炸图会变得很稀疏邻域扩展也捞不到东西。我的经验是实体粒度应该和你的典型问题粒度对齐。如果你的问题经常问某个决策是谁做的那决策和人应该分开抽成实体如果问题经常问某个项目的整体情况那项目本身作为一个实体就够了。8.2 关系类型的设计影响 DRIFT 的效果DRIFT 做缺口分析时会依赖关系类型来判断还缺什么。如果你的关系类型很单一比如只有相关这一种那缺口分析就很难做细。建议在索引时定义一套有语义的关系类型比如负责、依赖、属于、导致等这样 DRIFT 在生成新查询方向时能更有针对性。8.3 文本单元的大小文本单元太大检索时捞一个就占满上下文太小又可能丢失上下文。我的建议是文本单元的大小控制在 200 到 500 字之间这样既能保留足够的上下文又不会太占预算。9. 我自己的使用体会这套东西我前前后后调了大半年最大的体会是Local 和 DRIFT 不是替代关系而是互补关系。Local 是基础DRIFT 是在 Local 之上的增强。如果你的 Local 都没调好实体识别不准、邻域扩展乱捞那上 DRIFT 只会把问题放大因为它会在错误的基础上继续扩展。所以我的建议是先把 Local 的实体识别、邻域深度、排序截断这三块调稳再考虑上 DRIFT。DRIFT 的收益主要体现在复杂推理型问题上如果你的业务场景里这类问题占比不高那 Local 加 Global 的组合可能就够了没必要为了用 DRIFT 而用 DRIFT。最后分享一个小技巧在调 DRIFT 的轮数时可以先把判断够不够的阈值调严一点让它多跑一轮看看多出来的内容有没有实质帮助。如果有再逐步放宽阈值如果没有说明问题不在轮数上而在检索质量上得回头去调 Local 那部分。这个调试顺序能帮你快速定位问题到底出在哪一环。
