概念位置

主流 LLM benchmark 一覽：

事實查核註：各 benchmark 的飽和狀態、前沿模型 score 持續變動、上述為 2026/5 主流觀察。引用前以 Papers with Code 或 HuggingFace Open LLM Leaderboard 當前狀態為準。

Benchmark 的常見陷阱

1. 訓練資料污染（Contamination）：benchmark 題目本身在 pretrain corpus 出現過、模型「記得」答案、看似強實際是 memorization
2. 飽和（Saturation）：前沿模型 score 接近上限、無法區分模型品質差距（HumanEval 80%→95% 看似進步、實際 5% 多半是 lucky 而非實質提升）
3. LLM-as-judge bias：用 LLM（如 GPT-4）評其他 LLM、judge 的偏好（如「冗長 = 好」）會 bias 評分
4. Single-task overfitting：模型廠商針對 benchmark 特別 fine-tune、benchmark 高分但通用能力沒提升
5. Prompt sensitivity：同個 benchmark 用不同 prompt format、score 差幾個百分點

設計責任

讀 model card / paper 看到 benchmark 數字、判讀框架：

1. 看 multiple benchmarks、不只一個：如挑 coding 模型、看 HumanEval + MBPP + SWE-bench、不只看 HumanEval
2. 跟自己任務對齊的 benchmark 才重要：你做 RAG 應用、看 retrieval benchmark；你做 chat、看 MT-Bench / Arena
3. 看「相對」、不只看「絕對」：「Model A 在 MMLU 比 Model B 高 2%」可能 noise；「A 比 B 高 10%」更可信
4. In-house benchmark 是最後檢驗：自己的真實工作流案例 > 任何公開 benchmark

實測日期：2026-07-01 環境：macOS Apple Silicon、Ollama 0.7.x、nomic-embed-text（768 維） Corpus：content/ 全量 2,738 個 markdown 檔、24,216 chunks 前置 demo：rag-demo（pickle、463 chunks）

讀法建議

本案例用 Go 重寫了 RAG storage 層，Go 實作細節佔不少篇幅。依你的背景選讀法：

• Python 開發者、想選自己專案的 storage 方案：先跳到「通用可複製流程」（語言無關的五步驟）→「四方案 benchmark」→「二次選型評估」（結論/理由/前提三層框架），這三段跨語言可遷移。Go 實作段（架構、效能優化）可 skim。
• Go 開發者、想做類似工具：從頭讀，每段都跟你相關。
• 只想看選型框架、不管實作：直接跳「二次選型評估」。

從 demo 到 production 的重寫動機

rag-demo 用 Python pickle 跑通了 RAG 概念驗證：71 篇 → 463 chunks → pickle 儲存 → cosine retrieval → Ollama 生成。概念層完全正確（4.1 的 retrieval + augmentation 骨架），但作為這個 blog 的日常工具有三個專案特有的限制：

1. 工具鏈語言不同：blog 的核心工具是 Go（lint / fmt / cards），加 Python dependency 讓其他維護者 clone 後多一步環境設定。Python 專案不會有這個問題 — pickle 綁 Python 對 Python 專案是優點而非缺點。
2. 只索引部分 corpus：rag-demo 只跑 content/llm/（71 篇），blog 全量有 2,738 篇、24 個 section。
3. Demo 定位：ingest.py / query.py 是教學程式碼，不是維護工具（沒有 status、沒有 section filter）。

這是一次完整重寫、不是漸進升級 — rag-demo 的 Python 程式碼不會被修改或遷移，而是用 Go 重新實作相同的 RAG pipeline（chunk → embed → store → search）、保留相同的概念架構。rag-demo 作為教學 demo 繼續存在。

升級目標：一個跟 mdtools 同級的 Go CLI 工具，能對全量 content 做語意搜尋，其他維護者 clone 後 go build 即可用。完整原始碼在 scripts/blogsearch/。

選型過程（對應 4.22 演化階梯 + 工程約束）

第一軸：規模判讀

全量 content 產生 24,216 chunks（原本估計 ~1,500）。按 4.22 判讀樹，24K 落在「10K-100K → HNSW 或 brute-force」區間。預估 vs 實際的 16 倍落差揭露一個教訓：估計 chunk 數不能用篇數乘以常數，要看每篇的實際長度跟 chunking 策略。

第二軸：工程約束（本專案特有）

以下四個 constraint 反映這個 blog 專案的偏好、不是通用判準。換一組 constraint 會篩出完全不同的方案 — Python 專案不會有「Go 單 binary」constraint、已有 Docker 的團隊不會排斥外部 server。讀者套用時應先列出自己專案的 constraint、不是照搬這張表。

剩餘選項：Go + flat file + brute-force。

第三軸：延遲容忍

CLI 工具、每天用幾次、不是 API server。< 500ms 可接受。

結論：選階段二（flat file），brute-force cosine。

實作架構

 1scripts/blogsearch/
 2├── main.go                     # CLI: ingest / query / status
 3├── cmd/
 4│   ├── ingest.go               # walk content/ → chunk → embed → store
 5│   ├── query.go                # load → embed query → cosine top-K → lazy load text
 6│   └── status.go               # index stats
 7└── internal/
 8    ├── chunk/chunk.go           # paragraph-aware markdown chunking
 9    ├── embed/embed.go           # Ollama HTTP API wrapper
10    ├── search/search.go         # brute-force cosine similarity
11    └── store/store.go           # 三檔案 binary store

日常使用

1# 語意搜尋
2./bin/blogsearch query "retry 策略"
3
4# 只搜特定 section
5./bin/blogsearch query -section backend "connection pool 設定"
6
7# 查 index 狀態
8./bin/blogsearch status

Storage 格式（三檔案分離）

1.blogsearch/
2├── vectors.bin    # float32 binary（70.9 MB）— bulk read + unsafe.Slice 零拷貝
3├── meta.json      # compact metadata 不含 text（7.3 MB）
4└── texts.bin      # length-prefixed chunk text（19.2 MB）— top-K 才 lazy load

分離 text 的設計理由：query 時只需要 vectors + metadata 做 cosine search（78 MB），top-K 結果才從 texts.bin 按 offset 讀取 5 筆 text。省掉 19 MB 的 JSON 解析。

效能優化歷程

初版：9.5 秒

初版用逐 4-byte Read 載入 vectors.bin（17.5M 次 f.Read(buf)），加上 27MB 的 index.json（含所有 chunk text）一次 JSON 解析。

優化版：0.34 秒（28x）

三項改動：

瓶頸分析：0.34 秒裡、embedding API call（Ollama）約 77ms、file I/O + JSON parse 約 200ms、cosine 計算約 50ms。cosine 計算只佔 15%。

通用可複製流程（抽掉 Go/blog）

本案例的 Go 實作細節（unsafe.Slice、os.ReadFile）是語言特定的、但背後的流程步驟跨語言通用：

1. Walk corpus：遞迴掃描目標目錄的所有文件（markdown / code / 任意文字）
2. Chunk：段落感知分割、soft token cap、保留語意邊界（原理見 4.1 Chunking）
3. Embed：對每個 chunk 呼叫 embedding API（本地 Ollama 或 cloud API），得到固定維度向量
4. Store：向量 + metadata + text 分離存檔（binary vectors / compact JSON / lazy-load text）
5. Search：embed query → brute-force cosine → top-K → lazy load text for display

Python 實作同流程只是把第 4 步的 binary 檔換成 pickle / FAISS index / SQLite DB、第 5 步的 cosine 換成 numpy / FAISS / sqlite-vec query。Node.js / Rust 同理。

關鍵優化原則也跨語言：「分離向量與文字、query 時只載入向量、top-K 才載入文字」讓 I/O 量從 ~98MB 降到 ~78MB、JSON parse 從 27MB 降到 7MB。這個原則用什麼語言實作都有效。

四方案同 corpus Benchmark

用同一個 corpus（24,216 chunks、768 維、nomic-embed-text）比較四種 storage 方案。Benchmark 腳本在 scripts/blogsearch-bench/bench.py。

前置依賴

Benchmark 腳本讀 Go 工具產生的 index（.blogsearch/ 下的 vectors.bin + meta.json）。完整指令鏈：

1cd scripts/blogsearch && go build -o ../../bin/blogsearch .   # build Go 工具
2ollama serve &                                                  # 啟動 Ollama
3ollama pull nomic-embed-text                                    # pull embedding model
4./bin/blogsearch ingest -content content -out .blogsearch       # 建 index（~4 分鐘）
5uv run --with sqlite-vec --with faiss-cpu --with numpy \
6  scripts/blogsearch-bench/bench.py --index .blogsearch         # 跑 benchmark

若無 Go 環境，可用自己的 Python embedding 腳本產生相同格式的 vectors.bin（little-endian float32、n × dim 連續排列）+ meta.json（{"dim": 768, "count": n, "metas": [...]}），benchmark 腳本只讀這兩個檔案、不依賴 Go binary 本身。Corpus 格式無硬性要求，任何目錄下的 .md 檔案都可索引。

方法論

• Embedding：四方案共用同一組 embedding（從 Go index 載入），排除 embedding model 差異
• Query：同一句 query（“RAG storage 選型”），跑 5 次取 median
• Ingest 時間：只計 storage 操作（不含 embedding），Go 方案含 embedding 不可分離故標 —
• 環境：macOS Apple Silicon、Python 3.12、Go 1.25

結果

三個關鍵發現

延遲瓶頸在 I/O 和實作、不在演算法。Go flat file 的 151ms 裡、cosine 計算約 50ms、file I/O 約 100ms。FAISS flat 用 numpy BLAS 做同樣的 brute-force cosine、純計算 1.8ms — 計算層差約 28 倍（Go pure loop vs BLAS 向量化指令），加上 I/O 後端到端差 84 倍。

HNSW 的 query 加速在此規模 ROI 低。FAISS HNSW query 0.5ms vs flat 1.8ms、每次省 1.3ms。但 HNSW build 要 23.3s。每天查 100 次、要 179 天才回本 build 成本（23.3s ÷ 0.13s/天）。4.22 的判讀結論（「此規模 brute-force 夠用」）被數據驗證。

sqlite-vec 的 19ms 是「DB overhead 換功能」。比 FAISS flat 慢 10 倍、但多了 SQL metadata filter、transaction 保護、disk persistence。對「需要 filter 但不想維運 server」的場景有意義。

讀數據的注意事項

• Go 151ms 含 file I/O（每次 query 重載 78MB）；如果做 daemon mode（常駐、載入一次），query 會降到 ~50ms（純 cosine + overhead）
• FAISS 數字是 in-memory baseline（index 已載入），不含 index 檔案的載入時間
• sqlite-vec 數字含 disk I/O（每次 query 從 SQLite 讀取），是 persistent storage 的真實代價
• 四方案都不含 Ollama embedding call 時間（~77ms），實際端到端延遲要加上

二次選型評估：同結論、理由鏈翻轉

Benchmark 數據出來後，80 倍效能差距讓原始選型（Go + flat file）受到質疑：「是否該換 Python + FAISS 或 sqlite-vec？」重新用 WRAP 框架評估，結論相同（維持 Go），但理由鏈完全不同。

第一次選型的理由（事前）

「Go 工具鏈統一（mdtools 是 Go）+ 單 binary 分發（clone 後 go build 即可）。」

實測推翻的前提

第一次的理由鏈幾乎全數被推翻。如果只看理由，應該換方案。

第二次選型的理由（事後）

重新評估時加入三個第一次沒有的變數：

端到端延遲 vs in-memory benchmark。84 倍是端到端的數字（Go 151ms 含 I/O vs FAISS 1.8ms in-memory）。但 FAISS 從 disk 載入 index 也要 ~100-200ms，端到端差距縮小到 2 倍。sqlite-vec 是唯一不需要全量載入的方案（disk-based HNSW、端到端 19ms），差距從「84 倍」變成「8 倍」。

使用頻率決定 ROI。CLI 工具、每天 ~10 次手動 query。每次省 130ms（151 vs 19），一天省 1.3 秒。重寫投入 2-3 小時，回本時間 ≈ 19 年。注意這個計算對頻率極敏感：每天 100 次（如被整合進 MCP server 當 agent 工具）回本縮短到 1.9 年、每天 1000 次則 69 天。上方 HNSW ROI 也用每天 100 次計算 — 兩處頻率假設不同是因為比較對象不同（HNSW build 成本 vs 語言重寫成本），但讀者套到自己場景時應先確定自己的查詢頻率。

Ingest 瓶頸在 Ollama API、跟語言無關。~4 分鐘的 ingest 裡、embedding API call 佔 95% 以上。換 Python 不會改善 ingest 速度。

維持的理由是「痛點不存在」

維持 Go 的理由是改善的絕對收益太小、投入回不了本 — 151ms 對 CLI 使用模式不構成痛點，與「Go 好」或「工具鏈統一」無關。

這個翻轉的教學意義

正確的結論配錯誤的理由是脆弱的。第一次 WRAP 的結論（選 Go）在當時是對的，但理由鏈（工具鏈統一、< 10ms）被實測推翻後，如果不重新建立正確的理由鏈，下次環境變動（比如 blogsearch 從 CLI 變成 API server）就會用已失效的理由做出錯誤判斷。

判讀工具選型時，要區分三層：

1. 結論：選什麼方案
2. 理由：為什麼選（可能被推翻）
3. 前提：理由依賴的假設（規模、使用模式、效能數字）

前提變了、理由就要重建，即使結論沒變。寫進決策紀錄時，三層都要記 — 只記結論的話，下次重新評估時沒有判讀基礎。

區分「正當理由重建」跟「動機性推理」（先有結論再找理由）的判準：新理由是否在看到數據之前也能成立？本例的「130ms 對 CLI 不痛」在實測前也成立（CLI 使用模式本來就低頻），所以是正當重建。如果新理由只能在看到特定數字之後才講得通（如「151ms 剛好在 200ms 閾值內」——但閾值是事後設的），就是 post-hoc rationalization。

觸發換方案的訊號

Embedding model 選型（對應 4.12 constraint 優先序）

選 nomic-embed-text 的理由鏈：

1. Ollama 原生支援：ollama pull 一行、不需要額外 Python library 或 API key
2. 體積小：274 MB、跟 chat model 共用記憶體不打架
3. 已有驗證基線：rag-demo 用同一個模型跑過 463 chunks、retrieval 命中率確認可用
4. 768 維 sweet spot：24K chunks × 768 dim × 4 bytes = 70.9 MB，brute-force 可行

未來如果 CJK retrieval 品質不夠（目前可用但未做系統性評估），multilingual-e5-large 或 bge-m3 是備選。換模型只需改 embed.go 的 Model 變數 + 重新 blogsearch ingest（4.22 的「四層可替換」設計）。

CJK 混合 Chunking 觀察

Blog 內容是繁體中文 + 英文術語混合。Chunking 策略沿用 rag-demo 的 paragraph-aware split（空白行切段、soft token cap 400）。

Token 估算用 len(s) / 2 的 heuristic（CJK 字元多算一次）。不精確但 chunking 只需要粗略估算。跟 tokenizer 精確計算的差異在 ±20%、對 chunking 品質影響小於 chunk 邊界選擇的影響。

實際觀察：24,216 chunks 的 retrieval 品質在語意搜尋場景（「哪些文章跟 retry 有關」「RAG storage 選型」）表現良好。keyword 精確搜尋場景（「找 RFC 7807」）表現較弱 — 這是 embedding-only retrieval 的已知限制（見 4.1 的語意 vs 字面相似度對比），未來可加 BM25 做 hybrid search。

跟其他章節的對應

寫入吞吐

寫入吞吐決定 collector 每秒能消化多少事件。SQLite 的寫入效能主要受 fsync 頻率和 WAL checkpoint 影響。

單筆 INSERT

每筆 INSERT 獨立一個 transaction 時，每次 commit 都會 fsync。WAL mode 的 fsync 成本比 journal mode 低（append-only），但仍是寫入的主要瓶頸。

modernc.org/sqlite（pure Go）的效能約為 CGO driver（mattn/go-sqlite3）的 60-80%。上表數字基於 CGO driver，pure Go 需打八折。Go HTTP handler 的開銷（JSON 解碼、schema 驗證、goroutine 調度）再扣 10-20%。

批次 INSERT

一個 transaction 包裹多筆 INSERT，只做一次 fsync。Collector 接收 SDK 的 flush batch（一個 HTTP request 帶一批事件）天然適合批次寫入。

吞吐提升幅度和批次大小的關係：

提升來自 fsync 次數從「每筆一次」降到「每批一次」。超過 100 筆/tx 後邊際收益遞減。

實際預期

結合 pure Go driver、HTTP handler 開銷和批次寫入，不同環境下的預期吞吐：

和事件產生速率的對照

burst 和持續的差異在於：burst 是短暫的高峰（flush batch 到達後數秒內消化完），持續是長時間的穩定高流量。SQLite 的 WAL mode 對 burst 容忍度高（write lock 等待時間短），對持續高流量容忍度有限（write lock 等待累積）。

查詢延遲

查詢延遲決定 dashboard 的刷新體驗。SQLite 的查詢效能取決於索引覆蓋和掃描行數。

有索引的查詢

建議的索引（見 規模演進 的建議索引段）覆蓋 dashboard 的核心查詢模式。有索引時的預期延遲：

無索引的查詢

無索引時 SQLite 做全表掃描。掃描速度約 50-100 MB/sec（SSD）、10-30 MB/sec（HDD）。

超過 100 萬筆無索引查詢會超出 dashboard 可接受的刷新延遲 — 這是 day-one 就建索引的理由。

Dashboard 刷新頻率 vs 查詢延遲

Dashboard 的每個視圖有不同的刷新間隔和可接受延遲。查詢延遲超過可接受值時，dashboard 體驗變差（等待轉圈、資料過時）。

「需要預聚合」代表原始事件的聚合查詢超過可接受延遲，應該依賴分層保留策略中的 hourly_summary / daily_summary 表（見 規模演進 的分層保留段）。

資源消耗

記憶體

Raspberry Pi（1 GB RAM）上建議把 page cache 調小（PRAGMA cache_size = -512 = 512 KB），避免大結果集查詢（加 LIMIT），dashboard 刷新頻率降低。

CPU

磁碟

WAL 檔案通常 < 10 MB（auto-checkpoint 在 WAL 達到 1000 pages 時觸發）。分層保留策略下，原始事件只保留 7 天，長期佔用由聚合摘要表決定（遠小於原始事件）。

邊緣設備場景

Raspberry Pi、低配 VPS（1 核 / 1 GB RAM）、甚至 NAS 上跑 collector 時的特殊考量：

SD card 的隨機寫入：SD card 的隨機寫入 IOPS 極低（100-500 IOPS），WAL mode 的 checkpoint（把 WAL 內容合併回主資料庫檔案）可能卡住 1-5 秒。期間新的寫入等待 checkpoint 完成。建議調高 wal_autocheckpoint 的閾值（如 5000 pages），讓 checkpoint 頻率降低但每次時間更長 — 在非活躍時段（凌晨）手動觸發 PRAGMA wal_checkpoint(TRUNCATE)。

1 GB RAM：cache_size 調小（512 KB）、避免 SELECT * 不帶 LIMIT、GROUP BY 的結果集用 HAVING 條件過濾減少暫存。Dashboard 的長期聚合直接查 hourly_summary 表而非原始事件。

ARM CPU：pure Go SQLite driver（modernc.org/sqlite）在 ARM 上的效能差距可能比 x86 更大（pure Go 的 C-to-Go 翻譯在 ARM 的指令最佳化較少）。實測確認。

建議配置：邊緣設備上 collector 的 dashboard 刷新頻率從預設值降低（即時狀態卡 5 秒 → 30 秒，趨勢圖 30 秒 → 5 分鐘），降採樣 job 頻率從每小時改為每 6 小時。

實測方法指引

教學的預期數字是推導值，實際效能取決於使用者的硬體和 workload。Collector 提供內建的 benchmark 命令讓使用者在自己的環境實測。

寫入 benchmark

1# 單筆寫入：10000 筆，每筆獨立 transaction
2./collector benchmark write --events=10000 --batch=1 --storage=sqlite
3
4# 批次寫入：10000 筆，每 100 筆一個 transaction
5./collector benchmark write --events=10000 --batch=100 --storage=sqlite

輸出：total duration、events/sec、p50/p95/p99 latency per event。

查詢 benchmark

1# 先灌入測試資料
2./collector benchmark seed --events=100000 --storage=sqlite
3
4# 跑查詢 benchmark
5./collector benchmark query --type=error --group-by=name --storage=sqlite
6./collector benchmark query --session-id=random --storage=sqlite

輸出：query duration、rows scanned、rows returned。

Production 觀察指標

部署後用 DevOps dashboard（見 DevOps Dashboard 設計）觀察 collector 自身的效能 metric：

• collector.storage.write_duration_ms：每次寫入的延遲。P95 超過 100ms 是瓶頸訊號。
• collector.storage.query_duration_ms：每次查詢的延遲。P95 超過 dashboard 刷新間隔是瓶頸訊號。
• collector.storage.db_size_bytes：資料庫大小。接近磁碟可用空間的 80% 時觸發 purge 或擴容。
• collector.storage.wal_size_bytes：WAL 檔案大小。持續 > 50 MB 代表 checkpoint 跟不上寫入速度。

下一步路由

• 切換到 PostgreSQL 的觸發條件 → 規模演進
• SQLite 和 PostgreSQL 的功能分層 → 功能分層與 Backend 選擇
• Ingestion 端的擴展設計 → Ingestion Scaling

本章是 eval 設計的具體實作層——meta 層的 eval 軸選擇（先看軸再看工具的三軸座標）見 4.13 Eval 設計座標系、subjective eval 的核心工具見 4.21 LLM-as-Judge。三章合起來才是 production AI app 的完整 eval pipeline。

本章目標

讀完本章後、你應該能：

1. 看 model card benchmark 數字、判讀對自己場景的相關性。
2. 區分 capability benchmark（MMLU 等）跟 performance benchmark（tok/s 等）。
3. 跑 llama-bench 量測自己硬體 + 模型的真實速度。
4. 設計 in-house benchmark 評估自己工作流的真實品質。
5. 看到 benchmark 異常數字時、知道可能的陷阱。

Capability benchmarks：衡量模型「會什麼」

LLM benchmarks 卡片列了主流 benchmark 的覆蓋面。本節展開對寫 code 場景最相關的幾個：

Coding benchmarks 的演化

判讀建議：

1. 看 SWE-bench、別只看 HumanEval：HumanEval 早飽和、無法區分前沿模型；SWE-bench 仍有大差距、可信度高
2. HumanEval 90% vs 95% 差異不大：飽和區間的 noise 大、判斷 coding 能力靠 SWE-bench / 真實任務測
3. LiveCodeBench 避免污染：定期出新題、模型訓練 cutoff 後的題目不在 pretrain corpus、更能反映真實能力

事實查核註：本章所列 benchmark 飽和狀態（HumanEval 90%+、MMLU 85%+、GSM8K 90%+）、SOTA 數字（SWE-bench < 60%）、各模型在各 benchmark 的相對排名 — 都是 2026/5 估計、隨新模型推出快速變動、引用前以 Papers with Code 跟 HuggingFace Open LLM Leaderboard 當前狀態為準。

Reasoning benchmarks

判讀：

1. Reasoning model 在 AIME / GPQA 顯著領先 instruct model：這正是 reasoning model 的優勢區
2. MMLU 飽和：85%+ 後差別意義不大、改看 MMLU-Pro
3. GSM8K 接近飽和：90%+、改看 MATH / AIME

Long context benchmarks

判讀：聲稱「128K context」要配 RULER / LongBench 分數才知道實用、見 4.11 Long context engineering。

Performance benchmarks：衡量「跑多快」

跟 capability 並列的另一條軸 — 推論速度：

llama-bench：標準工具

llama.cpp 內建 benchmark 工具：

 1# 基本測試：純 generation 速度
 2llama-bench -m model.gguf -p 512 -n 128
 3# -p 512：prompt 512 token（測 prefill）
 4# -n 128：generate 128 token（測 decode）
 5
 6# 不同 context 長度的影響
 7llama-bench -m model.gguf -p 512,2048,8192 -n 128
 8
 9# 開 flash attention
10llama-bench -m model.gguf -p 512 -n 128 -fa 1
11
12# Speculative decoding 對比
13llama-bench -m target.gguf --draft-model drafter.gguf \
14            -p 512 -n 128 --speculative-draft 5

輸出範例：

1| model                |       size |     params | backend    | ngl |   test |              t/s |
2| -------------------- | ---------: | ---------: | ---------- | --: | -----: | ---------------: |
3| gemma3 31B Q4_K - M  |  18.45 GiB |    31.21 B | Metal      |  99 |  pp512 |    324.21 ± 1.27 |
4| gemma3 31B Q4_K - M  |  18.45 GiB |    31.21 B | Metal      |  99 |  tg128 |     28.43 ± 0.31 |

讀法：

• pp512：prefill 512 token 的 throughput（tok/s）
• tg128：generate 128 token 的 throughput（tok/s、即 tok/s）
• ± 0.31：多次跑的 std deviation、< 5% 是穩定基線

推論成本 vs 品質的 trade-off 矩陣

對自己機器跑 llama-bench 後、可以建一個矩陣：

1                     tok/s 高           tok/s 中           tok/s 低
2品質（HumanEval）
3     高              [Q4 7B coder]      [Q4 14B coder]    [Q4 30B reasoning]
4     中              [Q4 14B instruct]  [Q4 30B instruct]
5     低              [Q4 30B base]      [unused]          [unused]

對應到實際選型：

• 自動補完（高頻、低品質需求）：左上 tok/s 高的小模型
• 對話（中頻、中品質需求）：中段
• 複雜 reasoning（低頻、高品質需求）：右下大 reasoning model

In-house benchmark：自己工作流的真實評估

最重要的 benchmark 是「自己真實任務上的表現」、公開 benchmark 是粗略 filter。

建立 in-house benchmark 的步驟

 11. 蒐集真實案例
 2   - 從過往工作流挑 30-100 個有代表性的任務
 3   - 含「容易任務」「中等任務」「困難任務」三類
 4   - 每個任務記錄 (input prompt, expected output 或評分標準)
 5
 62. 定義評分機制
 7   - Objective（最理想）：unit test、exact match、能機械驗證
 8   - Semi-objective：rubric 評分、人工或 LLM-as-judge
 9   - Subjective（最後手段）：人工 A/B 偏好
10
113. 跑 candidate models
12   - 對每個模型、每個任務都跑、記錄輸出
13   - 注意推論參數一致（temperature、top-p、max_tokens 一樣）
14   - 注意 prompt 一致（chat template、system prompt）
15
164. 評分
17   - Objective：跑 test、算 pass rate
18   - Semi-objective：建 rubric、評分
19   - Subjective：人工 / LLM 評
20
215. 看分佈、不只看平均
22   - 平均 80% 可能來自「20 題滿分 + 80 題 70%」或「100 題 80%」
23   - 看 std、看哪些任務崩、針對性 debug

LLM-as-judge 的注意點

用 LLM（如 GPT-4、Claude）評其他 LLM 是省人力的方法、但有 bias：

1. Verbosity bias：judge 傾向給「答得長」的高分、即使內容沒提升
2. Position bias：A/B 比較時、judge 對 A、B 位置敏感、要做 swap 平均
3. Self-preference bias：judge 模型偏好自己風格的答案
4. Judge 能力上限：judge 模型本身不夠強、評不出兩個強模型的差距

緩解：

1. 用結構化 rubric：給 judge 明確評分標準、不只「哪個好」
2. 多 judge 取共識：用 2-3 個不同 judge model 各評、取一致 / 平均
3. Critical task 仍要人工 review：高 stake 任務不能全靠 LLM-as-judge

常見陷阱跟反例

陷阱 1：訓練資料污染

模型在 benchmark 題目上「看似強」、實際是 memorization：

判讀訊號：

• benchmark cutoff date 之前的 dataset、新模型分數異常高
• 同模型在「同 dataset 變體（rephrase）」上分數顯著低

緩解：用較新出題的 benchmark（如 LiveCodeBench 定期更新）。

陷阱 2：Single benchmark 過擬合

模型廠商針對特定 benchmark fine-tune、benchmark 高但通用能力沒提升：

判讀訊號：

• 在 benchmark A 顯著領先、在 benchmark B（測類似能力）沒差
• 同模型實際使用後評價跟 benchmark 不符

緩解：看多個 benchmark + in-house benchmark。

陷阱 3：Prompt sensitivity

同 benchmark 用不同 prompt 格式、score 差幾個百分點：

判讀訊號：

• model card 報的數字跟自己跑差很多
• 同模型不同 prompt template 結果差距大

緩解：自己跑、用一致的 prompt template；report 時明確標 prompt 版本。

陷阱 4：Sampling 設定不一致

不同模型用不同 temperature / top-p、結果不可比：

判讀訊號：

• 兩篇 paper 用同 benchmark 報不同數字、推論參數不同

緩解：對 reproduction 用 temperature=0 + greedy decoding 確保一致。

Benchmark 之間的關係跟導讀路徑

各 benchmark 在不同階段的角色：

 1研究模型能力（paper 階段）：
 2  HELM / MT-Bench / Chatbot Arena → 通用能力 baseline
 3  MMLU / GSM8K / AIME            → reasoning 能力
 4  HumanEval / SWE-bench           → coding 能力
 5  RULER / LongBench               → long context
 6
 7挑選模型（user 階段）：
 8  Open LLM Leaderboard            → 快速 filter
 9  MTEB（若 RAG）                  → embedding model
10  In-house benchmark              → final 確認
11
12監控模型（production 階段）：
13  自己工作流 KPI                  → 真實品質
14  A/B test                       → 部署前的決策
15  User feedback                  → 持續迭代

何時過時 / 何時不過時

不會過時的部分：

• Benchmark 跟自己任務對齊的必要性
• 訓練污染 / 飽和 / single-task overfit 的陷阱
• LLM-as-judge bias 的存在
• In-house benchmark 是最後 final test
• llama-bench 是量測本地推論的標準工具

會變的部分：

• 各 benchmark 的飽和狀態跟前沿 score
• 主流 benchmark 的選擇（HumanEval → MBPP → SWE-bench → …）
• LLM-as-judge model 的偏好（隨 judge model 更新而變）
• 新 benchmark 出現（特別是 reasoning / long-context 領域）

下一章

下一章：4.15 Vision in coding workflow、把 vision 維度加進 coding 工作流的設計取捨。讀完 4.10、模組四覆蓋了 LLM 作為系統元件的設計取捨（RAG、tool use、agent、應用層協議、workflow、resource planning、long context、embedding、benchmarking、vision）、寫 code 場景需要的應用層概念完整、之後可進入 模組五 PC 獨立 GPU 或 模組六 安全。