友情提示：本文共有 2995 个字，阅读大概需要 6 分钟。
想掌握对话沟通，语境为王。
我们将使用Tensorflow构建一个聊天机器人框架，向大家示范如何实现上下文的语境处理。
有没有想过为什么大多数聊天机器人缺乏会话语境？
我们将创建一个聊天机器人框架，为一个小岛上的轻便摩托车租赁店建立一个对话模型。这家小店的聊天机器人需要处理营业时间，预订选项等简单问答。我们也希望它能处理客户根据上下文提出的问题，例如关于同一天租金的查询。体验能做好的话，可以让客户的假期留下美好回忆！
这将通过三个步骤实现：
将对话意图的定义转换为Tensorflow模型
接下来，构建一个聊天机器人框架来处理响应
将基础的上下文语料，整合进响应处理过程
我们将使用tflearn，一个基于tensorflow的Python包。 一般用iPython notbook作为辅助工具
把会话意图的定义，转化为 TensorFlow 模型
第一步，完整的notebook脚本可以在这里找到。
聊天机器人框架框架需要一个能定义会话意图的架构。有一个简洁的实现方式，是使用JSON文件。
每个会话意图包含：
一个标签（唯一的命名）
模式组（用于神经网络文本分类器的句子模式）
响应组
稍后我们将添加一些基本的上下文元素。首先是导入的包：
如果是新手，看看“7行代码搞定深度学习”；如果还不清楚 TensorFlow 都能干啥，就看看这个。
加载 JSON 会话意图文件后，现在可以开始设计我们的文件、词语和分类器的类。
我们创建了文件（句子）列表，每个句子是一个由词干组成的列表，每个文件关联一个意图（一个类对象）。
词干"tak"将匹配“take”，“taking”，“takers”等。我们可以清理词语列表，删除无用的词目。但现在这样处理就够了。
麻烦的是，这个数据结构不能用到Tensorflow，需要进一步转换：从由词语组成的文本转换成由数值型变量组成的张量。
注意我们的数据是被打乱了的。Tensorflow将取出其中一些数据，并将其用作测试数据，以衡量新拟合模型的精度。
如果我们看一个单一的x和y列表元素，我们会得到词袋数组，一个用于意图模式，另一个用于意图类。
现在可以准备建模了。
同样的张量结构，也用在了 "toy’ 例子里的2层神经网络上，观察理解这个模型拟合训练数据的过程，会一直有用。
要完成这一部分的工作，我们将保存（"pickle"）模型和文档，以便下一个notbook脚本可以调用。
搭建聊天机器人框架
第二步的完整notebook脚本看这里。
我们将构建一个简单的状态机来处理响应，使用我们（从上一步）的意图模型作为分类器。这就是聊天机器人的工作原理，语境聊天机器人框架，是带状态机的分类器。
导入相同的库之后，我们 unpickle 模型和文件，并重新加载意图文件。注意，聊天框架与我们构建的模型是分开的。除非意图模式改变，否则不需要重建模型。由于有数百种意图和数千种模式，模型可能需要几分钟的时间才能建立。
接下来，我们将加载保存的Tensorflow（tflearn框架）模型。需要注意的是，首先需要定义Tensorflow模型需要的数据结构，就像上一节所述。
在处理意图之前，我们要想办法把用户输入生成词袋。这个技巧与我们以前使用过的训练文本相同。
现在可以建立响应处理器了。
每个传递给response方法的句子都被分类。分类器使用model.predict（）并且非常快。模型返回的概率向量与我们的意图按顺序一一对应，生成潜在响应列表。
如果一个或多个分类结果高于阈值，就可以判断一个标签是否与意图匹配，然后处理。我们将分类列表作为一个堆栈，并删除栈顶来寻找合适的匹配意图，直到找到一个或者栈为空。
我们来看一个分类示例，返回值中最有可能的标签及其概率。
雷锋网提醒，“你的店今天营业吗?”不是这个意图的模式之一：“模式”: [“今天营业吗?”, “今天什么时候开业?”, “今天的营业时间?”] ；而不管对应项“营业”和“今天” 多么适合模型（它们在选择的意图中是突出的）。
我们现在可以从用户输入中生成聊天机器人的响应。
以及上下文无关的其他响应..
让我们利用一些基本的上下文，实现我们聊天机器人的拖欠租赁谈话模型。
语境化
我们想要处理一个关于租赁摩托车的问题，并咨询租金是否今天到期。是非问题是一个简单的语境响应。如果用户回答“今天” ，上下文是租赁的时间范围，那么最好调取租赁公司编号1-800的问答响应。不占用时间。
为了实现这一点，我们将把“状态”的概念加入我们的框架。这包括用来维护状态的一个数据结构，和在处理意图时用来操作这个数据结构的特定代码。
因为我们的状态机的状态需要容易维护，恢复和复制等等，所以很重要的是要把它全部保存在像字典这样的数据结构中。
这是基本语境的处理过程：
我们的上下文状态是一个字典数据结构，它将包含每个用户的状态。我们将为每个用户使用一些唯一的标识（例如，元胞数）。这使得我们的框架和状态机可以同时维护多个用户的状态。
在意图处理流程中添加了上下文处理流程，如下所示：
如果一个意图想设值相应的上下文，则可以这样做：
如果其他意图想要与上下文相关联，则可以这样做：
以这种方式，如果用户刚刚输入“today”而与蓝色没有关联（无上下文信息），则我们的“today”意图将不被处理。如果他们输入“today” 作为对我们的Y/N问题（意图标签：“rental”）的回应，则意图被处理。
上下文状态更新了。
我们定义了“greeting”意图来简化上下文，就像通常的短对话一样。添加一个“show_details”参数来帮助我们理解其中的含义。
再试试输入“today”，这里有一些值得注意的...
首先，我们对无上下文相关的“today”的回应是不同的。我们的分类产生了2个合适的意图，而“opentoday”被选中，因为“今天”的意图虽然较高的概率，而被限制在不再适用的上下文中。语境很有用！
有一些事情需要考虑了，那就是下面的语境化...
带状态的状态模型
没错，你的聊天机器人将不再像无状态的服务端那么轻松愉快了。
除非要重置状态，重新加载模型和文档 - 每次调用您的聊天机器人框架时，那你都需要引入"状态"概念。
这个不难。可以在其进程中运行一个有状态的聊天框架，并使用RPC（远程过程调用）或RMI（远程方法调用）来调用，我推荐Pyro。
用户界面（客户端）通常是无状态的，例如。HTTP或SMS。
聊天机器人的客户端将调用Pyro函数，有状态服务来处理。看，惊不惊喜，意不意外！
这是一个构建Twilio SMS聊天机器人客户端的逐步指南，这里是FB Messenger的一个实现。
别把状态存到本地变量
所有状态信息都必须放在像字典一样的数据结构中，容易地持久化，重载或以原子复制。
每个用户的会话将生成上下文，这将为带有该用户状态的上下文。用户ID可以用他们的元胞数，Facebook用户ID或着其他唯一标识符。
有些情况需要（按值）复制用户的会话状态，然后作为意图过程来恢复。如果状态机在框架内带有状态相关的变量，那么在实际中难以有效的。
所以现在你有一个聊天机器人框架，一个有状态服务的方案，以及可以添加上下文的demo。以后大多数聊天机器人框架都将无缝地衔接上下文。
想想意图影响和反应不同上下文（语境）设定的创意方式。用户的上下文字典可以包含各种各样的会话上下文。
来一起愉快地玩耍起来！
来源： 雷锋网
本文如果对你有帮助，请点赞收藏《厉害！用Tensorflow搭建能理解语境的聊天机器人》，同时在此感谢原作者。
