第 16 章：成本、延迟与规模化评测

16.1 质量更高但系统不可用，也不是好版本

客服 Agent 的候选版本在答案质量上明显提升。它会更谨慎地检索知识、调用工具、解释规则，也更少出现无依据承诺。

但评测报告同时显示：

• 平均工具调用轮数从 3 次增加到 9 次。
• P99 延迟从 8 秒上升到 31 秒。
• 单会话成本上涨 2.8 倍。
• 部分用户在等待中转人工或退出。

这个版本不能简单判定为更好。

企业级 AI 评测必须把质量、成本和延迟放在同一张决策表里。质量提升如果以不可接受的成本和体验为代价，就不一定具备生产可用性。

16.2 质量、成本、延迟三维决策

一个 AI 系统的版本选择，至少要同时看三维：

维度	问题
质量	是否更正确、更安全、更可用
成本	Token、工具、人工、沙箱成本是否可接受
延迟	用户是否能接受响应时间

三者经常冲突。

策略	质量	成本	延迟
增加多轮思考	可能提升	上升	上升
增加检索 TopK	可能提升	上升	上升
强制工具校验	提升高风险准确性	上升	上升
使用小模型	可能下降	下降	下降
缓存常见结果	稳定	下降	下降

评测结论应说明版本位于什么取舍位置，而不是只报告质量分。

16.2.1 成本和延迟要按业务场景解释

成本和延迟没有脱离业务的统一答案。相同的 10 秒响应，在普通物流咨询中可能不可接受，在高金额退款审批中可能可以接受；相同的 3 次工具调用，在 FAQ 问答中可能过重，在部分退款金额计算中可能必要。

因此，成本与延迟评测应按场景分层，而不是用一个全局阈值评判所有任务。

场景	用户期待	可接受策略
普通 FAQ	快速、直接、低成本	轻检索、少工具、短回答
订单查询	身份安全和状态准确	身份核验 + 查询工具，延迟可略高
部分退款计算	金额准确和依据清楚	多工具校验、规则计算、必要解释
高金额退款	风险可控、可审计	严格流程、人工审批、较高成本可接受
投诉升级	快速识别和转接	减少无效解释，优先人工兜底

生产决策的关键不是“越便宜越好”，而是判断每一类场景中哪些成本属于必要质量成本，哪些成本属于低效浪费。身份核验、金额校验和高风险审批是必要成本；重复检索、无效循环和低价值 Judge 自检通常是浪费。

16.3 核心效率指标

成本与延迟评测需要标准指标。

指标	含义
input_tokens	输入 token 数
output_tokens	输出 token 数
total_tokens	总 token 数
cost_per_case	单样本模型成本
cost_per_session	单会话成本
tool_call_count	工具调用次数
retry_count	重试次数
latency_p50 / p90 / p99	不同分位响应时延
timeout_rate	超时比例
throughput	单位时间处理能力
sandbox_resource	CPU、内存、磁盘、执行时间

对于 Agent，还要记录步骤级成本。否则只看总成本，无法知道成本被哪个环节放大。

16.4 Agent 成本放大

Agent 比普通问答更容易成本失控。

常见成本放大原因：

原因	示例
多步规划	简单问题被拆成过多步骤
过度检索	每轮都重复检索相同知识
工具重试	工具失败后无策略反复调用
循环执行	代码 Agent 重复运行失败命令
长上下文累积	多轮对话不断带入无关历史
Judge 成本	大规模评测使用昂贵 Judge
人工复核过量	低风险样本也进入人工

客服 Agent 如果每次退款咨询都调用订单、会员、优惠券、物流和客服工单工具，质量可能提高一点，但成本和延迟会显著上升。

评测要识别哪些步骤必要，哪些是无效冗余。

对于代码 Agent 这类执行型系统，成本结构与客服 Agent 差异显著。客服 Agent 的主要成本是 Token 和工具调用；代码 Agent 的主要成本是沙箱执行时间（CPU/内存）和命令运行次数，Token 占比反而不高。代码 Agent 可能陷入无限循环反复执行失败命令，必须设置单步超时、总执行时间上限和资源配额作为硬性门禁，否则一次评测可能耗尽沙箱资源。

16.5 成本门禁

成本和延迟可以设置门禁，但要分层。

门禁类型	示例
观察	平均成本上涨 10%，进入报告
预警	P95 延迟超过基线 20%，需要解释
软门禁	单会话成本超过预算，需要审批
硬门禁	P99 延迟超过用户体验红线，阻断发布

客服 Agent 的高风险退款场景可以允许更高成本，因为工具校验和人工兜底有必要。普通物流查询则不应使用过重策略。

因此，成本门禁要按场景分层，而不是全局一个阈值。

16.6 评测体系自身的成本

评测也会消耗成本。

大规模评测需要考虑：

• 模型调用成本。
• Judge 调用成本。
• 工具和沙箱资源成本。
• 人工标注成本。
• 数据存储和日志成本。
• 运行时间和排队成本。

控制方法包括：

方法	说明
抽样	对低风险场景抽样评测
增量评测	只跑受变更影响的 Case
缓存	对确定性中间结果缓存
分层评估器	规则先筛，Judge 后判，人工兜底
并发调度	控制队列和资源配额
夜间批量	非阻塞评测放到低峰运行

评测系统如果过慢过贵，团队会绕开它。可持续运行本身就是质量体系的要求。

16.6.1 评测运行的分级调度

规模化评测要避免两种低效：所有变更都跑全量，或者为了省成本只跑少量样本。更合理的做法是按风险和时效分级调度。

调度层级	触发时机	目标	运行策略
Smoke	开发中、提交前	快速发现明显错误	小样本、低成本、分钟级反馈
受影响回归	合并前、发布前	覆盖变更影响范围	根据变更对象选择 Case
高风险全量	发布前	拦截 P0 / P1 风险	Red Team、关键 Regression 全量执行
夜间批量	非阻塞周期任务	发现慢性退化和漂移	大样本、低优先级、成本预算控制
线上采样	灰度和全量后	校准真实分布	抽样、脱敏、人工和自动结合

例如客服 Agent 的 Prompt 小改，可以先跑 Smoke 和相关 Regression；模型替换则必须跑全量业务 Eval、Red Team 和成本延迟；知识库日更可以跑受影响 RAG Case 和线上采样。分级调度的目标是让评测既不缺席，也不拖垮研发节奏。

16.7 帕累托前沿

版本比较不应只选质量最高的。

假设三个候选版本：

版本	质量分	单会话成本	P95 延迟
A	86	1.0x	4s
B	89	1.4x	6s
C	90	3.2x	18s

C 的质量最高，但成本和延迟可能不可接受。B 可能是更好的生产选择。

这就是质量、成本、延迟的帕累托选择：不存在一个版本在所有维度都最好时，要选择业务上最可接受的平衡点。

16.7.1 生产版本选择的决策表

版本选择可以用“质量收益是否覆盖生产代价”来判断。

质量变化	成本变化	延迟变化	建议决策
核心质量明显提升，高风险下降	成本可控	延迟可控	放行或扩大灰度
质量小幅提升	成本显著上升	延迟显著上升	谨慎，要求说明收益来源
总分提升但高风险退化	任意	任意	阻断或限定低风险场景
质量持平	成本下降	延迟下降	可灰度，观察线上体验
质量下降	成本下降	延迟下降	不应直接发布，除非明确降级场景
质量提升集中在低价值场景	成本上升	延迟上升	不优先发布

这张表能防止两种误判：一种是看到质量分提升就忽视成本，另一种是为了降低成本牺牲高风险质量。对企业 Agent 来说，最优版本通常不是分数最高的版本，而是在核心业务、安全边界、成本预算和用户体验之间最稳的版本。

16.8 代码和沙箱任务的资源评测

执行型 Agent 还要关注沙箱资源。

代码 Agent 的评测指标包括：

• 命令执行次数。
• 测试运行次数。
• 文件修改数量。
• 无关文件修改比例。
• CPU 和内存峰值。
• 沙箱运行时间。
• 网络访问和权限行为。

一个 Agent 最终修复了 bug，但过程中运行 80 次测试、修改大量无关文件、消耗过多资源，也不能算理想。

沙箱评测要同时看终态和过程成本。

16.9 客服 Agent 案例：调用轮数从 3 到 9

候选版本为了降低错误承诺，新增了更保守的策略：

1. 每个退款问题都检索政策。
2. 每个退款问题都查订单。
3. 每个退款问题都查会员权益。
4. 每个退款问题都调用优惠券工具。
5. 回答前再调用 Judge 自检。

质量有所提升，但大量简单问题也进入重流程。

评测拆解后发现：

场景	必要动作	候选版本动作
普通退款时效	检索政策即可	调用 4 个工具
金额计算	需要订单和优惠券工具	合理
会员权益	需要会员和退款规则工具	合理
投诉升级	应转人工	工具调用过多

修复方向不是放弃工具，而是做场景路由：低风险问题走轻流程，高风险问题走重流程。

16.9.1 成本优化不能破坏安全边界

降低成本时，最容易犯的错误是把必要的安全步骤也当作冗余步骤删除。

客服 Agent 的成本优化应遵守三条底线：

1. 不能删除身份核验、权限校验和高风险审批。
2. 不能用缓存结果替代需要实时校验的订单、金额和权益状态。
3. 不能为了减少工具调用而允许模型凭记忆回答高风险业务问题。

可优化的是低风险场景中的重复检索、无效 Judge、自循环工具调用、过长上下文和不必要人工复核。不可优化的是保障安全、合规和业务终态的关键动作。

成本动作	可否优化	判断依据
普通政策咨询每轮重复检索	可以	若同一会话内政策版本未变化，可缓存
退款提交前身份核验	不可删除	属于权限和合规底线
高金额退款人工审批	不可删除	属于风险控制底线
对低风险样本使用昂贵 Judge	可以	可改为抽样或低成本评估器
工具失败后无限重试	必须优化	应设置重试上限和转人工

质量、成本和延迟的平衡，不能以牺牲红线为代价。评测报告应明确哪些成本属于必要质量成本，哪些属于低效浪费。

16.10 交付物一：质量-成本-延迟三维评估表

版本	场景	质量指标	成本指标	延迟指标	决策
	核心场景	任务完成率、正确率	单会话成本	P95 / P99	放行 / 灰度 / 阻断
	高风险场景	安全通过率、误放率	工具成本	P95 / P99
	长尾场景	Hard Case 通过率	Judge 成本	平均耗时

这张表要求评测报告同时呈现三维信息。

16.11 交付物二：Agent 成本归因表

case_id	step	action	token_cost	tool_cost	latency_ms	是否必要	备注
	1	retrieve				是 / 否
	2	tool_call				是 / 否
	3	judge_check				是 / 否

成本归因表用于识别无效步骤、循环和过度工具调用。

16.12 交付物三：评测运行成本预算模板

eval_run_budget:
  scope: refund_agent_release_check
  max_cases: 5000
  max_model_cost_usd: 300
  max_judge_cost_usd: 120
  max_runtime_hours: 4
  max_human_review_cases: 200
  strategy:
    smoke: full
    golden: full
    regression: affected_only
    hard_case: sample
    red_team: full_for_high_risk
  escalation:
    if_budget_exceeded: require_eval_owner_approval

预算模板让评测系统可持续运行，并避免临时成本失控。

16.12.1 预算超限后的降级策略

评测预算超限时，不能简单停止评测，也不能无条件扩容。更稳妥的做法是定义降级策略。

超限类型	不建议做法	推荐策略
模型调用成本超限	随机砍掉样本	保留门禁、Red Team、关键 Regression，抽样低风险场景
Judge 成本超限	全部改成人工或全部跳过	规则先筛，Judge 只看开放语义和低置信样本
运行时间超限	取消发布前评测	分层执行，先跑阻断类门禁，再跑诊断类任务
人工复核超限	降低人工标准	优先复核 P0 / P1、Judge 分歧和线上高价值样本
沙箱资源超限	合并不相关任务	按风险和变更影响排队，限制长程任务并发

预算降级也要有质量底线：高危安全样本、核心回归样本、发布硬门禁不能随意跳过。低风险观察指标可以延后，高风险门禁不能省略。

16.13 常见误区

16.13.1 只看质量分

质量提升如果带来不可接受的延迟和成本，生产价值可能下降。

16.13.2 对所有场景使用同一成本阈值

高风险场景可以更重，低风险场景应更轻。

16.13.3 忽略评测自身成本

评测运行太贵太慢，会被研发流程绕开。

16.13.4 不做步骤级成本归因

总成本上涨无法指导优化。必须知道成本来自检索、工具、Judge、重试还是循环。

16.14 本章小结

企业级评测必须把质量、成本和延迟一起纳入决策。

Agent 场景尤其容易发生成本放大：多步调用、循环、工具重试、长上下文和 Judge 评估都会推高成本。评测体系自身也需要成本预算、抽样、缓存、增量执行和人工复核分流。

一个真正可上线的版本，不只是质量分更高，还要在成本、延迟和资源消耗上可接受。

从下一章开始，我们将进入 EvalOps 平台建设，看看如何把脚本和报告升级为持续运转的质量基础设施。