本文提到的机器学习系统带来的主要技术债类别包括:信息隐藏以及变化封闭带来的挑战 ; 胶水代码与配置;以及不断变化的外部世界以及分析模型结论对这一世界的理解误差。算法
本文中最重要的看法之一,在于技术债务应当成为工程师与研究人员们须要注意的问题。以大规模增长系统复杂性为代价进行解决方案研究显然不是什么明智的做法。即便仅仅增长一到两种看似无害的数据依赖关系,也有可能减缓进一步发展速度。虽然减小技术债务并不像证实新定理那样使人振奋,但其仍然是保持强劲创新能力的重要动力。事实上,为复杂的机器学习系统开发出全面且优雅的解决方案是一项极具现实意义的工做。数据库
……机器学习模型是一种创造复杂纠缠状态的机器,且不可能有效地对其改进工做进行隔离分配。做为证实,假设犈在一套模型当中使用特征 x1,……Xn,那么若是咱们改变 x1 中的值输入分布,那么其重要性、权重或者剩余特征可能所有发生改变——不管模型是以批处理形式进行彻底从新训练,仍是以在线方式进行逐步适应,状况都是如此。而添加新特征 xn+1 或者删除任何特征 xj,也均可能致使相似的变化。没有任何输入内容是真正独立存在的。牧羊这将其称为 CACE 原则:即任何改变都将改变一切。api
若是咱们了解到先验的重要性,就不须要利用机器学习进行重复证实!所以,模型有点像一台巨大的搅拌机器,咱们向其中投入大量信息并获取结果,但对输入内容中的各种变化的敏感度却难以预测,且几乎没法进行影响隔离。面对这样的难题,咱们该怎么办?虽然不存在百试百灵的方案,但做者给出了三种可能有所帮助的策略。安全
你能够隔离模型,转而提供整体结论。不过,纠缠问题仍然存在于每个模型当中。此外,“在规模化状况下,这种策略可能很难长期维持”。微信
制定方法以深刻理解模型预测的行为。你须要经过投资令模型再也不像黑匣子般难以捉摸——例如为其配备更多可视化工具。此外,我还和多家企业进行过交流,其中一部分公司表示其可以解释机器学习模型做出的决定——甚至包括监管要求,而这种能力亦是其商业模式中的重要组成部分。所以,请你们认真考虑这方面需求与实现途径。架构
使用更为复杂的正则化方法,以便在训练当中使用的目标函数可以反映出任何效能预测成本的上升迹象。“这种方法可能有用,但也只是可能。此外,其也许会增长系统复杂性进而带来更多债务,这反而背离了咱们减小纠缠度的初衷。”机器学习
另外一种寻找偶然耦合的方式在于创建隐藏反馈回路,这一点在未申报消费方当中体现得尤其明显。经过未申报消费方,系统只是在单纯消费建模产出的输出结果,而咱们几乎意识不到这些过程的存在。若是其根据影响模型的输入参数信息采起了某些行动,则这种隐藏的反馈回路很容易引起如下问题:函数
想象一下,在咱们的新闻标题点击率预测系统当中,系统中的某一组件负责以“智能化方式”肯定用于标题的字体大小。若是此字体大小模块开始将点击率做为输入信号使用,且字体大小确实会影响用户的点击倾向,那么字体大小当中将会包含一个由点击率添加的新的隐藏反馈回路。能够想象,这样一套系统会逐渐无休止地增长全部标题字号状况。工具
……尽管代码依赖性能够经过静态分析以及连接图等方法相对轻松地进行识别,但具有数据依赖性处理功能的分析工具却不多见。所以,咱们能够难以构建起可以解决大型数据依赖链的方案。学习
举例来讲,某些输入信号会随着时间推移而改变行为。遵循 CACE 原则,即便将这些变化做为改进方向,也很难对后果做出预测。另外一种数据依赖性则是模型中的特征集合,其中一些可以在准确性方面提供很是有限的增量。咱们能够经过多种方式利用本来未充分利用的依赖性——包括一部分已遭弃用的早期遗留特征,一次性添加的多项特征组合(而非仅仅挑出那些真正有做用的特征),或者那些为了追求准确率而添加、且没法证实自身对复杂性的影响的特征。按期对特征进行清除将很是重要。
举例来讲,假设在团队合并以后,为了简化而进行了一轮由旧产品编号到新产品编号的转换,那么两套方案都将在系统中做为特征。其中新产品只能得到一个新编号,但旧产品可能同时拥有两个编号。机器学习算法固然也会将旧编号归入依赖关系当中。一年以后,有管理人员清理了使用旧编号填充的数据库代码。这种变化不会被回归测试所检测到,由于清理以后旧编号直接再也不使用。这对机器学习系统的维护者而言显然不是什么好消息……
有能力理解数据依赖性的工具,将帮助咱们顺利搞定特征清理工做。谷歌公司的一支团队就构建出一款自动化特征管理工具:
自从采用以来,该方案帮助谷歌团队每一个季度安全删除数千行与特征相关的代码,同时自动验证其中的版本及其它问题。该系统还可以有效防止意外使用新模型中不推荐或已经损坏的特征。
最后一种数据依赖性管理方法,在于创建“校订”机制以从新利用现有模型。经过这种方式,你可以快速得到初步成果 ; 但在另外一方面,你将来对该模型的分析与改进将面临更高的成本。
使人惊讶的是,学术界意识到在大多数机器学习系统当中,只有很小一部分代码在实际进行“机器学习”。事实上,一套成熟的系统最终可能最多只有 5% 的代码负责机器学习,而其他 95% 甚至更多代码只是起到粘合做用,从而经过从新实现(而非从新使用)改善本来笨拙的 API……
这里须要解决的问题在于,不少机器学习库都被封装成了独立的工件,这无疑会引入大量胶水代码(例如从 Java 转换至 R 或者 matlab)。若是你们没法在更为普遍的系统架构内找到适合本身的资源选项,那么从新实现算法(5% 部分的代码)可能更有意义,且可以有效减小胶水代码的数量。
一大相关问题在于管道丛林——即过于复杂的数据准备管道。
管道丛林问题只能经过全面审视数据收集与特征提取的方式来避免。清除管道丛林并从头开始设计清理方法,确实是工程设计层面的一项重大投资,但这同时也可以显著下降持续成本并加速进一步创新活动。
一旦系统因胶水代码与管道丛林问题而变得僵化,不少朋友会忍不住调整生产代码中的实验代码路径以执行额外实验。这样作固然比较方便,但一旦频率太高,其只会引起更大的混乱。
做为典型实例,谷歌公司最近在对一套重要的机器学习系统进行清理时,发现其中存在着数以万计的未使用实验性代码行。在利用更紧密的 API 进行重写以后,这部分“遗产”可以大幅下降工做量、生产风险并控制系统复杂性,从而为新算法的实验铺平道路。
在本节的最后,“配置每每是现实世界的混乱对美丽算法形成干扰的载体:”
请考虑如下例子。特征 A 在 9 月 14 日到 9 月 17 日之间发生了记录错误。特征 B 直到 10 月 7 日才正式上线。因为记录格式发生了变化,用于计算特征 C 的代码必须对 11 月 1 日以前及以后的数据进行更改。特征 D 并未用于生产,所以在现场调协中进行模型查询时,必须使用替代性的 D’与 D”。若是特征 Z 被使用,那么全部训练相关任务必须得到额外的内存配额,不然其训练效率将显著下降。最后,因为延迟限制,特征 Q 排除掉了特征 R。全部这些混乱的条件使得配置难以正确修改且难以推理。此外,配置错误还可能引起高昂的代价——包括严重的时间浪费、计算资源损耗或者生产问题。
配置变动应该与代码变动同样获得谨慎处理,并交由同行进行评审。
经验代表,外部世界不多保持稳定。事实上,真实世界的性质变化正是机器学习当中技术债务的一大重要来源。
请不要手动设置决策阈值(例如显示或不显示广告),而应考虑经过评估现有验证数据以发现阈值此外,因果不明的相关特征也可能引起问题:
这彷佛并非什么主要问题:若是两个特征老是相关,但只有其中一个特征属于真正的因果关系,那么彷佛仍能够将信用归于二者并经过观察其共同现象得出结论。然而,若是外部世界中这两种特征的共生性忽然消失,那么预测行为可能发生显著变化。用于区分相关效应的全面机器学习策略也将超出咱们的讨论范围 ;[Bottou 2013] 就此给出了一些极好的建议与参考。结合本文的关注点,咱们注意到非因果关系属于隐藏债务的另外一种来源。
最后,实时监控系统相当重要。论文建议你们测量预测误差,并在系统采起的行动数量超过某个阈值时发布警报。
在一套按预期方式运做的系统中,预测标签的分布一般应该等同于观察标签的发布。这不须要进行全面测试,由于其能够经过单一空模型知足——即直接预测标签出现平均值,而没必要考虑输入要素。然而,这种简单的方法却带来了使人惊讶的良好效果,而此类度量指标的变化一般反映出须要注意的关键问题……
原文连接:
https://blog.acolyer.org/2016/02/29/machine-learning-the-high-interest-credit-card-of-technical-debt/
论文连接:
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43146.pdf