07 何时应改变开发、测试集和评估指标（When to change dev、test sets and metrics）

07 何时应改变开发、测试集和评估指标（When to change dev、test sets and metrics）

一、核心思想：评估指标与开发/测试集是“目标”，需随项目演进动态调整

• 开发集（dev set）和评估指标（metric）共同定义了模型优化的 目标方向。
• 如果当前指标或数据分布 无法准确反映真实业务需求或用户偏好，就应果断修改它们。
• 不要固守一个不合适的指标，即使它“数学上简洁”——关键是它是否能 正确排序算法优劣。

✅ 关键原则：
当指标或开发集不能预测实际部署效果时，必须修改！

---

二、典型场景一：评估指标未能反映业务风险（如色情内容误判）

问题描述

• 任务：构建猫图片分类器，向爱猫用户推荐猫图。

• 原始指标：分类错误率（Classification Error Rate）

  \[\text{Error} = \frac{1}{m_{\text{dev}}} \sum_{i=1}^{m_{\text{dev}}} \mathbb{1}\left\{ y^{(i)} \neq \hat{y}^{(i)} \right\}\]
• 算法 A：错误率 3%，但会将色情图片误判为猫图 → 用户体验极差。
• 算法 B：错误率 5%，但从不推送色情内容 → 用户更满意。

问题本质

• 原始指标对所有错误 等权重处理，忽略了错误类型的严重性差异。
• 导致指标“选错”了算法（A > B），但实际业务中 B 更优。

解决方案：引入加权错误率（Weighted Error）

• 对不同样本赋予不同惩罚权重 $w^{(i)}$：

  \[\text{Weighted Error} = \frac{1}{\sum_{i=1}^{m_{\text{dev}}} w^{(i)}} \sum_{i=1}^{m_{\text{dev}}} w^{(i)} \cdot \mathbb{1}\left\{ y^{(i)} \neq \hat{y}^{(i)} \right\}\]

• 其中：

  \[w^{(i)} = \begin{cases} 1, & \text{若 } x^{(i)} \text{ 不是色情图片} \\ 10 \text{ 或 } 100, & \text{若 } x^{(i)} \text{ 是色情图片} \end{cases}\]

💡 实现前提：需在开发集和测试集中人工标注哪些是色情图片，才能计算加权项。

启示

• 评估指标应体现业务优先级：高风险错误应被重罚。
• 指标设计不是纯技术问题，而是产品+工程+伦理的综合决策。

---

三、典型场景二：开发/测试集分布与真实应用场景不一致

问题描述

• 开发/测试集：来自网络的高质量、专业拍摄的猫图（清晰、构图好）。
• 实际应用：用户手机上传的模糊、遮挡、非标准角度的猫图。
• 结果：在开发集上表现好的模型（如算法 A），在真实场景中反而不如开发集上表现稍差的模型（算法 B）。

问题本质

• 数据分布偏移（Distribution Shift） ：训练/评估数据 ≠ 目标部署数据。
• 导致开发集上的指标失去预测能力。

解决方案：更换开发/测试集

• 新开发集应模拟真实用户输入：包含模糊、低光照、部分遮挡等“脏数据”。
• 目标：让开发集成为真实应用场景的代理（proxy） 。

✅ 黄金法则：
开发集和测试集应反映你最关心的、模型最终要服务的数据分布。

---

四、正交化思维（Orthogonalization）：分离“设定目标”与“优化目标”

吴恩达强调一种工程化思维框架：

步骤	任务	类比
Step 1	定义评估指标 + 开发集	设定靶心（目标）
Step 2	优化模型以在该指标上取得更好成绩	练习射击，提高命中率

• 这两个步骤应解耦（decoupled） ：

  • 先确保“靶子放对位置”（指标合理、数据代表真实场景）；
  • 再专注“如何打得更准”（调参、架构、训练技巧等）。

• 如果发现“打中靶心但用户不满意”，说明靶子位置错了，应回到 Step 1。

🧠 正交化的好处：避免在错误方向上过度优化，提升团队迭代效率。

---

五、实用建议：快速启动，持续迭代

• 不要追求“完美指标”才开始：

  • 先快速定义一个可用的指标和开发集，驱动初期迭代。

• 允许中途修改：

  • 一旦发现指标/数据无法反映真实需求，立即调整。

• 避免“无指标开发” ：

  • 没有明确评估标准的团队，容易陷入主观争论，大幅降低开发速度。

⏱️ 行动指南：
“先射箭再画靶”不可取；但“画好靶再射箭”也不现实。
合理做法是：先画个大致靶子，边射边修正靶心位置。

---

六、总结：何时应改变 Dev/Test Set 和 Metric？

触发条件	应对措施
指标无法区分算法优劣（如 A 指标更好但实际更差）	→ 修改评估指标（如引入加权、F1、业务KPI等）
Dev/Test 数据分布 ≠ 真实应用场景	→ 更换 Dev/Test Set，使其更贴近部署环境
用户反馈与指标结果矛盾	→ 重新审视指标设计，加入用户满意度维度
团队对“哪个模型更好”存在分歧	→ 完善指标，使其能客观排序模型

---

七、关键公式回顾（KaTeX 兼容）

1. 原始分类错误率：

   \[\text{Error} = \frac{1}{m_{\text{dev}}} \sum_{i=1}^{m_{\text{dev}}} \mathbb{1}\left\{ y^{(i)} \neq \hat{y}^{(i)} \right\}\]

2. 加权错误率：

   \[\text{Weighted Error} = \frac{ \sum_{i=1}^{m_{\text{dev}}} w^{(i)} \cdot \mathbb{1}\left\{ y^{(i)} \neq \hat{y}^{(i)} \right\} }{ \sum_{i=1}^{m_{\text{dev}}} w^{(i)} }\]

3. 权重定义：

   \[w^{(i)} = \begin{cases} 1, & \text{if } x^{(i)} \text{ is safe} \\ W \gg 1, & \text{if } x^{(i)} \text{ is inappropriate (e.g., porn)} \end{cases}\]