[8]的模型框架就是依照上面的过程进行设计的：
开发者提供一系列备选的actions，包括response模板和一些API函数，用来被bot调用。
由专家提供一系列example dialogues，用RNN来学习。
用一个模拟user随机产生query，bot进行response，专家进行纠正。
bot上线服务，与真实客户进行对话，通过反馈来提高bot服务质量。
一个完整的工作流程由上图描述，具体步骤看下图：
训练的时候是用一部分高质量的数据进行监督学习SL，用增强学习RL来优化模型，得到质量更高的结果。
文章[9]平衡了两种流行方案的优缺点，提出了一套有参考价值的、具有实际意义的seq2seq解决方案。
一共五个组件：
1、 Intent Network
这个部分可以理解为seq2seq的encoder部分，将用户的输入encode成一个vector。
2、 Belief Trackers
又被称为Dialogue State Tracking(DST)，是task-oriented bot的核心部件。本文的Belief Trackers具有以下的作用：
支持各种形式的自然语言被映射成一个有限slot-value对集合中的元素，用于在数据库中进行query。
追踪bot的state，避免去学习那些没有信息量的数据。
使用了一种weight tying strategy，可以极大地减少训练数据的需求。
易扩展新的组件。
3、 Database Operator
数据库查询的输入来自于Belief Trackers的输出，即各种slot的概率分布，取最大的那个作为DB的输入，进行查询，获取到相应的值。
4、 Policy Network
这个组件是像一个胶水，起到粘合其他上面三个组件的作用。输入是上面三个组件的输出，输出是一个向量。
5、 Generation Network
最后一个组件是生成模型，本质上是一个语言模型，输入是Policy Network的输出，输出是生成的response，再经过一些处理之后可以返回给用户了。这里的处理主要是将response中的slot，比如s.food还原成真实的值。这一步和文章[8]的step 10一样，将具体的值还原到entity上。
完全用end-to-end来解决task-oriented是不可能的事情，一定是在一个框架或者体系内用这种seq2seq的解决方案来做这件事情，文章[8]和[9]给出了很大的启发。
Knowledge Sources based模型
纯粹的seq2seq可以解决很多问题，但如果针对具体的任务，在seq2seq的基础上增加一个相关的knowledge sources会让效果好很多。这里的knowledge可以是非结构化的文本源，比如文章[10]中的ubuntu manpages，也可以是结构化的业务数据，比如文章[9]中的database，也可以是一个从源数据和业务数据中提取出的knowledge graph。
文章[10]作者将bot任务定义为next utterance classification，有一点像question answering任务，给定一个context和一个response candidate list作为备选答案，通过context来从candidate list中选择正确的response。本文的贡献在于在context的基础上，引入了task相关的外部专业知识库，并且这个知识库是非结构化的。
模型是三个rnn encoder组成，一个rnn来encode context，一个rnn来encode response，还有一个rnn来encode knowledge，然后综合起来做预测，选出最合适的response。模型被称作knowledge encoder。因为数据集采用的是ubuntu technical support相关的数据集，外部资源就选用了ubuntu manpages。
context sensitive模型
文章[11]的模型比较简单，但考虑的问题意义很大，history information的建模对于bot在解决实际工程应用的帮助很大，也直接决定了你的bot是否能够work。作者将history context用词袋模型表示，而不是我们经常采用的rnn，然后将context和用户query经过一个简单的FNN，得到一个输出。
|评价
bot response评价很难，虽然说可以借鉴机器翻译的自动评价方法BLEU来做，但效果不会太好。几乎每篇paper都是会花钱雇人来做人工评价，设计一套评价机制来打分，人工的评价更具有说服力。对于实际工程应用更是如此，用户说好才是真的好。而不是简单地拿着自己提的、有偏的指标，和几个方法或者其他公司的bot进行对比，来说明自己好。
|思考
读了一些paper，也和一线在做bot应用的工程师交流之后，有了一点思考，总结如下：
1、要不要做bot？流行一种说法是市面上没有好用的bot，要解决bot的问题需要很多技术同时进步，可能还需要非常长的一段时间，现在用这个东西来做business，简直荒谬。我个人的看法是，解决具体task的bot，结合当前先进的技术，做一些框架性的工具，并不是那么遥远的事情，虽然不容易，但却非常有意义，解决了垂直领域的bot问题，才有可能解决open domain的bot问题。也正是因为不容易，提高了门槛，才会出现真正的机会，诞生一些很牛的技术公司。
2、open domain还是task-oriented？如果是我，我会选后者，因为前者只是一个梦想，一个遥不可及的梦想，需要更多的技术层面上的大突破。task-oriented更加具体，更加实用，针对具体的业务，提供一些解决方案，已经有很多企业在做了，虽然一个通用性或者扩展性强的解决方案还没有出现，但一定是一个趋势，也是新一代做bot的公司的机会。
3、task-oriented bot为什么难，该朝哪个方向来发力？end-to-end是一种理想化的模型，用深度学习模型从大量训练数据中来“捕捉”一些features，“拟合”一些函数，虽然可以得到很不错的效果，而且使用起来确实很方便，但尴尬就尴尬在具体的task中是拿不到海量数据的，数据规模小了之后，纯粹的end-to-end就变得非常鸡肋了。然而真实的场景中，很多企业又有一定的数据，也有bot的需求，所以现在成熟的解决方案就是针对你的具体业务，来设计一些features，templates和rules，当客户的业务发生更改时，需要不断地维护现有的bot系统，十分费时费力。真实的场景中往往涉及到很多结构化的业务数据，纯粹地、暴力地直接根据context生成response是不可能做到的，文章[8][9]都给出了非常有启发性的解决方案，将end-to-end应用在局部，而非整体上，配合上Information Extraction和Knowledge Graph等技术，实现一个高可用的框架体系，这个应该是task-oriented bot的发展方向。 3/4 首页 上一页 1 2 3 4 下一页 尾页 |
