机器学习中的技术债务

许多人遇到技术债务时都会眉头紧锁，但一般来说，技术债务并不是一件坏事。例如，当我们需要在最后期限之前发布版本的时候，技术债务就是一个可以利用起来的合理手段。但是技术债务存在与金融债务一样的问题，那就是到了要偿还债务的时候，我们所付出的要比开始时付出得多。这是因为技术债务具有复合效应。

经验丰富的团队知道应该在什么时候偿还成堆的债务，但机器学习中的技术债务堆积起来却非常迅速。你可能在一天之内欠下价值数月的债务，即使是最有经验的团队也可能因为一时的疏忽而产生巨额债务，使得他们需要耗费半年才能恢复，这足以扼杀一个快速迭代的项目。

这里有三篇精彩的论文探讨了这个问题：

机器学习：技术债务的高息信用卡 NIPS'14（NIPS：神经信息处理系统大会）

机器学习系统中隐藏的技术债务 NIPS'15

你的机器学习测试成绩是多少？ NIPS'16

这些论文介绍了数十种机器学习反模式，它们可能会成为软件基础架构中的定时炸弹。在这里，我只讨论三个最重要的反模式。

反馈回路

当机器学习模型的输出间接馈入自己的输入时，就会产生反馈回路。听起来这很容易规避，但在实际操作中却正好相反。反馈回路有很多种变体，NIPS'14的一篇论文介绍了一个很典型的例子，而我在这里会给出一个更真实的例子。

例子

假设你的公司有一个购物网站。后端团队提出了一个推荐系统，它会根据客户的个人资料和以往的购买记录来决定是否弹出通知。很自然地，你会根据客户先前点击或忽略通知的记录来训练这个推荐系统（这还不算是反馈回路）。在启用这个功能后，你会很兴奋地看到点击通知的比例越来越高。你会把这个增长归功于人工智能，但你不知道的是，前端团队实现了一个固定的阈值，如果推荐的置信度小于50%，则隐藏通知，因为他们不希望向客户显示潜在的不良推荐。随着时间的推移，以前在50-60％置信范围内的推荐现在会被认为是小于50％，这样，最后就只剩下50-100％置信度的推荐了。这就是一个反馈回路。你的指标虽然增长了，但系统并没有得到改善。你不仅要**利用**机器学习系统，还要让它自己去**探索**，以避免使用固定的阈值。

在小公司中，控制反馈回路相对来说比较容易，但在拥有数十个团队的大型公司中，几十个复杂系统相互关联，这其中的反馈回路就很有可能会被忽略。

如果某些指标即使没有启动优化也在缓慢改善，那么说明反馈回路正在发挥作用。找到并解决回路并不容易，因为它涉及到跨团队的合作。

校正级联

当机器学习模型不再继续学习下去，并且你在最后给机器学习模型的输出打补丁的时候，就会产生校正级联。随着补丁的积累，你最终在机器学习模型的顶层创建的一层厚厚的启发式算法，就称为校正级联。为了顾及机器学习没有学习到的罕见特殊情况，对机器学习系统的输出使用过滤器是很容易的。

在对整个系统所有的指标进行训练的时候，校正级联会对机器学习模型正在尝试优化的那个指标进行相关化。随着这一层校正级联越来越复杂，你将无法确定机器学习模型的更改是否能对最终的指标起到改善作用，并最后也不知道该如何改进了。

流浪者（Hobo）特征

流浪者特征是机器学习系统中没用但又不能忽视的特征。有三种类型的流浪者特征：

捆绑特征（Bundle features）

有时，当有一组新的特征需要一起评估的时候，我们会将它们捆绑在一起整体提交。但不幸的是，只有其中的某些特征是有用的，而其他的一些特征甚至会起到反作用。

ε特征（ε-features）

有时，即使某个特征只是促使质量提高了一点点，我们也会倾向于添加这个特征。然后，如果基础数据稍稍有所改变，这个特征就可能很快失去作用，甚至起到反作用。

遗产特征（Legacy features）

随着时间的推移，我们为项目添加了一些新的特征，并且没有重新评估它们。几个月后，其中的一些特征可能会变得完全没用，或者被新特征所取代。

在一个复杂机器学习系统中，有效清除流浪者特征的唯一方法是试着一次只清除一个特征。也就是说，一次只删除一个特征，然后再训练机器学习系统，并使用你的指标进行评估。如果系统需要花一天的时间来训练，那么我们一次可以运行5个训练，如果我们有500个特征，那么清除掉这所有的特征则需要100天。但不幸的是，特征之间可能会相互影响，这意味着你必须尝试清除所有可能的特征子集，这时，难度就会指数级地上升。

结合我们的力量

在机器学习基础架构中如果同时包含这三种反模式将是整个项目的灾难。

因为反馈回路的存在，你的指标将无法反映系统的真实质量，机器学习模型将学习利用这些反馈回路，而不是学习有用的东西。此外，随着时间的推移，你的模型可能无意中由工程团队塑造出来，从而更多地利用这些回路。

校正级联会降低用机器学习模型直接进行测量的指标与整个系统之间的相关性。它可能对机器学习模型有积极的改善作用，但对整个系统指标的影响却是随机的。

因为流浪者特征的存在，你甚至都不会知道数百个功能中哪些是有用的，而且要全部清除它们的代价实在太大。在日常工作中，监测的指标可能会随机上下波动，因为某些垃圾特征会随机起作用。

最终，项目的指标会随机上下波动，无法反映实际的质量，也无法改进。唯一的出路是推倒重来，重写整个项目。

文章原标题《Technical Debt in Machine Learning》，作者：Maksym Zavershynskyi，译者：夏天，审校：主题曲。