搭建容易维护难！谷歌机器学习系统血泪教训(2)

令人惊讶的是，学术界意识到在大多数机器学习系统当中，只有很小一部分代码在实际进行“机器学习”。事实上，一套成熟的系统最终可能最多只有 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] 就此给出了一些极好的建议与参考。结合本文的关注点，我们注意到非因果关系属于隐藏债务的另一种来源。

最后，实时监控系统至关重要。论文建议大家测量预测偏差，并在系统采取的行动数量超过某个阈值时发布警报。

在一套按预期方式运作的系统中，预测标签的分布通常应该等同于观察标签的发布。这不需要进行全面测试，因为其可以通过单一空模型满足——即直接预测标签出现平均值，而不必考虑输入要素。然而，这种简单的方法却带来了令人惊讶的良好效果，而此类度量指标的变化通常反映出需要注意的关键问题……

（编辑：ASP站长网）