GraphRAG 是推理问题，而非数据库问题

向量 RAG 将文本块进行嵌入，通过余弦或点积相似度检索查询的最近邻，并将其放入上下文。它回答“此文档说了什么”，而且成本低：在索引时每个块只需一次嵌入调用，查询时每次查询也只需一次嵌入调用。

GraphRAG 用多阶段流水线取代了单次嵌入过程。在索引阶段，LLM 读取每个块并将实体及其关系抽取为结构化三元组：“公司 X，收购，公司 Y。”微软的原始实现随后在得到的图上运行 Leiden 算法（一种社区检测方法），将紧密相连的实体分组为簇，并递归此过程以构建层次结构：第 0 层为宽泛的通用社区，随后每一层上的社区逐步变得更窄、更具体。随后，LLM 为每一层的每个社区生成自然语言摘要。在提出任何查询之前，这就需要对整个语料库进行两次完整的 LLM 遍历。在查询阶段，系统会拉取相关的社区摘要（全局搜索）或遍历特定的实体关系（局部搜索），而不是或除了最近邻查找之外。

双遍索引步骤正是导致 GraphRAG 成本高昂的原因，也是它能够回答向量 RAG 在结构上无法处理的一类问题的关键——即‘当你跨文档连接实体时，整个语料库暗示了什么’。向量 RAG 没有这种连接的表示，它仅仅具备文本与查询之间的相似度。

GraphRAG-Bench，一个 ICLR 2026 基准测试，在四种查询类型上分别测试图检索与纯块检索，而不是报告一个综合得分。结果如下：

简单事实检索：块的准确率为 60.9%，图的准确率为 60.1%。两者持平，向量搜索在从单一文档中提取一个事实方面可能略占优势。

多跳推理：图胜出，70.3% 对 67.0%。上下文摘要——即需要综合跨多个文档信息的问题：图胜出 64.4% 对 51.3%，相差 13 个百分点。

聚合查询：图胜出 53.4% 对 42.9%，相差 10.5 个百分点。

这就是结果的真实面貌：一种专门用于多跳和综合问题的工具，而非普遍的升级。其他地方引用的更大差距——一些论文报告了 50 个百分点以上的波动——来源于一种不同且较为宽松的方法：LLM 评判者在广泛的“理解整个语料库”提示中挑选它更偏好的两个答案之一，且仅在一个狭窄的数据集上进行测试。

微软最初的 GraphRAG 论文在该设置下报告了在全面性方面的 72‑83% 胜率和在多样性方面的 62‑82% 胜率。LightRAG 论文 在其法律文档子集上报告了相较于朴素 RAG（16.4%）的 83.6% 胜率，相差 67 个百分点。这些是真实的数字，但它们衡量的是判定模型在单一领域的整个语料库提示上更喜欢哪个答案。它们并不是一般问答任务的准确率得分，也不适用于典型的生产工作负载。在基于这些数字制定预算之前，请先确认是哪种方法得出的结果。

适用于使用 GraphRAG 的场景：多跳问题、跨文档综合以及‘此语料库中的所有内容如何相互关联’类查询，例如初创公司在数千份合同中映射义务、在代码库及其相关工单中追踪错误，或将多年研究论文中的实体关联起来。

不要用于：单文档事实查询或常见问答式检索，答案只存在于一个位置，任务只是找到它。在这些场景下，向量 RAG 与图检索相当甚至更好，基础设施成本仅为其一小部分，且没有双 pass 索引延迟。

在评估 GraphRAG 之前，先超过真实基线：结合 BM25 关键词搜索、稠密嵌入和交叉编码器重排序器的混合检索。公开基准显示，在普通向量搜索上加入混合融合和重排序，召回提升约为 15%-30%。有一个广泛引用的比较显示，召回@10 从 78% 提升至 91%。评估 GraphRAG 时，多数团队未先跑这个更便宜的基线，而它在图引入之前就能弥合相当一部分合成差距。

在完整的 GraphRAG 流水线中，索引时实体抽取约占总索引成本的 75%。原因在于结构：抽取对每个 chunk 进行一次 LLM 调用，chunk 很小（通常 300-600 token，而嵌入调用一次能处理的窗口要大得多），社区摘要又在上面额外增加一次完整的 LLM 通过。这样会使处理的总 token 数增加约 3-5 倍，相比于为向量 RAG 索引同样的语料库。在真实生产语料库的规模下，这意味着数百万次 LLM 调用，而不仅仅是数据库配置的一条线项。

查询时间也会带来额外开销。全局搜索在合成答案之前必须读取相关层级的所有社区摘要；局部搜索需要遍历多个关系跳并提取相连实体的描述。两者都会在检索基础上增加 LLM 往返。公开比较表明，完整的 GraphRAG 查询延迟是普通向量 RAG 的 2-3 倍，端到端，甚至在生成开始之前。

有两个后果。首先，成本异议已不复存在。在 2024 年初，使用微软原始 GraphRAG 对 5GB 法律语料库建立索引的成本大约为 33,000 美元，这一数字导致近两年内几乎所有内部 GraphRAG 提案被否决。LazyGraphRAG，由微软研究院在 2025 年中旬发布，完全去除了索引过程中的两次昂贵的 LLM 调用。它采用 NLP 名词短语抽取而非 LLM 来构建概念共现图，随后将所有 LLM 推理推迟到查询阶段，通过迭代的最佳优先和广度优先搜索仅对所查询的具体内容进行相关性测试付费。

这使得索引成本降至与普通向量 RAG 相当，仅为原始全图 RAG 成本的约 0.1%，同时在查询成本降低超过 700 倍的情况下，仍能匹配 GraphRAG 全局搜索的回答质量。LightRAG 采用另一种方式弥合类似差距：它在索引阶段使用 LLM，但在检索时采用双层键——低层键用于特定实体和关系，高层键用于更广泛的主题，并支持增量图更新，使新文档能够合并到现有图中而无需完全重建索引。33,000 美元的成本异议对这两套系统均不再适用。剩下的问题是基础设施：你在哪里运行抽取模型，以及它与你的图存储、向量存储和生成 GPU 的距离有多近？

其次，抽取过程不需要前沿模型。从文本块中提取实体和关系并将其写入固定模式是一项狭窄且结构化的任务，非常适合在 vLLM 下运行的小型模型，使用语法约束的结构化输出解码（JSON 模式，由 xgrammar 或 outlines 等后端强制执行）。已发布的 vLLM 基准测试显示，Llama-3.2-3B 在单张 A100 上的典型批次大小下吞吐量约为 900–1,200 个 token/秒，而更大的开放模型在 vLLM 上在单张 GPU 高并发情况下可突破 15,000+ token/秒。在此吞吐量和价格点上，抽取成为普通 GPU 资源上的批处理作业，而不必为了让数百万个文本块经过计量的前沿 API 进行路由。

GraphRAG 部署包含四个相互不断通信的组件：负责在索引时调用 LLM 的抽取模型、图存储、处理混合搜索检索半部分的向量存储，以及负责遍历和生成的编排层。它们之间每一次跨越网络边界、不同区域、不同提供方或不靠近计算的存储的跳转都会增加延迟。这种延迟会在图遍历本身需要的多次查询时往返中累积，而此时的工作负载已经比纯向量 RAG 慢 2-3 倍。

在这里，数据位置是一级延迟变量，就像任何存储到 GPU 的路径一样：GPU 从同一数据中心读取数据、从不同数据中心读取数据以及从完全不同提供方的网络读取数据之间存在可测量的毫秒级差距。将三到四次这样的跳转堆叠到一次图遍历中，这个差距就不再可以忽略不计。

这一论点倾向于在同一区域、同一堆栈上运行抽取、两个存储和生成，而不是使用来自一个提供方的托管图数据库、另一个提供方的向量数据库，以及在当周 GPU 容量最便宜的任何地方进行推理。具体来说，在 DigitalOcean 上：利用 Serverless Inference 以批处理作业运行抽取，以应对突发的索引构建，因为它是计费的，并且在语料库更新之间可以缩放到零。当流量足够稳定以证明预留 GPU Droplet 容量的合理性时，将查询时的抽取和生成迁移到 Dedicated Inference（可选规格包括 H100、H200、Blackwell B300 以及 AMD MI300X/MI350X/MI355X，这些规格部署在大约 20 个全球数据中心的 400G RoCE RDMA 网络上）。

DigitalOcean 的 推理 堆栈运行一个经过调优的 KV 缓存管理和 speculative decoding 的自定义 vLLM 分支，这对于管道的查询时间半段尤为重要，因为在这一段延迟而不仅仅是吞吐量是约束。DigitalOcean 的 向量数据库 产品在托管 PostgreSQL 上支持 pgvector，同时也支持 Weaviate 和 OpenSearch，覆盖了与图存储和 GPU 所在同一账号和地区的混合管道的检索半段。请参阅我们的配套文章，了解关于冷存储与热推理延迟层次的一般性论述。

提取层：vLLM 提供一个 3B 到 8B 参数范围的小型指令调优模型，通过结构化输出解码强制实体/关系模式，作为针对语料大小的 GPU Droplets 的批处理作业运行。这一步骤占总管道成本的约 75%，并且相比于按 token 计量的前端 API，自托管方式能获得最大收益。

图存储：FalkorDB、Kuzu 或 Neo4j，根据规模和查询模式选择，而非品牌知名度。FalkorDB 将图表示为稀疏矩阵，并将遍历评估为线性代数运算，这使得多跳和聚合查询的延迟可预测；一份已发表的基准测试表明首次查询就绪时间低于半毫秒。Kuzu 是一种嵌入式磁盘引擎，适用于分析批处理工作负载，而非高并发服务。Neo4j 则牺牲部分专注度，换取更大的生态系统、更成熟的工具以及在团队需要扩展支持时更易招聘的人才池。

向量存储: Qdrant 或 pgvector 用于管道的混合检索部分。如果您希望减少一个服务的运维且嵌入向量规模适中，请在托管的 PostgreSQL 上使用 pgvector。当您的规模超过该操作简洁性不再带来收益的点时，转向 Qdrant，通常在几千万向量规模时。

管道: 使用 LightRAG 或 LazyGraphRAG 替代原始的全 GraphRAG 实现。两者现在的索引成本接近向量 RAG，同时保持了上文记载的多跳和合成准确性提升。对于持续变化且查询量不可预测的语料库，选择 LazyGraphRAG；如果您需要持久化、可查询的实体和关系数据，且能够接受索引时的 LLM 成本来换取后续更便宜的双层检索，则选择 LightRAG。

可观测性: 分别监控索引时每个 chunk 的 token 消耗和查询时每跳的延迟，而不要只看一个汇总数。如果只跟踪端到端的数字，包含两次索引时的 LLM 传递以及查询时两到三次往返的管道会掩盖哪个阶段是慢的或昂贵的。

部署: 将四个组件全部放在同一地区、同一云提供商上，这样频繁的索引时和查询时往返就不会在每跳上产生跨网络延迟费用。

我们正在发布一个开源的基准测试工具，它在同一地区的相同 DigitalOcean GPU Droplet 硬件上，针对三种管道（混合向量 RAG、LightRAG 和完整 GraphRAG）运行四种查询类别：简单事实、多跳、聚合和上下文摘要。语料库、抽取模型和生成模型保持不变，仅在运行之间更改检索架构。每种管道和每种查询类别都会记录索引成本、重新索引成本、P50/P99 查询延迟、每 1,000 次查询的成本以及所有四个核心 RAGAS 分数（忠实度、答案相关性、上下文精确度、上下文召回率）。每次运行会重复足够多次，以报告中位数和离散程度，而不是单一数字，因为后者可能被 LLM 输出长度的方差悄然扭曲。该仓库附带语料库加载器、三种管道配置和评估脚本，因此团队可以将其指向自己的文档进行设置并重新运行，而不仅仅是盲目信任的一张图表。

那种基准测量的是稳态准确度和成本。它无法捕捉到仅在 GraphRAG 流水线在生产环境中运行一段时间后才会出现的两种故障模式，而这两种故障在你决定采用之前都值得提前规划。

抽取错误会累积，检索错误不会。 一次错误的向量 RAG 检索是按查询发生的事件：下一次查询会得到全新的最近邻查找，不受上一次影响。错误的实体抽取会被烘焙进图中。如果索引时的模型错误地标注了关系或幻觉出了实体，该错误会一直存在于每个社区摘要以及所有触及它的遍历中，直至语料库被重新索引。向量 RAG 按查询失败；GraphRAG 在结构上失败，且这种故障较难被发现，因为它被包装在流畅的社区摘要中，而不是一个明显错误的检索块。

过时的成本远高于纸面上的表现。 完整的 GraphRAG 没有廉价的途径来更新单个文档。添加新的源材料意味着重新运行抽取并重新聚类社区，这就是行业花费两年试图消除的 33,000 美元级别的成本，而不是你一次性付费后就可以忘记的开支。这正是 LightRAG 的增量合并和 LazyGraphRAG 的即时构建在其标题索引成本之外真正重要的原因：它们使得图流水线能够适用于每日变化的语料库，而不仅仅是一次性索引后永久查询的情况。在采用原始 GraphRAG 或其懒惰变体之前，先询问你的源语料库变化频率，并确认流水线的更新策略与该频率相匹配，因为这一数字不会出现在任何准确度基准中。

这些内容并不支持或反对使用图。GraphRAG‑Bench 在事实查询上持平，在多跳和综合问题上领先 10 到 13 分，这意味着诚实的第一步是先自行划分查询混合，再选择架构，而不是因为供应商博客在你不共享的基准上展示了 50 分的胜率就直接采用图。先运行混合检索基线。如果多跳和跨文档问题仅占真实流量的一小部分，那就可以在此停止。如果不是这样，曾经让图成为硬性否决的索引成本已经不存在，剩下的决策完全取决于推理：使用哪个模型进行抽取，如何提供服务，以及它是否与你的图存储和向量存储相邻，或者相隔三跳网络。

以下是一些你可以参考的资源：

• GraphRAG-Bench：RAG 中何时使用图（ICLR 2026）
• 从局部到全局：面向查询聚焦摘要的 Graph RAG 方法，
• LightRAG：简单快速的检索增强生成（EMNLP 2025）
• LazyGraphRAG：为质量与成本树立新标杆