測試解讀：真實倉庫中它為Agent省下了多少Token和時間)
zvec-grep基準(zhǔn)測試解讀真實倉庫中它為Agent省下了多少Token和時間【免費下載鏈接】zvec-grepLocal-first search across your workspace, built for humans and AI agents.項目地址: https://gitcode.com/gh_mirrors/zv/zvec-grepzvec-grepzg是一個 Local-first 的混合檢索引擎把 ripgrep、BM25 全文檢索和向量語義搜索統(tǒng)一到同一個本地接口既能被人類在終端直接使用也能作為 MCP 工具交給 AI Agent。這篇文章帶你完整解讀 zvec-grep 官方發(fā)布的兩套配對基準(zhǔn)測試SWE-QA-Bench 與 BrowseComp-Plus數(shù)據(jù)看看在真實倉庫和 10 萬篇文檔級語料中接入 zvec-grep 究竟能為 Agent 省下多少 Token、工具調(diào)用次數(shù)和等待時間。先搞懂這兩項基準(zhǔn)測試是怎么做的zvec-grep 的基準(zhǔn)測試全部采用配對 A/B 實驗協(xié)議同一個 Agent、同一個模型、同一份任務(wù)提示詞、同一個代碼環(huán)境、同一套調(diào)用限額唯一變量是是否接入 zvec-grep 的索引與檢索工具。實驗組配置Baseline基線Agent 使用自帶的標(biāo)準(zhǔn)搜索工具如原生 grep、文件讀取Treatmentzvec-grep同樣的 Agent額外獲得一份預(yù)建好的本地索引 zvec-grep MCP 工具官方刻意做了幾件反刷分的事這也是數(shù)據(jù)可信的關(guān)鍵索引構(gòu)建時間單獨計量不計入 Agent 執(zhí)行耗時避免把一次性成本混進對比每個案例跑多次獨立試次3~5 次取均值對沖模型輸出本身的隨機性答案評分由盲評模型完成裁判不知道哪份答案來自哪一組防止按預(yù)期打分。協(xié)議細節(jié)可在 benchmarks/README.md 中查看。目前官方共維護三套評測面向代碼倉庫問答的 SWE-QA-Bench、面向超大規(guī)模文檔語料的 BrowseComp-Plus以及純檢索質(zhì)量的 zg-retrieval 基準(zhǔn)。下面重點解讀前兩者的省 Token、省時間數(shù)據(jù)。真實代碼倉庫實測20 個任務(wù)、11 個真實倉庫SWE-QA-Bench 從 Pylint、Matplotlib、Django 等 11 個知名開源項目中固定了 20 道檢索密集型軟件工程問題——答案分散在多個文件里且不提前告訴 Agent 答案在哪里。20 任務(wù) × 2 實驗組 × 3 輪獨立試次用 Claude CodeClaude Opus 5 高推理模式作答?？傆[結(jié)果灰色為 Baseline彩色為 Baseline zvec-grepCoding 場景四項核心指標(biāo)指標(biāo)Baseline接入 zvec-grep變化LLM 評審質(zhì)量分Judge88.4291.921.50 pp平均輸入 Token559K294K?47.3%平均工具調(diào)用次數(shù)23.429.76?58.6%Agent 平均耗時127.5 s79.7 s?37.5%翻譯成直白的話答案質(zhì)量不降反升每個任務(wù)少燒約 26 萬個輸入 Token、少調(diào)一半以上的工具、快近 48 秒。輸入 Token 占 Agent 成本的大頭?47.3% 基本可以直接按同比例折算到賬單上。三個明星倉庫的詳細賬單再看單倉庫粒度的數(shù)據(jù)差距更加直觀倉庫任務(wù)類型質(zhì)量分變化輸入 Token工具調(diào)用耗時Pylint靜態(tài)分析架構(gòu)探索AST 節(jié)點如何區(qū)分帶/不帶類型注解的屬性初始化61.33 → 77.0015.67 pp1.38M → 239K?82.7%54.7 → 9.0?83.5%286.3s → 69.5s?75.7%Matplotlib繪圖渲染數(shù)據(jù)流FontInfo如何貫穿數(shù)學(xué)文本渲染管線2.67 pp787K → 367K?53.3%30.3 → 13.0?57.1%213.8s → 101.7s?52.4%DjangoWeb 框架設(shè)計動機用戶名唯一約束與 ORM 事務(wù)的聯(lián)動2.33 pp759K → 416K?45.2%42.8 → 12.7?69.8%195.8s → 118.6s?39.4%三個倉庫的共同點證據(jù)橫跨多個文件和模塊且入口位置事先未知。這類調(diào)用鏈追蹤、數(shù)據(jù)流追蹤、架構(gòu)問答恰好是 zvec-grep 的主場——語義檢索先把候選文件縮小到幾份符號感知索引再幫你錨定具體函數(shù)Agent 就不再需要幾十輪grepread的盲目試探。值得注意的是 Pylint 一例接入 zvec-grep 后 Judge 分從 61.33 拉到了 77 分。省 Token 的同時答案本身也變好了——少繞彎路意味著更少在中途放棄或答非所問。10 萬篇文檔語料實測大規(guī)模文檔問答SWE-QA 考的是代碼庫BrowseComp-Plus 考的是海量文檔約10 萬篇人工校驗過的文檔100 道需要跨多篇文檔拼接證據(jù)的深度研究題每個案例 3 輪獨立試次共 300 次配對運行。完整數(shù)據(jù)來自 LATEST_REPORT.md核心結(jié)論指標(biāo)Baseline接入 zvec-grep變化回答準(zhǔn)確率98.67%99.00%0.33 pp平均輸入 Token1,675,3791,046,115?37.56%每案例省約 63 萬 Token平均工具調(diào)用次數(shù)25.4214.36?43.52%Agent 平均耗時259.4 s159.3 s?38.58%首次命中關(guān)鍵證據(jù)所需批次4.071.90?54.24%最后一條指標(biāo)尤其值得新手注意Agent 平均只需約 2 個交互批次就能摸到關(guān)鍵證據(jù)而基線要 4 個批次。檢索越快收斂后續(xù)每一步的上下文膨脹就越少——這正是 Token 和耗時大幅下降的根源。分案例看67/100 的 Case 輸入 Token 不升反降中位數(shù)降幅 25.8%官方也坦誠指出當(dāng)任務(wù)用精確關(guān)鍵詞就能秒查時zvec-grep 的增益會收窄。語義檢索的價值集中在搜索空間大、線索被改寫、答案位置未知的場景。為什么能省這么多把兩套數(shù)據(jù)放在一起省下來的 Token 和時間來自同一個檢索閉環(huán)語義發(fā)現(xiàn)縮小搜索空間——線索是改寫過的問題時靠意思而不是靠字面匹配直接命中相關(guān)文檔/文件詞法檢索錨定精確標(biāo)識符——BM25 ripgrep 讓FontInfo、postscript_name這類符號一次定位帶來源的緊湊證據(jù)——返回的是按相關(guān)性排序、帶文件位置和行號的片段Agent 不必反復(fù)讀整文件、重復(fù)調(diào)用工具。這套管線的設(shè)計可以參見 docs/04-pipeline.md。如何自己驗證這些數(shù)據(jù)如果你懷疑廠商自己測自己好消息是整套基準(zhǔn)都在倉庫里輸入、依賴版本、任務(wù)子集全部鎖死可復(fù)現(xiàn)總協(xié)議與指標(biāo)口徑benchmarks/README.md10 萬文檔語料的完整 300 試次報告benchmarks/browse-comp-plus/LATEST_REPORT.md20 任務(wù)代碼倉庫問答的定義、評審與復(fù)現(xiàn)指南benchmarks/swe-qa-bench/README.md純檢索質(zhì)量評測Hitk、MRR、nDCGbenchmarks/zg-retrieval/README.md一句話總結(jié)真實代碼倉庫質(zhì)量 1.5 分輸入 Token?47.3%工具調(diào)用?58.6%耗時?37.5%最極端的 Pylint 單案例 Token 省82.7%10 萬篇文檔語料質(zhì)量持平甚至微升輸入 Token?37.6%工具調(diào)用?43.5%耗時?38.6%結(jié)論很簡單證據(jù)越分散、入口越難找的任務(wù)zvec-grep 幫 Agent 省下的 Token 和時間越多——而對這類任務(wù)多花的那幾分鐘索引構(gòu)建時間早在第一輪檢索就賺回來了?！久赓M下載鏈接】zvec-grepLocal-first search across your workspace, built for humans and AI agents.項目地址: https://gitcode.com/gh_mirrors/zv/zvec-grep創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 zvec-grep基準(zhǔn)測試解讀：真實倉庫中它為Agent省下了多少Token和時間
zvec-grep基準(zhǔn)測試解讀真實倉庫中它為Agent省下了多少Token和時間【免費下載鏈接】zvec-grepLocal-first search across your workspace, built for humans and AI agents.項目地址: https://gitcode.com/gh_mirrors/zv/zvec-grepzvec-grepzg是一個 Local-first 的混合檢索引擎把 ripgrep、BM25 全文檢索和向量語義搜索統(tǒng)一到同一個本地接口既能被人類在終端直接使用也能作為 MCP 工具交給 AI Agent。這篇文章帶你完整解讀 zvec-grep 官方發(fā)布的兩套配對基準(zhǔn)測試SWE-QA-Bench 與 BrowseComp-Plus數(shù)據(jù)看看在真實倉庫和 10 萬篇文檔級語料中接入 zvec-grep 究竟能為 Agent 省下多少 Token、工具調(diào)用次數(shù)和等待時間。先搞懂這兩項基準(zhǔn)測試是怎么做的zvec-grep 的基準(zhǔn)測試全部采用配對 A/B 實驗協(xié)議同一個 Agent、同一個模型、同一份任務(wù)提示詞、同一個代碼環(huán)境、同一套調(diào)用限額唯一變量是是否接入 zvec-grep 的索引與檢索工具。實驗組配置Baseline基線Agent 使用自帶的標(biāo)準(zhǔn)搜索工具如原生 grep、文件讀取Treatmentzvec-grep同樣的 Agent額外獲得一份預(yù)建好的本地索引 zvec-grep MCP 工具官方刻意做了幾件反刷分的事這也是數(shù)據(jù)可信的關(guān)鍵索引構(gòu)建時間單獨計量不計入 Agent 執(zhí)行耗時避免把一次性成本混進對比每個案例跑多次獨立試次3~5 次取均值對沖模型輸出本身的隨機性答案評分由盲評模型完成裁判不知道哪份答案來自哪一組防止按預(yù)期打分。協(xié)議細節(jié)可在 benchmarks/README.md 中查看。目前官方共維護三套評測面向代碼倉庫問答的 SWE-QA-Bench、面向超大規(guī)模文檔語料的 BrowseComp-Plus以及純檢索質(zhì)量的 zg-retrieval 基準(zhǔn)。下面重點解讀前兩者的省 Token、省時間數(shù)據(jù)。真實代碼倉庫實測20 個任務(wù)、11 個真實倉庫SWE-QA-Bench 從 Pylint、Matplotlib、Django 等 11 個知名開源項目中固定了 20 道檢索密集型軟件工程問題——答案分散在多個文件里且不提前告訴 Agent 答案在哪里。20 任務(wù) × 2 實驗組 × 3 輪獨立試次用 Claude CodeClaude Opus 5 高推理模式作答?？傆[結(jié)果灰色為 Baseline彩色為 Baseline zvec-grepCoding 場景四項核心指標(biāo)指標(biāo)Baseline接入 zvec-grep變化LLM 評審質(zhì)量分Judge88.4291.921.50 pp平均輸入 Token559K294K?47.3%平均工具調(diào)用次數(shù)23.429.76?58.6%Agent 平均耗時127.5 s79.7 s?37.5%翻譯成直白的話答案質(zhì)量不降反升每個任務(wù)少燒約 26 萬個輸入 Token、少調(diào)一半以上的工具、快近 48 秒。輸入 Token 占 Agent 成本的大頭?47.3% 基本可以直接按同比例折算到賬單上。三個明星倉庫的詳細賬單再看單倉庫粒度的數(shù)據(jù)差距更加直觀倉庫任務(wù)類型質(zhì)量分變化輸入 Token工具調(diào)用耗時Pylint靜態(tài)分析架構(gòu)探索AST 節(jié)點如何區(qū)分帶/不帶類型注解的屬性初始化61.33 → 77.0015.67 pp1.38M → 239K?82.7%54.7 → 9.0?83.5%286.3s → 69.5s?75.7%Matplotlib繪圖渲染數(shù)據(jù)流FontInfo如何貫穿數(shù)學(xué)文本渲染管線2.67 pp787K → 367K?53.3%30.3 → 13.0?57.1%213.8s → 101.7s?52.4%DjangoWeb 框架設(shè)計動機用戶名唯一約束與 ORM 事務(wù)的聯(lián)動2.33 pp759K → 416K?45.2%42.8 → 12.7?69.8%195.8s → 118.6s?39.4%三個倉庫的共同點證據(jù)橫跨多個文件和模塊且入口位置事先未知。這類調(diào)用鏈追蹤、數(shù)據(jù)流追蹤、架構(gòu)問答恰好是 zvec-grep 的主場——語義檢索先把候選文件縮小到幾份符號感知索引再幫你錨定具體函數(shù)Agent 就不再需要幾十輪grepread的盲目試探。值得注意的是 Pylint 一例接入 zvec-grep 后 Judge 分從 61.33 拉到了 77 分。省 Token 的同時答案本身也變好了——少繞彎路意味著更少在中途放棄或答非所問。10 萬篇文檔語料實測大規(guī)模文檔問答SWE-QA 考的是代碼庫BrowseComp-Plus 考的是海量文檔約10 萬篇人工校驗過的文檔100 道需要跨多篇文檔拼接證據(jù)的深度研究題每個案例 3 輪獨立試次共 300 次配對運行。完整數(shù)據(jù)來自 LATEST_REPORT.md核心結(jié)論指標(biāo)Baseline接入 zvec-grep變化回答準(zhǔn)確率98.67%99.00%0.33 pp平均輸入 Token1,675,3791,046,115?37.56%每案例省約 63 萬 Token平均工具調(diào)用次數(shù)25.4214.36?43.52%Agent 平均耗時259.4 s159.3 s?38.58%首次命中關(guān)鍵證據(jù)所需批次4.071.90?54.24%最后一條指標(biāo)尤其值得新手注意Agent 平均只需約 2 個交互批次就能摸到關(guān)鍵證據(jù)而基線要 4 個批次。檢索越快收斂后續(xù)每一步的上下文膨脹就越少——這正是 Token 和耗時大幅下降的根源。分案例看67/100 的 Case 輸入 Token 不升反降中位數(shù)降幅 25.8%官方也坦誠指出當(dāng)任務(wù)用精確關(guān)鍵詞就能秒查時zvec-grep 的增益會收窄。語義檢索的價值集中在搜索空間大、線索被改寫、答案位置未知的場景。為什么能省這么多把兩套數(shù)據(jù)放在一起省下來的 Token 和時間來自同一個檢索閉環(huán)語義發(fā)現(xiàn)縮小搜索空間——線索是改寫過的問題時靠意思而不是靠字面匹配直接命中相關(guān)文檔/文件詞法檢索錨定精確標(biāo)識符——BM25 ripgrep 讓FontInfo、postscript_name這類符號一次定位帶來源的緊湊證據(jù)——返回的是按相關(guān)性排序、帶文件位置和行號的片段Agent 不必反復(fù)讀整文件、重復(fù)調(diào)用工具。這套管線的設(shè)計可以參見 docs/04-pipeline.md。如何自己驗證這些數(shù)據(jù)如果你懷疑廠商自己測自己好消息是整套基準(zhǔn)都在倉庫里輸入、依賴版本、任務(wù)子集全部鎖死可復(fù)現(xiàn)總協(xié)議與指標(biāo)口徑benchmarks/README.md10 萬文檔語料的完整 300 試次報告benchmarks/browse-comp-plus/LATEST_REPORT.md20 任務(wù)代碼倉庫問答的定義、評審與復(fù)現(xiàn)指南benchmarks/swe-qa-bench/README.md純檢索質(zhì)量評測Hitk、MRR、nDCGbenchmarks/zg-retrieval/README.md一句話總結(jié)真實代碼倉庫質(zhì)量 1.5 分輸入 Token?47.3%工具調(diào)用?58.6%耗時?37.5%最極端的 Pylint 單案例 Token 省82.7%10 萬篇文檔語料質(zhì)量持平甚至微升輸入 Token?37.6%工具調(diào)用?43.5%耗時?38.6%結(jié)論很簡單證據(jù)越分散、入口越難找的任務(wù)zvec-grep 幫 Agent 省下的 Token 和時間越多——而對這類任務(wù)多花的那幾分鐘索引構(gòu)建時間早在第一輪檢索就賺回來了?！久赓M下載鏈接】zvec-grepLocal-first search across your workspace, built for humans and AI agents.項目地址: https://gitcode.com/gh_mirrors/zv/zvec-grep創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考