【AI 工程】Hidden Technical Debt in Machine Learning Systems（一）

这是一篇2015年提出的论文，但是我今天看还是对现实的实践具有指导作用。本文从传统软件工程的技术债引出机器学习系统的技术债，并且比较了两者不同。

不同点具体为：
传统的软件技术债都是代码层面的，但是机器学习系统代码层面、系统层面都有。
具体的比较方面如下：

复杂模型侵蚀边界（Complex Models Erode Boundaries）

传统的软件开发，可以用封装和设计模式等方法将整个工程分为多个模块解偶，这种系统的输入、输出的影响是确定的，但是机器学习系统各个模块的输出改变，输出是不确定的。这就造成了边界不清晰，各部分耦合非常严重，主要有如下方面：

Entanglement（纠缠）：

 CACE principle: Changing Anything Changes Everything

这种情况是说ML system的的输入、学习率、学习器等互相依赖的情况，比如输入数据改变，这些组成成分也会改变，这在传统的软件工程中，改变是确定的，但是机器学习中却不清楚系统的变化方向。
作者提出的改进点为：
1、隔离模型
2、直接观测系统的预测输出

Correction Cascades（校正级联）：
我们又一个模型A，新来一个任务，我们通过以A为输入，来校正新任务，形成A‘。这时候A’就依赖A了。这就形成了依赖，

作者提出改进点为：
1、在A中加入相关特征，学习到新任务
2、重新训练一个A‘

Undeclared Consumers（未声明消费者）：
这部分跟传统的软件工程一样，需要通过机制知道下游消费者都有哪些。

数据依赖成本甚于代码依赖（Data Dependencies Cost More than Code Dependencies）

这部分讲我们的系统形成数据依赖的情况，主要又下面几个方面：

Unstable Data Dependencies（不稳定的数据依赖）：
我们的模型有输入，而输入不稳定，比如我们的模型的输入是另一个模型的输出，而这个模型经常在更新，这就造成了我们的输入的不稳定性。又比如tf-idf词表

这种情况的一个解决方案是维护一个数据依赖的版本，使用比较稳定的版本。当更新数据后，验证过后再切换到另一个版本。

Underutilized Data Dependencies（无效的数据依赖）：
这个是讲有些数据对模型用处不大，而我们又依赖它，这就增加了模型的潜在风险，因为让我们的系统依赖变复杂了。

解决办法：
1、leave-one-feature-out evaluations，也就是踢出一个特征，看看对模型影响大不大，不大我们删除这个特征，这一步需要经常做。

Static Analysis of Data Dependencies（静态数据依赖）：
使用工具静态分析数据的依赖。

参考文献

[1] 原文，https://papers.nips.cc/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf
[2] https://www.zhihu.com/question/424523708/answer/1511283545