文档助手需要 18 秒才能生成回复，团队第一反应是换模型。但如果大部分时间都在等资料检索，模型换得再快，也未必解决问题。
先测量各阶段耗时，再决定改哪里。下面的数字只是示例，不是性能基准。
画出一次请求的时间线
为请求分配编号，记录进入队列、检索开始与结束、模型开始返回、工具调用结束的时间。也要记录用户什么时候看到第一项有用结果，以及整个任务何时完成。
假设排队 2 秒、检索 9 秒、生成草稿 5 秒、保存 2 秒，应先排查检索。加快生成也可能有帮助，但无法收回其他阶段的等待时间。
如果阶段并行，不要把耗时简单相加。既要看各阶段，也要看从开始到完成的实际总时间。
用相同条件对比
选一组有代表性的任务：短问题、长文档请求，以及需要外部工具的任务。记录文档大小、是否重试、是否已有缓存。重复提问时很快，不代表首次使用也同样快。
普通请求和特别慢的请求都要看。平均值可能掩盖少数让人印象深刻的长等待。性能日志保留时间和安全的标识，不要复制客户资料和完整提示词。
针对瓶颈改，不降低质量标准
- 排队： 检查任务是否被无关工作阻塞。
- 检索： 检查是否找了超出回答所需的资料。
- 生成： 用同一套质量样本测试更短输入或更快模型。
- 工具调用： 避免反复查询；只有互不依赖的步骤才考虑并行。
- 等待体验： 展示真实进度，明确什么时候可以审核结果。
不要为了让演示更快，就跳过证据、校验或审批。每次修改后重跑相同用例，同时比较耗时和正确性。
质量评估可参考 AI 测试指南，也可以联系我们讨论工作流检查。
