Search Tools Benchmark: Claude Native vs index1 vs qmd

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 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 快)
"搜索是怎么工作" (CJK 语义)91 ms-0.20sGrep 无法语义搜索
"向量搜索实现原理" (CJK 语义)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 组合

      
    

查询	引擎所要時間 (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）。

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 种言語分块)。

AI Code Search Tools Benchmark

Claude Native

index1

qmd

0データソースと方法論 (方法論)

データラベリング説明

1AI Agent 使用体验 (Agent Experience)

⚡ AI の検索結果読み取り速度比較

AI Agent 実際の使用比較: 1回の検索の完全なフロー

主要な AI Agent / エディタ互換性

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

2.1 CJK 機能マトリックス

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

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

🌏 index1 CJK一键配置

3リソース要件 vs 規模 (リソース要件)

3.1 索引构建時間

3.2 数据库 / 存储大小

3.3 运行时メモリ使用量

4検索レイテンシ vs 規模 (レイテンシ at Scale)

4.1 エンドツーエンド検索レイテンシ (End-to-End Query レイテンシ)

4.2 レイテンシ可視化比較 (100K 規模)

关键词搜索 @ 100K ドキュメント

レイテンシ增长趋势 (10K → 100K)

index1 実測レイテンシ分解 (当前規模)

5Token 消費 vs 規模 (Context Window Impact)

5.1 高頻度語 "search" 查询 Token 消費

5.2 不同词频 Token 消費比較 (100K ドキュメント規模)

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

10K ドキュメント项目

50K ドキュメント项目

100K ドキュメント项目

6検索品質评分 (検索品質)

Claude Native (Grep/Glob)

index1 + Ollama

qmd (Query + Rerank)

7機能マトリックス (機能マトリックス)

8クロスプラットフォーム兼容性 (Cross-platform Compatibility)

8.1 AI 编辑器兼容矩阵

8.2 操作系统兼容性

9適用シーン推荐 (When to Use What)

Claude Native (Grep/Glob)

index1

qmd

10総合評価 (総合評価)

结论: 三工具组合策略

5.1 高頻度語 `"search"` 查询 Token 消費