百度前AI产品经理分享:如何设计好的AI用户体验与构架

三个基本原则:期望、错误和信任

建立用户正确的期望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产品是跨领域的,牵涉到的职能并不只是机器学习而已

 

一、AI产品设计框架基础知识

如上图,这就是本篇要讲解的AI产品设计框架。其中左侧的Agent就是今天的主角,可以称为“学习的基于效用的Agent”。这个名称中包含了三个部分,我们就先来解释一下这三个部分:

  • Agent:能够行动的某种东西。(第二章示例所讲解的Agent,对应的就是一个可以自主玩牌的Agent)。
  • 学习的Agent:可以简单理解为可以自主学习自我升级的Agent。

基于效用的Agent:可以简单理解为此类Agent在选择执行的行为时,总是选择期望能得到最大化收益的行为。

上图中右侧的是环境,也就是Agent所处的环境,可以理解为Agent的外部环境。这个环境可以是真实环境,也可以是网络虚拟环境。

Agent可以通过传感器来感知环境的当前情况,通过执行器对环境产生影响。举个例子:假如一个机器人Agent,就是将摄像头或麦克风作为传感器来获取图像与声音,将机器手臂与机器腿作为执行器来进行特的定操作与移动物理位置。再比如微软的聊天机器人小冰也是一个Agent,只不过所处的环境是网络,他通过获取文字输入的接口作为传感器,通过发送回复信息的接口作为执行器。

已经讲解了最基本的一个Agent的结构情况,如果说想让Agent在环境下运行,那么首先要做的事情就是定义环境。

1.1 环境定义

Agent都会有其需要完成的任务,在设计Agent时,第一步就是尽可能完整地详细说明任务环境。任务环境的定义内容包括:性能度量、环境以及Agent的执行器与传感器,称之为PEAS描述(Performance(性能度量),Environment(环境),Actuators(执行器),Sensors(传感器))。我们通过以下描述来理解各个定义内容:

  • Agent在其所处的环境中,通过传感器收集感知信息,形成Agent内部的感知序列。
  • Agent在其所处的环境中,针对感知信息会生成一个行动序列,并由执行器完成。
  • 一个理性Agent,对每一个可能的感知序列,根据已知的感知序列和Agent具备的当前知识信息,选择能使其性能度量最大化的行动。

下面给出一个示例:

1.2 基于效用的Agent的设计

定义好环境,我们就要回到对主体Agent的设计上来了。

上图就是基于效用的Agent的设计框架。其中,矩形表示Agent决策处理过程,椭圆形表示对应处理过程所中用到的背景知识信息。

下面我们将按照Agent的处理顺序依次说明每一个处理步骤的具体处理方法,并且会说明每一个步骤为下一步骤所输入的信息。

1.3 学习的基于效用的Agent的设计

以上已经完成了对一个基于效用的Agent的设计描述。但真的一个智能Agent就这样就完成了么?如果对于一个不能自主学习并进化系统逻辑的Agent,还不能称其为智能化的。那么我们只需将上述的Agent设计加入一个能够学习的环境中即可。接下来我们看看能够学习的基于效用的Agent是如何设计的吧。

学习Agent可以被划分为4个概念上的组件:学习组件、性能组件、评判组件、问题产生器。在此部分中的性能组件,就是“学习的基于效用的Agent”中“基于效用的Agent”的整体。设计框架如下图所示:

下面将对于除性能组件外的其他组件进行简单说明:

  • 学习元件:利用来自评判元件的反馈评价Agent做的如何,并确定应该如何修改性能元件以便将来做得更好。
  • 评判元件:根据固定的性能标准告诉学习元件Agent的运转情况。评判元件是必要的,原因是感知信息自身无法指出Agent的成功程度。性能标准是固定的。概念上说,应该把性能标准置于Agent之外加以考虑,理由是Agent不应该修改性能标准来适应他自己的行为。
  • 问题产生器:负责可以得到新的和有信息的经验的行动建议。如果性能元件自行其是,他会一直根据已知的知识采取最佳行动。但是,如果Agent希望进行少量探索,做一些短期内可能次优的行动,那么他也许会发现对长期而言更好的行动。问题发生器的任务就是建议探索性行动。它的目标是发现一种更好的物体运动的理论并改进自己的头脑。

到现在为止我们已经简单了解了如何搭建一个“学习的基于效用的Agent”。此时是不是非常希望从概念的层次实操一把?由于笔者正在学习AI的入门阶段,还没有真正了解到每个具体概念的应用方法,因此我也只能从最表面的层次演练一下。对于没有描述清楚的内容,笔者会在今后的学习中逐步完善并分享。同时,如果文章中存在错误,也希望大牛们多多指出。

二、一个简单的产品定义示例

下面将要分享的简单事例是《自动斗地主Agent》,一个YY的成果,自己玩耍而已大家不要太过认真。

我的想法是,设计一款能够自主学习优化并且帮我最大化获胜的某个移动端斗地主App游戏的智能自动化游戏Agent。

第一步:首先定义一下游戏的环境

模型信息:关于独立于Agent的世界如何变化的规则信息与Agent自身的行动会影响世界的规则信息,此处会将游戏中对于斗地主的全部规则录入,诸如:发牌规则、叫地主规则、出牌规则、加分规则、获胜规则等等。并且会录入一般化的出牌策略,诸如:压制策略、辅助同伙策略等等。

第二步:对于基于效用的Agent,我们做如下定义

  • 效用判断的规则信息:这里根据环境中已经出过的牌,每个选手的出牌历史、角色以及猜测可能剩余的牌等信息,判断出最能符合最大化收益的出牌行为。
  • 传感器就是获取环境中当前的游戏状态信息,如:谁出了什么牌等;
  • 执行器就是能够模拟手机点击来执行叫地主、出牌等操作;

第三步:对于学习的Agent,我们做如下定义

  1. 性能标准:根据初始时手中的牌、过程中的得分情况与最终完成后其他选手中剩余牌的情况给出一个对于一轮玩牌结果的奖励或惩罚的分数。
  2. 学习组件:会不断对更为一般化的开局与出牌策略、更为一般化的农民合作策略、针对识别某个人或某种类型的人的开局与出牌策略、如何试探其他玩家的出牌策略等策略提出学习目标,并根据结果修正Agent中的效用判断。

 

附:我的学习计划

  • 《人工智能:一种现代的方法(第3版)》
  • 《深度学习》书籍中的数学知识
  • 《终极算法:机器学习和人工智能如何重塑世界》
  • 《传感器实战全攻略》
  • 《数学之美》

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/2905.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息