营运与维护 · 实作指南
平均四秒，不代表每位客户只等四秒
平均四秒仍可能掩盖长时间等待；厘清计时范围、百分位、失败与逾时的统计方式。
AAHouse 原创解说视频，采用 AI 辅助概念画面、合成旁白及原创音乐。
英文逐字稿 · 简体中文普通话逐字稿 · 台湾华语逐字稿 · 澳门粤语逐字稿
先看一组虚构数字
假设一家美国花店用 AI 整理定制订单：一百次请求中，九十次各用一秒，十次各用三十一秒。平均值是四秒，但仍有十位客户等待半分钟以上。这是人为构造的算例，不是客户测试结果。讨论“够不够快”之前，先问谁在等，以及从哪个时刻开始计时。
- 90 次 × 1 秒
- 10 次 × 31 秒
- 平均 4 秒 ≠ 人人 4 秒
未经修改的原始来源说明图。
平均值回答不了所有体验问题
Google 的 SRE 指南提醒，平均延迟会掩盖很慢的尾部请求，并建议观察分布。[1] 本文建议同时展示中位数、较高百分位和样本量，而非只报一个平均数。百分位描述某个观察窗口内的位置，不保证下一位客户一定在该时间内完成，也不是服务承诺。
- 中位数：典型位置
- 较高百分位：慢端体验
- 样本量：解释边界
未经修改的原始来源说明图。
把计时起点和终点写出来
我们建议把用户点击到可用结果的时间，与模型开始到首段输出的时间分开。排队、检索、工具调用和结果检查都可能增加等待。两个图表只有在测量对象、起终点和时间窗口一致时才适合直接比较；出现第一段文字，不等于订单已经完成。
- 点击 → 可用结果
- 模型启动 → 首段文字
- 两种计时，不混为一谈
未经修改的原始来源说明图。
不要把几个百分位再取平均
Prometheus 文档说明，预先计算的百分位不能直接聚合成整体百分位；对多个实例的百分位取平均会产生误导。[2] 需要跨实例观察时，工程团队应采用能正确合并的分布数据，并核对估算误差。本文不是要求企业更换监控产品，而是提醒先审查计算方法。
- 实例百分位 ≠ 可加总值
- 先核对分布合并方法
- 再观察整体慢端
未经修改的原始来源说明图。
别把失败请求悄悄删掉
建议将成功、失败与超时分开展示，同时注明各自数量和规则。如果只看成功请求，慢到超时的体验可能从图表中消失。不要为了让百分位好看而排除不方便的样本。客户等待可以先用清楚的进度和人工入口改善，但不能把提示优化宣称为处理速度提高。
- 成功、失败、超时
- 每类数量与规则可见
- 不删除不方便的样本
未经修改的原始来源说明图。
用小实验决定下一步
为试点准备普通订单、较长说明和需要额外检索的虚构样本，记录端到端耗时、是否成功及是否需要人工介入。团队应按业务需要设定目标，并检查慢请求的原因。这是建议的测试计划，未在客户系统执行。先找到等待发生在哪一段，再决定优化模型还是流程。
- 普通、长说明、检索样本
- 耗时 + 成功 + 人工介入
- 先定位等待，再优化
未经修改的原始来源说明图。