您好、欢迎来到现金彩票网!
当前位置:彩之网 > 子串 >

以 Facebook 的 witai 为例讲解机器人对话平台(Bot Framework)

发布时间:2019-06-19 09:40 来源:未知 编辑:admin

  Wit.ai 是 Facebook 推出的用于将自然语言转化为可处理指令的 API 平台,其目的是为了帮助开发者便捷的打造类 Siri 语音对话应用或设备。

  前些日子,云栖大会上,阿里的资深技术专家海青在介绍阿里 ALIME 团队的 Bot Framework 时提到了 Google 的 api.ai 和 Facebook 的 wit.ai,所以我希望了解一下,对于我在做业务时遇到的问题、有过的想法,国外一线大厂是怎样处理的。

  本篇文章将会从理解和对话两个方面去讲解 wit.ai,主要参考资料为 wit.ai 的英文原版文档:。

  我们需要对用户的意图进行区分,但问题在于用户表达同一意图的说法可能是无限的。

  wit.ai 内置了一些常用实体,这些内置实体不必通过用户的标注就能够完成实体识别。不过具体的业务场景下,我们还会用到一些

  。如果需要 wit.ai 完成这些自定义实体的识别,就需要进行适当的用户问句标注。

  有些情况下,我们希望抽取的实体值是可枚举的,也即我们能够处理的实体值是一个有限的词典。

  我们当然不止希望 pizza_type 只识别 cheese,可以通过图示的方式为这个实体增加可识别的 pizza_type 实体值,添加完成后,可以尝试在 expression 中输入 [新的实体值] + pizza,发现我们新增的 pizza_type 实体值,是可以被自动识别的。不过,识别范围也仅限于我们在 pizza_type 中添加的 keywords。

  很多情况下,我们也希望能对有限词典之外的词进行识别,比如上例中的 pizza_type,当然,我们能处理的只有配置好的 pizza_type 实体值,但并不意味着当用户需要其他类型的 pizza 时,我们就无法作答。

  策略不会尝试去抽取用户问句中的某个词或是某个短语,而是会将整个句子作为一个整体来理解,比如意图、情感等,通过分析整个用户问句来得到实体值。

  策略被用来抽取用户问句中的子串,这些子串通常不会包含在预定义的实体值词典中。

  策略用于处理需要抽取的实体值可枚举的情况,我们为实体准备好一个预定义的实体值词典,该实体的抽取就通过使用实体值词典做匹配来完成。

  在一些经典的场景(比如订票)中,按照上文的定义,实体的抽取确实应该使用 keywords 策略,但如果同一条用户问句中需要抽取多个同类实体呢?建立起同类实体与多个词典内实体值之间的对应关系就成了需要解决的问题。

  举个例子,expression 为 I want go from NY to SF,其中 NY 和 SF 均为 wit/location 实体中的值。在这样的业务场景下,我们需要同时抽取出两个 wit/location 实体,值分别为 NY 和 SF,并且区分好 NY 是出发点,而 SF 是目的地。

  对于每个抽取出的实体,wit.ai 都会提供一个置信度,当置信度足够低时,或许我们应当采用特殊的处理方式,比如进行确认或直接丢弃。但如何定义置信度的『足够低』呢?

  如上图,如果我们需要当准确率未达到1时进行特殊处理,那么我们就应该选取置信度为0.79,然后对置信度低于0.79的实体抽取情况进行特殊处理。

  规则应当分为共用和非共用,不同业务方应当使用不同的规则域。因为同一位置的同一个词可能会被不同规则抽取到不同的实体中,不同业务方之间不应相互影响,同一业务方在编写规则时也应当注意通用性。

  相似问句语料的提供可以通过与规则编写相同的方式进行,搜索策略采用 trait 即可。

  模型的训练是实时的且不可见的,通过 expression 可以即时验证结果。

  如果一次标注中抽取了多个实体,那么在用户问句不完整的情况下,能否将原标注结果中全部实体的一个子集抽取出来。也即抽取的粒度,是一个实体,还是一次完整的标注?推测为一个实体,但当出现冲突时,与完整标注更接近的应当拥有更高的优先级。

  首先我们处理信息完整的情况,如图所示,我们按照上文讲过的方式利用 context-key 同时拿到 showTime、theater、movie,然后将其拼装成 Bot sends.

  wit.ai 采用 bookmark 来做这种情况的处理。如图所示,我们在 findTheater 函数的调用前添加一个 call-findTheater 的 bookmark,当用户补全时间实体后,我们便利用 Jump 跳转到 call-findTheater,随之进行 findTheater 函数的调用,改走信息完整的分支。

  同时,我们当然希望不止能够识别用户的 yes,与之同意图的 yep、yeah 等也应当被认定为是用户的肯定回答。相对的,否定意图除了 no 之外,也应当包含 nope 等其他实体值。

  这种情况下,如果用户回答的意图为 yes(处理方式上文中已经提到过),我们会追问一个额外的问题:Which sports do you watch the most?

  在调查的第二部分开始之前,我们先做一个 question-2 的 bookmark,为第一个问题 intent 为 no 的处理做准备。

  之后进行第二个问题回答的处理,询问用户:Ok. And do you watch sport online?,当用户回答的 intent 为 yes 时,调用 computer-result 函数,给出 result 作为返回值,拼装成最后的 Bot sends. 同时在函数调用之前增加一个 end 的 bookmark.

  按照之前的流程图,当第一个问题的 intent 为 no 时,应当直接跳转到第二个问题;当第二个问题的 intent 为 no 时,应当直接结束。

  session_id 是我们自己产生的,用于标记与同一个用户一次对话全部内容的唯一 ID. 需要注意的是,即便是同一个用户,不同的对话也应当拥有不同的 session_id。

  与百度 UNIT 平台相比,传入 context 并由函数进行 DST 和 policy 的方式要比为答案提供设置准入条件的方法要更加灵活。

  目前的 wit.ai 中似乎没有反映出多轮过程与答案系统分离的思想,还是较为原始的,从头至尾,非叶子节点中的 Bot sends 算作多轮过程,叶子节点的 Bot sends 作为答案。

  Facebook 也发现对话系统能够利用的不应该只局限于用户问句中提供的信息,推出了 Bot engine,可以使用用户画像以及场景信息;意识到答案也不应当只局限于简单的文本,推出了 Built-in NLP for Messager,可以调用丰富的前端样式来做答案的展示。 并准备于2018年2月1日废弃掉对话部分所讲的 Stories UI.

  对话系统应当具有节点间跳转的能力,wit.ai 采用 bookmark 来完成。阿里小蜜的在订票场景下的『换出发地』应当也是相同的原理;商品推荐时的『换一换』推测是通过该方法重复进入相同的推荐节点,但 context 中会记录该节点的进入次数,进而展示不同的结果。

  常用的肯定、否定、请求更多等用户动作应被当做 intent 来处理,同时要注意不能只将其看做一些词的合集来处理,而是采用 trait 策略整体看待以识别意图。

  同一个 Session 中,通常只有一个 context,这个context 由我们自己的函数维护,根据 context 的不同做出不同回应,返回不同的值,而后续的对话过程又依赖于函数调用的返回值来做多轮对话的分支。

  quick replies 可以每次单独设置,但也可以尝试把 keywords 类型实体的实体值词典利用起来。

  废弃现有的 Stories UI 后,用户画像以及场景信息由 context 传递,由函数来做 DST,应当是没有疑问的。但前端模板的调用是由函数来做,还是由当前的 Bot sends 模块改进得到?我个人倾向于由函数来做,一是更为灵活,二是可以将多轮过程与答案系统分离,Bot sends 只起到澄清以及推进对话的作用,而不是同时兼具答案提供的功能。

  作者:我偏笑 ,AI产品经理大本营”成员,“AI研习小分队”的分享嘉宾之一

  本文由人人都是产品经理专栏作家 @黄钊 授权发布于人人都是产品经理,未经作者许可,禁止转载。

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。

http://ibtlsports.com/zichuan/104.html
锟斤拷锟斤拷锟斤拷QQ微锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷微锟斤拷
关于我们|联系我们|版权声明|网站地图|
Copyright © 2002-2019 现金彩票 版权所有