本文是机器学习入门教程的第五篇，前四篇分别是：
1.机器学习能为你的业务做什么？有些事情你肯定猜不到
2.关于机器学习算法 你需要了解的东西
3.如何开发机器学习模型？
4.机器学习团队中的角色、技能和组织结构技能详解
我们之前已经讨论过“如何使团队能够更加有效地运作”这个问题了。下面，我们来看看如何帮助用户从机器学习系统中获益吧。
机器学习模型和结果并不容易解释
许多机器学习算法都是黑匣子：输入大量的数据，然后获得一个以某种神秘方式工作的模型。这使得很难向用户解释机器学习的结果。在许多算法中，还存在着交互效应（各种特征互相之间存在着某些关系，不能仅仅通过将每个特征的效果简单相加来解释），这使得模型更加难以解释了。你可以把这个看成是特征之间的复合效应，特征之间以多种奇怪而又复杂并且不为人类所理解的方式结合在一起，整体效应大于各个部分效应的总和。
也就是说，你和你的团队需要确信机器学习的结果是有道理且解释得通的。并且，如果你能在超出统计标准的水平之上理解了结果，那解释起来就更容易了。这也有助于确定未覆盖的情况或结果无意义的领域，正如我们模型构建阶段所看到的那样。这对用户来说更为重要，在很多时候，他们需要得到一个解释才会相信你的结果。即使你的结果是100％准确的，也不会有人相信，所以你需要把呈现出来的结果向用户解释。在极端情况下，你甚至还可能有法律上的义务去解释结果，比如拒绝贷款申请。在法律上，你必须给予客户拒绝的理由。由于增加了复杂性，模型不会100％准确，即使有80％的准确性也是相当不错的了。所以在某些情况下，用户会想了解实际上是错误的结果！
我们所面临的挑战并不仅限于针对外部客户的模型，同时也要获得内部用户的信任。即使内部团队支持你，他们也不太可能采用他们自己无法理解或者不信任的结果。我曾看到过一些案例，团队倾向于使用易于理解的规则引擎，而不使用可能会产生更好结果的机器学习模型，只是因为规则引擎是可以解释的：人们写出规则，这样，大家就能够理解它们了。
在构建模型之前，这个问题不能忽略。我们需要提前考虑用户可能希望看到的模型数据和组件，考虑如何让呈现出来的结果得到用户的信任。这可能会让原先构建模型的方法发生改变，还有助于防止出现你有答案而无法向用户解释的情况。
可解释性建模
对可解释性的需求可能会影响到模型构建的方式。假设我们正在基于Marc Andreessen框架为投资者建立一个评估创业公司的平台，任何一个创业公司都具备三个核心要素，分别是团队、产品和市场。现在，Andreessen认为，市场是最重要的因素，但其他一些投资者认为，一个好的团队可以找到将小市场培育长大的方法，所以团队更重要。你可以将创业公司的这三个维度结合起来计算出一个总的评分或者成功的概率，并给出一些你认为正确的“绝对真理”，但投资者未必会对此感兴趣。更具体一点说，投资者可能想了解一下公司在其他某些方面表现得怎么样。除了模型之外，你更需要让他们看到这个。这里有几种不同的方法：
- 为市场、产品和团队构建三个独立模型，使用这三个模型在单一的维度上评估公司。然后构建一个将所有这些特征（以及潜在的其他特征）结合在一起的综合模型。这样，投资者既可以看到总体结果，也可以看到他们最关心的某个具体维度。
- 构建聚合模型，从中找出一种提取最适合于每个维度特征的方法，并让用户感觉到它们的价值和重要性，或者显示与每个维度一致的数据点，以树立用户对结果的信心。
正确的方法在很大程度上取决于问题所属的领域、可用的数据、建模方法等，但在进入模型的原型设计之前，应该进行充分讨论和评估。
向用户呈现结果
在确定如何显示结果的时候，我们的目标是要让结果清晰、可信，并且最重要的是，可行。这个没有现成的指导手册，我在这里将介绍一些方法和注意事项，希望能为你提供一些思路。
- 回溯。这种方法是将历史数据插入到模型中使其产生过去的预测，这样可以根据已知值对预测进行验证。例如，如果你建立了一个用N-1年的数据来预测第N年值的模型，那么你可以将两年前的数据插入到模型中，看看一年前的预测是否正确，因为一年前的信息是可以获取到的。这是测试模型的潜在方法。由于历史数据存在是否完整的问题，在没有某些简化假设或模型调整的情况下，模型要获得足够的数据覆盖是有难度的（例如，如果模型使用了来自社交网络的数据，那么你不能回溯到一个社交网络还不存在的时间点）。对于某些模型，例如强化学习模型，这也是不可行的。
- 解释你的方法和输入。只需告诉用户在模型中用到的数据类型，通过让他们看到决策是基于相同类型的变量来建立信任，如果用户不得不做出决定，他们就会考虑使用这些数据。在Andreessen对初创公司评估案例中，对市场评估部分的简要说明是这样的：“一家初创公司的市场潜力要考虑到市场上同类公司的数量和总的销售额、在全球范围内这个市场在过去5年的增长情况、新产品发布的数量、在该领域与宏观经济趋势中的并购活动。” 虽然这不是一个完整的解释，它确实让用户瞥见了这个黑匣子。如果你引入了一个新的评分，那么这绝对是必要的，原因如前所述。
- 公开一些基础数据。这种方法是用户最容易理解和相信的，因为他们亲眼看到了数据。但这设计起来并不是最简单的，它存在几个缺点：你需要公开那些可能不希望或无法公开的数据（例如，由于法律方面的约束，数据是专有的），在某些情况下，数据与结论可能并不一致（建模与概率有关），或者数据可能甚至不存在；该算法不需要对其评估的所有实体进行全面的数据覆盖。
- 简化并仅显示指定的结果，以便于决策。不出所料，亚马逊对于某些产品的推荐做得很好。我搜索了一个护膝套，看看下面我从谷歌搜索结果中找到的页面。
亚马逊并没有给我30个类似的产品让我来选择，它知道每个相关产品确切的购买概率，所以给了我很简单的两个选择：最便宜的商品，以及最畅销且评价最高的商品。我不知道他们挑选产品的标准，以及判断与我选择的产品是否匹配的标准。在这一点上，亚马逊让我能够轻松地做出决定，我无需关心上面那些细节问题。
示例：从商品搜索跳转过来的页面
- 定义一个新指标。你应该考虑的一个问题是你是否创建了一个新的指标（一种新的“评分”）或者预测一个易于理解的指标：你可以构建模型来预测现有的指标（例如公司的收入、房屋的价值等等）；或者，你可以创建一个体现某个概念但尚不具备可被接受的指标的评分，以便按照这个概念（例如“针对某个行业的FICO评分”）实现对实体的排名。这个决定很大程度上取决于是否存在一个单一的度量来表达商业目标，或者这是一个需要几个因素权衡的混合体。例如，如果我们要评估商业房地产资产对零售业使用的吸引力，我们可能希望建立一个“零售健康评分”，其中包括几个组成部分，比如每平方英尺的销售额、每平方英尺总成本，以及区域品牌价值贡献等等。在这种情况下，由于没有包含这些指标的单一指标，因此你可能需要为每个组成部分单独进行建模，然后再通过某种类型的相对权重将它们组合在一起。选择新的评分时，你应该重点考虑一下你可能需要花更多的时间和精力来教你的用户。
- 精确度并不总是很重要。很多模型生成的结果是一个非常精确的数字。如果你向用户展示如此精确的数字，那么用户就可能遇到比想象中更大的风险。预计价格为583,790美元的房屋并不一定比580,625美元的房屋更贵，误差幅度可能远大于3000美元。有时，向客户展示过于精确的数字会适得其反。给用户的结果最好不要是很精确的数字，可以考虑用范围、等级或其他一些不是那么精确的数字来表示。
- 有策略地提供对原始数据的访问。除了展示风险模型的结果之外，借贷公司还提供了它的原始数据，供其他人在这基础上构建自己的机器学习模型。这个方法与你有关吗？它能促进部分业务的增长吗？除了提供潜在的货币选择之外，这种方法还有助于机器学习研究界加快创新的步伐。例如，Microsoft的COCO和CIFAR数据集的可用性已经极大地提高了图像分类能力。
重申一下，用户体验的选择在很大程度上取决于主题、产品和用户需求。上述任何选项都不会与你的产品无关。如果用户无法理解，即使是最好的模式也毫无用处。
一个讨厌但又很重要的注意事项
可解释性是机器学习研究不断发展的领域，研究人员正在积极寻求使模型不再是黑匣子的方法。这里有一个例子，LIME：一个针对分类器模型的“解释器”，它用于在模型构建完成后以人类可以理解的方式来解释结果。
另一个研究领域是Layer-Wise Relevance Propagation（LRP），一种“解构”神经网络预测的技术，以此来可视化并理解单个输入变量对预测的贡献。
产品经理应注意的工程问题
尽管稳固的系统架构主要是由工程团队负责设计的，但业务需求也会影响到机器学习系统，从而将一个伟大的系统变得糟。作为一个项目经理，你直接跟工程团队讨论的越多，就越有可能最终构建出满足业务需要的系统。虽然下面这个列表并不完整，但应该会让你产生一种相见恨晚的感觉。
- 对实时的要求。算法的结果可以提前计算出来吗，还是需要实时计算？当你获取到新的数据，或者用户输入了特定信息或执行某些操作时，模型是否需要立即生成反映新数据的结果？实时系统的架构与可以处理脱机数据的系统架构相差很大。
- 数据和模型的依赖关系。你的系统可能包含多个模型，其中一个模型的输出是另一个模型的输入。当一个模型的输出发生变化时，是否需要重新运行其他的模型呢？当添加或修改数据时，哪些模型需要重新运行（有时甚至需要重新训练）？应该以多快的速度进行更新，可接受的SLA是什么呢？
- 数据收集的频率。数据收集和累积的速率会影响流水线的设计和存储方法的选择。数据收集的频率取决于数据实际变化的频率、数据变化的重要性以及获取数据的成本（如果数据需要购买的话，就要考虑支付成本，以及检索、处理和存储成本）。例如，如果你正在收集有关地震的数据，数据的变化可能不会很频繁，但一旦数据发生改变，就需要立即获取到；如果你正在收集有关餐厅开门营业和关门休市的数据，那么这个数据可能就会比地震数据变化得更频繁一些，即使你可能早几天或者晚几天发现数据的变化，那也不会对产品的整体效用产生重要的影响。
- 数据收集的方法。如何收集数据，批量还是流式传输？是推还是拉？对实时的要求使得数据收集进一步的复杂化。系统可能需要支持多种数据收集或上传方法，例如，API、文件上传等等。它需要模块化以支持所有必需的方法，并将数据从数据处理中分离出来（这是一个很好的软件工程设计原则）。
文章原标题《Machine Learning is Very Much a UX Problem》，作者：Yael Gavish，译者：夏天，审校：主题曲哥哥。
文章为简译，更为详细的你容，请查看原文
