为什么要做这件事

RAG 已经从论文概念变成了 AI 应用的基础设施。过去一年涌出来大量 RAG 方案，每一家都说自己准确率最高、成本最低、延迟最小。

但实际用起来根本不是那么回事。

我们是 ContextDB 的产品团队，每天和 RAG 打交道。一个普遍的毛病：大多数 Benchmark 只跑一两个数据集，而且往往挑对自己有利的场景。用户选型的时候没有靠谱的参考。

所以我们把自己的方案和四家主流 RAG 方案放在一起，在四个完全不同的数据集上跑了一遍，用同一套评估标准对比。准确率、Token 成本、检索延迟、跨场景稳定性——五家方案，数据说话。

先声明一点：评测是自家团队做的，虽然我们尽量保持客观，但读者应该对这个背景保持警惕。最好在自己的数据上复现验证。

参评方案

选这四家的原因很简单：它们分别代表了 RAG 的四种技术路线——结构化索引、图谱增强、轻量级、通用框架。这样对比更有参考价值。

四个数据集

评测数据集的选择直接决定结论是否可信。我们刻意挑了四个差异很大的场景。

FinanceBench（金融问答）：专业术语密集、数字精确度要求高、文档之间大量交叉引用。典型查询："某公司在 2023 年 Q3 的营业利润率是多少？与上一季度相比变化了多少？"考验的是精确数字检索和跨文档关联。

SyllabusQA（教学大纲问答）：结构化程度高、信息密度大。"这门课的期末项目占多少分？提交截止日期是什么时候？"考验结构化信息的精准检索。

Qasper（学术论文问答）：篇幅长、论证链复杂、需要理解上下文。"这篇论文提出的方法和 baseline 相比，在哪个指标上提升了多少？"考验长文档中的信息定位和语义理解。

ClapNQ（常识问答）：开放域，问题覆盖面广，需要一定推理能力。"标准 52 张扑 克牌中，红桃和方片加起来有多少张？"考验通用知识检索和简单推理。

准确率

这是最核心的指标——检索到的内容是否真正回答了用户的问题。

我们的方案平均 79.3%，比第二名 PageIndex 高出约 6 个百分点。不过说实话，我不确定这个差距在所有场景下都成立——我们选的数据集可能恰好偏向三层记忆架构擅长的类型。

LightRAG 准确率偏弱，平均约 65%，在 Qasper 和 ClapNQ 上掉得尤其厉害。HippoRAG 2 在金融场景表现不错（74.8%），但到教学大纲场景就滑到 71.4%——图谱增强在某些结构化场景中并不占优。

Token 成本

RAG 系统的运行成本主要体现在 Token 消耗上——索引构建、查询解析、上下文注入都要花 Token。以完成同等数量查询的消耗为基准（LightRAG 为 1.0x）：

这个结果有点出人意料：准确率最高的方案 Token 成本反而最低，只有 LightRAG 的 1/3。

原因在三层记忆架构。原子事实层只存最小知识单元，避免大量冗余上下文被注入 Prompt。LightRAG 虽然名字叫"Light"，索引构建阶段反而需要较多 Token 来维护文档块之间的关联信息。HippoRAG 2 要维护知识图谱，Token 成本最高。

不过要注意，这个成本对比是在特定数据规模下得出的。数据量增长后各方案的 Token 消耗曲线可能不同，这一点我们没有充分验证。

检索延迟

端到端响应时间，包括查询解析、检索、重排：

延迟方面 PageIndex 是最好的，1.38 秒，比我们的方案快了约 15%。如果你的场景对响应速度极度敏感（比如实时客服），PageIndex 的结构化索引方案确实更合适。HippoRAG 2 的图谱遍历在复杂查询时会带来额外开销。

跨场景稳定性

这是我们特别在意的一个角度——准确率高的方案，在不同场景下表现是否一致？

用四个数据集准确率的标准差来衡量（标准差越低越稳定）：

稳定性方面 LightRAG 和 HippoRAG 2 更好。标准差越低说明在不同场景下表现越一致。我们的方案标准差 3.6，是五家中波动最大的——虽然准确率绝对值高，但在不同场景间起伏也更大。这可能是因为我们选的场景恰好对它比较友好，换一个场景集合结论可能不同。

综合评分

我们尝试对四个维度各打 10 分，但需要说明这个打分带有主观性，权重分配取决于你的业务优先级：

如果你更看重延迟和稳定性，PageIndex 和 HippoRAG 2 的总分差距会缩小很多。这个表只是一个参考维度，不是最终结论。

几点诚实的讨论

评测是自家做的，我想尽量说点实话。

PageIndex 在延迟上确实有优势。 如果你的场景对响应速度极度敏感，它的结构化索引方案值得优先考虑。而且它的稳定性也不错（标准差 3.5），仅次于 LightRAG 和 HippoRAG 2。

HippoRAG 2 的图谱增强在金融场景确实有效。 如果你的数据本身就是高度关联的知识图谱结构，它的准确率不错。跨场景稳定性也是五家中第二好的（2.9）。缺点是 Token 成本较高。

LightRAG 的定位有点尴尬。 它叫"Light"，Token 成本并不最低。简单场景下它是合理的选择，复杂场景下准确率掉得明显。但它的跨场景稳定性是最好的（2.7），这意味着你不会在某个场景上突然踩坑。

我们的方案优势是准确率和 Token 成本的组合。 79.3% 的准确率配合 LightRAG 1/3 的 Token 成本，这个组合在五家方案中比较突出。但短板也很明显——延迟不是最优，跨场景稳定性是五家中最差的。如果你的业务场景和我们测试的四个数据集差异很大，准确率优势可能不存在。

这次评测的局限：

• 数据集是我们选的，可能偏向我们的方案擅长的类型
• 没有测试数据规模变化后的性能曲线
• 延迟测试的网络环境固定，不一定反映生产环境表现
• 综合评分带有主观权重，不同业务场景下权重应该不同

如何复现

想在自己的数据集上验证，可以这样接入：

curl -fsSL 'https://context-database-client.oss-cn-hangzhou.aliyuncs.com/install.sh' | bash -s -- --agent <agent> --api-key <api-key>

目前支持 Qoder、Claude Code、Codex、OpenClaw、OpenCode、Hermes 和 QoderWork 等主流 Agent。

LOCOMO 基准测试的评测框架是公开的，你可以在自己的数据上跑同样的评估流程。我们鼓励复现——经得起不同数据集检验的结论，才是可靠的。

选型建议

RAG 方案选型不应该只看 Demo 效果或者某一个数据集上的数字。准确率、成本、延迟、稳定性需要综合考量，而且要在足够多样的场景下验证。

没有万 能方案，看你的场景：

• 追求准确率和成本的最优组合，可以试试我们的方案
• 追求极 致延迟，PageIndex 值得看看
• 数据天然适合图谱结构、看重稳定性，HippoRAG 2 可以试试
• 预算有限、场景简单，LightRAG 是个不错的起点

建议在自己的真实数据上跑一遍再做决定。

参考链接

• RDS ContextDB 快速入门