Benchmark

情境

你的團隊想驗證「OCR 在我們自己的 codebase 上值不值得上 CI」。你不信任公開 benchmark（那 50 個 repo 跟你的技術棧無關），所以決定用最近 20 顆已合併的真實 PR 跑一次迷你測量——比對「OCR 發現」對「開發者事後真正修的 bug」。

Step 1 — 收集 PR 的事後修正當 ground truth

# 挑 20 顆已合併 PR，用 git log 找「合併後緊接的 bug-fix commit」
git log --oneline --grep="fix" main..feature  | head -20

事後修正 commit 裡的 diff 就是「這顆 PR 漏掉的真實缺陷」——標準的 ground-truth 素材。

Step 2 — 對每顆 PR 跑 OCR（固定 ref，避免漂移）

for pr in $(cat pr-shas.txt); do
  ocr review -c "$pr" --format json --audience agent \
    --background "review for benchmark" > "out/$pr.json"
done

用 -c <sha> 而非 --from/--to——單 commit 評審的結果可重現，適合量測。

Step 3 — 對照統計

jq -r '[.comments[] | {path, content}]' out/*.json \
  | rg -i "null pointer|nil|panic|data race|deadlock|leak" | wc -l

關鍵問題：OCR 有沒有在「事後 bug-fix 會碰的同一段程式碼」發評論？命中 = 真 Recall；沒命中 = 漏檢。

為什麼選這條審查路徑

公開 benchmark 回答「這工具整體強不強」；你自己 repo 的 mini-benchmark 回答「這工具對我的 codebase 有沒有用」。用「合併後 bug-fix」當 ground truth，比人工標註省力且客觀——但注意取樣偏誤：只會測到「被發現的 bug」，「還沒爆的雷」是統計不到的。

預期產出

20 顆 PR、OCR 平均 2.4 條評論/PR、每顆 4,200 token
其中 6 顆 PR 的事後 fix 落在 OCR 有評論的同一區塊 → 粗略 Recall ≈ 30%
→ 結論：上 CI 當「第一道閘」值得，但別當最後一道

情境

你們公司要在「換模型」與「改規則」時知道會發生什麼——不想每次靠感覺。你要建立一套持續評測平台：固定的測試集（golden set）、可重現的評審、自動計算 Precision/Recall/成本、每次變更（模型、規則、模板）都跑一遍並出報告。

Step 1 — 建立 golden set（把「事後修正」當 ground truth）

# 挑 50 顆已合併 PR + 它們的「事後 bug-fix commit」
# fix commit 的 diff = 該 PR 漏掉的真實缺陷（ground truth）
for pr in $(cat golden-pr-shas.txt); do
  git show --stat "$pr" | head -5
done

Step 2 — 建立評測腳本（固定 ref 與模型，可重現）

#!/usr/bin/env bash
# eval-ocr.sh <model> <rules-file>
MODEL="$1"; RULES="$2"
for pr in $(cat golden-pr-shas.txt); do
  ocr review -c "$pr" --model "$MODEL" --rule "$RULES" \
    --format json --audience agent > "out/$MODEL/$pr.json"
done

Step 3 — 自動比對「評論是否命中 ground truth 的檔案/行」

# 對每條評論，檢查 fix-commit 改到的檔案是否被評論覆蓋
python3 eval-match.py out/$MODEL/*.json golden-fixes.json
# → 輸出 precision / recall / f1 / total_tokens / wall_time

Step 4 — 每次變更跑一遍，輸出對照報告

eval-ocr.sh claude-opus-4-6 .opencodereview/rule.json
eval-ocr.sh claude-sonnet-4-5 .opencodereview/rule.json   # 換模型
eval-ocr.sh claude-opus-4-6 .opencodereview/rule-v2.json  # 改規則
# 比較: F1、成本、延遲 → 用數據決定「升級 or 維持」

為什麼選這條路徑

公開 benchmark 回答「這工具整體強不強」；自己的 golden set 回答「對我的 codebase、我的模型、我的規則，強不強」。固定的 -c <sha> + 固定模型讓評測可重現；自動比對「評論 vs fix commit」讓 Precision/Recall 客觀（雖會低估 Recall，因為「未爆的 bug」測不到）。這套平台讓「換模型」從爭論變成看表決策。

預期產出

model A: F1 0.58, $1.9/PR, 38s
model B: F1 0.61, $3.4/PR, 51s
rule v2: F1 0.63 (both models), 成本 -12%（規則讓 agent 少探索）
→ 決策: 保留 model A + rule v2（成本效率最高）