面向NLP的AI产品方法论——如何设计多轮语音技能

本系列文字是一位创业者的投稿《面向NLP的AI产品方法论》，老曹尽量不做变动和评价，尽量保持系列文章的原貌，这是第2篇。

设计语音技能跟软件开发一样集体协作完成，本文主要讨论，产品经理在业务各阶段开发中，应该处理的任务。

在产品设计阶段，产品经理应该需要思考的3个任务，以及在后续【业务开发】【功能验收】【更新迭代】阶段的2个任务。

给自己做一个命题作文，比如，电影。（其实是从外卖，电影、酒店3个里面随机选的）

电影有2类服务，一个是通过语音购买电影票，属于多轮语音交互，一个是通过语音点播电影节目，单轮语音交互。讨论多轮的时候顺带上单轮。

语音购买电影票，本文不讨论语音下单支付。语音点播电影，本文不讨论语音控制（暂停/播放/快进/换一个/音量控制）。

不讨论与开发沟通、需求文档、数据埋点、后台工具接入、风控预警、支付订单、GUI的设计……只讨论如何做好多轮语音交互技能设计。

1、使用场景与用户画像

产品的基本功，怎样的用户在什么情况下，使用什么硬件设备，使用语音达成目标？

语音技能是专门对不同的群体而设计的，比如对盲人设计订餐功能，比如专门为外卖/快递小哥，设计打/接电话，群发短信的服务等，都是要考虑好用户画像。为方便大众理解，以电影作为例子。

点播电影使用场景:

1. 用户在家/办公室，使用智能电视/有屏音箱，通过语音点播电影。
2. 用户在车里，通过车机，使用语音点播电影。

在车里语音点播电影节目，可以是“播放喜羊羊第5集”给后座带屏幕的小孩看。

主屏的车机只做操控，不适合播放任何电影，干扰司机驾驶（即使是副驾驶有观影需求）这个就是一个权衡，必要的时候，还要通过摄像头检测司机的眼动以保证驾驶安全，当然自动驾驶到达某种程度，我们交付给用户的体验，又会进行改变。

同时也要考虑一下其他语义之间的冲突和关联。比如说，“我想看窗外”（假设有个这个名字的电影，或者是误识别）会不会跟“语音控制车窗打开”这类技能互相冲突。

买电影票使用场景:

1. 用户在车里通过语音购买电影票。
2. 用户在任意地方通过语音买电影票。

买电影票而言，用户虽然是全程填槽，但是在家使用，和在车机使用是完全不同的场景。

在室内使用，买电影票，用户没有明确某个电影，话术可以是“为你找到如下电影”加展示列表的方案，然后用户可以使用眼睛做筛选，手指滑动电影列表，点触选场次、座位等。

在车内使用，用户同样没有明确，我们尽量不希望干扰司机的视线和手指，会采用，报电影名的方案，“评分前三的是《电影1》《电影2》《电影3》你想看那一部？”这种选择的方案，尽量保护司机的眼睛和手不受打扰，后面的设计逻辑以此类推。

买电影票买的是服务，用户有明确某个电影，然后找电影院的需求。同样有为了消遣时间（电影是其中一个选项），先找电影院，然后选择看什么电影的需求。这些都是不同的场景行为。

这种就是在怎样的场景下，用户如何用语音技能服务，在设计技能的时候，这一类思考一定要到位，后面的所有设计，也是基于场景开展。

2、中控设计与业务边界

添加一个技能并不是那么简单，要站在全局角度去思考问题。

点播电影，从发起需求到电影播放。

买电影票，从发起需求到生成订单进入支付环节。

此处存在几种情况。

• 情况1、此前没有，从0到1搭建一个新技能，如此业务处理就简单。
• 情况2、已有一种技能存在，新增另外一个技能，要考虑并行情况。

比如当用户说“我想看电影”，如果是情况1，单个技能则很容易处理。

但是如果是情况2，两个技能同时存在，“我想看电影”就是一个模糊表述。

接下来的业务流程处理，就十分值得讨论和考究了。

单个技能并不难，难得是如何处理好与其他已存在技能之间的关系。用户在对话过程中的每一句话，都会被识别意图。

用户的第一句，使用显性跳转，直接进入对应的逻辑即可，这种情况非常容易处理，中控很容易根据用户的意图做分配行为。

难得是，用户不使用显性跳转，采用模糊表述。

上面两种选择都是方案选择，从实现难度上而言，从体验层面而言，产品经理做得都是基于各种约束条件下的效用选择。

以下两种情况，用户全程无意识，但是造成了，连续两句话都是模糊表述的情况。

我们先假设自己的语音助手同时存在，电影点播和买电影票2个技能，来看看用户连续2句话都是模糊表述的情况。

语言表述就是如此，随场景和时间变化，在某些情况下表述，就是是模糊，过一段时间（比如院线排片下线）表述，就不会引起歧义。

当用户模糊表述的时候，如果每次都采用追问的方案，就非常尴尬了，这个后面会讲，一方面用户在某些语境下实际上就是“你应该懂我”当下我所指的是什么，而计算机则未必明白。

所谓业务边界，相对而言比较容易理解。

点播电影归类于【语音&内容】，取决于接口方提供的作品，要考虑未来播放其他的内容的边界。比如有些经典作品名，存在音乐歌曲、戏剧、有声小说、电影、MV、等多种形式，而咱们做的技能，恰好又包含上述，且接口丰富每种资源都能够搜到，那么就需要通过上下文的理解去处理好每一种指代，继而做好边界处理。

买电影票归类于【语音&服务】，通过筛选电影院、作品名、场次、座位等，最终达成下单的结果，流程清晰明确，那么买电影票的其他相关服务，比如买爆米花可乐一类的零食，办理影城的会员卡一类附加的，则是边界外的内容。

往往把点播电影做好了，点播其他的音频、视频内容，也大同小异。同理买电影票做好了，买其他的（音乐会、演唱会、戏剧、景点）票，也大同小异。相对而言就是主槽位和辅槽位的变化不同。

一开始就穷尽所有情况，后续管理和添加技能库也方便拓展，而一开始想得比较简单，后续想要加想要改，那就麻烦得多了。不光说业务逻辑层麻烦，训练数据也很麻烦。

故而一开始就讲了，这一块是全局性的考量。

3、槽位设计与对话设计

自然语言处理，本质是结构预测，基于用户的表述，提取用户的话术里面的词槽，通过服务接口，完成后续行为。

对话设计是基于场景设计业务逻辑，通过对话管理，最终帮助用户达成目标。

点播电影需求明确，直接得到结果的有：播放电影星球大战、播放周星驰的功夫、播放电锯惊魂第三部等等。

还有一些筛选的行为，好莱坞最近有什么新电影、我想看喜剧片/动作片、评分前10的好莱坞电影、詹姆斯卡梅隆导演的电影等，然后基于搜索结果，确认播放行为。

故而归纳出点播电影的槽位：[影片名]、[主演]、[导演]、[影片类别]、[评分]……

点播电影相对简单，筛选后即可播放。而买电影票则复杂的多，毕竟买电影买的是服务，筛选条件较多。

常规来看，用户定电影票的流程一般有如下两种情况。

已经想好了看某个电影，然后基于此，寻找电影院。例如：我想看IMAX版本的阿凡达，基于此完成后续的追问，最终完成填槽行为。

另一种纯粹是为了消遣时间，先找附近的电影院，然后基于此完成后续的追问，最终完成填槽行为。

继而提炼出买电影票的槽位。

通过例句我们可以看出，辅助槽位是用来帮助主槽位做查询行为的。

主槽位一般是服务于整体流程需求的进行设计，辅助槽位是基于接口情况，以及自身理解进行设计归类。

对话设计分为两个部分，定义主流程和对话管理。

点播电影，只有一个，即为影片，所有的服务都是为了选中影片而服务的，选中了就直接播放。而买电影票则是，因为其业务属性，需要4个主槽位都填写完毕。

主体流程设计基于用户习惯，只要在后续的对话过程中，把4个主槽位确认完毕，即可完成买电影票的下单行为。

对话管理。此处是引用一段在其他文章里面的内容。

———————————————————————————————— 在对话服务过程中，反向管理用户的表达，完善槽位的引导。 例如在买电影票的场景，从需求到下单至少需要4个核心槽位。A电影名，B电影院，C场次，D几张票。（选座可以提供默认规则） 想要完成订单的确认，则成功引导用户填充ABCD四个槽位即可。好的完善和引导，则是： 如果用户填充了AB，AI应该追问CD的例子：我想看《魔童哪咤》，帮我在附近找个最近的电影院。此时AI需要展示哪几个场次可以选择，然后追问要买几张票 如果填充了ABC，应该追问D的例子：我想看《魔童哪咤》，附近找个最近的电影院，8点钟左右开场的。此时AI只需要追问要买几张票即可。 ABCD四个主槽位，无论用户的先后顺序，先填充哪个槽位，后续能够完善填充即可。 人类的表述千奇百怪，无论多少个槽位，人类都可以组织语言联合起来表述。乱序填充槽位才是智能化，自然表述的的基本要求。 ————————————————————————————————

自然语言处理中，用户仅能依靠有限的语音提示以及短期记忆来完成操作。因此对话设计需要通过明确提示用户需要进行的反馈，以及能进行的选择，逐步的缩小用户的对话走向，帮助用户明确意图，并完成最终的服务提供。

4、异常情况与自查清单

用户按照正常情况来，一般而言都能够完成任务。但是总会遇见异常情况的，服务的完整性需要保障，包含以下但不限于：

1、接口服务故障，导致的无法查询。故障如何上报，或是自家公司运维层面的故障错误。

2、接口服务正常，查不到对应的东西，推荐近似内容规则如何设计。如某个系列电影被买断，但是没有播放版权，如何给予近似推荐。

3、用户在对话过程中如果歧义表述，如何修复对话，并把业务拉回到正轨上。

4、未覆盖话术如何兜底、冲突条件如何做取舍，模糊表述如何应对。例如：

• 有没有团购券，爆米花，介绍一下这个电影的剧情。
• 帮我找一个距离我最远的电影院，买一张最贵的电影票。
• 有没有10块钱以内的IMAX电影票。（显然是不可能的事）

还有一些否定表述，双重否定，前后矛盾的表述。

异常情况有太多种类型，分布于业务设计中的各个阶段。

• 阶段1：产品经理凭借业务理解和设计经验去思考异常情况。
• 阶段2：测试过程中，其他人员发现了异常情况。
• 阶段3：产品上线后，用户遭遇了异常情况。

由于业务类型太多，无法逐一穷举。

但是在这个过程中，我们可以为自己设计一套业务的自查清单，来帮助自己完善思考的维度。

可以自己从经验中提炼，也可以学习其他的规范，典型如《Google对话式交互规范指南》《阿里语音交互设计指南》《亚马逊语音交互设计规范》一类是用来管理话术设计的清单。

清单越多，自己的专业度越好，交付的产品质量保障越好。

很多的东西都是自我不断完善，总结提炼，复盘消化后，最终内化为自己的专业能力。

5、技能测试与版本迭代

通过了自查清单后，然后进入了内部流程测试，一般而言分为两个测试步骤。

内行自测：产品经理（VUI设计师）自己编写对话测试用例。

外行复测：找小白用户（非而业务相关的行政人事等）自由放飞测试。

这2个过程中，往往会产出各种数据，业务边界及异常情况，以及各种修改建议，然后重新迭代调整，直至数据和体验达到一定标准后，即可更新上线。

上线前，依照流程标准，已经做好了数据埋点，并搭建好了完整的用户对话log分析后台。

上线后，通过业务后台观察业务数据，和实际真实用户的表述，继而迭代技能，提升体验。

举一个例子，是笔者在后续观察用户对话日志时的一些发现。

《速度与激情8》刚刚上映，用户会表述是我想看速度与激情、速激、速8等等；《魔童哪咤》上映的时候，用户的表述是，我想看哪咤的电影；《叶问3》上映的时候，用户的表述会是，叶问。甚至是甄子丹的那个电影；

这些就是真实的用户表述，此处就需要考虑这类应对方案，增加NER，模糊查询，动态词库管理。最终完成语音交互技能的迭代。

这类问题如果有共性特征，我还会进行业务自查清单的迭代，当下次处理同样类型的业务时，便可提前考虑到位。

从这个例子可以得出：“一开始就做好”相比“通过各种渠道反馈发现不好，然后通过迭代去做好”，从产品设计基本功上来看，根本是两种境界。

再列举一个笔者在开发过程中印象深刻的例子，。

我们在设计电影票技能的时候，内部曾经讨论到，如果用户需求明确，且一口气完整满足4个词槽，是否应当直接给予结果？例如：我帮我买2张《魔童哪咤》的电影票，附近找个最近的电影院，晚上8点钟左右开场的，随便什么座位都行。

为了完成这个，我们花费了不少精力。从我们后台的实际数据表现去看，实际上用户并不会这么说，很少有用户做多个复合条件叠加查询的，且从来没有用户会一口气说出4个词槽！可以明确一个结论，我们此前的的一部分工作被浪费掉了！

从这个例子，我们可以得出一个思考：面对难题，每个人都能出方案，而难题有多种不同的解法，方案有优劣之分，话术覆盖有先后顺序，精力的分配有侧重考量……

希望大家尽快达到这种境界，能从多个看似不同的方案中，挑选出不同情况下的最优解，即通过大家的复盘总结，迭代出自己的语音交互设计方法论。