机器学习中的错误分析--双手沾满泥土的体力活

原创
10/24 04:17
阅读数 0

吴恩达在机器学习策略中反复提到做错误分析的重要性。错误分析也慢慢地成为机器学习项目中不可缺少的环节。

(图片来源: https://blog.sujeetjaiswal.com/machine-learning-an-introduction-de88d85ebc5d)


之前,我也特意在我们team的wiki上写了一页,督促我们重视错误分析。引经据典自不用说,但还有自己写的几句话,如今看来挺有意思。

  • 引入一个算法可能需要几个星期,但它可能并不理想。

  • 修改一个已有算法的小问题,可能只需要几个小时,但它可能意外的提高了模型的性能。

  • 增加一个feature,可能只需要几天,但它可能就解决了某些难归类问题。


利益这么明显,为什么机器学习工程师们还是对错误分析这么踌躇不前呢。说明现实有很多问题。


不久前,team接到一个项目,用公开数据重新训练一组模型。算法,流水线不变,就是换个数据。听上去非常简单,项目开始直接叫负责数据的律师妹子上。花了几个月整理数据,训练结束后,metric也不错,问题就是用测试数据一跑,和原来的模型的预测结果相差非常大。必须做错误分析。那么实际问题就来了,谁来做。


吴恩达在提到错误分析的时候,例子是,猫狗分类项目。相信,每个工程师都可以区分的出猫和狗,但是专业领域的问题,比如说我们,法律相关领域,还有医疗,农业等等,负责训练模型的机器学习工程师并不都能看出样本有什么特殊之处。对于自己都无法分类的问题,怎么去分析模型为什么出错。于是,一般来说,当模型训练到达到分数要求后,机器学习工程师们的工作就结束了。


那似乎让有专业知识的人来做错误分析比较合适。的确是这样,专业人士为根据自己的分析,做一份报告,从专业的角度可能会总结出哪些问题解决的不好。首先要说明的是,走一遍错误的例子相当的累人,其次总结出的规律也相当的有risk。这个规律可能只是随机的。


怎么利用错误分析呢。对于机器学习工程师来说,这又是一轮新的迭代。传统的想法是,必须消化理解报告,找出改善的地方。实际上这个过程相当的难,机器学习工程师必须对流水线很了解,对于特征选择非常清楚。随着深度学习和AutoML的普及,机器学习越来越黑盒,对于错误报告采取什么行动,更多的是尝试,而不是有目的的修正。而且每一次的尝试,需要完整的实验得出统计结果,而这样一次尝试可能花上数天时间,结果却常常不如意。折腾几个月,没有任何改进也很正常。


这个过程听上去和A/B testing很相似。A/B testing可以简单理解为直接上线A/B两套系统,看哪个更受欢迎,就采用哪个。当然A/B testing要做很多统计学上的分析,不能简单粗暴的认为使用多的就是好的,而是要排除各种随机可能产生的”多”。听上去也不是那么简单,周期也很长,回报也不是那么直接。

(图片来源于: https://learn.g2.com/a-b-testing)


是的,不管是错误分析还是A/B testing,都是需要很多的尝试,反馈和分析的迭代。这大概是和大数据打交道无法逃避的模式。


有一天,我和朋友说,其实搞机器学习搞大数据是个体力活。朋友说,别扯了,那可是人工智能啊。你们搞人工智能都说是体力活,那其它行业呢。人工智能的目标是减少体力活,但生产人工智能的的确确是个体力活。比如说标注数据,清洗数据,调试算法,还有本期主题,错误分析。


本文开始提到,为什么机器学习工程对错误分析踌躇不前,除了之前提到的专业知识缺乏,迭代周期长之外的问题,那就是错误分析也是一个双手沾满泥土的体力活。不知道如何改进对吧,流水线都看一遍吧。好了,流水线都看明白了,流水线上的处理器会有什么差错吗?处理器之间有依赖关系吗?很好,之前的开发工程师都写了相关测试,如果没有测试过又有疑点呢?疑点太多怎么办?如果机器学习模型效果不好,那以前的测试欠债,现在看来都是要还的。错误分析现在看来怎么像是分析技术欠债了。的确是,谷歌提到MLOps的时候就是直接的以技术债务的方式提出。成熟的MLOps和乱糟糟的infrastructure,对于错误分析来说是是阳关大道和荆棘小路的区别。于是乎做错误分析,当然不如实现新算法有意思。


写到这里,终于可以说,之前在wiki上写下的那些话有多天真了。不过错误分析,还是需要有人去做的。 


本文分享自微信公众号 - 一起learn大数据和机器学习(hundendagis)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部