Question

1. 学术界可能会惊讶地发现：很多机器学习系统只有一小部分代码实际上专门用于学习或预测，如下图中间部分的黑框所示。其余的周边基础设施庞大而复杂，这部分可以描述为管道 plumbing 。

   不幸的是，结合了机器学习方法的系统经常以高负债high-debt 的设计模式而告终。在这里，我们研究了几种可能出现在机器学习系统中的系统设计反模式system-design anti-patterns ，应该尽可能避免、或者重构它们。

   

2. 胶水代码Glue Code：机器学习研究人员倾向于将通用解决方案开发为独立包self-contained packages。在像 mloss.org 这样的地方 ，或者内部代码 、专有包 、云平台这些地方，有各种各样的开源包。

   使用通用包通常会导致胶水代码的系统设计模式，其中编写了大量的支持代码来将数据导入和导出通用包。从长远来看，胶水代码的成本很高，因为它倾向于将系统冻结到一个特定包的特性上，测试替代品可能会变得非常昂贵。通过这种方式，使用一个通用包可能会抑制改进 improvements ，因为它使得利用领域特定的属性、或者调整目标函数来实现领域特定的目标变得更加困难。

   因为一个成熟的系统最终可能是（最多） 5% 的机器学习代码和（至少）95% 的胶水代码，所以创建一个干净的原生解决方案可能比重用一个通用包的成本更低。

   对抗胶水代码的一个重要策略是将黑盒black-box 封装到通用 API 中。这使得支撑的基础设施的可重用性reusable更高，并降低了包变更的成本。

3. 管道丛林Pipeline Jungles：作为胶水代码的一个特例，管道丛林经常出现在数据准备阶段。随着新信号的识别和新信息源的逐渐加入，这些可以有机地发展evolve organically 。

   如果不小心地维护，以机器学习友好格式而准备数据的系统，最终会变为一个由抓取、连接、以及采样等步骤组成的、带中间文件输出的丛林。管理这些管道、错误检测、以及从故障中恢复都是困难和昂贵的。测试这类管道通常需要昂贵的端到端的集成测试。所有这些都增加了系统的技术债，并使得进一步创新的代价更高。

   只能通过全面考虑数据收集和特征提取来避免管道丛林。废弃管道丛林并从头开始重新设计的全新方法确实是一项重大的工程投资，但是它可以显著降低系统前进的成本并加快进一步的创新。

   胶水代码和管道丛林是集成问题integration issues 的征兆，其根本原因可能是过度分离的 “研究”角色和 “工程”角色。当机器学习 packages 在象牙塔环境中研发时，最终结果对于在实践中使用它们的团队而言可能看起来像是黑盒。

   将工程师和研究人员嵌入到同一个团队（实际上，通常是一个人）的混合研究方法hybrid research approach 可以帮助显著减少这种摩擦来源friction source 。

4. 死亡的实验代码路径Dead Experimental Codepaths：胶水代码和管道丛林的一个常见结果是：通过将实验代码路径实现为主力生产代码中的条件分支，在短期内内使用替代方法进行实验变得越来越有吸引力。

   对于任何单个变更，以这种方式进行实验的成本相对较低，因为周围的基础设施都不需要重新开发。然而，随着时间的推移，这些累计的代码路径会产生越来越多的债务，因为维护向后兼容性compatibility的难度越来越大，复杂度也呈指数型增长。对代码路径之间所有可能的交互进行测试，这变得困难或者不可能。这里一个著名的危险例子是： Knight Capital 的系统在 45 分钟内损失了 4.65 亿美金。这显然是由于过时的实验代码路径的意外行为。

   与传统软件中的dead flags 情况一样，定期重新检查每个实验分支以查看是否可删除通常是有益的。通常只有一小部分可能的分支被实际使用，很多实验分支可能已经被测试过并且被放弃了。

5. 抽象债务Abstraction Debt：上述问题强调了这样一个事实，即明显缺乏支持机器学习系统的强大抽象。Zheng 最近做了一个令人信服的比较，把机器学习状态的抽象和数据库技术的状态进行比较，指出在机器学习文献中没有任何东西能够像关系数据库这个基础抽象一样成功。描述数据流、模型、或预测的正确接口是什么？

   特别是对于分布式学习，仍然缺乏广泛接受的抽象。可以说 Map-Reduce 在机器学习中的广泛使用是由于缺乏强大的分布式学习抽象。事实上，近年来为数不多的几个广泛认同的领域之一似乎是： Map-Reduce 对迭代式的机器学习算法而言是一个糟糕的抽象。

   参数服务器parameter-server 抽象看起来更加健壮，但是这个基本思想有多个相互竞争的规范specifications 。缺乏标准的抽象使得组件之间的界限很容易变得模糊。

6. 常见气味Common Smells：在软件工程中，设计气味design smell 可能表明组件或系统中存在潜在的问题。我们确定了一些机器学习系统中的常见气味，不是硬性规定而是作为主观指标。

   • 普通旧数据类型气味Plain-Old-Data Type Smell：机器学习系统使用和产生的丰富信息通常都是使用普通的数据类型（例如原始浮点数、原始整数）来编码的。在一个健壮的系统中，一个模型参数应该知道它是一个对数几率乘子log-odds multiplier、还是一个决策阈值，预测值应该知道有关生成它的模型的各种信息以及它如何被消费。

   • 多语言气味Multiple-Language Smell：用特定的语言编写系统的特定部分通常很有吸引力，尤其是当该语言有一个方便的库或语法来完成手头的任务时。然而，使用多种语言通常会增加有效测试的成本，并且增加将所有权ownership转移给其他人的难度。

   • 原型气味Prototype Smell：通过原型在小范围small scale内测试新想法是很方便的。然而，经常依赖原型环境可能是一个指标，表明大范围full scale 的系统是脆弱的、难以变更的，或者可以从改进improved 的抽象和接口中受益。

     维护原型环境需要付出代价，而且时间压力可能会鼓励将原型系统用作生产解决方案，这是非常危险。此外，在小范围内发现的结果很少可以反映大范围的现实。

     例如，DNN 模型在小样本下的表现和大样本下的表现可能截然不同。模型在小样本下可能很快训练完毕，但是在大样本下可能无法训练（资源需求是天文数字）。