假设一家美国花店用 人工智能 整理定制订单：一百次请求中，九十次各用一秒，十次各用三十一秒。平均值是四秒，但仍有十位客户等待半分钟以上。这是人为构造的算例，不是客户测试结果。讨论“够不够快”之前，先问谁在等，以及从哪个时刻开始计时。

谷歌的网站可靠性工程 指南提醒，平均延迟会掩盖很慢的尾部请求，并建议观察分布。 本文建议同时展示中位数、较高百分位和样本量，而非只报一个平均数。百分位描述某个观察窗口内的位置，不保证下一位客户一定在该时间内完成，也不是服务承诺。

我们建议把用户点击到可用结果的时间，与模型开始到首段输出的时间分开。排队、检索、工具调用和结果检查都可能增加等待。两个图表只有在测量对象、起终点和时间窗口一致时才适合直接比较；出现第一段文字，不等于订单已经完成。

普罗米修斯 文档说明，预先计算的百分位不能直接聚合成整体百分位；对多个实例的百分位取平均会产生误导。 需要跨实例观察时，工程团队应采用能正确合并的分布数据，并核对估算误差。本文不是要求企业更换监控产品，而是提醒先审查计算方法。

建议将成功、失败与超时分开展示，同时注明各自数量和规则。如果只看成功请求，慢到超时的体验可能从图表中消失。不要为了让百分位好看而排除不方便的样本。客户等待可以先用清楚的进度和人工入口改善，但不能把提示优化宣称为处理速度提高。

为试点准备普通订单、较长说明和需要额外检索的虚构样本，记录端到端耗时、是否成功及是否需要人工介入。团队应按业务需要设定目标，并检查慢请求的原因。这是建议的测试计划，未在客户系统执行。先找到等待发生在哪一段，再决定优化模型还是流程。