在先前的文章，我谈到了《AI 开拓指南：机器学习产品是什么？》，AI及ML产品须要更多的试验、反复调度，也因此带来更多的不愿定性。 关于什么是AI及ML产品，在《如何设计和管理AI产品?》这篇文章里有更详细的解释。
因此，我们须要为ML工程师和数据科学家供应足够的空间和弹性，来探索可能的办理方案。 同时也须要明确定义目标函数（objective function），并鼓励团队尽早测试，以免失落去方向。
为AI&ML 产品设计用户体验 （UX） 时，同样面临这样的寻衅。 在过去的几个月里，我与UX团队互助，网络客户见地并改进ML产品的用户体验。 以下是我们学到的三件最主要的事情：
三个基本原则：期望、缺点和信赖建立用户精确的期望Set the Right Expectations
机器学习模型的表现会随着数据更多而提高，也便是说，ML模型会不断自我进步，这是利用AI&ML最大的好处之一。 但这也意味着，他们一开始的表现不会是完美的。
因此，必须让用户理解ML产品不断进步的实质。 更主要的是，我们须要与用户互助，事先确定一套验收标准（acceptance criteria）。只有当ML模型符合验收标准时，我们才会推出该项产品。
设置验收标准时，可以比较系统的基准性能（baseline performane），替代或现有办理方案的性能，或乃至是比较标准答案（ground truth），
例如：比较人工翻译及机器翻译的准确度。 或是将机器预测的景象数据，拿来与真实景象数据做比较。 又或是将机器包装的速率及准确度，与人工操作比较，客户可以设定：唯有ML模型的准确度到达人工的90%才能上线。
有时，制订验收标准可能比想象中繁芜：你可能有多个不同的用户类型，他们须要不同的验收标准。 或者，你的利用案例哀求在某个分外项目必须完备没有缺点。
其余须要把稳的是，模型本身的准确性常日并不是最好的衡量标准，一样平常须要考虑精确度（Precision）和召回率（Recall）之间的权衡。 这在前一篇文章有更详细的解释。
如果用户须要ML模型从第一天开始就有很好的表现，可以预先演习的模型（pretrained model）：是先搜集数据，确定模型达到验收标准。
但是，要把稳的是，纵然利用预先演习的模型，例外情形（edge case）仍可能发生。 你须要与用户互助，制订操持降落风险。例如：如果模型不起浸染，有什么备案？ 如果用户想要添加新的利用案例，须要多永劫光重新演习模型？ 须要多少额外的数据？ 当不许可更新模型时，用户是否可以设置更新中断期？ 这些问题都须要事先回答。
通过建立用户的精确期望，你不仅可以避免用户挫折，乃至可以让用户感到惊喜。 亚马逊搭载Alexa语音助理的智能型喇叭便是一个很好的例子。 我们对类人形机器人有很高的期望：我们预期它们可以像人类一样自然交谈和动作。
以是，当智能机器人Pepper（下图）没有办法和我们进行流畅的对话时，我们感到沮丧，不想再利用它。 比较之下，Alexa 定位为智能型喇叭，降落了客户的期望。 当我们理解到它不仅仅可以播放音乐，还有很多其他的功能时，就能够让用户感到预期外的惊喜。
保持信息公开透明（transparency）是加强沟通和信赖的另一个主要部分。 ML 比软件工程更具不愿定性。 因此，显示每个预测的相信区间（confidence level），也是建立精确期望的一种办法。 这么做也能够让用户更理解算法的事情事理，从而与用户建立信赖。
建立信赖（Build Trust）
ML算法常日缺少透明度，就像一个黑盒子，我们知道输入（例如图像），和输出预测（例如，图像中的工具/职员是什么）分别是什么，但不知道盒子里是如何运作的。 因此，向用户阐明ML模型如何运作很主要，可以帮助我们建立信赖，和得到用户支持。
如果不对算法多做解释，有可能会让用户觉得被疏远，或觉得产品不足人性化。 例如，优步司机抱怨说Uber算法觉得非人性化，他们质疑算法的公正性， 由于算法所做的决定，并没有给他们明确的阐明。 这些驾驶也认为算法搜集很多他们的数据，对它们非常理解，但他们对算法的事情事理和决策却理解的很少。
相反的，亚马逊的网页很清楚地见告用户为什么他们推举这些书。 这只是一个大略的单行阐明。 见告用户其他看过该项产品的用户还浏览过什么商品，但却可以让用户大致理解算法的事理，让用户可以更好地信赖推举系统。
同样的优步司机研究也创造，司机以为他们常常被监视，但他们不知道这些数据将用于什么用场。 除了遵守 GDPR 或其他数据保护法规外，还该当考试测验让用户理解他们的数据是如何被管理的。
优雅地处理缺点（Handle Errors Gracefully）
“… 也有未知的未知-那些我们不知道我们不知道的… 这一类每每是最困难的”
——唐纳德· 拉姆斯菲尔德
“… But there are also unknown unknowns — the ones we don’t know we don’t know… it is the latter category that tend to be the difficult ones”
——Donald Rumsfeld
在设计系统时，常日很难预测系统会如何出错。 这便是为什么用户测试和质量担保（Quality Assurance），对付识别失落败状态（fail state）和例外情形（edge case）极其主要。 在实验室或实际现场，进行更多的测试，有助于最大限度地减少这些缺点。
你也须要根据缺点的严重性和频率进行分类和处理。 有须要关照用户并立即处理的致命缺点（fatal error）。 但也有一些小缺点，并没有真正影响系统的整体运作。 如果你每个小缺点都关照用户，那会非常烦人，滋扰用户的产品体验。 相反的，如果不立即办理致命缺点，那可能会是灾害性的。
你可以将缺点视为用户期望和系统假设之间预期之外的交互（unexpected interactions between user expectations and system assumptions）：
用户缺点User Error：当用户”误用”系统时，导致的缺点。系统缺点System Error：当系统无法供应用户期望的精确答案时，就会发生系统缺点。 它们常日是由于系统固有的局限性造成的。情境缺点Context Error：当系统按预期运作，但用户确察觉到缺点时，这便是情境缺点。 这常日是由于我们设计系统的假设是缺点的。举例来说，如果用户不断谢绝来自App运用的建议，产品团队可能须要查看并理解缘故原由。 例如，用户可能从日本搬到了美国，但是运用程序缺点地根据用户的日本信用卡信息，假设用户居住在亚洲。 在这种情形下，用户的实际位置数据可能是提出此类建议的更好数据依据。
最棘手的缺点类型是未知未知（the unknown unknowns）：系统无法检测到的缺点。 像上面的例子便是属于这种缺点类型，必须要回去剖析数据或非常模式，才有可能察觉。
另一种方法是许可用户供应回馈feedback：让用户能够很随意马虎地，随时随地供应回馈。 让用户帮助你创造未知未知，或是其他类型的缺点。
你也可以利用用户回馈来改进你的系统。 例如。 YouTube 许可用户见告系统他们不想看到的某些建议。 它还利用这一点网络更多数据，使其建议更加个人化和准确。
将ML模型预测作为建议，而不逼迫用户实行，也是管理用户期望的一种办法。 你可以为用户供应多个选项，而不指定用户应实行哪些操作。 但请把稳，如果用户没有足够的信息来做出精确的决策，这个方法就不适用。
我们之前谈到的许多一样平常原则仍旧适用在这里。 你可以在我上一篇文章中找到更多详细信息。
如何设计和管理AI产品？定义好问题并尽早测试：如果听到有人发起”让我们先构建ML模型，看看它能做什么。 ”常日要很小心，没有定义好问题前就试图开拓产品，常日会摧残浪费蹂躏团队大量韶光。知道何时该当或不应该利用ML。从第一天就开始操持数据策略。构建ML产品是跨领域的，牵扯到的职能并不但是机器学习而已
作者：Bastiane Huang，拥有近10年产品及市场开拓管理履历，目前在旧金山担当 AI/Robotics新创公司产品经理，专注于开拓机器学习软件，用于机器人视觉和掌握。
本文由 @Bastiane 原创发布于大家都是产品经理，未经容许，禁止转载
题图来自Unsplash，基于 CC0 协议。