我们已经学习了如何设置开发集和评估指标
这就好比确定你的团队要瞄准的靶子
可有时候 项目进行到一半 你可能会发现
靶子放错了位置
这时候 就应该移动你的靶子
让我们看一个例子
假设你决定构建一个猫分类器
用于寻找猫的图像 并展现给爱猫的用户你决定使用分类误差作为评估指标
算法A和算法B分别有
3%和5%的误差
看起来算法A表现得更好
可是当你实际测试和检查这些算法时
发现算法A由于某些原因 会将很多色情图片也分类为猫
假如你将算法A投入使用 用户们的确
可以看到更多猫的图片 毕竟它只有3%的误差
可是与此同时 该算法也会向用户
展示一些色情图片 不论是对你的公司还是客户来说
这都是无法容忍的
相比之下 算法B有5%的误差
虽然能得到的猫的图片较少 但是不会有色情图片
所以无论是从你的公司的角度
还是从用户的角度来看
算法B实际上是一个更好的算法
因为它不会让色情图像通过
在这个例子中
尽管算法A在评估指标上表现得更好
只有3%的误差 可实际上这个算法很糟糕
在这个例子中 评估指标和开发集
都倾向于选择算法A 因为根据评估指标
算法A的误差更低 效果更好 然而你和你的用户
更倾向于选择算法B 因为它不会让色情图片通过
在这种情况下
当你的评估指标
无法正确地对算法的优劣进行排序时
就像此例中错误地判断算法A更优秀
这时你就应该
修改评估指标 可能也要修改开发集或测试集
在这个例子中 所使用的分类误差指标
可以写为如下的形式 1除以m_dev
m_dev是开发集中的样例数量
从i等于1到m_dev
对开发集中第i个样例的预测
是否不等于实际标签进行求和
y_pred这个符号表示预测值
取值为0或1
这个符号表示一个函数
用来统计使括号里的式子为真的样例的数量
这个公式统计了分类错误的样例的数量
这个评价指标的问题在于
它对色情图片和非色情图片一视同仁
然而实际上 你不希望分类器错误地标记色情图片
例如将一张色情图片分类为猫
然后展现给毫无防备的用户
用户看到这样的图片一定会非常不满
改良这个评估指标的一种方法是 在这里加入一个权重项
称为w^(i) 当x^(i)不是色情图片时 令w^(i)=1
当图片是色情图片时
令w^(i)=10 或者更大 比如100
这样 你对色情图片的样例
赋予了更大的权重 当算法错误地将
色情图像分类为猫时
将产生更大的误差值
在这个例子中
我们为色情图像的分类加上了10倍的权重
如果需要归一化常数
这一项会变成对w(i)求和
从而令误差值仍在0和1之间。
这里权重的细节并不重要 实际上 要实现这个权重
你需要检查一遍开发集和测试集
将其中的色情图片标记出来
这样才能实现这个权重函数
需要记住的是
当你发现评估指标
无法对算法的优劣给出正确的排序时
那么就需要考虑定义一个新的评估指标
这里的例子只是定义评估指标的一种方法
评价指标的目的是为了能够准确地告诉你
给出两个分类器 哪一个更适合你的应用
就本次视频的目标而言
大家不需要太关心如何定义新的误差指标
重点是 如果你对原有的误差指标不满意
那就不要将就着使用这个你不满意的指标
而是定义一个新的指标 使其能够更好地
反应你的偏好 以符合你对更好的算法的定义
也许你已经注意到了 目前为止我们只讨论了
如何定义一个指标来评估分类器
我们定义了一个评估指标 来帮助我们
更好地对分类器进行排序
以区别它们在区分色情图片上的不同水平
这其实就是正交化思想的一个例子
我认为 应该将机器学习问题分解成独立的步骤
第一步是确定一个指标 以衡量分类器在你的目标上的性能
然后我再单独地考虑 如何在这个指标上得到很好的性能
所以 可以把机械学习任务看成是两个独立的步骤
用靶子来比喻
第一步是摆放靶子
确定你要瞄准的地方 这是一个完全独立的步骤
这就像是一个你可以调节的旋钮
用于独立地调整靶子摆放的位置
至于如何准确地瞄准和射中这个靶子
则由另一个独立的旋钮进行调节
第一步先定义评估指标 第二步再做别的事情
就像射靶
也许你的学习算法在优化这样一个代价函数
在训练集上对损失之和进行最小化
你也可以修改这个代价函数
来引入这些权重
可能最后还要修改这个归一化常数
修改为1除以对w^(i)求和
再次强调 如何定义代价函数J并不是重点
重点是这种正交化的思想 放置靶子是第一步
瞄准和射击靶子是另一个独立的步骤 单独地进行
换句话说 我建议大家
将定义指标看成是一步 在定义了指标之后
再考虑如何在这个指标上做好
有时可能需要修改神经网络所优化的代价函数J
在进入下一个章节前 让我们再看一个例子
假设我们有两个猫分类器 A和B
它们在开发集上的误差分别为3%和5%
或者是在测试集上的误差 其中的图片是从网上下载的
高质量 取景很好的图片
可是当你实际部署算法产品的时候
你却发现实际上算法B的表现更好
尽管它在开发集上的表现不佳
你发现训练使用的图片
是从网上下载的高质量图片
而当你部署到手机应用上时
用户会上传各种各样的图片 例如取景很不好
猫没被照全 或者猫的表情很奇怪
或者图像很模糊
当你对算法进行实际测试时 发现其实算法B的表现更好
这是另一个评价指标和开发/测试集出了问题的例子
问题在于 评估时使用的
开发集和测试集中都是非常精美 高分辨率
取景很好的图片 而你的用户
真正关心的是 能否正确识别他们上传的图片
这些图片往往拍得不那么专业 比较模糊 取景不好
指导方针是
如果在你的指标上
以及在当前开发集和测试集的分布上表现得很好
不能对应于 在你真正关心的应用场景上也表现得很好
这时就需要修改指标 和/或开发集和测试集
换句话说 当我们发现 在具有非常高质量图片的
开发集和测试集上进行评估
无法正确预测你的应用的实际表现情况
因为你的应用实际需要处理的是
低质量的图片 那么就应该修改你的开发集和测试集
让你的数据能够更好地反应 实际中你真正关心的数据的情况
整体的方针是 如果在你当前使用的指标和数据上
获得很好的性能 并不对应于做好你真正关心的事情
那就需要修改你的指标 和/或你的开发集和测试集
让它们能更好地反应 你真正需要算法做好的事情
通过评估指标和开发集 你可以
更快地对算法A还是算法B更好做出决定
可以确实地提高你和你的团队进行迭代的速度
所以我的建议是
即便你无法定义一个完美的评估指标和开发集
你也应该尽快将它们确定下来 以此来驱动你们团队的迭代速度
如果之后发现选的不好
你有了更好的想法 你完全可以再进行修改
对于大对数团队 我不建议
在没有任何评估指标和开发集的情况下
进行长时间的开发 因为这实际上会
降低你们团队进行迭代和改善算法的效率
以上我们讲了什么时候需要修改你的评估指标 和/或开发集和测试集
我希望这些指导方针能够帮助你为你的整个团队
设立一个明确的目标 从而能更有效率地朝着改善性能的方向进行迭代