为什么机器学习是你最大的噩梦。
作者：Vincent Tatan
编译：ronghuaiyang
首发：AI公园公众号

你最大的机器学习噩梦

=============

【凌晨3点】快来！我们的定价全搞砸了！我们以100美元的价格卖出了13000美元的相机！在亚马逊的Best Prime Day上，机器学习出现了错误。

假设你是亚马逊的一名ML工程师，您的团队刚刚发布了一个新的RNN定价模型，该模型可以根据购买趋势自动设置价格，你已经对该模型进行了无数次的回测和调优。你2年的努力终于产生了结果，预计每年将产生100万的额外收入。

你太高兴了，你预订了一个昂贵的假期来庆祝。你在去Bahamas的路上，直到你收到…坏消息。

你的ML模型出了问题，所有商品的价格都错了。你疯狂地打开集成管理器进行回滚。但为时已晚，系统已经发货了，你的“前沿ML模型”让你的公司损失了300万美元。

第二天，你决定改一下模型的Bug。你测试了模型。它看起来很好。价格分布有变化吗？数据准备有问题吗？或者来自最近下游数据的质量有变化？你拼命地绞尽脑汁，还是毫无头绪。因此，你决定用虚拟机和不同的配置文件隔离每个下游数据，从头重新构建模型，并逐个测试它们。你无法跟踪每个版本的更新，直到几个不眠之夜才解决了这个问题。

在数据或整体有变化的时候，最前沿的ML模型将成为你最大的噩梦

技术债

技术债是代码实现过程中所作的权宜之计的持续成本。这是由于为早期软件发布和更快的上市时间提供短期利益而采取的快捷方式造成的。技术债会累加。推迟工作以偿还债务会导致成本增加、系统脆弱和创新率降低。

1992年，Ward Cunningham创造了这个术语来解释产品涉众的重构需求。对于你们中间那些还不明白的人。技术债是近藤麻理惠的对立面，他说"让我们把脏衣服扫到床底下，问题就解决了"。

同样，在人工智能和机器学习领域，我们都会增加技术债。我们喜欢做“忍者修复”，采取诸如硬编码函数、糟糕的代码和不负责任的复制-粘贴等捷径。如果你赶在最后期限前完成任务或交付概念证明(POC)，这些都是非常好的和必要的。但如果没有去还这些技术债，那就非常危险了。

不是所有的债都是坏的，但不去还债是会有复利的 ——
D Sculley，机器学习系统中的隐藏债务：https://papers.nips.cc/paper/...

我们的AI和ML在数据上运行。错误的输入，错误的输出。你使用的特征越多，它就变得越不稳定，尤其是当这些特征依赖于系统的许多部分时。

你的不稳定的机器学习系统

想象一下使用CRM(客户关系管理)系统构建价格歧视(类似于机票)的定价系统。定价系统的质量将高度依赖于来自CRM的数据，而缺少特征将破坏ML中的所有结果。

现在，假设它通过更互联的ML和其他系统连接到更多上游流的特征。你的ML模型在最好的情况下是脆弱的，在最坏的情况下是破碎的，从而感染它的下游。

在一个以人工智能为基础的快速发展的初创公司中，这已经成为一种常态，因为他们疯狂地赶时间去实现他们的产品，并把它们展示给他们的利益相关者。我曾与一位在AI初创公司工作的朋友交谈，他提到他们从未使用过适当的版本控制(Git)、问题跟踪器(Jira)或任何开发Ops管理工具来开发他们的ML系统。令人震惊的是，许多人在没有适当的DevOps和技术债务管理的情况下跳进ML/AI的炒作中。这和用牙签造机器人是一样的。

对于软件工程来说，DevOps非常重要。但是对于ML产品，MLOps是不可分割的

4个最大的机器学习Pipelines的错误

1) 纠缠

ML系统是带有数据的机器。通常很难做出孤立的改变(Changing Anything, Changing Everything——CACE)。这适用于特征工程、ML调优、正则化、数据采样等。

让我们假设你的定价模式在所有产品上都很有效，除了吸尘器(因为它很糟糕)。你通过提高清洁产品定价的敏感性来固定吸尘器的价格，但你发现你造成了与洗碗机的价格分配不匹配。真空吸尘器的价格分布并不适用于较窄的洗碗机的价格分布。现在需要创建可能影响其他产品的不同规则。

你会认识到数据和见解是相互纠缠的。不同的调优和模型公式将导致难以隔离的一般洞察力的变化。

纠缠的数据和系统会导致很难孤立和调试问题

2) 复杂的Pipelines

AI和ML系统由许多不同的工作流pipelines组成，它们依次负责复杂的工作。ML系统将由许多工程师构建，并与许多不同的系统和数据源互连。

在适当的ML pipelines中，你需要设计许多作业，包括抓取、生成数据、ETL、验证数据清洁度、交叉验证、监视性能和部署。很快，你的模型将变得非常复杂。如果没有合适的工具和操作的标准，跨使用不同语言的多个系统和遗留系统进行简单的更改将花费数小时。

复杂的pipelines会使你的工程工作缓慢且充满bug。如果处理不好，你可能会花几个小时来做一些简单的修改。

3) 隐含的反馈回路

现实世界的系统最终会影响我们的数据。想象一下，你的销售代表发布了一项营销活动来接触儿童，并积极地将他们包括在你的定价模型所使用的CRM系统中。

ML模型会感知到很大一部分顾客会购买玩具。因此，ML模型对玩具价格会提高，对昂贵产品会过度打折。然而，监控到你的价格飙升，你的竞争对手的定价模式也会自动填补市场的过高价格的玩具。你的系统也会这样做，恶性循环就出现了。

隐藏的反馈循环给ML系统带来了麻烦，而由于在ML系统之外相互链接数据依赖关系，使得调试更加困难

4) 不稳定的数据依赖

假设你的定价模式依赖于顾客的性别。如果一个男人浏览了化妆品，他很可能会买它作为礼物给他的妻子/女朋友，所以支付意愿更高。你的机器学习已经准备好根据性别来决定价格了。

然而，你的业务代表在上游CRM中添加了“性别”特征之外的标签。如果看到的值不是男性或女性，你的ML系统会崩溃吗？现在这个型号的化妆品价格是多少？与代码依赖相比，这是非常脆弱的，因为这意味着当上游系统更新时，并提供未被怀疑的特下一个错别字征时，你的模型可能会崩溃。

在特征工程和特征标注过程中，数据依赖会导致语义不匹配导致逻辑错误和质量下降。

还机器学习的技术债

技术债务是一种痛苦。作为Visa的前数据工程师和谷歌的数据科学家，我必须确保一个适当的可靠的渠道，保持透明和负责任。我需要一个标准的操作来管理机器学习的技术和数据方面，并确保质量不会随着时间的推移而受到影响。

关于如何最小化MLOps技术债务，有三个小技巧

1) 测试你的代码和数据

在科技行业，测试是最重要但也最乏味的职位之一。它仍然是非常重要的考虑测试来限制技术债务和确保ML生产质量。在DevOps中，我们了解了两种类型的测试：单元测试(测试单一功能)和集成测试(测试集成的功能)。然而，在MLOps中，我们需要在服务于生产之前建立一个canary流程来测试ML Pipeline的质量。

这包括测试数据依赖性的可准备性，以识别不可见的数据(想象一下男性/女性性别的例子)。