Search Tools Benchmark: Claude Native vs index1 vs qmd

index1

# AI Code Search Tools Benchmark

Claude Native (Grep/Glob) vs index1 vs qmd — 3種類の検索ツールの異なる規模における完全なパフォーマンス比較

Apple Silicon M2 · 48 GB RAM テスト規模: 10K / 50K / 100K ドキュメント Ollama v0.15.4 · bge-m3 1024d (CJK) 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 チャンカー CJK最適化 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
--- | --- | ---
1回の検索返却量 | ~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 実際の使用比較: 1回の検索の完全なフロー

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 1個で完結
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 决策负担。

## 2CJK言語サポート比較 (CJK Language Support)

CJK言語の検索品質は、分詞精度、Embedding モデルの言語カバレッジとクエリ戦略の最適化の3つの次元に依存します。 以下比較に基づく index1 配置 bge-m3 + jieba 分词实际测試す结果。

### 2.1 CJK 機能マトリックス

能力項目 | Claude Native | index1 + bge-m3 | qmd
--- | --- | --- | ---
中国語分詞 | N/A (字面一致) | ✓ jieba 正確な分詞 pip install index1[chinese] | ✗ porter unicode61 Unicode 文字で分割、セマンティックなし
Embedding モデル | N/A | bge-m3 1024d BAAI 多言語モデル、CJK 最適化 | embeddinggemma 300M 英語中心、CJK セマンティック損失が深刻
CJK クエリ戦略 | N/A | 動重み付け CJK 検出時 → BM25=0.2 / Vec=0.8 | 固定权重 不区分言語，无自适应
言語横断検索 | ✗ 仅字面一致 | ✓ 中国語で英語コード検索 "配置合并" → config.py merge() | 限定 モデルのセマンティック能力が弱い
日本語 / 韓国語 | ✗ | ✓ bge-m3 ネイティブサポート ベクトル検索利用可能、BM25 には追加の分詞器が必要 | ✗

### 2.2 CJK 設定リソースオーバーヘッド

設定方案 | モデル大小 | 向量項目 | メモリ使用量 | 索引速度 (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 · CJK最適化 | ~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 CJK一键配置

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 比較
--- | --- | --- | --- | ---
`"CJK"` (低频词, 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 快)
`"搜索是怎么工作"` (CJK 语义) | 91 ms | - | 0.20s | Grep 无法语义搜索
`"向量搜索实现原理"` (CJK 语义) | 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 节省
--- | --- | --- | --- | --- | --- | ---
`CJK` | 罕见词 | ~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)

完全一致
语义搜索
CJK 查询
结果排序
跨言語
召回率
准确率 (Precision)
适合: 已知标识符精确查找

#### index1 + Ollama

完全一致
语义搜索
CJK 查询
结果排序
跨言語
召回率
准确率 (Precision)
适合: 探索性问题 + 多言語项目

#### qmd (Query + Rerank)

完全一致
语义搜索
CJK 查询
结果排序
跨言語
召回率
准确率 (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 (CJK最適化) | 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)
CJK最適化 | ✗ | ✓ 动态调权 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 + 多言語

最佳场景
  • 中大型多言語コード项目
  • 中英文混合搜索 (CJK最適化)
  • 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)
  • CJK / 多言語查询
  • 追求低レイテンシ (< 500ms)
  • 内存不足 (< 16 GB)
10K→100K レイテンシ增长
  1.08x (LLM 推理常数主导)

## 10総合評価 (総合評価)

項目 | Claude Native | index1 | qmd
--- | --- | --- | ---
搜索速度 (小規模) | ★★★★★ | ★★★★☆ | ★★☆☆☆
搜索速度 (大規模) | ★★☆☆☆ | ★★★★☆ | ★★★☆☆
搜索精度 (Precision) | ★★★☆☆ | ★★★★☆ | ★★★★★
Token 效率 | ★★☆☆☆ | ★★★★★ | ★★★★☆
语义理解 | ★☆☆☆☆ | ★★★★☆ | ★★★★★
CJK / 多言語 | ★☆☆☆☆ | ★★★★☆ | ★★☆☆☆
易用性 / 零配置 | ★★★★★ | ★★★★☆ | ★★★☆☆
资源消費 | ★★★★★ | ★★★☆☆ | ★★☆☆☆
コード文件サポート | ★★★★★ | ★★★★☆ | ★★☆☆☆
大規模可扩展性 | ★★☆☆☆ | ★★★★☆ | ★★★★☆
クロスプラットフォーム兼容性 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 (语义/CJK 查询)。
10K-100K 文件: index1 为主 (Token 節約 99%+)，Grep 仅用于已知标识符。
大型英文ドキュメント库: qmd (最高精度) + Grep (快速定位)。
多言語コード项目: index1 (唯一サポート CJK最適化 + 5 种言語分块)。