假設一家美國花店用 人工智慧 整理客製訂單：一百次請求中，九十次各用一秒，十次各用三十一秒。平均值是四秒，但仍有十位客戶等待半分鐘以上。這是人為構造的算例，不是客戶測試結果。討論“夠不夠快”之前，先問誰在等，以及從哪個時刻開始計時。

Google的網站可靠性工程 指南提醒，平均延遲會掩蓋很慢的尾部請求，並建議觀察分佈。 本文建議同時展示中位數、較高百分位和樣本數，而非只報一個平均數。百分位描述某個觀察時段內的位置，不保證下一位客戶一定在該時間內完成，也不是服務承諾。

我們建議把使用者點選到可用結果的時間，與模型開始到首段輸出的時間分開。排隊、檢索、工具呼叫和結果檢查都可能增加等待。兩個圖表只有在測量對象、起終點和時間範圍一致時才適合直接比較；出現第一段文字，不等於訂單已經完成。

Prometheus 文件說明，預先計算的百分位不能直接聚合成整體百分位；對多個執行個體的百分位取平均會產生誤導。 需要跨執行個體觀察時，工程團隊應採用能正確合併的分佈資料，並核對估算誤差。本文不是要求企業更換監控產品，而是提醒先審查計算方法。

建議將成功、失敗與逾時分開展示，同時註明各自數量和規則。如果只看成功請求，慢到逾時的體驗可能從圖表中消失。不要為了讓百分位好看而排除不方便的樣本。客戶等待可以先用清楚的進度和人工入口改善，但不能把提示最佳化宣稱為處理速度提高。

為試行準備普通訂單、較長說明和需要額外檢索的虛構樣本，記錄端到端耗時、是否成功及是否需要人工介入。團隊應按業務需要設定目標，並檢查慢請求的原因。這是建議的測試計劃，未在客戶系統執行。先找到等待發生在哪一段，再決定最佳化模型還是流程。