对话式人工智能产品越来越常见，从Siri到电话客服，不知不觉中它们已在你身边寻觅了一个位置。笔者的产品是一款去年上线的客服机器人，简单聊聊从0到1的经验。

从交互形式来划分，智能客服包括纯语音（如天猫精灵），纯文本（如小冰），纯可视化界面（如一些电商的客服，完全通过界面交互来完成对话），语音+可视化界面（如Siri等手机助手）。交互形式没有好坏，这一点同非AI产品一样，根据用户使用场景选择最合适的形式即可。

从产品定义出发，智能客服类产品，最根本的价值在于以低成本取代人工客服工作中大量重复性的部分，再基于这个前提，去挖掘更多商业变现的可能性。人工客服的工作大致分为两种，一种是咨询类的，客服只需回答问题；另一种是申请类的，客服要帮客户完成一些业务办理。

因此，从可实现的功能来划分，智能客服可分为问答式和业务办理式，再细分为单轮/多轮问答与单轮/多轮业务申请。首先什么叫单轮对话呢？

——“吃了吗您呐？”

——“吃了”

那么多轮对话的概念呢？

——“吃了吗您呐？”

——“吃了”

——“吃了什么呀”

——“老北京炸酱面”

多轮对话的另一个名字，叫作基于上下文关系的对话。单轮与多轮申请也是同理，一句话就能解决的为单轮，需要反复几次的是为多轮。

无论是问答还是申请业务，作为一个智能客服，它就离不开NLP，NLP就离不开语料。

在如上的例子中，通常的工作方法是，我们定义一个用户意图叫“吃了吗”，然后把相似的语料（吃了么？吃饭了吗？吃了没？你有没有吃饭？……）喂给机器人，之后写一些用例来测试它识别的准确率，如果识别率较低，就继续喂它语料，直到我们对识别率满意为止。用同样的方法，我们就可以让机器人学会理解很多种用户意图了。

多说一嘴，其实这里就是机器学习中样本集与测试集的概念。样本集用来学习，测试集用来测试学习的效果。另外由于机器学习的本质还是数学与统计，并没有真正的理解，所以学习效果非常依赖语料的质量。

直观的表现是，不同的意图中，语料差异越大，识别的准确率越高。比如：“吃了吗”和“吃了没”是相似的，“吃了吗”和“看星星看月亮从诗词歌赋谈到人生哲学”是不相似的。那么后者作为两种意图去做识别，就是容易分开的，而前者两个说法过于相近，可能会得到很差的识别结果。所以训练师需要了解基本的机器学习原理，才能够检查和调整样本集的质量。

现在我们的机器人已经能够听懂一些人话了，下一步只要定义好回复的内容，比如给“吃了吗”回复“吃了”，给“睡了吗”回复“没睡”，再把这些需求交给可爱的开发同学，一个支持单轮问答的机器人就完成了！（好的这是做一个PM最愉快的时刻了）

多轮对话设计的本质，是定义场景和将多个单轮对话进行组合。对于前面提到的例子来说，在“吃了”后面问“吃了什么呀”是正常的结合语境的问法，而脱离语境问这一句的话，就会让听者感到困惑。所以这部分的需求是这样写：

当用户表达“吃了吗”的意图，机器人应回复“吃了”；

当用户上一个表达是“吃了吗”and机器人回复是“吃了”and用户这一个表达是“吃了什么呀”，机器人应回复“老北京炸酱面”；

当用户上一个表达是“睡了吗”and机器人回复是“没睡”and用户这一个表达是“吃了什么呀”，机器人应回复“亲您想问什么呢？”

再次把需求交给开发，我们就得到了一个支持两轮对话的机器人。如果需要增加轮次或新的场景，那么在此基础上添加相应的逻辑即可。

再说到业务办理，本质是在问答的基础上增加与用户相关的数据交互，比如当用户说“帮我订个车去人民广场”。那么机器人应该回复“好的”的同时，拿用户的手机号和“人民广场”等信息去完成订车这一操作。

大部分时候，业务办理和多轮对话是交叉的，比如订车的场景下，机器人可能需要再问一下什么时间出发，对车辆是否有要求，那么这至少要用三轮对话来完成。

讲完了基本框架，再说说落地。在实际的需求分析过程中，我们需要了解业务背景，了解业务规则下人工客服的工作内容。从其中归纳出最终用户一般有哪些需求，他们会问什么，怎么问，抽取出用户意图，根据重复性高的对话流程做对应的轮次设计。

假设我们做的是信用卡客服机器人，那么用户意图很可能有“手续费怎么算”“逾期了有什么影响”，下一句用户则可能会继续问，“那我还上了还影响吗”。

这其中需要思考的点很多，原则包括但不限于：

• 了解业务规则，了解最终用户的需求；
• 抽取意图时注意差异化，意图过于接近会给后期的识别结果带来麻烦；
• 从用户记录中提取语料时要注意筛选，高质量的语料是高识别率的前提；
• 设计轮次时要跟意图一起考虑，不能基于无法识别的意图做设计；

以及有一个格外需要注意的地方是，对话式智能产品与其他产品的不同在于，用户的表达是不受限的。它不像普通的产品，一个页面上如果只有一个按钮，那么用户就不可能有第二个操作。而对话中，用户可能会讲任何东西，例如我的小机器人已经被问了若干次，“你的爸爸妈妈是谁呀”。

所以在设计流程时，需要考虑用户不按正常流程走完的可能性，也要在设计回复时，尽可能引导用户往自己想要的方向去做表达，根本原则是收敛而非发散。

本文由 @一个圆圈儿 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议