第 10 章：评测类型全景与组合策略
第 10 章：评测类型全景与组合策略
10.1 只跑公开 Benchmark，不能决定企业应用能否上线
客服 Agent 准备发布前，团队查看了候选模型的公开 Benchmark 分数。候选模型在通用推理和知识问答上表现更好，于是有人认为可以直接替换。
但上线后，退款场景出现大量误答。原因很简单：公开 Benchmark 没有覆盖企业自己的政策、工具、流程、风险边界和用户分布。
评测类型没有一种能解决所有问题。公开 Benchmark 可以帮助模型选型，但不能代替业务 Eval Set；离线评测可以支撑发布前判断，但不能代替线上灰度；自动评测可以提高效率，但不能完全代替高风险人工复核。
企业级评测需要组合策略。
10.2 静态 Benchmark：适合摸底，不适合直接发布决策
静态 Benchmark 的价值是快速了解基础能力。
适合用于：
- 模型初筛。
- 基础推理、语言、代码、知识能力摸底。
- 横向比较候选模型。
- 发现明显短板。
不适合用于：
- 判断企业业务场景能否上线。
- 替代安全与合规评测。
- 证明 Agent 工具调用可靠。
- 判断知识库和业务流程是否正确。
客服 Agent 需要理解企业退款政策、调用订单工具、遵守身份核验流程。这些能力通常不在公开 Benchmark 中。
因此，Benchmark 是起点，不是终点。
10.3 业务 Eval Set：企业评测的主战场
业务 Eval Set 面向真实业务任务。
它应覆盖：
- 核心业务场景。
- 高频用户意图。
- 高风险场景。
- 长尾表达。
- 多轮对话。
- 工具和知识库链路。
- 安全与兜底策略。
客服 Agent 的业务 Eval Set 可以包括：
| 场景 | 样本类型 |
|---|---|
| 订单查询 | 标准查询、身份核验失败、查无订单 |
| 退款咨询 | 普通退款、部分退款、优惠券、会员积分 |
| 物流问题 | 延迟、丢件、改地址 |
| 发票问题 | 开票、重开、抬头修改 |
| 投诉升级 | 高风险情绪、人工转接 |
| 安全边界 | 隐私请求、越权查询、诱导绕规则 |
业务 Eval Set 是发布和回归的核心依据。
10.4 Golden、Regression、Hard Case、Red Team 的职责边界
企业评测常用四类关键数据集。
| 类型 | 作用 | 更新方式 |
|---|---|---|
| Golden Set | 稳定衡量核心能力 | 低频维护 |
| Regression Set | 防止已知问题复发 | 随 Bad Case 增长 |
| Hard Case Set | 覆盖复杂和边界场景 | 持续补充 |
| Red Team Set | 探测安全和滥用风险 | 随风险策略更新 |
四类数据不能混用。
Golden Set 要稳定，用于版本可比性。Regression Set 要快速吸收已修复问题，防止复发。Hard Case Set 用于暴露能力边界，不应要求所有早期系统都满分。Red Team Set 用于红线风险，失败往往不能用平均分掩盖。
客服 Agent 退款政策误答被修复后，应进入 Regression Set；“用户诱导 Agent 绕过身份验证查订单”应进入 Red Team Set；“多轮复杂优惠券部分退款”可以进入 Hard Case Set。
10.4.1 数据集组合要服务决策，而不是追求平均覆盖
企业评测集不是把所有样本平均分配到各类场景。不同数据集承担不同决策职责，因此样本比例也应不同。
| 数据层 | 适合高占比覆盖什么 | 不适合承担什么 |
|---|---|---|
| Golden Set | 核心稳定能力、高频场景、代表性流程 | 暴露全部长尾和攻击风险 |
| Regression Set | 已修复 Bad Case、历史事故、反复出现的问题 | 衡量整体业务能力 |
| Hard Case Set | 长尾、复杂、多约束、边界任务 | 作为唯一发布门禁 |
| Red Team Set | 安全、越权、隐私、诱导、成本攻击 | 衡量日常体验 |
| Online Sample | 真实分布、漂移、未覆盖问题 | 发布前确定性验收 |
客服 Agent 的发布报告如果只说“总通过率 92%”，价值有限。更有用的表达是：Golden 是否稳定，Regression 是否防复发，Hard Case 暴露了哪些能力边界，Red Team 是否触发阻断，线上灰度是否支持继续放量。
因此，评测组合的核心不是“样本越多越好”，而是每一层都能回答自己的决策问题。
10.5 在线评测与 A/B
离线评测通过后，仍需要线上验证。
在线评测关注真实用户分布下的表现：
- 投诉率。
- 转人工率。
- 重复提问率。
- 工具失败率。
- 用户满意度。
- 成本和延迟。
- 安全事件。
A/B 测试适合比较两个策略，但必须注意风险控制。高危场景不能为了实验随意暴露给用户。
客服 Agent 可以在低风险咨询场景做较大流量 A/B，在退款、账号和隐私场景采用更保守灰度，并配合人工抽检。
在线评测不是用来替代离线评测，而是校准离线评测。
10.6 人工评测与自动评测
人工评测适合高风险、复杂、争议和 Rubric 校准场景。自动评测适合规模化、回归和快速反馈。
| 方式 | 适合 | 不适合 |
|---|---|---|
| 规则 | 格式、字段、安全词、结构校验 | 复杂语义 |
| 脚本 | 工具终态、数值计算、检索指标 | 开放回答质量 |
| LLM Judge | 语义质量、风格、忠实性 | 高风险最终裁决 |
| 人工 | 高风险、争议、业务语境 | 大规模日常回归 |
组合方式通常是：
- 规则和脚本先拦截确定性问题。
- Judge 扩展语义覆盖。
- 人工复核高风险和低置信样本。
- 人工结果反过来校准 Judge。
10.7 动态评测与沙箱
Agent 执行型任务需要动态环境。
静态样本只能告诉你“模型会怎么说”，不能验证“Agent 会怎么做”。
沙箱评测适合：
- 代码修改和测试执行。
- 多步工具任务。
- 状态变化任务。
- 长程规划任务。
- 有副作用风险的模拟任务。
客服 Agent 可以在模拟订单系统中评测退款流程，代码 Agent 可以在隔离仓库中评测修复 bug 的全过程。
动态评测要记录环境初始状态、工具返回、状态变化和终态。否则无法复现。
10.8 多层评测防线
企业发布流程中，可以设计多层防线。
| 阶段 | 评测类型 | 目标 |
|---|---|---|
| 开发中 | Smoke、单组件 Case | 快速发现明显问题 |
| 合并前 | Golden、受影响 Regression | 防止核心退化 |
| 发布前 | 全量业务 Eval、Hard Case、Red Team | 支撑发布决策 |
| 灰度中 | Online 指标、人工抽检、Bad Case 采样 | 验证真实流量 |
| 全量后 | 持续监控、周期回归 | 发现漂移和复发 |
多层防线的重点是分工。Smoke 不负责证明系统可靠，Red Team 不负责衡量日常体验，线上监控不负责替代发布前门禁。
10.9 客服 Agent 发布组合
一次客服 Agent 发布可以这样组合评测：
| 变更 | 必跑 | 可选 |
|---|---|---|
| Prompt 修改 | Smoke、Golden、Regression | Hard Case 抽样 |
| 知识库更新 | RAG Case、相关业务 Regression | 线上采样复核 |
| 工具 Schema 修改 | Tool Case、Trace Case | 沙箱端到端 |
| 模型替换 | 全量业务 Eval、Red Team、成本延迟 | 人工偏好评测 |
| 安全策略修改 | Red Team、误拒评测 | 灰度人工抽检 |
评测组合应由变更类型触发，而不是每次都人工决定。
10.9.1 变更触发评测矩阵
企业级评测不能依赖人工记忆决定“这次该跑什么”。每类变更都应绑定默认评测组合。
| 变更对象 | 主要风险 | 必须触发的评测 |
|---|---|---|
| Prompt | 指令遗漏、风格变化、边界放松 | Golden、Regression、Judge 校准样本 |
| 模型 | 能力变化、安全策略变化、成本变化 | 全量业务 Eval、Red Team、成本延迟、抽样人评 |
| 知识库 | 过期政策、召回失败、引用错位 | RAG Case、知识版本检查、相关 Regression |
| 工具 Schema | 参数错误、接口兼容、权限变化 | Tool Case、Trace Case、沙箱端到端 |
| Agent 编排 | 步骤顺序、循环、异常恢复 | Trace 评分、Workflow Case、成本归因 |
| 门禁阈值 | 质量标准漂移、发布风险变化 | 历史 Run 回放、风险评审、审批留痕 |
| Evaluator | 分数不可比、Judge 漂移 | Meta-Eval、人工一致性、历史样本重评 |
矩阵的好处是让评测从“项目制检查”进入“变更驱动机制”。只要变更发生，系统就能自动选择最小必要评测范围，同时保证高风险变更不会漏测。
10.10 交付物一：评测类型选型决策表
| 目标 | 推荐评测 | 不应只依赖 |
|---|---|---|
| 模型初筛 | 静态 Benchmark | 业务上线结果 |
| 业务发布 | 业务 Eval Set、Golden、Regression | 公开 Benchmark |
| 防复发 | Regression Set | Golden Set |
| 探测边界 | Hard Case、Red Team | 平均分 |
| 验证真实效果 | Online、A/B、灰度 | 离线分数 |
| Agent 执行 | 沙箱、Trace、终态检查 | 最终回答 |
| 高风险裁决 | 人工复核 + 自动证据 | 单一 Judge |
这张表帮助团队选择正确工具，而不是迷信单一评测方法。
10.11 交付物二：多层评测防线设计模板
system: 客服 Agent
change_type: knowledge_base_update
stage:
development:
evals:
- smoke_rag_retrieval
pre_merge:
evals:
- affected_rag_cases
- refund_regression_set
pre_release:
evals:
- full_refund_eval_set
- red_team_privacy_cases
- cost_latency_check
gray_release:
monitors:
- transfer_to_human_rate
- complaint_rate
- unsupported_answer_rate
post_release:
actions:
- online_bad_case_sampling
- regression_set_update
模板要明确每一层的目的、数据和动作。
10.12 常见误区
10.12.1 用 Benchmark 替代业务评测
通用能力强不代表企业任务可靠。
10.12.2 用平均分覆盖红线风险
Red Team 和 P0 风险不能被平均分掩盖。
10.12.3 所有评测都全量跑
全量评测成本高，会拖慢迭代。应按变更类型触发。
10.12.4 只做离线，不做线上
离线评测必须通过线上反馈校准。
10.12.5 只做自动，不做人评校准
高风险和争议场景需要人工建立质量基准。
10.13 本章小结
企业级评测不是选择某一种评测方法，而是构建组合防线。
公开 Benchmark 适合模型摸底，业务 Eval Set 支撑发布决策，Golden 保持核心能力可比，Regression 防复发，Hard Case 暴露边界，Red Team 控制安全风险，Online 和 A/B 验证真实分布，沙箱和 Trace 支撑 Agent 执行评测。
有了评测策略，下一章我们将解决"用什么评"的问题——评测数据资产该如何建设、分层和管理。