Benchmark 是什麼What actually counts as a benchmark
沒有 ground truth 與對照組的比較，不叫 benchmark。
01一句話只有一句
有真值、有基準線、有事先講好的判準，才叫 benchmark。
02Why should I care?我為什麼要讀這頁
你要交的是一篇 methodology paper。這種 paper 沒有生物學新發現可以賣，它唯一的商品就是「這套流程有用」這句話，而這句話的全部重量壓在 benchmark 上。benchmark 站不住，reviewer 連 Cas9 都不用懂就能退你的稿。
用你熟的世界對一次：你不會靠「我的新泛函重現了我自己以前算的那組數」去投稿。你會拿 GMTKN55 這種別人建的、你動不了的測試集，跟 PBE、B3LYP 這些人人手上都有的基準線比，用事先講好的誤差指標（MAD，GMTKN55 上是 WTMAD-2）報結果，而且你一定會被問「你的參數是不是在這個測試集上調過」。這整套文化在計算化學裡是常識，常識到沒人會特地寫出來。
麻煩的是 Cas9 計算領域沒有 GMTKN55。沒有公認的測試集、沒有公認的 baseline、沒有公認的成功判準，於是不少 MD 論文的「驗證」就是「我們的結果與已知的結構生物學一致」。這對你其實是好消息：這一章要做的事就是自己組一個出來，而「組出一套可防守的 Cas9 專一性 benchmark」本身就足以撐起一篇 methodology paper。至於它是不是第一個 —— 那是一句要靠文獻檢索背書的宣稱，不是靠印象，動筆前自己查一次再決定寫多強。
03What這是什麼
benchmark 不是「跟別的東西比一比」。它是一個在看到結果之前就固定下來的預測任務，少一個零件就退化成 demo。
四個必要零件：
- Ground truth —— 獨立於你的方法產生的答案。關鍵字是「獨立」。如果答案本身是另一個預測模型算出來的（例如拿 CFD score 當答案），你測到的是「你有多像它」，不是「你有多對」。哪些實驗資料算數、各自的偏差在哪，見 ground truth 從哪來。
- Baseline（基準線） —— 比你便宜、比你笨的做法。至少要兩層：一層是真正的亂數排序，另一層是該領域已有的 heuristic。在 Cas9 off-target 上，那個 heuristic 就是 mismatch 個數與 CFD score（把每個 mismatch 位置的活性折扣查表後連乘起來的純序列分數，CPU 上幾毫秒）。沒有 baseline 的相關係數不是結果，是裝飾。
- 事先登記的成功判準 —— 用哪一組資料、算哪一個 metric、多少算贏。這三件事必須在你看到自己的數字之前寫死。
- Negative control —— 一個你確定「本來就不該有訊號」的案例。它測的不是你的方法有多強，是你的 pipeline 會不會無中生有。
第五件常被忘記的：holdout。 至少留一部分資料，從頭到尾一次都不看，最後才拿出來跑一遍。
「有 ground truth」不等於「ground truth 是對的」。實驗資料一樣有偵測極限、有系統性偏差、有它自己回答不了的問題。benchmark 的誠實度取決於你有沒有把真值的偏差也寫進限制段，而不是取決於你有沒有真值。
Prospective 與 retrospective 的差別，比多數人以為的大。
- Retrospective（回溯式）：答案已經公開，你在知道答案的世界裡開發方法。這不是罪，幾乎所有方法學都從這裡起步。但它有一個無法靠自律消除的漏洞：你、你的 pipeline、你的參數、你對 metric 的選擇，全都已經被答案汙染過了，而且汙染的程度連你自己都估不出來。
- Prospective（前瞻式）：判準先鎖、預測先交、答案後到。CASP、CAPRI、SAMPL、D3R 這些盲測挑戰，存在的理由就是把整個領域強制推到 prospective，而它們反覆得到的教訓是一致的：同一個方法在 retrospective 的成績通常高於它在 prospective 的成績。
你不太可能為 Cas9 辦一個盲測挑戰，但你可以做一件成本幾乎為零的事：把預測結果先 commit 進 git，再去查答案。 這一步把 retrospective 變成一個有時間戳的準 prospective，而且它值錢的地方在於，你在論文裡可以寫出來。
04Why為什麼重要
四個零件不是儀式，它們各自堵住一個具體的漏洞。三種最常見的「假 benchmark」，恰好就是各缺一件。
假 benchmark 之一：只跟自己比。 「我們的流程比我們上一版好」「加了這一項之後相關性提升了」。缺的是 baseline。這種寫法最大的問題不是不嚴謹，是它沒有排除掉零假設：你不知道一個只數 mismatch 個數的兩行程式能不能做到同樣的事。在 off-target 這個題目上，序列本身就攜帶了大量訊號，任何跟序列沾邊的量都會拿到不錯的相關係數。不打 CFD score 這條線，你的 MD 流程就沒有存在理由。
假 benchmark 之二：只報相關係數。 一個 Spearman ρ = 0.6 看起來很好，但它單獨存在時什麼都證明不了。缺的是判準與不確定度：n 是多少？信賴區間多寬？拿掉最極端的那一個點還剩多少？baseline 是多少？在 n = 8 的變體 panel 上，ρ = 0.6 用 Fisher z 粗估的 95% 信賴區間大約是 −0.18 到 0.92 —— 跨過 0，這時候「有相關」這句話本身就是過度宣稱。這個算術你現在就可以做一次，不需要任何模擬結果。
假 benchmark 之三：事後挑 metric。 你手上有 RMSD、RMSF、接觸數、BSA、鹽橋、HNH 距離、MM-PBSA 至少七八個量，每個量又有好幾種定義方式（cutoff 抓 3.5 Å 還是 4.0 Å、算重原子還是算 Cα）。如果你先看了哪一個跟實驗對得上再決定報哪一個，你做的是在雜訊裡撈相關性。這在統計上有個名字叫 garden of forking paths，而它可怕的地方是：你完全可以在每一步都很誠實的情況下做出這件事。
一個能把高保真變體排在前面的流程，也可能只是在測「這個變體改了幾個帶正電殘基」。negative control 的作用就是逼出這種 trivial 訊號。你的專案裡已經有一個現成的：eSpCas9(1.1) 在 on-target 底物上本來就該是 null，因為它的設計原理是削弱與 non-target 股的靜電抓握，在完全配對的底物上沒有東西可削。如果你的流程在 on-target 底物上就把 eSpCas9(1.1) 判成「更專一」，那它讀到的不是專一性機制，是胺基酸組成。
05How怎麼做
八個步驟，照順序做，不要跳。
- 一句話寫下預測任務。 輸入是什麼、輸出是什麼、要排序的是什麼。寫不出來就代表你還沒有 benchmark，只有一堆分析。可用的三種任務型態見 ground truth 從哪來。
- 先過可靠性關卡。 任何要進入打分的量，必須先通過 metric 可靠性 的跨 replica 檢驗。用一個 CV 145.5% 的量去對實驗答案，你測的是亂數種子。
- 選 ground truth，並寫下它的偏差。 一併寫下你為什麼選這一份而不是另一份。
- 架 baseline 階梯。階梯長什麼樣，由第 1 步的任務決定 —— 這一點很多人搞錯。
- 排序 off-target 位點（同一個蛋白、不同位點）：亂數排序 → mismatch 個數 → CFD score。你要贏的是第三階。
- 排序蛋白變體（同一條 guide、不同 Cas9）：CFD 在這裡是常數，因為它的輸入裡根本沒有蛋白序列，拿它當 baseline 沒有意義。這一階要換成兩種東西：一是 trivial 序列特徵（突變個數、淨電荷變化、突變殘基到 DNA 的距離），二是現行做法本身 —— 也就是文獻上普遍採用的平衡結合 ΔΔG（MM-PBSA／FEP 那一類）。第二種才是這個題目真正要對照的那條線。
- 寫 pre-analysis 檔案並 commit。 一份純文字檔就夠：任務、資料集、要報的 metric（只能一個主 metric）、成功門檻、要跑的 negative／positive control、holdout 是哪些。
git commit之後才開始跑分析。這份檔案日後直接變成論文方法段。 - 設定對照組。 negative control 用 eSpCas9(1.1) 的 on-target 底物；positive control 用文獻上確定更專一的變體（HypaCas9、SpCas9-HF1 這一類）。兩者都要先寫下「預期看到什麼」。positive control 要連遞送格式與 guide 一起寫死：同一批變體換成 RNP 遞送、或換一條 guide，實驗上的排序就可能翻掉（見 ground truth 從哪來），你的「正確答案」必須指定是哪一組實驗條件下的答案。
- 跑，然後一次報完。 主 metric、baseline 對照表、效果量與信賴區間、以及失敗案例。刻意把做錯的那幾個案例列出來，是這類論文最能建立信任的一段。
- 最後才動 holdout。 動了就不能再回頭調。
成本現實決定了 benchmark 的大小，這件事必須提前算。
你的一個 5F9R 完整 R-loop 三元系統是 535,265 atoms，跑過的規格是 4 replica × 約 87 ns。而在共用 GPU 叢集上，可同時執行的 job 數與可用儲存空間都有硬性上限。把這幾個約束乘一乘就會發現：benchmark panel 的大小不是你想要多大，是你付得起多大。 所以第 1 步就要倒過來算：能跑 N 個系統，就只能設計一個 N 個點的任務，然後老實在論文裡寫 n = N。
baseline 完全不用 GPU。mismatch 計數、CFD score、序列模型的分數都是 CPU 上幾秒鐘的事。所以正確的順序是先把整條 baseline 階梯跑完，看看它們在你的 panel 上能做到多好，再決定你的 MD 要投多少 GPU 時數才可能贏過它。這一步花不到一天，卻可能省下幾百 GPU 小時。
06When什麼時候用
- 在跑第一條 production 軌跡之前。 benchmark 是設計文件，不是收尾工作。任務定不下來，你根本不知道該跑哪些系統。
- 當你想在論文裡寫「我們的方法可以預測 X」時。 一寫出「預測」兩個字，reviewer 就會啟動這一整套檢查。
- 當你要在 funnel 裡新增一層 gate 時。 每一層過濾都是一個 claim，每個 claim 都需要它自己的 baseline。
- 當你要主張某個既有做法應該被換掉時。 「ΔG 不適合當專一性 ranker」這種主張，只有拿出 ΔG 在同一個 panel 上輸給某條 baseline 的證據才站得住。
- 投稿前的自我攻擊。 把自己當 reviewer，照本頁的 Reviewer Thinking 逐條走一遍。
07When NOT什麼時候別用
-
metric 還沒過可靠性關卡時，不要做 benchmark。 為什麼會壞：量測誤差會把真實相關係數往 0 壓，這是統計上的必然，不是運氣問題。一個跨 replica CV 接近 100% 的量，就算它背後的物理跟實驗完全一致，你也量不到相關性。怎麼看出它壞了：換一組亂數種子重跑，跟實驗的相關係數整個變號或掉一半。這是最便宜的診斷，也幾乎沒人做。
-
計算輸出與實驗輸出的量綱對不起來、又沒有明寫連結假設時，不要硬對。 為什麼會壞：你的輸出是 Å、kcal/mol、接觸數，實驗輸出是 read count 與 indel 百分比。中間那條換算不是自動成立的，它是一個你必須自己提出並且承擔的假設。跳過它去報相關係數，等於在說「我相信這兩個量成正比」而不說出口。怎麼看出它壞了：你講不清楚「如果這個假設是錯的，哪一個觀測會不一樣」。
-
panel 只有個位數個點時，不要報 ROC-AUC 或 p 值。 為什麼會壞：AUC 在小樣本下的解析度極粗，取值被限制在少數幾個離散值上，而且對單一點的移動極度敏感。怎麼看出它壞了：做 leave-one-out，把每一個點輪流拿掉重算，看 AUC 跳動範圍。如果拿掉一個點 AUC 就從 0.9 掉到 0.6，那 0.9 這個數字不存在。正確的做法是報原始排序表，讓讀者自己看那幾個點。
-
negative control 也「成功」的時候，不要繼續往下做。 為什麼會壞：這代表你的流程抓到的是某個跟任務無關的 trivial 訊號（電荷數、序列相似度、系統大小），而它在真正的案例上剛好也管用。怎麼看出它壞了：把 negative control 的分數跟一個明顯無關的變數（例如突變殘基的總電荷變化）去做相關，如果對得上，訊號來源就找到了。
-
一次比較超過一個主 metric 時，不要用「其中一個顯著」當結論。 為什麼會壞：你有八個量、每個量兩三種定義，等於在做二十幾次比較，其中出現一個看起來漂亮的純屬預期。怎麼看出它壞了：問自己「我總共看了幾個版本才決定報這一個」，如果答案大於 1 而你沒有做多重比較校正，這個結果就是暫定的。
-
只有 retrospective 資料、卻要宣稱 prospective 等級的結論時，不要寫。 為什麼會壞：這是誠信問題，不是統計問題，而且 reviewer 抓得到。怎麼看出它壞了：檢查你的參數（cutoff、時間窗、要不要丟掉某條 replica）是不是在看過答案之後動過。動過就照實寫，並降低結論的強度。
08Project Lens跟我的 project 多相關
為什麼是五星： 因為 methodology paper 的全部價值就在 benchmark。在任何以 MD 排序變體的流程裡，可靠性分析回答的是「穩不穩」，benchmark 回答的是「對不對」，而前者做完不等於後者成立：一個量很穩，不代表它指向正確的東西。穩而不對就是精密的錯誤，reviewer 的第一問一定落在這裡。
為什麼不是更低： 還有一個更現實的理由。在共用叢集上，可同時執行的 job 數與可用儲存空間都有硬性上限，你能跑的系統數量因此被鎖死。在算力是硬約束的情況下，benchmark 設計屬於「不燒 GPU 卻決定每一個 GPU 小時值不值得」的那一類工作（ground truth 盤點與可靠性分層也在同一類）。花三天把任務、baseline 階梯、對照組、holdout 定清楚，可能比多跑三百 GPU 小時更能決定這篇 paper 能不能過，而且它必須排在那三件事的最前面 —— 因為任務定義決定了另外兩件事要對誰做。
具體怎麼用： 現在就寫那份 pre-analysis 檔案，即使 ground truth 還沒定案。先寫任務，再照第 4 步把對應的 baseline 階梯跑完 —— 如果主線是變體排序（現實上就是），那一階要拿到手的數字不是 CFD，而是「trivial 序列特徵與 ΔΔG 型打分在我的 panel 上能做到多好」。這個數字會直接決定 funnel 的每一層還值不值得投資源，也會決定 ΔG 能不能當專一性 ranker 這個問題要用什麼證據來收尾：要的不是論證 ΔG 不好，是把 ΔG 放上同一張表，讓它自己交出成績。
09Reviewer Thinkingreviewer 會問什麼
你的 baseline 是什麼？如果只用 mismatch 個數或 CFD score，成績差多少？點開看參考答案
這是這一類論文最常被一擊斃命的地方。誠實的回答必須是一張表：亂數、最笨的序列 heuristic、該領域現行的計分、你的流程，四列在同一個 panel 上的同一個 metric。位點排序任務裡「現行計分」就是 CFD score；變體排序任務裡 CFD 是常數（它看不到蛋白序列），該擺在那一列的是平衡結合 ΔΔG。如果你贏得不多，那也要寫出來，然後把賣點改成「提供了序列模型看不到的機制解釋」而不是「預測更準」。主動把 baseline 表放進正文，比放在補充材料裡更能建立信任。
這是 prospective 還是 retrospective？你在看過答案之後調過任何參數嗎？點開看參考答案
絕大多數情況下答案是 retrospective，直說就好，這不丟臉。真正該給的是補償：說明你用什麼機制限制自己（pre-analysis 檔案的 git 時間戳、holdout、只報一個主 metric），以及哪些參數確實是在看過部分結果後定的。寫下來的限制不會被扣分，被抓到的限制才會。
你的 negative control 是什麼？它有沒有給出你預期的 null？點開看參考答案
你有一個現成而且漂亮的：eSpCas9(1.1) 在 on-target 底物上。它的機制是削弱對 non-target 股的靜電抓握，完全配對的底物上沒有東西可以削，所以本來就該 null。你的模擬給了這件事一個定性旁證：三個 grip 位點裡 K848 貼著 non-target 股（跨 4 replica 平均 0.7 nm），K1003 與 R1060 平均落在一到兩奈米外（1.6 nm、1.5 nm）。但這一句只能講到這裡為止 —— 這三個逐位點距離的跨 replica CV 都在 38 到 46%，全部是 noise tier，R1060 在其中一條 replica 就貼到 0.5 nm。所以不能反過來說「那兩個位點隔太遠、不可能有靜電接觸」，那正是這張表本身在警告你不要做的推論。把它寫成 negative control 的機制敘事可以，順便當成「逐位點量不能拿來下二分結論」的自我示範，反而更值得寫進正文。
你的 n 這麼小，效果量的信賴區間是多少？點開看參考答案
不要迴避，直接給。在個位數的 panel 上，相關係數的信賴區間通常寬到跨過 0，這時候正確的敘述是「排序方向與實驗一致，但樣本量不足以支持定量宣稱」。同時說明為什麼 n 只能這麼小（單一系統 535,265 atoms、4 replica × 約 87 ns，加上叢集併發與儲存的硬性上限）。把限制歸因到算力上限並給出可跑的系統數，比含糊帶過有說服力。
你總共試過幾個 metric？為什麼報這一個？點開看參考答案
如果你先定了主 metric 才跑，就照實說，並把其他 metric 的結果全部附在補充材料裡。如果你是看了之後才挑的，那也照實說，並把結論降級成「探索性發現，需要獨立資料驗證」。這一問是 reviewer 用來測你誠信的，答錯的代價遠高於承認探索性。
10Common Mistakes最常犯的錯
- 只跟自己的前一版比。 後果：無法排除「兩行程式的 heuristic 也能做到」這個可能。正解：加上亂數與 CFD score 兩層 baseline，成本是 CPU 上幾秒鐘。
- 報相關係數卻不報 n 與信賴區間。 後果：reviewer 自己算完會發現區間跨過 0，信任瞬間歸零。正解：一律附 n、信賴區間、leave-one-out 的敏感度。
- 把 CFD score 同時當 baseline 又當 ground truth。 後果：循環論證，你的方法「準」只代表它像一個序列模型。正解：CFD 永遠只能站在 baseline 那一欄。
- 看過結果之後才決定 cutoff 或時間窗。 後果：實質上是在調參數去配答案，而且無法自我察覺。正解：寫 pre-analysis 檔案並 commit，之後的每一次更動都留在 git 歷史裡。
- 沒有 negative control。 後果：無法區分「抓到機制」與「抓到 trivial 相關」。正解：eSpCas9(1.1) 的 on-target 底物是免費的現成對照。
- 在 metric 可靠性未知的情況下就去對實驗。 後果：量測誤差把真相關壓成 0，你會誤判成「這個物理量沒用」。正解：先做 跨 replica 的 CV 分層，再談準不準。
- 把 benchmark 留到論文快寫完才做。 後果：發現該跑的系統當初沒跑，而 GPU 額度已經燒完。正解：benchmark 是第一份文件，不是最後一份。
11Further Reading讀哪幾篇
12Summary三句話
benchmark 是一個在看到結果之前就固定下來的預測任務，四個零件缺一不可：獨立的 ground truth、比你笨的 baseline、事先登記的成功判準、以及一個本來就該 null 的 negative control。三種最常見的假 benchmark 恰好各缺一件，而它們共同的症狀是「數字很漂亮但排除不掉任何一個平凡解釋」。對這個 project 而言，benchmark 設計不燒一分鐘 GPU 卻決定論文成敗，應該在跑下一條軌跡之前就先寫完。