index1

AI Code Search Tools Benchmark

Claude Native (Grep/Glob) vs index1 vs qmd — 三种搜索工具在不同规模下的完整性能对比

Apple Silicon M2 · 48 GB RAM 测试规模: 10K / 50K / 100K 文档 Ollama v0.15.4 · bge-m3 1024d (中日韩) 2026-02-06
🌐 EN 中文 日本語 한국어
⚡

Claude Native

Grep / Glob / Read — Claude Code 内置工具 (ripgrep)
Rust + SIMD 零依赖 O(N) 线性扫描 精确匹配 无需索引
📚

index1

BM25 + 向量混合搜索 — Python MCP Server
FTS5 O(log N) sqlite-vec Ollama 5 种分块器 中日韩优化 L1/L2 缓存
🤖

qmd

BM25 + 向量 + LLM 重排序 — Bun/TypeScript MCP Server
3 个 GGUF 模型 Query Expansion LLM Rerank 无外部依赖 专注 Markdown
10K 文档 / ~50 MB 代码
中型项目 (Django, Flask)
50K 文档 / ~250 MB 代码
大型项目 (React, Vue)
100K 文档 / ~500 MB 代码
超大型项目 (Linux 内核子集)

0数据来源与方法论 (方法论)

数据标注说明

MEASURED 在 index1 项目上实际测量 (17,725 chunks, 1,707 文档)
REFERENCE 来自官方基准测试或论文 (ripgrep, SQLite FTS5, sqlite-vec, Ollama)
PROJECTED 基于组件性能 + 算法复杂度推算 (标注计算公式)
▶ 数据来源与可信度明细（点击展开）
数据来源 来源详情 可信度
index1 实测本项目 17,725 chunks / 1,707 文档 / 185MB 数据库，多次运行取中位数高 (实测)
ripgrep 基准官方 burntsushi/ripgrep 仓库 README 基准测试 (Linux kernel, ~1GB 语料)高 (官方)
SQLite FTS5sqlite.org 官方文档 + andrewmara.com 18M 行 trigram 基准高 (官方+三方)
sqlite-vecalexgarcia.xyz 官方 v0.1.0 发布基准 (SIFT1M/GIST500K)高 (作者发布)
Ollama embedcollabnix.com 嵌入模型指南 + nomic.ai 官方博客中高
qmd 管道tobi/qmd 源码分析 + 组件基准推算 (无官方发布基准)中 (推算)
规模推算基于算法复杂度 O(N)/O(log N)/O(N*D) 从实测基准线性/对数外推中 (推算)

1AI Agent 使用体验 (Agent Experience)

⚡ AI 读取搜索结果速度对比

无论使用哪个 AI Agent（Claude Code、Cursor、Cline...），每次搜索后都要读取返回结果。
返回越多，AI 读得越慢、花费越高。

指标 index1 qmd
单次搜索返回量 ~460 tok ~900 tok
AI 读取耗时 < 0.1 秒 ~0.2 秒
搜索延迟（端到端） ~100 ms ~1,200 ms
20 次搜索累计 9,200 tok 18,000 tok
200K 窗口占用 4.6% 9%
AI 费用 (20 次 / $3/M) $0.03 $0.05
AI 每次搜索需要读取的 Token 量（越短越好）
qmd
900 tok — 0.2 秒
index1
460 tok — < 0.1 秒 🔥

MEASURED 费用按 Claude Sonnet $3/M input tokens 估算

AI Agent 的搜索效率不仅取决于速度，更取决于调用复杂度和Token 消耗。 一个需要多次试错的 tool 会浪费 Agent 的推理 Token 和用户等待时间。
维度 Claude Native index1 qmd
AI 每次搜索调用数1 次 (Grep)1 次 (docs_search)1-3 次 (需判断 search/vsearch/query)
AI 需要理解的 API3 个 (直觉型)1 个统一入口6 个 tools
索引初始化无需1 步: index1 index2 步: bun run index + bun run vector
环境自动诊断N/A✓ index1 doctor --fix✗
💰 单次返回 Token~36,000 tok (高频词)~460 tok (Top-5)~900 tok (Top-10)
搜索延迟 (体感)< 50 ms~100 ms~1,200 ms (query 全管道)
Ollama 不可用时N/A自动降级纯文本搜索向量搜索完全不可用

AI Agent 实际使用对比: 一次搜索的完整流程

Claude Native (Grep)
1. Grep("search")
2. 返回 950 行 (~36K tokens)
上下文窗口被塞满
调用 1 次 | 耗时 ~40ms | 但 Token 爆炸
index1
1. docs_search("搜索怎么工作的")
2. 返回 Top-5 结果 (~460 tokens)
精准、省 Token、支持中文
调用 1 次 | 耗时 ~100ms | Token 节省 98%+
qmd
1. AI 纠结: 用 search? vsearch? query?
2. 试 search("search") → 结果一般
3. 改用 query("search") → 等 1.2s
结果更精准，但 AI 决策成本高
调用 1-3 次 | 耗时 1.2s+ | 精度最高但流程复杂

主流 AI Agent / 编辑器兼容性

各工具通过 MCP 协议接入 AI Agent。Claude Native 为内置工具，无需额外配置。

AI Agent MCP 支持 Claude Native index1 qmd 备注
Claude Code ✓ 原生 内置 ✓ 1 个入口 ✓ 6 个 tools index1 一个 docs_search 搞定
OpenClaw ✓ MCP 内置 ✓ ✓ 开源 Claude Code 替代，原生 MCP
Cursor ✓ MCP 内置 (不同实现) ✓ ✓ 需判断 tool Cursor 的 AI 倾向选最少 tools
Windsurf ✓ MCP 内置 ✓ ✓ MCP stdio 模式
Cline ✓ MCP 内置 (VS Code) ✓ ✓ VS Code 扩展，支持 MCP
Aider ✗ 内置 grep 需手动集成 需手动集成 暂无原生 MCP 支持
GitHub Copilot 部分 内置 需 Agent Mode 需 Agent Mode Copilot Agent Mode 支持 MCP

index1 的 1 个统一入口设计让所有 AI Agent 都能一次调用命中，无需理解多个 tools 的区别。 qmd 的 6 个 tools (search/vsearch/query/get/multi_get/status) 增加了 AI 的决策负担。

2中日韩语言支持对比 (CJK Language Support)

中日韩（中日韩）语言的搜索质量取决于分词精度、Embedding 模型语言覆盖和查询策略调优三个维度。 以下对比基于 index1 配置 bge-m3 + jieba 分词的实际测试结果。

2.1 中日韩 能力矩阵

能力维度 Claude Native index1 + bge-m3 qmd
中文分词 N/A (字面匹配) ✓ jieba 精确分词
pip install index1[chinese]		 ✗ porter unicode61
按 Unicode 字符切分，无语义
Embedding 模型 N/A bge-m3 1024d
BAAI 多语言模型，中日韩优化		 embeddinggemma 300M
英文为主，中日韩 语义丢失严重
中日韩 查询策略 N/A 动态调权
检测到 中日韩 → BM25=0.2 / Vec=0.8		 固定权重
不区分语言，无自适应
跨语言搜索 ✗ 仅字面匹配 ✓ 中文查英文代码
"配置合并" → config.py merge()		 有限
模型语义能力弱
日语 / 韩语 ✗ ✓ bge-m3 原生支持
向量搜索可用，BM25 需额外分词器		 ✗

2.2 中日韩 配置资源开销

配置方案 模型大小 向量维度 内存占用 索引速度 (10K) 存储 (10K)
index1 (纯 BM25) 0 N/A ~80 MB ~10 s ~60 MB
index1 + Ollama
nomic-embed-text 768d		 274 MB 768d ~600 MB ~10 min ~150 MB
index1 + Ollama + bge-m3
bge-m3 1024d · 中日韩优化		 ~1.2 GB 1024d ~900 MB ~14 min ~200 MB
qmd
embeddinggemma 300M + 2 GGUF		 ~2.2 GB (3 模型) 768d ~2.5 GB ~8 min ~80 MB

3.3 FTS5 分词机制对比 (Why It Matters)

FTS5 全文搜索的效果完全取决于分词器。中文没有空格分隔词语，选错分词器 = BM25 搜索废掉。
🔍 查看分词机制详细对比
qmd — porter unicode61
-- store.ts 建表语句
CREATE VIRTUAL TABLE documents_fts
  USING fts5(filepath, title, body,
  tokenize='porter unicode61');

-- 查询 "中文搜索" 的处理过程：
输入: "中文搜索"
split(/\s+/): ["中文搜索"] ← 整体
FTS5 索引: 中|文|搜|索 ← 逐字
✗ 查询词 ≠ 索引词，匹配失败
porter 是英文词根还原器（running→run），对中文无效
unicode61 按 Unicode 字符边界切分，中文逐字拆开
index1 — jieba + 默认分词器
# db.py 预处理
def tokenize_for_fts5(text):
  if has_cjk(text):
    return " ".join(jieba.cut(text))

# 查询 "中文搜索" 的处理过程：
输入: "中文搜索"
jieba.cut(): ["中文", "搜索"]
FTS5 查询: "中文" OR "搜索"
✓ 查询词 = 索引词，精确匹配
索引时和查询时都经过 jieba 分词，保证一致性
纯英文自动跳过 jieba，零额外开销
查询示例 index1 BM25 结果 qmd BM25 结果
"搜索功能" search.py, cli.py (精准) 无结果或随机匹配
"配置合并" config.py merge() (精准) 无结果
"search function" search.py (正常) search.py (正常)

MEASURED 基于 index1 源码项目实际搜索测试 · CODE qmd FTS5 配置来源: store.ts:519

🌏 index1 中日韩一键配置

index1（3 步完成）
pip install index1[chinese]
index1 config embedding_model bge-m3
index1 index --force
✓ 完成！支持中文搜索 + 跨语言查询
qmd（无官方方案）
1. 自行寻找中文 GGUF embedding 模型
2. 修改源码 store.ts 中的模型 URI
3. 修改维度配置，重建索引
4. FTS5 分词仍无法改善
✗ 无开箱即用的中文支持

MEASURED bge-m3 模型大小 ~1.2GB (BAAI/bge-m3) · MEASURED 1024d 向量 vs 768d: 存储 +33%, 索引 +40%, 搜索延迟 +15%

3资源需求 vs 规模 (资源需求)

3.1 索引构建时间

工具 索引策略 10K 文档 50K 文档 100K 文档 数据来源
Claude Native 无需索引 0 s 0 s 0 s MEASURED
index1 FTS5 倒排索引 ~10 s ~30 s ~60 s PROJECTED
index1 + Ollama FTS5 + Ollama embedding ~10 min ~45 min ~90 min PROJECTED @9K tok/s
qmd FTS5 + GGUF embedding ~8 min ~35 min ~70 min PROJECTED

3.2 数据库 / 存储大小

工具 存储内容 10K 50K 100K
Claude Native 无 (扫描源码) 0 MB 0 MB 0 MB
index1 FTS5 索引 + 原文 ~60 MB ~250 MB ~500 MB
index1 + Ollama FTS5 + 768d 向量 ~150 MB ~600 MB ~1.2 GB
qmd FTS5 + 向量 + llm_cache ~80 MB ~350 MB ~700 MB

3.3 运行时内存占用

工具 内存组成 10K 50K 100K
Claude Native ripgrep 进程 + 文件缓冲 ~50 MB ~150 MB ~400 MB
index1 Python + SQLite 页缓存 ~80 MB ~150 MB ~250 MB
index1 + Ollama Python + SQLite + Ollama 模型 ~600 MB ~700 MB ~800 MB
qmd Bun + SQLite + 3 GGUF 模型 ~2.5 GB ~2.7 GB ~3.0 GB

REFERENCE ripgrep 9.5M 文件 = ~400MB RSS (burntsushi/ripgrep#1823) · REFERENCE Ollama nomic-embed-text ~500MB resident

4搜索延迟 vs 规模 (延迟 at Scale)

延迟 = 从发起查询到返回结果的端到端时间。Claude Native 和 index1 有实测数据，qmd 基于组件基准推算。

4.1 端到端搜索延迟 (End-to-End Query 延迟)

工具 / 模式 计算公式 10K 文档 50K 文档 100K 文档
Claude Native (Grep) ripgrep_scan 30-50 ms 150-250 ms 300-500 ms
index1 + Ollama BM25 + embed + vec + RRF ~60 ms ~90 ms ~120 ms
index1 BM25 + RRF < 5 ms ~8 ms ~15 ms
index1 缓存命中 L1 cache lookup < 1 ms < 1 ms < 1 ms
qmd search (BM25) FTS5 only < 5 ms ~8 ms ~15 ms
qmd vsearch (Vector) embed + vec ~30 ms ~65 ms ~90 ms
qmd query (全管道) expand + BM25 + vec + RRF + rerank ~1,200 ms ~1,250 ms ~1,300 ms
qmd 缓存命中 llm_cache lookup ~5 ms ~5 ms ~5 ms
100K 文档搜索延迟对比
柱高 = 延迟，越短越快
400 ms
120 ms
15 ms
<1 ms
15 ms
90 ms
1,300 ms
5 ms
Grep
index1
+Ollama
index1
BM25
index1
cache
qmd
BM25
qmd
vector
qmd
full
qmd
cache

4.2 延迟可视化对比 (100K 规模)

关键词搜索 @ 100K 文档

Claude Native (Grep)300-500 ms
index1 + Ollama~120 ms
qmd query~1,300 ms

延迟增长趋势 (10K → 100K)

Claude Native10x 增长
index1 + Ollama2x 增长
qmd query1.08x 增长
qmd 延迟由 LLM 推理主导 (常数)，规模增长影响极小。
Grep O(N) 线性增长，index1 BM25 O(log N) 几乎不变。

index1 实测延迟分解 (当前规模)

Python 进程启动~80 ms
Ollama HTTP~50 ms
BM25 + Vec + RRF~85 ms
MEASURED MCP 长驻进程模式无启动开销，实际查询 ~85-120ms
MEASURED index1 实测数据 (17,725 chunks / 1,707 文档)
查询 引擎耗时 (Cold) 引擎耗时 (Hot) CLI 总耗时 Grep 对比
"中日韩" (低频词, 46行)576 ms94 ms0.21s0.43s (Grep 更慢)
"embedding" (中频, 257行)119 ms85 ms0.20s0.24s (接近)
"search" (高频, 950行)100 ms-0.22s0.21s (平手)
"config" (超高频, 4386行)119 ms-0.24s0.18s (Grep 快)
"搜索是怎么工作的" (中日韩 语义)91 ms-0.20sGrep 无法语义搜索
"向量搜索的实现原理" (中日韩 语义)89 ms-0.21sGrep 无法语义搜索
"how does search work" (EN 语义)332 ms-0.44sGrep 无法语义搜索
"how to configure watch paths"228 ms-0.34s需 2-3 次 Grep 组合

5Token 消耗 vs 规模 (Context Window Impact)

Token 消耗 = 搜索结果注入 AI 上下文窗口的 token 数。Grep 返回所有匹配行 (O(N))，index1/qmd 只返回 Top-K (常数)。 这是大规模项目中最关键的差异。

5.1 高频词 "search" 查询的 Token 消耗

规模 Grep 匹配行数 Claude Native (Grep) index1 (Top-5) qmd (Top-10) index1 节省
当前 (64 文件) 950 行 M ~36,000 tokens M ~460 tokens M ~900 tokens 98.7%
10K 文档 ~15,000 行 P ~375,000 tokens ~460 tokens ~900 tokens 99.88%
50K 文档 ~60,000 行 P ~1,500,000 tokens ~460 tokens ~900 tokens 99.97%
100K 文档 ~120,000 行 P ~3,000,000 tokens ~460 tokens ~900 tokens 99.98%

M = 实测, P = 基于词频密度线性推算。Claude 上下文窗口 200K tokens，100K 文档查 "search" 的 Grep 结果需要 15 个完整窗口才能装下。

5.2 不同词频的 Token 消耗对比 (100K 文档规模)

查询词 词频类型 Grep 匹配行 Grep Tokens index1 qmd index1 节省
中日韩 罕见词 ~1,000 ~25,000 ~460 ~900 98.2%
embedding 中频词 ~30,000 ~750,000 ~460 ~900 99.94%
search 高频词 ~120,000 ~3,000,000 ~460 ~900 99.98%
config 超高频 ~500,000 ~12,500,000 ~460 ~900 99.99%
import 极高频 ~800,000 ~20,000,000 ~460 ~900 99.99%

5.3 会话级别 Token 影响 (20 次搜索 / 200K 窗口)

Grep 消耗量级过大（10K 项目 250K tok / 100K 项目 2.4M tok），无可比性，此处仅对比 index1 与 qmd。

10K 文档项目

index1 消耗~9.2K (5%)
qmd 消耗~18K (9%)

50K 文档项目

index1 消耗~9.2K (5%)
qmd 消耗~18K (9%)

100K 文档项目

index1 消耗~9.2K (5%)
qmd 消耗~18K (9%)
index1/qmd 的 Top-K 输出始终 < 1K tokens，不受规模影响。
index1 返回量约为 qmd 的一半（460 tok vs 900 tok）。

6搜索质量评分 (搜索质量)

Claude Native (Grep/Glob)

精确匹配
语义搜索
中日韩 查询
结果排序
跨语言
召回率
准确率 (Precision)
适合: 已知标识符的精确查找

index1 + Ollama

精确匹配
语义搜索
中日韩 查询
结果排序
跨语言
召回率
准确率 (Precision)
适合: 探索性问题 + 多语言项目

qmd (Query + Rerank)

精确匹配
语义搜索
中日韩 查询
结果排序
跨语言
召回率
准确率 (Precision)
适合: 英文文档的高精度语义搜索

7功能矩阵 (功能矩阵)

功能 Claude Native index1 qmd
运行时Rust (ripgrep)Python 3.10+Bun (TypeScript)
搜索算法字面匹配 + 正则BM25 + Vector + RRFBM25 + Vector + QE + RRF + Rerank
BM25 全文搜索ripgrep (非 BM25)✓ FTS5✓ FTS5
向量语义搜索✗✓ sqlite-vec✓ sqlite-vec
Embedding 引擎N/AOllama (本地)node-llama-cpp (本地 GGUF)
默认 Embedding 模型N/Anomic-embed-text 768d (默认)
bge-m3 1024d (中日韩优化)		embeddinggemma-300M (仅英文)
模型生态与可扩展性
可选模型数量N/AOllama 生态 数百个仅 GGUF 格式
换模型方式N/A一条命令: index1 config embedding_model xxx改源码传 GGUF URI
模型预设档位N/A5 档 (lightweight / standard / chinese / multilingual / high_precision)无预设，写死 3 个模型
中文模型切换N/Aollama pull bge-m3 一键切换需自行寻找 GGUF 中文模型
模型热切换N/A✓ 改配置 + index --force✗ 需重新编译/重启
Query Expansion✗✗✓ Fine-tuned 1.7B GGUF
LLM Reranking✗✗✓ qwen3-reranker 0.6B GGUF
RRF 融合✗✓ k=60✓ k=60 + position-aware
查询缓存✗✓ L1/L2 (10min TTL)✓ llm_cache (SQLite)
MCP Tools3 (Grep/Glob/Read)56
分块策略无 (全文)5 种语言感知 (md/py/rs/js/txt)Markdown 分块 (800 tok/chunk)
支持文件类型所有文本.md .py .rs .js .ts .jsx .tsx .txt.md (Markdown)
中日韩优化✗✓ 动态调权 BM25=0.2/Vec=0.8✗
Web UI✗✓ Flask (port 6888)✗
文件监听✓ 实时✓ watcher✗
自动诊断 (doctor)N/A✓✗
外部服务依赖无Ollama (可选)无
跨平台macOS/Linux/WindowsmacOS/Linux/WindowsmacOS/Linux (Bun)

8跨平台兼容性 (Cross-platform Compatibility)

MCP 工具需要在不同 AI 编辑器中工作。以下对比各工具在主流 AI Agent 中的集成难度和兼容性。

8.1 AI 编辑器兼容矩阵

AI 编辑器 / Agent Claude Native index1 qmd
Claude Code ✓ 内置 ✓ MCP stdio ✓ MCP stdio
Cursor ✓ 内置 ✓ MCP stdio ✓ MCP stdio
Windsurf ✓ 内置 ✓ MCP stdio ✓ MCP stdio
Cline (VS Code) ✓ 内置 ✓ MCP stdio ✓ MCP stdio
OpenClaw ✓ 内置 ✓ MCP stdio ✓ MCP stdio
CLI / 脚本 ✗ 无独立 CLI ✓ index1 search ✓ bun run search

8.2 操作系统兼容性

平台 index1 qmd
macOS (ARM / Intel) ✓ pip / pipx ✓ bun
Linux (x64 / ARM) ✓ pip / pipx ✓ bun
Windows ✓ pip / pipx ⚠ Bun Windows 支持有限
Docker ✓ ✓

9适用场景推荐 (When to Use What)

Claude Native (Grep/Glob)

速度之王 — 适合精确查找和小规模项目
最佳场景
• 已知函数名/类名的精确查找
• < 10K 文件的小型项目
• 需要零延迟、零配置
• 正则表达式高级匹配
避免使用
• > 10K 文件 + 高频词 (token 爆炸)
• 语义理解 / 概念搜索
• 中文查英文代码
• 需要结果排序的场景
10K→100K 延迟增长
10x (O(N) 线性)

index1

均衡之选 — 低延迟 + 低 Token + 多语言
最佳场景
• 中大型多语言代码项目
• 中英文混合搜索 (中日韩优化)
• AI Agent Token 预算有限
• 需要同时搜 .py/.rs/.js/.md
避免使用
• 纯 Markdown 文档库 (qmd 更好)
• 追求极致 Precision (qmd 有 rerank)
• 内存 < 8 GB
10K→100K 延迟增长
2x (O(log N) BM25 + O(N) vec)

qmd

精度之王 — LLM Rerank 实现最高搜索质量
最佳场景
• 大型英文文档库 (README, 手册)
• 需要最高搜索精度
• 不想安装/维护 Ollama
• 有充足内存 (≥ 16 GB)
避免使用
• 代码文件搜索 (只支持 .md)
• 中日韩 / 多语言查询
• 追求低延迟 (< 500ms)
• 内存不足 (< 16 GB)
10K→100K 延迟增长
1.08x (LLM 推理常数主导)

10总评 (总评)

维度 Claude Native index1 qmd
搜索速度 (小规模)★★★★★★★★★☆★★☆☆☆
搜索速度 (大规模)★★☆☆☆★★★★☆★★★☆☆
搜索精度 (Precision)★★★☆☆★★★★☆★★★★★
Token 效率★★☆☆☆★★★★★★★★★☆
语义理解★☆☆☆☆★★★★☆★★★★★
中日韩 / 多语言★☆☆☆☆★★★★☆★★☆☆☆
易用性 / 零配置★★★★★★★★★☆★★★☆☆
资源消耗★★★★★★★★☆☆★★☆☆☆
代码文件支持★★★★★★★★★☆★★☆☆☆
大规模可扩展性★★☆☆☆★★★★☆★★★★☆
跨平台兼容性
macOS / Linux / Windows		★★★★★
macOS / Linux / Windows		★★★★★
macOS / Linux / Windows		★★★☆☆
macOS / Linux (Win 有限)
🤖 AI Agent 易用性★★★★☆★★★★★★★☆☆☆
🏆 总分 40 / 60 50 / 60 37 / 60

结论: 三工具组合策略

没有一个工具在所有维度上胜出。推荐的策略是根据项目规模和查询类型选择:

< 1K 文件: Claude Native 足够，无需额外工具。
1K-10K 文件: Claude Native (精确查找) + index1 (语义/中日韩 查询)。
10K-100K 文件: index1 为主 (Token 节省 99%+)，Grep 仅用于已知标识符。
大型英文文档库: qmd (最高精度) + Grep (快速定位)。
多语言代码项目: index1 (唯一支持 中日韩优化 + 5 种语言分块)。

MEASURED index1 实测: 17,725 chunks / 1,707 文档 / Apple M2 48GB · REFERENCE ripgrep (burntsushi.net), FTS5 (sqlite.org), sqlite-vec (alexgarcia.xyz), Ollama (collabnix.com) · PROJECTED 基于 O() 复杂度 + 组件基准推算

Claude Native = Grep/Glob/Read (ripgrep) | index1 = BM25 全文搜索 | index1 + Ollama = BM25 + 向量混合搜索 | qmd = BM25 + GGUF Vector + LLM Rerank

Generated 2026-02-06 | github.com/nichochar/index1