數值、單位與位元

從 120ms 降到 90ms，減少了百分之幾？

使用工具

改善報告可能同時出現「快了 25%」「快了 33%」或「變成原來的 75%」。同一組量測值因分母或指標不同，可得到不同結果。先釐清基準與描述對象，比立即找計算錯誤更有效。

用比例工具比較範例處理時間 120ms 與 90ms。它依輸入計算，不量測實際服務。即使兩值量測條件不同也能算出結果，因此計算成功不是比較公平的證明。

在增減率模式輸入原值 120、新值 90，結果 -25%，公式為 (90－120)÷120×100。負號表示耗時減少，可以說「處理時間縮短 25%」，不代表效能變差。

比較條件

before = 120 ms
after = 90 ms
difference = -30 ms
change = -25%

輸入前先統一單位。若把 120ms 與 0.09 秒直接輸入為 120 和 0.09，工具無法知道單位不同。比例雖無量綱，原始兩值仍需同一尺度；毫秒與秒、byte 與 KB 應先換算。

比例模式輸入部分 90、基準 120，得到 75%，表示新耗時占原耗時的比例。剩餘 75%，減少的是 25%。如果報告標題是「減少率」，不能把 75% 直接貼上去。

如果從 120ms 真正減少 75%，剩下應為 30ms，而不是 90ms。簡短標籤也要區分「原來的 75%」「減少 25%」「減少 75%」。公式正確，不代表措辭不會誤導。

交換為原值 90、新值 120，增幅約 33.3333%。差仍是 30ms，分母卻變為 90。增減率不對稱，交換順序不只是改變符號，應同時檢查公式與結果。

同樣，100 增加 20% 為 120，再減少 20% 得到 96，不會回到 100，因為第二次基準更大。合併折扣或容量變化時，不要直接加減百分比，應依實際順序計算各階段。

假設逐件循序且沒有其他等待，120ms 一件約為每秒 8.333 件，90ms 約為 11.111 件，處理量增加約 33.333%。這與耗時減少 25% 不矛盾，因為比較的是倒數量。

實際服務有並行、排隊、外部呼叫與其他限制，簡單倒數模型不能保證伺服器容量增加 33%。應區分實測「單件耗時減少 25%」與有條件的「同條件循序處理量約增加 33%」。

比例之間的直接差用百分點表達：2% 到 1% 是下降 1 個百分點；相對原來的 2%，則減少 50%。增減率模式輸入 2 與 1 得到 -50%。只說「下降 1%」容易產生歧義。

還要看原始次數：100 次中 2 次與 1 次，十萬次中 2000 次與 1000 次，比例變化相同，但證據量不同。工具不判斷統計顯著性或因果，不能只憑比例就斷言是改善效果而非隨機波動。

原值為 0 時會除以零，工具拒絕給出一般增減率。0 到 1 不能寫成增加 100%，更適合寫「從 0 件增至 1 件」或「新增 1 件」，明確說明數量與狀態。

很小的非零基準也會產生大比例：1 到 10 增加 900%，實際只多 9 件。只突出百分比會隱藏規模。小基數或負基準尤其需要確認一般公式是否表達所需意義，並附絕對差。

可寫「平均耗時從 120ms 降為 90ms，減少 30ms，相對原值減少 25%」。平均值應與平均值、中位數與中位數比較，並統一量測條件。拿改善後最快一次比較原平均或最壞值，算對了也不證明改善。

工具負責核對輸入值的算式。基準選擇、何謂改善、證據強度屬於其他判斷。寫結論前，比較反向變化、剩餘比例與絕對差，可避免百分比脫離上下文。

上午 100 次中錯誤 10 次，為 10%；下午 900 次中錯誤 9 次，為 1%。直接平均得 5.5%，但全天是 1000 次中 19 次，即 1.9%。時段請求數不同，不能等權平均。先合計原次數，再輸入部分 19、基準 1000；只收集百分比會丟掉合併所需的分母。

前後比較也要統一範圍。所有請求的錯誤率與單一功能的錯誤率不是同一對象，應先核對時間段、功能範圍和失敗定義。數字能輸入不代表比較有意義。若彙總條件改變，應連同數值一起記錄，避免把定義變化誤當改善。