假設一間美國花店用人工智能整理訂製訂單。一百次請求入面，九十次每次用一秒，十次每次用三十一秒。平均係四秒，但係仍然有十位客等超過半分鐘。呢組數字係人為構造嘅算例，唔係客戶測試結果。討論夠唔夠快之前，先問邊個喺度等，同埋由邊個時間點開始計。

Google 嘅網站可靠性工程指南提醒，平均延遲會掩蓋好慢嘅尾端請求，建議睇埋分布。本文建議同時顯示中位數、較高百分位同樣本數，唔好淨係報一個平均數。百分位描述某段觀察時間入面嘅位置，唔保證下一位客一定喺嗰個時間之內完成，亦唔係服務承諾。

我哋建議將用戶按一下到攞到可用結果嘅時間，同模型開始到第一段輸出嘅時間分開。排隊、檢索、工具呼叫同結果檢查，都可能增加等候。兩個圖表要喺量度對象、起點終點同時間範圍都一致，先適合直接比較。出咗第一段字，唔等於訂單已經完成。

Prometheus 文件講明，預先計好嘅百分位，唔可以直接合併成整體百分位；將多個執行個體嘅百分位再取平均，會誤導。要跨執行個體觀察，工程團隊應該用可以正確合併嘅分布資料，再核對估算誤差。本文唔係要求企業換監控產品，而係提醒先審查計算方法。

建議將成功、失敗同逾時分開顯示，同時講明每類嘅數量同規則。如果淨係睇成功請求，慢到逾時嘅體驗可能會喺圖表消失。唔好為咗令百分位好睇，就剔走唔方便嘅樣本。清楚嘅進度同人手求助入口，可以先改善等候體驗，但係唔可以將提示改善講成處理速度提升。

為試行準備普通訂單、較長說明，同需要額外檢索嘅虛構樣本，記錄端到端用咗幾耐、成唔成功，同需唔需要人手介入。團隊應該按業務需要設定目標，再檢查慢請求嘅原因。呢個係建議測試計劃，未喺客戶系統執行。先搵出等候發生喺邊一段，再決定優化模型定流程。