与智能语音助手交谈的用户期望聊天机器人提供情报。 如果您正在开发商务机器人，则期望值会更高：客户希望用户遵循所需的预定场景，而用户希望机器人能够智能地，最好是人为地回答所提出的问题，帮助解决问题，有时甚至只是闲聊。
我们提供英语聊天机器人，可通过各种渠道与用户进行通信-Facebook Messenger，SMS，Amazon Alexa和网络。 我们的漫游器取代了支持服务，保险代理，并且可以聊天。 这些任务中的每一个都需要其自己的开发方法。
在本文中，我们将告诉您我们的服务包含哪些模块，每个模块的制造方式，选择的方法以及原因。 我们将分享分析不同工具的经验：当生成神经网络不是最佳选择时，为什么我们使用Word2vec而不是Doc2vec，ChatScript的魅力和恐怖之处等等。
乍看起来，我们正在解决的问题似乎微不足道。 但是，在自然语言处理领域，技术实施和人为因素都存在许多困难。
- 十亿人说英语，而每个以英语为母语的人都以自己的方式使用英语：有多种方言和各自的语音功能。
- 许多单词，词组和表达方式都模棱两可：这张照片中就是一个典型的例子。
- 正确解释单词的含义需要上下文。 但是，要求客户澄清问题的机器人看起来并不像可以根据用户的要求切换到任何主题并回答任何问题的机器人那样酷。
- 人们常常在现场演讲和信函往来中，要么忽略语法规则，要么回答如此简短，以至于几乎不可能恢复句子结构。
- 有时，为了回答用户的问题，有必要将其请求与FAQ文本进行比较。 同时，您需要确保在FAQ中找到的文本确实是答案，而不仅仅是包含与请求匹配的几个单词。
这些只是最明显的方面中的一些，还有语，行话，幽默，讽刺，拼写和发音错误，缩写以及其他使该领域难以工作的问题。
为了解决这些问题，我们开发了一种使用一系列方法的机器人。 我们系统的AI部分包括对话管理器，识别服务和重要的复杂微服务，这些服务可以解决特定问题：意图分类器，常见问题解答服务，闲聊。
开始对话。 对话管理员
机器人中Dialog Manager的任务是与实时代理进行通信的软件模拟：它应指导用户通过对话场景达到一些有用的目标。
为此，首先找出用户想要的东西（例如，计算汽车保险费用），其次，找出必要的信息（地址和其他用户数据，有关驾驶员和汽车的数据）。 在那之后，服务应该给出一个有用的答案-填写表格并将结果提供给客户。 同时，我们不应该问用户他已经指出了什么。
Dialog Manager允许您创建这样的方案：以编程方式对其进行描述，以小砖块构建-特定问题或应在特定时刻发生的操作。 实际上，该场景是有向图，其中每个节点都是消息，问题，动作，如果从一个节点到另一个节点的转换有多种选择，则边缘将确定这些节点之间转换的顺序和条件。
节点的主要类型
- 等待节点到达队列的节点将出现在消息中。
- 等待用户表现出某种意图的节点（例如，写：“我想获得保险”）。
- 等待用户验证和保存数据的节点。
- 用于实现各种算法设计（循环，分支等）的节点。
如果该节点是关闭的，则控制权将不再转移给它，并且用户将不会看到已经提出的问题。 因此，如果我们在这样的图中对第一个开放节点进行深度搜索，则会得到需要在给定时间向用户提出的问题。 依次回答Dialog Manager生成的问题，用户将逐渐关闭图中的所有节点，并认为他已执行了规定的脚本。 然后，例如，我们为用户提供了我们可以提供的保险选项的描述。
“我已经说了一切！”
假设我们要求用户输入姓名，并且在一条消息中他还将给出他的出生日期，姓名，性别，婚姻状况，地址，或发送其驾照的照片。 系统将提取所有相关数据并关闭相应的节点，也就是说，将不再询问有关出生日期和性别的问题。
“顺便说一句...”
对话框管理器还提供了在多个主题上同时进行交流的功能。 例如，一个用户说：“我想获得保险。” 然后，在没有完成此对话的情况下，他补充说：“我想根据以前附加的保单付款。” 在这种情况下，对话框管理器将保存第一个主题的上下文，并在第二个脚本完成后提供从被中断的位置继续上一个对话框的功能。
可以返回用户已经回答的问题。 为此，系统在收到来自客户端的每个消息后会保存图形的快照。
有哪些选择？
除了我们的方法外，我们还考虑了另一种用于实现对话框管理器的AI方法：将用户的意图和参数馈送到神经网络的输入中，系统本身会生成相应的状态，这是需要询问的下一个问题。 但是，在实践中，此方法需要添加基于规则的方法。 也许此实现选项适用于琐碎的场景-例如，订购食物时，您只需要获取三个参数：用户要订购的商品，何时接收订单以及订购地点。 但是，在复杂的情况下（如我们的主题领域），这仍然是无法实现的。 目前，机器学习技术无法在复杂情况下从质上指导用户达到目标。
对话框管理器是用Python Tornado框架编写的，因为最初我们的AI部分是作为单个服务编写的。 选择了一种语言，可以在不花费任何资源的情况下实现所有这些目的。
“让我们决定。” 识别服务
我们的产品能够通过不同的渠道进行交流，但AI部分完全独立于客户端：这种交流仅以代理文本的形式出现。 对话框管理器将上下文，用户响应和收集的数据传输到识别服务，该服务负责识别用户的意图并检索必要的数据。
如今，识别服务由两个逻辑部分组成：管理识别管道的识别管理器和提取器。
识别经理
识别管理器负责识别语音含义的所有基本阶段：令牌化，词形化等。它还确定将跳过消息的提取器（识别文本中实体和属性的对象）的顺序，并确定何时停止识别并返回完成的结果。 这样，您就可以以最期望的顺序仅运行必要的提取器。
如果我们询问用户名是什么，那么首先检查答案中是否包含该名称是合乎逻辑的。 名称已经来了，没有更多有用的文本了-这意味着可以在此步骤完成识别。 一些其他有用的实体已经出现，这意味着必须继续承认。 该人员最有可能添加了其他一些个人数据-因此，您需要运行提取器来处理个人数据。
取决于上下文，提取器的启动顺序可能会有所不同。 这种方法使我们可以大大减少整个服务的负担。
提取器
如上所述，提取器能够识别文本中的某些实体和属性。 例如，一个提取器识别电话号码； 另一个决定一个人对一个问题的肯定或否定回答； 第三-识别并验证消息中的地址； 第四是有关用户车辆的数据。 通过一组提取器传递消息-这是识别我们传入消息的过程。
对于任何复杂系统的最佳操作，有必要结合各种方法。 在提取器上工作时，我们坚持这一原则。 我将重点介绍我们在提取器中使用的一些工作原理。
将我们的微服务与内部机器学习一起使用（提取程序向该服务发送一条消息，有时为其提供的信息加以补充并返回结果）。
- 使用POS标记，语法分析，语义分析（例如，通过动词确定用户的意图）
- 使用全文搜索（可用于在消息中查找机器的品牌和型号）
- 使用正则表达式和响应模式
- 使用第三方API（例如Google Maps API，SmartyStreets等）
- 逐字搜索句子（如果一个人很快回答“是”，那么将其通过ML算法搜索意图就没有意义）。
- 我们还在提取器中使用现成的自然语言处理解决方案。
有哪些选择？
我们研究了NLTK，Stanford CoreNLP和SpaCy库。 当您开始NLP审查时，NLTK会首先在Google SERP中退出。 对于原型解决方案而言，它非常酷，具有广泛的功能，并且非常简单。 但是它的性能很差。
Stanford CoreNLP有一个严重的缺点：它提取了具有非常大的模块，内置库的Java虚拟机，并消耗了大量资源。 另外，该库的输出很难定制。
结果，我们选择了SpaCy，因为它对我们来说具有足够的功能并且具有最佳的亮度和速度比。 SpaCy库的运行速度比NLTK快几十倍，并且提供了更好的字典。 但是，它比Stanford CoreNLP容易得多。
目前，我们使用spaCy进行标记化，消息向量化（使用内置的经过训练的神经网络），文本中参数的主要识别。 由于该库仅满足我们识别需求的5％，因此我们不得不添加许多功能。
“曾经是……”
识别服务并不总是由两部分组成。 第一个版本最简单：我们轮流使用不同的提取器，试图了解文本中是否有任何参数或意图。 AI甚至都没有闻到-这是一种完全基于规则的方法。 困难在于，可以以多种方式表达相同的意图，每种方式都必须在规则中进行描述。 在这种情况下，有必要考虑上下文，因为根据所提出的问题，相同的用户短语可能需要不同的操作。 例如，在对话中：“您结婚了吗？” -“已经两年了”，您可以理解该用户已结婚（布尔型含义）。 然后从对话“你要开车多久？” -“已经两年”您需要提取值“两年”。
从一开始，我们就知道支持基于规则的解决方案将需要大量的努力，并且随着支持意图的增加，规则的数量将比基于ML的系统更快。 但是，从业务角度来看。 我们需要运行MVP，基于规则的方法使我们能够快速完成此任务。 因此，我们使用了它，并并行地研究了意图识别的ML模型。 一旦出现并开始提供令人满意的结果，他们就逐渐开始放弃基于规则的方法。
对于大多数信息提取情况，我们使用ChatScript。 该技术提供了自己的声明性语言，使您可以编写模板以从自然语言中提取数据。 多亏了WordNet，该解决方案在后台非常强大（例如，您可以在识别模板中指定“颜色”，而WordNet可以识别任何狭窄的概念，例如“红色”）。 当时我们没有看到类似物。 但是，ChatScript编写得非常歪斜且容易出错，使用它几乎不可能实现复杂的逻辑。
最后，弊端被抵消了，我们放弃了ChatScript，转而使用Python中的NLP库。
在“识别服务”的第一个版本中，我们将灵活性发挥到了极致。 每个新功能的引入大大降低了整个系统的速度。
因此，我们决定完全重写Recognition Service，将其分为两个逻辑部分：小型轻巧的提取器和Recognition Manager，后者将管理该过程。
“你想要什么？” 意图分类器
为了使机器人进行充分的通信-根据请求提供必要的信息并记录用户的数据-必须根据发送给他的文本确定用户的意图（意图）。 我们与用户互动的意图清单受到客户业务任务的限制：可能是为了寻找保险条件，填写有关您自己的信息，获得常见问题的答案等等。
基于神经网络，尤其是基于递归LSTM / GRU的意图分类有很多方法。 他们在最近的研究中已经证明了自己，但是它们有一个共同的缺点：为了正常操作需要非常大的样本。 在少量数据上，此类神经网络要么难以训练，要么产生不令人满意的结果。 Facebook的Fast Text框架也是如此（我们对其进行了审查，因为它是用于处理中短短语的最新解决方案）。
我们的培训样本非常高质量：数据集由精通英语并且知道保险领域特定知识的全职语言专家组成。 但是，我们的样本相对较小。 我们试图用公共数据集来稀释它们，但是，除了极少数例外，它们与我们的细节不符。 我们还尝试通过Amazon Mechanical Turk吸引自由职业者，但这种方法也被证明是行不通的：他们发送的数据部分质量较差，必须对样本进行再次检查。
因此，我们正在寻找一种可以在较小样本上运行的解决方案。 随机森林分类器证明了数据处理的良好质量，该分类器接受了将数据转换为我们的词袋模型向量的训练。 使用交叉验证，我们选择了最佳参数。 我们的模型的优点包括速度和大小，以及相对容易的部署和再培训。
在研究意图分类器的过程中，很明显，对于某些任务，它的使用不是最佳的。 假设用户想要更改保险或车号中指示的名称。 为了使分类器正确确定此意图，必须将在这种情况下使用的所有模板短语手动添加到数据集。 我们找到了另一种方法：为Recognition Service制作一个小型提取程序，该提取程序通过关键字和NLP方法确定意图，并为那些使用关键字的方法不起作用的非标准短语使用Intent分类器。
“他们总是问这个。” 常见问题
我们的许多客户都有“常见问题解答”部分。 为了使用户直接从聊天机器人接收此类答案，有必要提供一种解决方案，以解决以下问题：a）识别FAQ请求； b）将在我们的数据库中找到最相关的答案并将其发布。
在Stanford SQUAD数据集上训练了许多模型。 当FAQ中的响应文本包含用户问题中的单词时，它们可以很好地工作。 可以说，常见问题解答说：“弗罗多说他会带环去莫多，尽管他不知道那里的路。” 如果用户问：“ Frodo将把戒指带到哪里？”，系统将回答：“致魔多”。
通常，我们的情况是不同的。 例如，对于两个类似的请求-“我可以付款吗？” 和“我可以在线付款吗？” 机器人必须以不同的方式做出反应：在第一种情况下，给人一种付款方式，在第二种答案中-是的，您可以在线付款，这是页面地址。
用于评估文档相似性的另一类解决方案着眼于长答案-至少几个句子，其中包含用户感兴趣的信息。 不幸的是，在问题和答案简短的情况下（“我如何在线付款？”-“您可以使用贝宝付款”），它们的工作非常不稳定。
另一个解决方案是Doc2vec方法：将大文本提取为向量表示形式，然后将其与相同格式的其他文档进行比较，并揭示相似系数。 这种方法也必须取消：它专注于长篇文章，但我们主要处理一两个句子中的问题和答案。
我们的决定基于两个步骤。 第一：使用嵌入，我们使用Google Word2vec模型将句子中的每个单词转换为向量。
之后，我们考虑所有单词的平均向量，以一个向量的形式表示一个句子。第二步，我们获取问题的向量，并在FAQ数据库中找到它，并以相同的向量形式存储，在某种程度上（在我们的情况下为余弦），是最接近的答案。优点包括易于实现，非常容易的可扩展性和相当简单的可解释性。缺点是优化机会有限：此模型很难修改-在大多数用户情况下效果很好，或者您不得不放弃它。“说吧？” 闲聊
有时用户写的东西完全不相关，例如：“今天天气很好。” 这不包括在我们感兴趣的意图列表中，但是我们仍然希望进行有意义的回答，以证明我们系统的智能。对于此类决策，可以使用上述方法的组合：它们基于非常简单的基于规则的解决方案或生成神经网络。我们希望尽早获得原型，因此我们从Internet上获取了一个公共数据集，并使用了一种与FAQ中非常相似的方法。例如，用户写了一些有关天气的信息-并使用将两个句子的矢量表示与某个余弦量度进行比较的算法，我们在公共数据集中寻找一个尽可能接近天气主题的句子。培训课程
现在我们没有一个目标，那就是要创建一个可以对从客户收到的每条消息进行培训的机器人：首先，正如经验所示，这是机器人死亡的方法（请记住，IBM Watson 必须删除底座，因为它开始使用垫子进行诊断微软的Twitter机器人在一天之内就成为了种族主义者。其次，我们努力在质量上完成保险公司的任务。自学机器人不是我们的业务任务。我们已经为语言学家和QA命令编写了许多工具，通过这些工具，他们可以在后期审核期间通过探索对话和与用户的通信来手动重新训练机器人。尽管如此，我们的机器人似乎已经准备好通过图灵测试。一些用户开始与他进行认真的交谈，认为他们正在与保险代理人交谈，甚至有人在机器人误解了他的情况下开始威胁老板。计划
现在，我们在视觉部分进行工作：显示脚本的整个图形以及使用GUI编写脚本的能力。在识别服务方面，我们正在引入语言分析以识别和理解消息中每个单词的含义。这将提高反应的准确性并提取其他数据。例如，如果某人填写了汽车保险并提到自己的房屋没有保险，则机器人将能够记住该消息并将其传递给操作员以联系客户并提供房屋保险。工作中的另一个功能是反馈处理。与机器人的对话结束后，我们询问用户是否喜欢该服务。如果Sentiment Analysis认为用户的评论是正面的，则我们邀请用户在社交网络上分享他们的观点。如果分析表明用户做出了负面反应，则该机器人会澄清问题所在，并给出答案，然后说：“好，我们将解决问题”，并且不愿意在信息流中分享评论。与机器人进行尽可能自然的通信的关键之一是使机器人模块化，并扩大其可用的反应范围。我们正在努力。也许由于这个原因，用户已经准备好真诚地将我们的机器人作为保险代理。下一步：确保该人正在尝试感谢该机器人。
本文由Sergei Kondratyuk和Mikhail Kazakov撰写。在评论中写下您的问题，我们将为您准备更多实用的材料。