Appearance
Q24 · 大模型应用上线前你最关心哪些工程指标？
一个客服 Agent 在演示时回答了“订单 A123 的耳机能不能申请退款”，看上去很流畅。可是真让它接待几千位用户，问题会变得具体：多少回答确实符合订单和政策？用户要等多久？政策接口偶尔超时时它会不会乱猜？每次回答要花多少钱？如果只展示一段成功对话，团队无法决定能否上线。
我会把上线判断拆成四组可量化的问题：答案质量、用户实际等待时间、可靠性与安全边界、单次及总成本。 再检查请求量增长时这些指标是否仍可接受。图中的四个物件对应这四组问题；它们都是需要测量的维度，不是一张图能证明的合格成绩。
这篇文章沿用一笔虚构咨询：今天为 2026-09-26，A123 耳机于 2026-09-23 签收、未拆封；当前政策规定“签收后 7 天内且未拆封，可提交人工退款审批”。正确回复应是“根据已核对的订单与政策，初步符合提交人工审批的条件”，不能擅自说“退款已批准”。真实项目要以服务端订单和当时有效政策为准，不能拿示例日期当生产数据。
先认清指标里的术语
| 术语 | 通俗解释 | A123 客服里的对应物 |
|---|---|---|
| 指标 / Metric | 事先定义统计口径、持续记录的数字 | 一周内有多少次答错退款条件 |
| 样本 / 请求 | 一次被测问题及其相关资料，或线上一次用户交互 | “A123 耳机能申请退款吗？” |
| 离线评测 | 上线前用固定题集检验一个版本 | 用已标好预期答案的退款案例测试新 Prompt |
| 在线监控 | 上线后从真实请求观察趋势 | 记录一周的延迟、工具超时和人工转接比例 |
| 正确率 | 符合事先评分规则的样本数占全部样本数的比例 | 既查订单又查政策、结论没越界的比例 |
| 分母 | 算比例时“全部”到底指哪些请求 | 100 条测试案例，还是只有成功返回的 92 条 |
| P95 / 第 95 百分位 | 把耗时从小到大排，约 95% 的请求不慢于这个值 | 大多数用户等到完整回答的上界附近 |
| 端到端延迟 | 从用户发起请求到收到结果的总时间 | 包含模型、订单工具、政策工具及网络 |
| 首字时间 / TTFT | 用户等到第一个可见内容的时间 | 流式界面何时开始出现有意义的文字 |
| 失败率 | 按明确错误定义，失败请求占全部请求的比例 | 超时、服务报错、无法取得必须的政策 |
| Token | 模型处理文本等内容的计量片段 | 两次模型调用读入政策、生成答复的用量 |
| 单次成本 | 完成一笔业务请求耗费的模型及相关服务成本 | 模型 token、搜索/检索接口和重试的费用 |
| SLI / SLO | SLI 是测到的服务水平指标；SLO 是给该指标定的目标 | SLI 为“2 秒内完成的请求比例”，SLO 是团队约定的门槛 |
| 灰度 / Canary | 先让少量真实流量试新版本并比较 | 先给少量客服请求使用新 Prompt，出现异常就回退 |
这里的“答对率”不是只看中文是否顺畅；“失败率”也不是只看 HTTP 有没有返回 500。一个模型很快返回 200 OK，却凭空宣布“已退款”，技术请求成功，业务答案仍失败。反过来，政策服务暂时不可用时，应用说明无法核实并转人工，虽然没有给出自动结论，却可能是符合安全要求的处理。具体如何计分，要在上线前约定清楚。
先把“答对”定义到能评测
对于 A123，质量至少含四层：
- 事实正确。 订单是不是 A123、签收日是不是 2026-09-23、是否未拆封，必须与订单系统一致。
- 依据正确。 使用的是当日对耳机有效的政策，而非旧版、其他商品类目的规则；答复要能指出根据哪一份材料。
- 结论正确。 3 天在 7 天之内且未拆封，只能说“可提交人工审批”，不能把申请资格写成退款已完成。
- 缺证据时行为正确。 订单归属核验失败、政策查不到或两个来源冲突时，要暂停结论并说明缺口；不允许模型凭常识补一条退货政策。
因此，离线测试题不能只放“最简单的 A123 正例”。至少再放签收 13 天、已拆封、政策版本冲突、查询超时、非本人订单、用户诱导“不要查政策直接同意”等案例。每条样本要带预期可接受行为，而不只是一个标准句子。例如“签收 13 天”可能期待“按此政策不符合提交条件，并给人工申诉入口”；“政策服务超时”期待“不做资格判断，转人工”。这些标注最好由业务负责人核对。OpenAI 的模型优化指南要求评测数据能代表真实输入，LangSmith 的评测类型说明也区分上线前的基准、单元和回归评测与上线后的在线评测。
先定分母，再报数字。 假设我们有 100 条离线案例：90 条按预期答复，6 条正确说明证据不足并转人工，4 条给了无依据的肯定结论。若评分规则认为那 6 条转人工正是预期，合格数是 90 + 6 = 96，合格率 96/100 = 96%。若有人只统计模型生成了具体答案的 94 条，并把 90 条正确除以 94，就得出约 95.7%；这和前一个指标定义不同，不能在报告里混用。更不能把 4 条危险回答从分母里删掉。
同一个“总体正确率”也可能遮住重要小类。100 条里如果只有 5 条非本人订单，而其中 2 条泄露了状态，即使总体分数高，也不能上线。要按普通咨询、无依据咨询、敏感订单、工具失败等切片分别看，并对越权读取、错误批准等高风险事件设单独的“不得出现”要求。对有标准结果的字段，可以用程序自动比对；对答复是否误导用户，可以让人工抽检或评审模型辅助，但评审模型的分数也需要校准，不能当成绝对真值。LangSmith 评测文档区分代码评审、模型评审与人工反馈适用场景。
用户等多久：平均值和 P95 要一起看
端到端耗时从用户发出问题开始，到完整且可用的答复到达为止。对于 A123，它包括身份校验、订单接口、政策检索、可能两次模型调用、程序校验和网络传输。只测模型单次生成的耗时，会漏掉慢的政策接口；只测浏览器收到第一个字，也会漏掉后面等工具 10 秒才补出结论的情况。
假设 100 次请求按耗时从短到长排序，第 95 个是 3.2 秒，那么按常见的“最近秩”定义，P95 为 3.2 秒：约 95% 请求在 3.2 秒内完成，仍有约 5% 更慢。统计平台可能用不同的插值算法，精确数值会略有区别，因此同一看板要固定算法和统计窗口。平均耗时可能只有 1.1 秒，但若少量请求卡在 12 秒，用户依然会明显抱怨。Google SRE 的监控指南建议看延迟百分位数，以识别均值掩盖的慢请求。
流式输出时还要看首字时间：用户何时看到第一段有用内容？但“正在为你查询”这样的占位文字不能当成真正的答案。可以分开统计首字时间、完整答案时间、订单接口耗时、政策接口耗时和模型调用耗时。比如 A123 总耗时 4 秒，其中政策接口 2.8 秒，优化模型提示词只能碰到小头；应先处理政策检索性能和超时策略。OpenAI 延迟优化指南把减少不必要请求、输出 token、串行等待等列为优化方向。
上线目标没有放之四海而皆准的数字。实时客服和夜间批处理的允许等待不同。团队要先与产品确认“用户能接受多久”，再为相同的业务路径、相同流量规模设门槛，例如“工作时间的客服查询，至少 95% 在约定秒数内完成”。压测时既要看平常流量，也要看活动峰值；模型服务和工具接口还可能有速率上限，超限后的排队与重试会把 P95 拉高。Google SRE 对 SLI/SLO 的定义、OpenAI 生产实践
可靠性：把“停得安全”也算进来
一笔 Agent 请求可能经历多个子步骤。假设订单工具成功、政策工具超时，外层程序捕获异常并返回“暂无法核实，已转人工”。在 HTTP 层，这次请求可以是正常返回；在业务层，它是未自动解决；在工具层，政策查询是一次失败。看板必须分别记录，否则“HTTP 成功率 100%”会掩盖政策服务故障，也会把安全转人工误说成“问题自动解决”。
我会至少分开统计：
| 指标 | 建议口径 | A123 的失败例 |
|---|---|---|
| 请求完成率 | 用户收到明确结果或明确的安全退路 / 全部请求 | 页面一直转圈、无错误提示 |
| 自动解决率 | 无需人工且答案按业务规则合格 / 全部适用请求 | 政策超时转人工，不算自动解决 |
| 工具失败率 | 指定工具失败次数 / 该工具调用总次数 | 政策查询 100 次里 7 次超时 |
| 无依据肯定回答率 | 缺订单或政策证据仍作肯定判断的次数 / 相关缺证据请求 | 查不到政策仍说“保证能退” |
| 越权或高风险操作次数 | 未授权访问/执行的次数，单独报告 | 其他用户查到 A123 细节，或自动发起退款 |
这些分母要写在看板说明里。“工具失败率”按调用次数算时，一笔用户请求如果重试了 3 次，会贡献 3 次调用；“请求完成率”按用户请求数算时只贡献 1 次。两者不能直接相加或比较。工具层追踪能帮忙定位哪一步失败；LangSmith 的可观测性概念把一条请求表示为 trace，把模型和工具调用表示为子 run，适合把这两种口径分开观察。
失败处理本身也有验收条件。订单查询超时，不能用模型对 A123 的猜测补出状态；政策查到两个互相冲突的版本，不能随机挑一个；模型持续反复调用同一工具，要被步数、耗时和费用预算停住。权限检查应在服务端和真实工具里做，而不是只写“不要泄露订单”在提示词中。上线前针对这些路径做故障演练，确认最终仍能给用户清楚的下一步。安全问题除了常规错误率，还要单独记录数据泄露、提示词注入、越权工具调用以及人工审批是否被绕过。OpenAI 生产安全实践、安全最佳实践
一次咨询花多少钱，要算整条链
“每次成本”不是看模型价目表上某个单价。一次 A123 咨询可能先让模型决定查什么，调用订单与政策工具，再让模型生成答复；遇到超时还可能重试。应把模型输入/输出 token、模型调用次数、外部搜索或数据库调用、缓存命中和重试按同一请求 ID 汇总。用户看的是“一次咨询”，所以报表至少给出每次成功咨询的平均成本、P95 成本或高成本尾部，以及日总额和峰值预算。
假设某模型与相关服务的计费规则已经确认，示意计算如下；表里的数字只讲计算方法，不是任何提供商当前价格：
| 本次咨询动作 | 假设费用 |
|---|---|
| 第一次模型调用：判断需查订单与政策 | 0.004 元 |
| 第二次模型调用：根据结果组织答复 | 0.009 元 |
| 外部检索服务 | 0.002 元 |
| 合计 | 0.015 元 |
如果第二次模型调用因格式错误又重试两次，每次都耗 0.009 元，合计会变为 0.015 + 2×0.009 = 0.033 元；一次失控的循环可能进一步放大费用。精确账单要按提供商实际用量、计费单位、缓存、币种和时间核对。不设调用上限，只看平均每次成本，容易被少数异常请求拖垮预算。OpenAI 的成本优化指南把减少请求、减少 token 和选择合适模型列为基本杠杆；生产实践也强调用量跟踪与花费控制。
降成本不能只改一个数字。把模型换小或缩短上下文可能减少费用，却可能漏掉政策关键条款；强行限制输出可能让用户看不懂“为什么仍需人工审批”。应在同一批评测题上同时比较质量、P95 延迟和成本。若小模型处理普通政策咨询已达标，可把复杂冲突案例升级到能力更强的模型或人工；路由规则和升级条件也要评测，避免“难题刚好被便宜模型误判”。
指标怎样变成上线决策
指标只有连着测量方法才有用。我会按下面顺序验收：
- 冻结一个候选版本。 记录模型版本、提示词版本、工具代码、政策知识库版本和依赖配置。否则今天的正确率与明天的延迟可能根本不是同一套系统。
- 准备代表性题集。 正常、长尾、无权限、资料缺失、超时、政策冲突和恶意文本都要覆盖；给每类标注预期动作和严重程度。
- 在相同负载下测端到端。 记录完整答案的 P50/P95/P99、首字时间、吞吐量、工具耗时和队列时间。性能报告要说明并发数、请求规模、测试时长和统计窗口；不能把空载开发机的平均耗时当线上目标。
- 计算质量与边界指标。 用程序检查确定性字段与权限；对表述质量做人工抽检或有校准的评审。报告总分也报告关键切片，尤其零容忍的越权、虚构审批、敏感信息泄露。
- 核算真实成本并设置预算。 按一次用户请求聚合模型和工具用量，模拟峰值、重复工具调用与重试，确认限额触发时有可理解的退路。
- 小流量灰度并准备回滚。 先让一小部分真实请求进入新版本，持续比较线上质量、P95、失败率、人工转接率与成本；超过预设界限就切回上一个稳定版本，并保留去敏的故障样本供复盘。
这里的“预设界限”应由业务影响倒推，而不是照抄别人说的“正确率 95% 就够”。客服的退款建议可能要严格控制“错误批准”，即使整体准确率不错，一次严重误导也可能让版本不能上线。一个内部知识库摘要工具则可能容忍某些措辞差异，但仍不能容忍数据泄露。Google SRE 把可测的 SLI 与明确的 SLO 连接起来，本题也应这样做：先定义何为用户满意或可接受失败，再给数字门槛。Google SRE：Service Level Objectives
上线不是“测试结束”。新政策、新用户问法、模型版本变化都会让质量漂移。线上看板持续记录趋势；发现问题后，把脱敏案例加入离线题集，修复后再比旧版本。LangSmith 把上线前离线评测与线上在线评测分开，线上异常还能反过来补充离线回归集。LangSmith 评测类型
面试时可以这样回答
我上线前先定义业务成功，而不是只看模型输出是否流畅。对客服 Agent，我会用有标准答案和预期失败行为的样本测事实、依据、结论与缺证据时是否停住，并单独看非本人订单、政策冲突等高风险切片。性能看用户端到端的 P95/P99 和首字时间，同时拆出模型、检索和工具耗时；可靠性要区分 HTTP 成功、工具失败、自动解决与安全转人工。成本按一笔用户请求汇总所有模型调用、token、搜索和重试，并看异常高成本尾部。每个指标写清分母、测试负载、目标和报警条件。验收后先灰度，和稳定版本比较；如果无依据肯定回答、越权、尾部延迟或成本越过门槛，就回滚并把案例加入回归集。
若面试官追问“一个 200 响应为什么仍可能失败”，可以答：模型可能成功返回了错误的退款结论，或工具超时后它擅自猜测；技术成功率与业务正确率要分开。若追问“平均延迟 1 秒还要看 P95 吗”，答：少量 10 秒慢请求会让用户体验很差，平均值会掩盖它们。若追问“上线门槛是多少”，答：先写清场景、风险和统计口径，门槛由业务影响与用户等待容忍度决定，不能凭空给所有应用一个固定数字。