您的評估分數在樣本數上說了謊

取一個包含 58 個案例的黃金測試集，以及一個依據真實搜尋索引作答的線上文件助理，比較其重新排序器開啟與關閉兩種情況。只看點估計，重新排序器把排名第一的頁面恰為正確頁面的答案比例從 61.8% 提升到 74.5%。這看起來像是進展，在狀態更新裡通常會被回報為 12.7 個點的提升。

在什麼都沒改的情況下把同一組執行兩次，答案正確率先是 71.2%，接著是 76.0%。每個案例做三次重複量測後再測，大約每九個觀測案例中就有一個在完全相同的量測之間改變了裁決：正確性上是 54 個中的 6 個，排名第一的頁面上是 57 個中的 7 個。

原因並不是量測壞了，而是在 58 個案例（其中一些根本無法量測）上的差異，完全落在樣本自身就能產生的雜訊之內。告訴您是否學到了東西的，是區間，而不是點估計。

應該回報什麼

三個數字，依這個順序：差值、它的區間，以及其背後的案例數。少於這些，讀者就無法評判這個結論。以下就是那次執行，重新排序器開啟對照關閉，逐案配對，單位為點：

每個區間都跨越了零，而且跨得很寬。點估計都說重新排序器有幫助；區間卻說這個測試集無法判斷它是有幫助還是有害。這本身就是一項發現：這個測試集太小、遺失太多，無法回答它被用來回答的問題。

遺失不等於零

58 次呼叫中有四次從受測系統傳回 HTTP 500，另有兩次評判呼叫沒有傳回可解析的裁決。把未評分案例以零計入平均的測試框架，會把這六個記為助理失敗：在 58 個中憑空製造出六個失敗。Oloproof 把它們記為遺失，並加寬區間，以涵蓋它們可能的任何取值。

這正是第三列所計入的代價。在截取前三個排名頁面時，58 個案例中只有 27 個可以量測，而區間把另外 31 個計入其中，而不是把它們藏起來。

小測試集也能通過閘門

同樣的規則在小規模一端同樣成立。一次三個案例的冒煙執行得分 1.000，95% 區間為 0.292 至 1.000。拿點估計與目標比較的閘門會放行它。讀取區間的閘門則會說出事實：三個案例無法區分一個完美的系統與一個十次只對三次的系統。

收窄區間

更多的案例會收窄區間，少遺失一些案例也會。在同一個測試集上，把系統的 HTTP 500 宣告為暫時性錯誤，讓執行器重試，幾分鐘後就找回了 22 個遺失案例中的 18 個，並使區間收窄了 39%，其他一切都沒有改變。

一個區間越過門檻的差值，無論大小，都能支撐決策，閘門應當依據的正是它。在此之前，請回報差值、它的區間以及背後的案例，並說明答案尚未揭曉。