图检索什么时候值得上？不是所有语料都适合
数据截至 2026-07，价格与限额以各官网为准。
图检索值不值得上，取决于你的语料里有没有真实存在的关系，而不是取决于你的检索效果好不好。如果用户的问题需要跨好几篇文档把线索串起来才能回答，图检索能补上普通向量检索天生缺的那一环；如果每个问题在单篇文档里就有答案，那么无论召回多差，图检索都不是你该动的那个旋钮。
常见的误解是把图检索理解成”向量检索的升级版”——好像召回不准就该换成图，换了就更准。这个理解偏了。向量检索和图检索处理的根本不是同一件事：向量检索解决的是”哪些片段跟这个问题字面或语义上像”，图检索解决的是”这些片段之间是什么关系、能不能顺着关系往下走”。召回不准的原因大多在解析、分块、嵌入模型、混合检索、重排这几段，这些问题不会因为建了一张图就消失。搞错了病因，图只会让你多花一笔钱，还得多维护一套东西。
这篇按”该不该上、什么时候上、怎么上”的顺序讲一遍。
图检索改的是块与块之间的关系，不是向量本身
先把机制讲清楚，后面的判断才有依据。
普通 RAG 的链路是：文档切块 → 每块算嵌入向量 → 提问时算问题向量 → 找最相似的若干块 → 塞进上下文让模型回答。这条链路里，块与块之间是彼此孤立的。第 12 块和第 340 块哪怕讲的是同一个人、同一份合同的上下条款，系统也不知道它们有关系——除非它们的文字恰好足够相似。
图检索多做一步：从语料里抽出实体（人、机构、产品、条款编号、故障码等）和它们之间的关系，构成一张图。提问时不只找相似块，还能顺着实体之间的边往外走一跳、两跳，把关联的内容一并召回。RAGFlow 这类开源 RAG 引擎把知识图谱构建做进了产品内置能力，这也是它被归到”适合有链接的结构化语料”那一类的原因。
一句话总结差别：向量检索答的是”最像的是哪几段”，图检索答的是”跟它有关的还有哪几段”。你的业务问题落在哪一边，决定了要不要上。
哪四类语料值得上
值得认真考虑图检索的语料，大致是这四类：
第一类：文档之间有显式引用关系的。 法规条款互相援引、企业制度文件”详见第 X 号文”、API 文档里一个接口跳到另一个接口、内部 wiki 页面之间大量互链。这类语料的关系是白纸黑字写在文里的，抽取准确率相对高，图建起来最划算。
第二类：同一批实体反复跨文档出现，而问题恰好是关于实体关系的。 比如”这家供应商还给我们哪几个项目供过货""这个负责人经手过哪些合同”。答案分散在几十份文档里，每份只提一句，向量检索按相似度捞回来的往往是最啰嗦的那几段，而不是最全的那几段。
第三类：需要多跳推理的问题。 “A 组件故障会不会影响 C 系统”——语料里只写了 A 影响 B、B 影响 C，没有任何一段直接写 A 和 C。这种问题向量检索基本无解，因为答案根本不以连续文本的形式存在，得靠关系拼出来。
第四类：需要全局性回答的问题。 “这批文档整体反映了哪些主要风险""这个项目的争议集中在哪几处”。这类问题没有”标准答案段落”，取 top-k 相似块永远只能看到局部。图检索在做社区/主题聚合上有先天优势。
如果你的真实问题里有相当比例落在这四类，图检索是值得投入的方向。
哪三类语料不值得上
反过来，下面这三种情况先别碰图：
一是单条独立的问答型语料。 客服 FAQ、产品说明书条目、政策口径问答，每条自成一体，彼此没有需要串联的关系。给它建图，抽出来的边大多是噪声，检索时反而把不相关的内容拉进上下文。
二是一次检索就够的事实型问答。 “这款设备的额定功率是多少""退货期限几天”。这类问题只要块切得合理、嵌入模型选得对，普通检索就能稳定命中。答案就在一处，多跳没有意义。
三是语料变动很频繁的场景。 图不是建一次就完事——文档一改，牵涉到的实体和边都得重抽、重建。如果你的知识库每天都在更新，先想清楚增量更新怎么做，再决定要不要引入这层结构。低估维护成本是这条路上最常见的翻车点。
上之前先做一次诊断，别凭感觉
判断该不该上图，有一个成本很低但很有效的做法：把最近一段时间的真实用户问题捞出来，取三十到五十条，人工分成三类。
第一类，答案完整地存在于某一段文本里，只是没被召回——这是检索问题，该调的是解析、分块、混合检索、重排，跟图无关。第二类，答案分散在多篇文档，需要拼接——这是图检索的主场。第三类，答案压根不在语料里——这是内容缺口，建什么都没用，得先补内容。
统计一下三类各占多少。如果第二类不到两成，那你现在最该做的不是上图，是回头把解析和检索这两段调扎实。按瓶颈选而不是按名气选，这个原则在图检索这件事上尤其成立——因为图是所有 RAG 增强手段里，投入产出比波动最大的一个。
关于按瓶颈定位问题在哪一段，可以先看 RAG 框架怎么选？按瓶颈选，别按 star 数选，里面把解析、检索、评估、图关系四段的入手顺序说得更细。
顺带说一句名气这件事：GitHub star 只反映关注度，不代表适用性。截至 2026 年 1 月的第三方统计里，LangChain 约 125,000、Dify 约 114,000、RAGFlow 约 70,000、LlamaIndex 约 46,500、Haystack 约 24,000。这几个数字排出来的顺序，跟”谁更适合你的语料”没有对应关系，看看就好，具体能力以各项目官方文档当前版本为准。
落地路径：先用现成引擎，别一上来自己造图
确认要上之后，最稳的起步方式不是自己写实体抽取和图存储，而是先用把这件事做进产品里的引擎试一遍，看看在你的真实语料上效果如何。
RAGFlow 内置了知识图谱构建，同时它的强项本来就在深度文档理解——分块尊重文档结构、版面感知解析，第三方对比里把它归为适合扫描版 PDF、财报、版式复杂的法律文书这类传统文本解析器搞不定的语料。这两件事凑在一起有个实际好处：需要图检索的语料（法规、合同、财报）往往同时也是版式复杂的语料，解析和图能在同一套系统里解决，省掉一层拼接。它的具体能力和参数以官方文档当前版本为准。
自托管方面，RAGFlow 走 Docker 部署，有 slim 和 full 两种镜像，slim 约 2GB、full 约 9GB，区别在于是否内置嵌入模型。如果你打算用外部嵌入服务，slim 就够；想开箱即用、不想再单独部署嵌入模型，选 full。磁盘和拉取时间的差别在这里，提前规划好。
向量库这一层通常还是要配的——图检索不替代向量检索，两者是叠加关系。Qdrant 是常见搭配，支持过滤、payload 索引与量化，第三方称在 100 万以上向量规模下可做到 50 毫秒以内的检索；它可以作为独立二进制运行，也可以跑在 Docker 容器里。这个延迟数字是第三方口径，不是官方承诺指标，实际表现跟你的向量维度、过滤条件、硬件都有关系，务必自己压测一遍。选型细节可以看 向量数据库怎么选？Qdrant/Milvus/Supabase 对比。
关于 RAGFlow 在文档理解这一段的具体强项和不适用场景，RAGFlow 强在哪？扫描件与复杂版式的文档理解 讲得更完整。
成本代价要提前算清楚
图检索的开销主要在两处，都容易被低估。
建图阶段。 从文档里抽实体和关系，绝大多数实现是靠大模型逐段处理的，也就是说你要把整个语料库过一遍模型。语料越大，这笔一次性成本越高。具体多少钱取决于你的语料规模、用哪个模型、抽取提示怎么写，没有一个通用倍数可以照搬——谁给你一个固定的”贵 N 倍”的说法，都要打个问号。稳妥做法是先拿百分之一的语料跑一遍，实测出单位成本再外推。
维护阶段。 文档更新后图要跟着更新。全量重建简单但贵，增量更新省钱但要处理实体消歧、边失效这些琐碎问题。这部分工作量在方案评估时最容易被漏掉，等上线三个月后文档改了一轮才发现图已经对不上，那时候返工代价更大。
还有一个隐性成本：图检索召回的内容通常更多、更长，进模型的上下文变大，单次问答的推理开销也会跟着涨。第三方基准里也有类似的观察——比如有评测指出 LangChain 的 LCEL 语法能做复杂的查询重写，但相比 LlamaIndex 的直接检索会多出约 15% 到 20% 的延迟开销，这是第三方口径的基准数据、不是官方指标，但它说明的道理是通用的：每加一层处理，就要为延迟付一次账。图检索加的这一层比查询重写更重。
图检索很少单独用
实际生产里，图检索基本不会作为唯一的召回方式。更常见的是混合：向量检索保证语义相似的内容不漏，关键词检索保证专有名词、编号这类精确匹配不丢，图检索负责补上关系那一维，最后统一走一遍重排。哪一路权重高，是拿评估集调出来的，不是拍脑袋定的。
框架层面，“混着用”同样是常态。一个被反复提到的生产组合是：LlamaIndex 做 ingestion 与索引，LangChain 做编排，LangGraph 做 agent 工作流。这几个项目不是互斥的替代关系，两者的分工差异在 LangChain 和 LlamaIndex 的分工：一个广一个深 里有更细的说明。
如果你的检索还需要”自己决定要不要检索、检索几次”，那已经是另一个方向的增强了，可以参考 Agentic RAG 是什么？会自己规划检索的智能体。图检索和 agentic 检索可以叠加，但建议一次只加一层，否则出了问题分不清是谁的锅。
另外，无论你加哪一层，评估都得先建起来。瓶颈在评估这一段的话，通常的做法是在你已有的框架上加挂 RAGAS，而不是换框架。没有评估集，你没法证明图检索到底带来了多少提升，也就没法判断这笔钱花得值不值。
诚实说局限
有三件事必须讲明白。
抽取质量决定一切。实体和关系是模型从文本里抽出来的，抽错了、抽漏了、同一个实体被拆成三个不同名字，图就是歪的，而且歪得很隐蔽——检索照样返回结果，只是结果不对。上线前一定要人工抽查一批抽取结果。
不是所有”看起来有关系”的语料都真的有关系。有些文档集看着都在讲同一个业务，但彼此之间没有可抽取的显式关联，硬建出来的图边多是模型的联想，噪声比信号多。
对基础没打好的项目，图检索不是捷径。如果解析这一步还在丢表格、分块还在把一句话切两半，先把这些补上，收益比建图确定得多，成本也低得多。RAG 本身的基本盘可以回头看 RAG 是什么。
小结
图检索的适用条件很具体：语料里有真实存在的引用或实体关系，用户问题需要跨文档串联或多跳推理，且语料不会天天大改。满足这些条件，它能解决普通向量检索结构性解决不了的问题；不满足，它就是一笔昂贵的额外维护负担。
判断方法比结论更重要——捞三五十条真实问题分类统计，看需要拼接的那一类占多少，让数据替你做决定。真要上，先用内置知识图谱的现成引擎在小样本上跑通、实测成本，再决定要不要铺全量。最后记住，图检索是叠加在向量检索之上的一层，不是替换，各家能力和参数以官方文档当前版本为准。