【Google 年度顶级论文】机器学习系统，隐藏多少技术债？
2015-12-9 11:23 |原作者: 译者：王婉婷 李宏菲 张巨岩|来自: 新智元|
查看: 39721|
评论: 0
3. 数据依赖比代码依赖成本更高 在经典的软件工程环境中，依赖债务（dependencydebt）被认为是代码复杂程度和科技债的重要贡献者。我们已经发现，机器学习系统中的数据依赖具有相似的形成债务的能力，但可能更难被察觉到。代码依赖可以通过编译器和链接的静态分析被鉴定出来。由于缺乏相似的工具用来鉴定数据依赖，形成大型的、难以拆解的数据依赖链是一件很容易发生的事情。 依赖于不稳定的数据 为了获得快速进展，将其他系统生成的信号当作输入的特征是非常便利的。然而，一些输入的信号是不稳定的（unstable），这意味着它们的行为随着时间会发生数量上的变化（quantitatively）或是质量上的变化（qualitatively）。这可能发生得非常隐蔽，比如这个输入信号来自于另一个自身会随时间更新的机器学习模型，或者一个依赖于数据的、用来计算TF/IDF分数或是语义映射的查找表（lookuptable）。这也可能发生得非常明显，比如当输入信号的工程所有权（engineeringownership）独立于使用这个输入信号的模型的工程所有权。在这样的情况下，可以在任何时候对输入信号进行更新。这是非常危险的，因为即使是对输入信号的“改进”也可能会对使用这个信号的系统产生不确定的危害作用，要诊断这样的问题需要很高的成本。比如，想象一下这样的情况：一个输入信号之前的校准是错误的（mis-calibrated），使用这个信号的模型很可能拟合这些错误的校准；对信号作了更正以后，整个模型都会突然发生变化。 针对依赖于不稳定数据的问题，一种常见的缓解策略是，对于一个给定信号创建一份标记版本的副本。比如，与其允许一个词汇（words）到主题（topics）的语义映射聚合随时间一直变化，创建这个映射的冻结副本（frozenversion）、一直使用到更新版本被彻底检查确认完毕是更好的选择。然而，创建每个版本的副本会带来它自己的成本，例如可能的冗余以及同一信号随时间而产生的不同版本的维持成本。 依赖于未充分使用的数据 在代码层面，未被充分使用的依赖指的是大部分时候非必要的包（Packages）。相似的，依赖于未充分使用的数据指的是几乎不能为模型提供性能提升的输入信号。这会导致机器学习系统在变化的时候容易出现问题，有时候还会造成灾难，即使这些依赖可以被无损移除。 例如，假如要简化从老编号方案到新编号方案的过渡，那么两种方案都作为特征留在系统里。新的产品只有新的编号，但老的产品会有新、老编号，而模型在某些产品上，会持续依赖于老的编号。一年后，停止将老编号填充进数据库的代码被删除了。这对于机器学习系统的维修者来说不会是一个愉快的日子。 依赖于未充分使用的数据，这个问题可以通过多种方式蔓延进入模型中。 遗留特征：很常见的例子是，特征 F 在早期的开发中存在，但随着开发进行，在新的特征中 F 变成多余了，但并没有被发觉。 捆绑特征：很多时候，一组特征被评估为有用的。但是由于截止期限的压力或其他类似原因，这组特征都被加入到新模型了，其中就很可能包括一些没有价值的特征。 є特征：作为机器学习研究者，总是会想方设法改善模型的精确程度，哪怕这个精确度的提升是非常的小，或者带来的复杂度会很高。 相关特征：有时候两个特征是相关性很高，但其中一个特征有更直接的因果作用。很多机器学习方法很难识别出来区别，而是把这两者等同看待，甚至可能选择了没有因果关系的那个特征。当真实世界的行为改变了特征之间的相关性，结果就会变得很脆弱、不够稳健。 依赖于未充分使用的数据这一问题可以通过完全把一个特征丢弃以评估检测。这项工作需要定期进行，以识别并移除多余的特征。
图1：在真实世界的整个机器学习系统中，只有一小部分是由机器学习的代码组成，图片中用中间的小黑盒来表示。它需要大量并且复杂的周边设施。 对数据依赖作静态分析 在传统的代码中，编译器和编译系统可以用依赖图（dependencygraphs）做静态分析。数据依赖的静态分析工具非常少，但它们对于错误检查、访问者追踪、迁移和更新（migrationand updates）来说都很必要。这类工具其中之一就是自动特征管理系统（automatedfeature management system），它让数据源和特征可以被标注，然后运行自动检查来确保所有的依赖都有恰当的标注，而依赖树（dependencytree）可以被完全解开（fullyresolved）。这类工具在实践中能让迁移和删除操作变得安全得多。 4. 反馈循环 现在机器学习系统的主要特征之一即是，如果系统随时间不断进行更新，这些系统最终会影响它们自身的行为。这就导致了某种形式的分析债，即在一个系统未发布之前很难预测一个给定模型的行为。这些反馈循环可以有不同的形式，但如果所有这些反馈循环是随时间而逐渐发生的话，它们是很难被检测到的，当模型更新不频繁时就是这样。 直接反馈循环 一个模型可能直接影响到它自身未来训练数据的选择。尽管理论上正确的解决方法是赌博机算法，但是采用标准的监督算法已经是一种很普遍的做法。问题是赌博机算法（例如语境赌博机算法）实质上不能很好的地缩放到现实世界中要求的动作空间的尺度大小。因而，可以通过采用一些随机化的操作或者隔离受到给定模型影响的某部分数据等方式来缓解上述的不良影响。 隐藏反馈循环 直接反馈循环分析起来代价是非常昂贵的，但是它们至少提出来了一个机器学习研究者们很自然地会去琢磨的统计挑战。相比之下，更困难的情况是隐藏反馈循环，即两个系统在世界范围内间接地互相影响。 一个例子可能是，如果两个系统单独地决定一个网页的某些方面，例如一个系统对产品进行挑选并展示，另一个系统挑选相关的评论。改进一个系统可能导致另一个系统行为的变化，因为作为对于改变的反应，用户开始更多或更少地点击其他部分。需要注意的是，在两个完全不相交的系统中也可能会存在隐藏反馈循环。可以从来自于两个不同的投资公司的两个股票市场预测模型的案例加以考虑，如果对其中的一个模型做出某些改进（或者，bug），则另一个模型的投标和购买行为相应地也会受到一定程度的影响。 5. 机器学习系统的反面模式 对于学术领域的众多研究者而言，了解到在许多的机器学习系统中仅仅只有一小部分的代码用来进行学习或者预测可能会让他们感到非常惊讶（如图1所示）。在Lin和Rayboy语言中，除了仅有的小部分代码用于学习或者预测，大部分剩余代码被称为“管道工程”。 不幸的是，对于一个融合了机器学习算法并最终债台高筑的系统来说，这很普遍。在这个章节中，我们检测了数个在许多的机器学习系统中显露的反面模式系统设计，以及在有可能的时候哪些应该被避免或重构。 粘合代码 机器学习研究者倾向于开发普遍适用的解决方案作为自给自足的包（packages）。在像mloss.org、in-house code、专有软件包、基于云平台等地方，有许多这种包以开源包的形式存在。 采用通用软件包经常会导致粘合代码的系统设计模式，在这种系统设计模式中，包含了大量支持数据写入通用软件包或者数据从通用软件包中输出的代码。粘合代码的代价从长远来看是很高的，因为这将系统局限于（freeze）一个特定包的特点，如果要测试其他方法，成本就会变得不可避免的昂贵。因此，采用通用包会抑制改进，因为以粘合代码的形式使得利用特定领域的特性或者调整目标函数实现特定领域的目标变得更加困难，。由于一个成熟的机器学习系统可能最终会包含（最多）5%的学习代码和（最少）95%的粘合代码，创建一个干净纯粹的解决方案比重复使用通用软件包成本要更低。 对抗粘合代码的重要策略之一就是，将黑盒包（black-box packages）包装进普通的应用程序接口。这让周边支持的基础设施能被更多地重复利用，降低更换包的成本。 管道丛林 作为粘合代码的一种特殊情况，“管道丛林”（pipeline jungles）现象经常出现在数据预备阶段。随着新信号逐渐被鉴定、新信息资源逐渐被添加，管道丛林也有机地发展起来。一不小心，在机器学习系统友好的格式下，预备数据的结果系统可能会成为一个充满碎片、联结部分以及采样步骤的丛林，经常也会有中间输出文件在其中。管理这些管道、检测错误、以及从失效中修复等全部都是非常困难和代价昂贵的事情。测试这样的管道通畅要求端到端的整合测试。上述所有情况增加了系统的技术债，并且使得未来创新的成本更加昂贵。 只有从整体上考虑数据收集和特征提取的过程，才能够避免“管道丛林”现象的发生。用从头再来的方式消除管道丛林，以及从最底层开始重新进行设计，确实是一项工程上的重大投资，但是其也是一项能够大幅减少持续增的成本并加速未来创新的工程。 粘合代码和“管道丛林”是集成问题表现出来的症状，根源可能在于“研究”和“工程”角色过于分离。当机器学习包是在象牙塔的环境中被开发出来时，对于在实践中部署这些包的团队来说结果可能看上去像一个黑盒。工程师和研究者处于同一个团队的混合研究方法（事实上，很多时候研究者和工程师是同一个人）能够显著地减少源头的摩擦。 失效的实验代码路径 粘合代码或是“管道丛林”的一个常见结果是，在主要的生成代码中，通过执行实验代码路径作为条件分支来演示具有选择性方法的实验过程，从短期看来是极具吸引力的。对于任何单独的改变，以这种方式来进行实验，成本是相对较低的——周边的基础设备无需再返工。然而，随着时间的推移，由于后台兼容性的维护愈加困难以及循环复杂度（cyclomatic complexity）呈指数增长，这些日渐积聚的代码路径将会导致技术债的持续增加。对代码路径间所有可能的交互做测试变得非常困难，或者说不可能。这种危险的一个著名例子就是Knight Capital的系统在45分钟里损失了4.65亿美元，由于从废弃的实验代码路径产生了未被预料到的行为。 和传统软件领域中的“死旗”（dead flags）一样，周期性地重复检查每个实验分支，从而纠察出哪个实验分支可以舍弃的方法是非常有益的。一般仅仅是一小部分分支能够被实际应用到，其它许多实验分支可能被测试一次后就遭到舍弃。 抽象化债务 上述的问题强调了这样的一个事实：明显缺少强抽象来支持机器学习系统。Zheng最近对机器学习抽象状态与数据库技术状态做了令人信服的比较，得到这样的一个结论：机器学习领域的文献中，没有哪一篇将相关数据库（relational database）作为基本抽象（basic abstraction）的论文得到的结果能达到接近成功的地步。什么样的接口才是描述一个数据流、一个模型、或者一个预测的正确接口？ 特别是对于分布式学习来说，仍然缺乏被广泛接受的抽象。可能有人会争论，机器学习中Map-Reduce的广泛应用是由于缺乏强分布式学习抽象。事实上，在最近几年，广泛协议的几个领域之一认为Map-Reduce对于迭代的机器学习算法是一个性能很差的抽象。 参数服务器抽象更具有鲁棒性，但这个基本思想有多个相互竞争的规范。标准抽象的缺乏使得不同组成部分之间的界限太容易被模糊化。 常见异味 在软件工程中，系统设计的异味（smell）指的是在一个系统中或者系统中的一个部件中存在的潜在问题。我们鉴别了一些机器学习系统的异味，这些并不是不可违逆的准则，而只是主观判断的指标。 POD类（Plain-Old-Data）异味：机器学习系统采用和生成的丰富数据信息全部是用浮点数、整数等普通的数据类型进行编码的。在一个鲁棒的系统中，一个模型的参数应该明确自己代表的是一个对数赔率系数、还是一个决策阈值，一个预测应该知道关于产生这个预测的模型的各种片段信息以及它将如何被使用。 多语言异味：用一种特定的语言编写系统中的一部分代码是一件非常具有诱惑力的事情，特别是当这种语言对于手头的任务而言有一个便利的库（library）或脚本。然而，用多种语言编写系统经常会增加测试成本，并且会增加将所有权让渡给其他人的难度。 原型异味：通过原型在小范围内测试新的想法是非常方便的。然而，定期地依赖于一个原型环境暗示着系统的脆弱性、难以改变，并能够从改善的抽象性和接口受益。维护一个原型环境需要承担它的代价，并且有个显著的威胁是，时间压力会促使一个原型系统变成了产品解决方案。除此之外，在小范围内发现的结果不能很好地应用在整个范围内。 6. 配置债 另一个令人惊讶的债务积累的区域是机器学习系统的配置。任何大系统都有许多配置选择权，包括哪些特征被采用，数据是怎样选择，许多特定学习算法的设置，潜在的预处理和后处理、验证方法等等。我们已经观察到不论是工程师还是研究者都将系统的配置看作是一个事后的想法。事实上，系统配置的验证和测试可能被看作是不重要的。在一个成熟的系统中，系统的配置占有举足轻重的地位，用于系统配置的行数远远超过了传统代码的行数。每个系统配置行都可能含有潜在的错误。 考虑以下的案例。特征A应该是9/14，但被错误地记录为9/17。在10/7之前，特征B在数据上是不可用的。因为记录格式的改变，要改变用于计算11/1之前和之后数据关于特征C的代码。特征D在产品中是不可用的，所以在实际设置中查询模型，就需要使用替代性的特征 D’和D’’。如果特征Z被采用，由于查找表的原因，训练工作必须给定额外的存储空间，否则他们会无效率地进行训练。因为延迟约束，特征Q排除使用特征R。 这一切的混乱使得配置难以修改正确，并且很难合理解释这种现象。然而。配置的错误代价是昂贵的，它会导致时间的大量损失、计算资源的浪费以及生产问题。这使得我们清楚知道，应根据以下原则进行良好的系统配置。 （1）从以前的系统配置中做出小的改变，应该能很容易地指明。 （2）人为错误、遗漏、或者是疏忽是很难发生的。 （3）在两个不同构造的模型间，应该能很容易看出不同。 （4）能够容易的自动维护和验证配置，例如在这些方面：采用的特征数量、数据依赖关系的传递闭包。 （5）能够很容易地探测无用的或者冗余的设置。 （6）系统配置应进行全码的检查，并且记录到存储空间中。 |
免责声明：
除非特别声明，文章均为投稿或网络转载，仅代表作者观点，与大数据中国网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。如果本文内容有侵犯你的权益，请发送信息至ab12-120@163.com，我们会及时删除
上一篇：大数据与数据挖掘的相对绝对关系
下一篇：数据分析挖掘体系
最新评论
最新新闻
最新新闻
/1 
