Search Tools Benchmark: Claude Native vs index1 vs qmd

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 FTS5 | sqlite.org 官方文档 + andrewmara.com 18M 行 trigram 基准 | 高 (官方+三方)
sqlite-vec | alexgarcia.xyz 官方 v0.1.0 发布基准 (SIFT1M/GIST500K) | 高 (作者发布)
Ollama embed | collabnix.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 需要理解的 API | 3 个 (直觉型) | 1 个统一入口 | 6 个 tools
索引初始化 | 无需 | 1 步: `index1 index` | 2 步: `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 ms | 94 ms | 0.21s | 0.43s (Grep 更慢)
`"embedding"` (中频, 257行) | 119 ms | 85 ms | 0.20s | 0.24s (接近)
`"search"` (高频, 950行) | 100 ms | - | 0.22s | 0.21s (平手)
`"config"` (超高频, 4386行) | 119 ms | - | 0.24s | 0.18s (Grep 快)
`"搜索是怎么工作的"` (中日韩 语义) | 91 ms | - | 0.20s | Grep 无法语义搜索
`"向量搜索的实现原理"` (中日韩 语义) | 89 ms | - | 0.21s | Grep 无法语义搜索
`"how does search work"` (EN 语义) | 332 ms | - | 0.44s | Grep 无法语义搜索
`"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 + RRF | BM25 + Vector + QE + RRF + Rerank
BM25 全文搜索 | ripgrep (非 BM25) | ✓ FTS5 | ✓ FTS5
向量语义搜索 | ✗ | ✓ sqlite-vec | ✓ sqlite-vec
Embedding 引擎 | N/A | Ollama (本地) | node-llama-cpp (本地 GGUF)
默认 Embedding 模型 | N/A | nomic-embed-text 768d (默认) bge-m3 1024d (中日韩优化) | embeddinggemma-300M (仅英文)
模型生态与可扩展性
可选模型数量 | N/A | Ollama 生态 数百个 | 仅 GGUF 格式
换模型方式 | N/A | 一条命令: `index1 config embedding_model xxx` | 改源码传 GGUF URI
模型预设档位 | N/A | 5 档 (lightweight / standard / chinese / multilingual / high_precision) | 无预设，写死 3 个模型
中文模型切换 | N/A | `ollama 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 Tools | 3 (Grep/Glob/Read) | 5 | 6
分块策略 | 无 (全文) | 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/Windows | macOS/Linux/Windows | macOS/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 种语言分块)。