给开发者的箴言：我们该如何面对和使用机器学习技术？

本文是 Guy Royse 通过自己的亲身经历写给开发者们的关于机器学习的感悟。本文以第一人称翻译，讲述了对于开发者而言应当如何面对和使用机器学习技术。

更多干货内容请关注微信公众号“AI 前线”（ID：ai-front）

当我第一次听说机器学习的时候，我的反应几乎是 “切”。我才不管呢。

我不认为它对我和我的工作有多大的影响。我当时正忙着开发一个软件，这个软件主要实现从某些远程源提取数据， 将规则应用于这些数据，并将其显示在屏幕上。机器学习并不会改变这个流程。

事实上，我上面所说的只是一个苍白的谎言。我当时被吓坏了。因为每当有一种新的技术正在流行，那么我必须掌握，这样才能保持与时俱进。而这一次， 它不仅仅是一个新的编程语言或 JavaScript 框架。这是一门全新的技术。我不知道这会对我写的软件产生怎样的影响，但我有预感，这绝不是好事。

没错，事实证明确实是我落后了。机器学习的确非常适合我所从事的工作，虽然从使用上来讲与之前的方法肯定有所不同，但并没有达到让人震惊的地步，也证明我的害怕并不合理。让我用一种看似离题的东西来解释——“业务逻辑”。

“业务逻辑层”是位于 “表示层” (即用户看到的内容) 和 “数据层” (即我们拥有的信息) 之间的代码位（译者注：可参考三层架构）。它是一种双向适配器，它通过一种有意义的方式获取数据并将其呈现给用户，同时可以从用户那里获取有意义的输入并且用技术手段保存数据。

对于一个简单的应用程序，在业务逻辑方面往往没有什么特别的设计。这些数据与用户希望看到的内容相匹配，因此这些应用程序只关注将数据放在屏幕 (也可能是一张纸) 上。它们往往很容易编写和维护，因为没有很重要的逻辑关系。

当然，你最终还是需要多一点的逻辑性的东西。当用户输入一个特定的值——通知他们某一特定的东西；当数据有一些特殊的价值——显示一些特殊的东西。像这样的规则便是应用程序的业务逻辑。这些规则往往一开始很简单，由于经验不足或出于权宜之计，这些规则往往被错误地放入表示层或数据层。但它们很快变得相当复杂，你的代码将变得复杂且没有逻辑，这对应用开发来说是难以维护和发展的。那么正确处理这些规则的正确方案是什么呢？答案是：让他们自己成为独立的一层。

但是随着规则的增长和扩展，业务逻辑层本身可能会变得相当复杂。我在一家保险公司工作了多年，我的亲身经历让我明白这一点。在俄亥俄州的库亚霍加县，如果环保局对车辆的检查不超过 90 天，那就做一件事。但如是在富兰克林或库亚霍加 (而不是其他任何县)，环保局的检查不超过 60 天，则做一些其他的事情。真是令人抓狂！这样的代码会很快失控，变得像个 marinara 面条。

通常，解决这个问题的办法是使用规则引擎。你可以在外部软件中定义所有规则，然后使用该软件来执行规则，而不是编写一组深度嵌套的难以理解的条件。规则引擎针对管理这些规则进行了优化，甚至可以将它们公开给业务本身，而不仅仅是开发人员。但有时即使是规则引擎也会变得难以管理，同时，规则在其中的相互作用也会变得难以理解。如果将写代码比作制作意大利面的话，那么最终你的代码将是复杂的 marinara 面条，什么乱七八糟的配料都有，而不是简单的肉酱面，可以清楚的看到你的面条。

在这一点上，有一个值得重视的事实。所有这些方法都是在过于复杂的情况下才会出现问题，可以肯定的是，复杂性对于每个方法来说是相对而言的。但是，一旦规则过于复杂，这些方法都会变得难以管理。那么，业务逻辑层就仅仅是实现一个固定的规则引擎吗？

你好，机器学习了解一下？

机器学习就像一个类固醇上的规则引擎。它允许我们创建封装复杂模式的规则，而其他技术几乎不可能完成这样的功能。但是，它并不是用来建立规则的，而是找到规则，然后为我们提供规则的编码。我们要提供的只是示例和正确的答案 （对应机器学习理论中的特征和标签），它将创建一个抽象的对象以供我们执行这些规则（即模型）。

这真的是一个相当巧妙的技巧！

这意味着我们可以使用模型取代所有的业务逻辑功能吗？当然不是。规则引擎并不能取代我们编码的所有业务逻辑，它可以对业务逻辑层进行增强。有时，我们的代码只需要一个简单的条件就可以工作得很好，而有时, 合理使用规则引擎可以更好地管理业务逻辑。代码、规则引擎与机器学习三者并非对抗关系，我们应当从三者中正确挑选方法。应用程序的业务逻辑层，即数据层和用户之间的层，可以由很多东西组成: 代码中的简单规则、规则引擎和现在的机器学习模型。

事实证明，机器学习并不能改变我正在做的事情。我还在编写软件，主要实现从一些远程源提取数据，将规则应用于这些数据，然后将其展示在屏幕上。但是我们找到了一种新的方法来封装过于复杂的规则，以前我们无法管理，甚至在某些情况下无法定义这些规则。