本文是Guy Royse通过自己的亲身经历写给开发者们的关于机器学习的感悟。本文以第一人称翻译,讲述了对于开发者而言应当如何面对和使用机器学习技术。
更多干货内容请关注微信公众号“AI前线”(ID:ai-front)
当我第一次听说机器学习的时候,我的反应几乎是 “切”。我才不管呢。
我不认为它对我和我的工作有多大的影响。我当时正忙着开发一个软件,这个软件主要实现从某些远程源提取数据, 将规则应用于这些数据,并将其显示在屏幕上。机器学习并不会改变这个流程。
事实上,我上面所说的只是一个苍白的谎言。我当时被吓坏了。因为每当有一种新的技术正在流行,那么我必须掌握,这样才能保持与时俱进。而这一次, 它不仅仅是一个新的编程语言或 JavaScript 框架。这是一门全新的技术。我不知道这会对我写的软件产生怎样的影响,但我有预感,这绝不是好事。
没错,事实证明确实是我落后了。机器学习的确非常适合我所从事的工作,虽然从使用上来讲与之前的方法肯定有所不同,但并没有达到让人震惊的地步,也证明我的害怕并不合理。让我用一种看似离题的东西来解释——“业务逻辑”。
“业务逻辑层”是位于 “表示层” (即用户看到的内容) 和 “数据层” (即我们拥有的信息) 之间的代码位(译者注:可参考三层架构)。它是一种双向适配器,它通过一种有意义的方式获取数据并将其呈现给用户,同时可以从用户那里获取有意义的输入并且用技术手段保存数据。
对于一个简单的应用程序,在业务逻辑方面往往没有什么特别的设计。这些数据与用户希望看到的内容相匹配,因此这些应用程序只关注将数据放在屏幕 (也可能是一张纸) 上。它们往往很容易编写和维护,因为没有很重要的逻辑关系。
当然,你最终还是需要多一点的逻辑性的东西。当用户输入一个特定的值——通知他们某一特定的东西;当数据有一些特殊的价值——显示一些特殊的东西。像这样的规则便是应用程序的业务逻辑。这些规则往往一开始很简单,由于经验不足或出于权宜之计,这些规则往往被错误地放入表示层或数据层。但它们很快变得相当复杂,你的代码将变得复杂且没有逻辑,这对应用开发来说是难以维护和发展的。那么正确处理这些规则的正确方案是什么呢?答案是:让他们自己成为独立的一层。
但是随着规则的增长和扩展,业务逻辑层本身可能会变得相当复杂。我在一家保险公司工作了多年,我的亲身经历让我明白这一点。在俄亥俄州的库亚霍加县,如果环保局对车辆的检查不超过 90 天,那就做一件事。但如是在富兰克林或库亚霍加 (而不是其他任何县),环保局的检查不超过 60 天,则做一些其他的事情。真是令人抓狂!这样的代码会很快失控,变得像个 marinara 面条。
图:marinara 面条,据说传统意大利家庭一家一个版本,做起来十分随意,想加什么配料加什么。
在这一点上,有一个值得重视的事实。所有这些方法都是在过于复杂的情况下才会出现问题,可以肯定的是,复杂性对于每个方法来说是相对而言的。但是,一旦规则过于复杂,这些方法都会变得难以管理。那么,业务逻辑层就仅仅是实现一个固定的规则引擎吗?
你好,机器学习了解一下?
机器学习就像一个类固醇上的规则引擎。它允许我们创建封装复杂模式的规则,而其他技术几乎不可能完成这样的功能。但是,它并不是用来建立规则的,而是找到规则,然后为我们提供规则的编码。我们要提供的只是示例和正确的答案 (对应机器学习理论中的特征和标签),它将创建一个抽象的对象以供我们执行这些规则(即模型)。
这真的是一个相当巧妙的技巧!
这意味着我们可以使用模型取代所有的业务逻辑功能吗?当然不是。规则引擎并不能取代我们编码的所有业务逻辑,它可以对业务逻辑层进行增强。有时,我们的代码只需要一个简单的条件就可以工作得很好,而有时, 合理使用规则引擎可以更好地管理业务逻辑。代码、规则引擎与机器学习三者并非对抗关系,我们应当从三者中正确挑选方法。应用程序的业务逻辑层,即数据层和用户之间的层,可以由很多东西组成: 代码中的简单规则、规则引擎和现在的机器学习模型。
事实证明,机器学习并不能改变我正在做的事情。我还在编写软件,主要实现从一些远程源提取数据,将规则应用于这些数据,然后将其展示在屏幕上。但是我们找到了一种新的方法来封装过于复杂的规则,以前我们无法管理,甚至在某些情况下无法定义这些规则。
查看英文原文:Machine Learning for Developers: Lies, Truth, and Business Logic
评论