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

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

 

 

(图片来源: 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上写下的那些话有多天真了。不过错误分析，还是需要有人去做的。