为什么要做这件事
RAG 已经从论文概念变成了 AI 应用的基础设施。过去一年涌出来大量 RAG 方案，每一家都说自己准确率最高、成本最低、延迟最小。
但实际用起来根本不是那么回事。
我们是 ContextDB 的产品团队，每天和 RAG 打交道。一个普遍的毛病：大多数 Benchmark 只跑一两个数据集，而且往往挑对自己有利的场景。用户选型的时候没有靠谱的参考。
所以我们把自己的方案和四家主流 RAG 方案放在一起，在四个完全不同的数据集上跑了一遍，用同一套评估标准对比。准确率、Token 成本、检索延迟、跨场景稳定性——五家方案，数据说话。
先声明一点：评测是自家团队做的，虽然我们尽量保持客观，但读者应该对这个背景保持警惕。最好在自己的数据上复现验证。
参评方案
| 方案 | 类型 | 特点 |
| ContextDB | 阿里云 RDS 上下文数据库 | 三层记忆架构 + 知识生命周期管理 |
| PageIndex | 结构化索引方案 | 基于页面级别的文档索引 |
| HippoRAG 2 | 图谱增强 RAG | 基于知识图谱的检索增强 |
| LightRAG | 轻量级 RAG | 简单高效，主打低成本 |
| OpenViking | 开源 RAG 框架 | 通用型 RAG 框架 |
选这四家的原因很简单：它们分别代表了 RAG 的四种技术路线——结构化索引、图谱增强、轻量级、通用框架。这样对比更有参考价值。
四个数据集
评测数据集的选择直接决定结论是否可信。我们刻意挑了四个差异很大的场景。
FinanceBench（金融问答）：专业术语密集、数字精确度要求高、文档之间大量交叉引用。典型查询："某公司在 2023 年 Q3 的营业利润率是多少？与上一季度相比变化了多少？"考验的是精确数字检索和跨文档关联。
SyllabusQA（教学大纲问答）：结构化程度高、信息密度大。"这门课的期末项目占多少分？提交截止日期是什么时候？"考验结构化信息的精准检索。
Qasper（学术论文问答）：篇幅长、论证链复杂、需要理解上下文。"这篇论文提出的方法和 baseline 相比，在哪个指标上提升了多少？"考验长文档中的信息定位和语义理解。
ClapNQ（常识问答）：开放域，问题覆盖面广，需要一定推理能力。"标准 52 张扑克牌中，红桃和方片加起来有多少张？"考验通用知识检索和简单推理。
准确率
这是最核心的指标——检索到的内容是否真正回答了用户的问题。
| 数据集 | ContextDB | PageIndex | HippoRAG 2 | LightRAG | OpenViking |
| FinanceBench | 81.2% | 72.5% | 74.8% | 66.3% | 69.1% |
| SyllabusQA | 83.7% | 78.1% | 71.4% | 68.2% | 73.6% |
| Qasper | 76.4% | 69.8% | 73.2% | 63.5% | 67.9% |
| ClapNQ | 75.9% | 71.2% | 68.5% | 62.1% | 65.8% |
| 平均 | 79.3% | 72.9% | 72.0% | 65.0% | 69.1% |
我们的方案平均 79.3%，比第二名 PageIndex 高出约 6 个百分点。不过说实话，我不确定这个差距在所有场景下都成立——我们选的数据集可能恰好偏向三层记忆架构擅长的类型。
LightRAG 准确率偏弱，平均约 65%，在 Qasper 和 ClapNQ 上掉得尤其厉害。HippoRAG 2 在金融场景表现不错（74.8%），但到教学大纲场景就滑到 71.4%——图谱增强在某些结构化场景中并不占优。
Token 成本
RAG 系统的运行成本主要体现在 Token 消耗上——索引构建、查询解析、上下文注入都要花 Token。以完成同等数量查询的消耗为基准（LightRAG 为 1.0x）：
| 方案 | Token 成本（相对值） |
| ContextDB | 0.33x |
| PageIndex | 0.85x |
| HippoRAG 2 | 1.42x |
| LightRAG | 1.0x（基准） |
| OpenViking | 1.15x |
这个结果有点出人意料：准确率最高的方案 Token 成本反而最低，只有 LightRAG 的 1/3。
原因在三层记忆架构。原子事实层只存最小知识单元，避免大量冗余上下文被注入 Prompt。LightRAG 虽然名字叫"Light"，索引构建阶段反而需要较多 Token 来维护文档块之间的关联信息。HippoRAG 2 要维护知识图谱，Token 成本最高。
不过要注意，这个成本对比是在特定数据规模下得出的。数据量增长后各方案的 Token 消耗曲线可能不同，这一点我们没有充分验证。
检索延迟
端到端响应时间，包括查询解析、检索、重排：
| 方案 | 平均延迟 |
| ContextDB | 1.64s |
| PageIndex | 1.38s |
| HippoRAG 2 | 2.45s |
| LightRAG | 1.82s |
| OpenViking | 2.11s |
延迟方面 PageIndex 是最好的，1.38 秒，比我们的方案快了约 15%。如果你的场景对响应速度极度敏感（比如实时客服），PageIndex 的结构化索引方案确实更合适。HippoRAG 2 的图谱遍历在复杂查询时会带来额外开销。
跨场景稳定性
这是我们特别在意的一个角度——准确率高的方案，在不同场景下表现是否一致？
用四个数据集准确率的标准差来衡量（标准差越低越稳定）：
| 方案 | 准确率标准差 |
| ContextDB | 3.6 |
| PageIndex | 3.5 |
| HippoRAG 2 | 2.9 |
| LightRAG | 2.7 |
| OpenViking | 3.2 |
稳定性方面 LightRAG 和 HippoRAG 2 更好。标准差越低说明在不同场景下表现越一致。我们的方案标准差 3.6，是五家中波动最大的——虽然准确率绝对值高，但在不同场景间起伏也更大。这可能是因为我们选的场景恰好对它比较友好，换一个场景集合结论可能不同。
综合评分
我们尝试对四个维度各打 10 分，但需要说明这个打分带有主观性，权重分配取决于你的业务优先级：
| 方案 | 准确率 | Token 成本 | 延迟 | 稳定性 | 总分 |
| ContextDB | 9.5 | 9.8 | 8.0 | 7.5 | 34.8 |
| PageIndex | 8.2 | 7.0 | 9.0 | 8.4 | 32.6 |
| HippoRAG 2 | 8.0 | 4.0 | 6.5 | 8.8 | 27.3 |
| LightRAG | 6.5 | 5.5 | 7.5 | 9.0 | 28.5 |
| OpenViking | 7.2 | 5.0 | 7.0 | 8.6 | 27.8 |
如果你更看重延迟和稳定性，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 是个不错的起点
建议在自己的真实数据上跑一遍再做决定。
参考链接
