效能評測
559 工具下的
路由準確率
三組評測集、兩種模型大小同一個 router、同一份 FAISS 索引、同一批 manifests 下面數字來自最新 router build（multilingual-e5-base，RERANK_ALPHA=0.7）
實驗設定
- 工具池：559（CLIbrary 499 + MCP 60）
- Embedding 模型：
intfloat/multilingual-e5-base（768 維） - 策略：
clibrary— FAISS top-1 → 用小 LLM 抽參數（或 A 路套模板） - 後端：Ollama 本地（qwen2.5:3b、qwen2.5:14b）
- Manifests：504 個，intent_triggers 經過 3 輪修補
核心發現
只要 routing 由 embedding-based router 處理，模型大小就變得不重要 qwen2.5:3b 和 qwen2.5:14b 在 1,500 筆 paraphrase 評測上的 CLI 準確率幾乎完全一樣
| 模型 | 評測 | 樣本 | CLI 準確 | Top-3 | Pick | 參數 | E2E |
|---|---|---|---|---|---|---|---|
| qwen2.5:3b | paraphrase | 1,500 | 81.80% | 83.40% | 98.08% | 69.00% | 61.27% |
| qwen2.5:14b | paraphrase | 1,500 | 81.67% | 83.27% | 98.08% | 68.87% | 61.20% |
| Δ (3b − 14b) | +0.13pp | +0.13pp | ±0 | +0.13pp | +0.07pp | ||
當 router 扛起檢索責任，把 LLM 從 3B 換到 14B（4.7 倍參數）幾乎沒帶來任何額外準確率在大模型上花的算力是浪費——把資源放在更好的 intent_triggers 上面
更極端的版本：在 in_domain 評測上，約 98% 的 query 走 A 路（直接套模板，完全不呼叫 LLM）：
| 模型 | 評測 | 樣本 | CLI 準確 | Top-3 | A 路命中 |
|---|---|---|---|---|---|
| qwen2.5:3b | in_domain | 500 | 86.80% | 88.00% | 98.64% |
| qwen2.5:14b | in_domain | 500 | 86.80% | 88.00% | 98.64% |
| Δ (3b − 14b) | ±0 | ±0 | ±0 | ||
兩個模型的所有指標連小數點後 4 位都一樣——當 98.6% 的 query 完全跳過 LLM，模型大小就邏輯上不可能造成差別
Adversarial 評測集
Adversarial 評測共 204 筆，每個 intent 都被刻意設計來誤導 router：
表面詞彙指向工具 A，但語意核心是工具 B（intent confusion、false friends、ambiguous scope、negation traps）下面數字皆使用 clibrary_top3 策略
| 階段 | CLI 準確 | Top-3 | FAISS miss |
|---|---|---|---|
| 原始 FAISS | 58.0% | 78.9% | 43 / 204 |
| + Trigger Patch R1（10 CLIs） | 73.5% | 88.2% | 24 / 204 |
| + Trigger Patch R2（23 CLIs） | 83.3% | 97.1% | 6 / 204 |
| + Trigger Patch R3（4 CLIs） | 86.3% | 100% | 0 / 204 |
套用 R3 後 FAISS 索引、兩個模型對照：
| 模型 | 樣本 | CLI 準確 | Top-3 | Pick | 參數 | E2E |
|---|---|---|---|---|---|---|
| qwen2.5:3b | 204 | 84.31% | 100% | 84.31% | 86.27% | 77.94% |
| qwen2.5:14b | 204 | 86.27% | 100% | 86.27% | 87.75% | 79.90% |
Top-3 = 100% 表示正確工具一定在前三名；CLI 準確 84–86% 之間的差距，是 LLM 從這 3 個裡挑錯的部分大模型在這裡略有幫助（+1.96 pp）——這是整份報告中唯一能看到模型大小確實有影響的場景
其他評測集（qwen2.5:3b）
| 評測 | 策略 | 樣本 | CLI 準確 | Top-3 | E2E |
|---|---|---|---|---|---|
| in_domain | clibrary | 500 | 86.80% | 88.00% | 65.20% |
| paraphrase | clibrary | 1,500 | 81.80% | 83.40% | 61.27% |
| cross_domain | clibrary | 328 | 68.90% | — | 67.70% |
| adversarial（R3 後） | clibrary_top3 | 204 | 84.31% | 100% | 77.94% |
延遲與成本
Router 本身的指標（不含 B 路 LLM call）：
- 延遲 p50：36 毫秒
- 延遲 p95：39 毫秒
- A 路命中率：~80% 的 query 完全不呼叫 LLM
- Token 成本（A 路）：0 — 純檢索套模板
- Token 成本（B 路）：~150 — 與工具數無關，固定值
可重現性
Router 已上 PyPI（pip install clibrary-hub）和 GitHub
（clibrary-hub/CLIbrary）
工具庫在 clibrary-hub/cli-tools
評測集隨 router repo 一起發佈，路徑 benchmark/eval_sets/