zvec-grep基准测试解读：真实仓库中它为Agent省下了多少Token和时间

zvec-grep基准测试解读：真实仓库中它为Agent省下了多少Token和时间

【免费下载链接】zvec-grepLocal-first search across your workspace, built for humans and AI agents.项目地址: https://gitcode.com/gh_mirrors/zv/zvec-grep

zvec-grep（zg）是一个 Local-first 的混合检索引擎，把 ripgrep、BM25 全文检索和向量语义搜索统一到同一个本地接口，既能被人类在终端直接使用，也能作为 MCP 工具交给 AI Agent。这篇文章带你完整解读 zvec-grep 官方发布的两套配对基准测试（SWE-QA-Bench 与 BrowseComp-Plus）数据，看看在真实仓库和 10 万篇文档级语料中，接入 zvec-grep 究竟能为 Agent 省下多少 Token、工具调用次数和等待时间。

先搞懂：这两项基准测试是怎么做的

zvec-grep 的基准测试全部采用配对 A/B 实验协议：同一个 Agent、同一个模型、同一份任务提示词、同一个代码环境、同一套调用限额，唯一变量是"是否接入 zvec-grep 的索引与检索工具"。

实验组	配置
Baseline（基线）	Agent 使用自带的标准搜索工具（如原生 grep、文件读取）
Treatment（zvec-grep）	同样的 Agent，额外获得一份预建好的本地索引 + zvec-grep MCP 工具

官方刻意做了几件"反刷分"的事，这也是数据可信的关键：

• 索引构建时间单独计量，不计入 Agent 执行耗时，避免把一次性成本混进对比；
• 每个案例跑多次独立试次（3~5 次）取均值，对冲模型输出本身的随机性；
• 答案评分由盲评模型完成，裁判不知道哪份答案来自哪一组，防止按预期打分。

协议细节可在 benchmarks/README.md 中查看。

目前官方共维护三套评测：面向代码仓库问答的 SWE-QA-Bench、面向超大规模文档语料的 BrowseComp-Plus，以及纯检索质量的 zg-retrieval 基准。下面重点解读前两者的"省 Token、省时间"数据。

真实代码仓库实测：20 个任务、11 个真实仓库

SWE-QA-Bench 从 Pylint、Matplotlib、Django 等 11 个知名开源项目中固定了 20 道"检索密集型"软件工程问题——答案分散在多个文件里，且不提前告诉 Agent 答案在哪里。20 任务 × 2 实验组 × 3 轮独立试次，用 Claude Code（Claude Opus 5 高推理模式）作答。

总览结果（灰色为 Baseline，彩色为 Baseline + zvec-grep）：

Coding 场景四项核心指标：

指标	Baseline	接入 zvec-grep	变化
LLM 评审质量分（Judge）	88.42	91.92	+1.50 pp
平均输入 Token	559K	294K	−47.3%
平均工具调用次数	23.42	9.76	−58.6%
Agent 平均耗时	127.5 s	79.7 s	−37.5%

翻译成直白的话：答案质量不降反升，每个任务少烧约 26 万个输入 Token、少调一半以上的工具、快近 48 秒。输入 Token 占 Agent 成本的大头，−47.3% 基本可以直接按同比例折算到账单上。

三个明星仓库的详细账单

再看单仓库粒度的数据，差距更加直观：

仓库	任务类型	质量分变化	输入 Token	工具调用	耗时
Pylint（静态分析）	架构探索：AST 节点如何区分带/不带类型注解的属性初始化	61.33 → 77.00（+15.67 pp）	1.38M → 239K（−82.7%）	54.7 → 9.0（−83.5%）	286.3s → 69.5s（−75.7%）
Matplotlib（绘图渲染）	数据流：FontInfo如何贯穿数学文本渲染管线	+2.67 pp	787K → 367K（−53.3%）	30.3 → 13.0（−57.1%）	213.8s → 101.7s（−52.4%）
Django（Web 框架）	设计动机：用户名唯一约束与 ORM 事务的联动	+2.33 pp	759K → 416K（−45.2%）	42.8 → 12.7（−69.8%）	195.8s → 118.6s（−39.4%）

三个仓库的共同点：证据横跨多个文件和模块，且入口位置事先未知。这类"调用链追踪、数据流追踪、架构问答"恰好是 zvec-grep 的主场——语义检索先把候选文件缩小到几份，符号感知索引再帮你锚定具体函数，Agent 就不再需要几十轮grep+read的盲目试探。

值得注意的是 Pylint 一例：接入 zvec-grep 后 Judge 分从 61.33 拉到了 77 分。省 Token 的同时答案本身也变好了——少绕弯路意味着更少在中途放弃或答非所问。

10 万篇文档语料实测：大规模文档问答

SWE-QA 考的是"代码库"，BrowseComp-Plus 考的是"海量文档"：约10 万篇人工校验过的文档，100 道需要跨多篇文档拼接证据的深度研究题，每个案例 3 轮独立试次（共 300 次配对运行）。

完整数据来自 LATEST_REPORT.md，核心结论：

指标	Baseline	接入 zvec-grep	变化
回答准确率	98.67%	99.00%	+0.33 pp
平均输入 Token	1,675,379	1,046,115	−37.56%（每案例省约 63 万 Token）
平均工具调用次数	25.42	14.36	−43.52%
Agent 平均耗时	259.4 s	159.3 s	−38.58%
首次命中关键证据所需批次	4.07	1.90	−54.24%

最后一条指标尤其值得新手注意：Agent 平均只需约 2 个交互批次就能摸到关键证据，而基线要 4 个批次。检索越快收敛，后续每一步的"上下文膨胀"就越少——这正是 Token 和耗时大幅下降的根源。

分案例看，67/100 的 Case 输入 Token 不升反降，中位数降幅 25.8%；官方也坦诚指出：当任务用精确关键词就能秒查时，zvec-grep 的增益会收窄。语义检索的价值集中在"搜索空间大、线索被改写、答案位置未知"的场景。

为什么能省这么多？

把两套数据放在一起，省下来的 Token 和时间来自同一个检索闭环：

1. 语义发现缩小搜索空间——"线索是改写过的问题"时，靠意思而不是靠字面匹配直接命中相关文档/文件；
2. 词法检索锚定精确标识符——BM25 + ripgrep 让FontInfo、postscript_name这类符号一次定位；
3. 带来源的紧凑证据——返回的是按相关性排序、带文件位置和行号的片段，Agent 不必反复读整文件、重复调用工具。

这套管线的设计可以参见 docs/04-pipeline.md。

如何自己验证这些数据

如果你怀疑"厂商自己测自己"，好消息是整套基准都在仓库里，输入、依赖版本、任务子集全部锁死可复现：

• 总协议与指标口径：benchmarks/README.md
• 10 万文档语料的完整 300 试次报告：benchmarks/browse-comp-plus/LATEST_REPORT.md
• 20 任务代码仓库问答的定义、评审与复现指南：benchmarks/swe-qa-bench/README.md
• 纯检索质量评测（Hit@k、MRR、nDCG）：benchmarks/zg-retrieval/README.md

一句话总结

• 真实代码仓库：质量 +1.5 分，输入 Token−47.3%，工具调用−58.6%，耗时−37.5%；最极端的 Pylint 单案例 Token 省82.7%；
• 10 万篇文档语料：质量持平甚至微升，输入 Token−37.6%，工具调用−43.5%，耗时−38.6%；
• 结论很简单：证据越分散、入口越难找的任务，zvec-grep 帮 Agent 省下的 Token 和时间越多——而对这类任务，多花的那几分钟索引构建时间，早在第一轮检索就赚回来了。

【免费下载链接】zvec-grepLocal-first search across your workspace, built for humans and AI agents.项目地址: https://gitcode.com/gh_mirrors/zv/zvec-grep