爱丽丝的B2B技能：从原型到第一卢布都被保存了

不久前，在圣彼得堡举行了第二次对话会议，专门讨论对话式人工智能，我很幸运能作为演讲者发言。 主题是为一家大型公司开发原型B2B技能。 该报告描述了他们如何通过相对较慢的Web服务和公司封闭的基础架构来“结交朋友”。 这将在削减下进行讨论。

如果突然之间您不知道爱丽丝的技能是什么，请看一下扰流板：它简短地描述了什么。

主意

这一切是怎么开始的？ 在2018年3月13日， 他们宣布了Yandex.Dialogs平台的Beta测试（Alice的技能）。 那时，许多人已经对虚拟助手感兴趣，这意味着这是与相当大的受众合作的绝佳机会。 一个聊天机器人的想法已经在我脑海中旋转了很长时间，所以我认为在业余时间的基础上增加一些技巧很有趣。 而且，如果他也能在工作中带来收益，那将是非常出色的。

我们公司在商务旅游领域提供全方位的服务，这意味着您可以掌握帮助用户进行商务旅行的技能。
然后，我在团队中开发了一个移动应用程序，通过该应用程序，您可以找到商务旅行的航班选择和旅馆，并安排合适的旅馆。 我们努力增加的关键指标之一是下载数量。 提出的想法是，如果该技能可以将用户引向应用程序，那么它将帮助我们增加这些指标。 这对于使用此项目进行验证是必要的。

为了使一项技能对任何人都有用，它必须解决用户的特定任务。 在这种情况下，搜索商务旅行的选项。 也就是说，该技能必须收集有关去向的信息，并在移动应用程序中显示结果。 因此，用户将使用有趣的语音交互来接收所需的选项，并继续在我们的应用程序中工作，这意味着开发人员将获得所需的性能提升。

事实证明，这项技能应该像这样工作：向用户打招呼；向用户打招呼。 通过名字找到他； 提出澄清的问题，从而获得必要的旅行参数：城市（从何处和何处）和日期。 接下来显示识别的参数。 如果一切正确，请开始搜索，然后提供指向该应用程序的链接。

资源和局限性

要完成其任务，该技能需要与我们的内部API交互，并且其Web服务需要在某个地方发布。 一方面，它可以工作，但是，正如已经提到的，开发是在空闲时间进行的，因此，我不想依赖任何专门分配的公司资源。 因此，您必须利用默认情况下可用的功能。

例如，测试服务器。 开发人员具有在其上部署Web应用程序的足够权限，但是由于服务器不突出，因此只能在公司的内部网络上使用。 同时，他可以访问Internet，这意味着可以使用它。

技能Web服务必须可以从外部访问（以便Alice可以在哪里发送请求），因此必须将其放置在外部主机上。

为了使技能能够完成其任务，您需要一个公司Web服务，该服务可以搜索配置文件和城市，并且可以从外部进行访问。 尽管移动应用程序API有其自身的细微差别，但它适用于此。 它们的事实是，您只能代表一个特定用户连接到API，这意味着可用于搜索的配置文件范围将受到限制。 最令人不快的是-通过API启动的搜索结果只会显示给该用户。 但是，它具有必需的功能，这意味着您可以使用它。

因此，外部托管技术将与API交互。 它当然是相当快的，但是根据测试结果，有时答案没有时间在要求的1500毫秒内到达（这是Yandex.Dialogs平台的要求）。 为了仍然将结果发送给正确的用户，您必须代表他运行搜索服务，该服务仅在内部网络上可用。 不幸的是，API对此无济于事，这意味着您需要以某种方式将请求从技能直接转移到内部基础结构。
这些问题将在可用时予以解决。

阶段 问题与解决方案

首先，为了总体上实现所描述的场景，该技能需要将状态存储在某个位置：阶段，用户名，城市和日期。 信息不多，所以您不应该为其部署整个数据库，尤其是因为它太麻烦了。 您可以将状态存储在缓存中。

选择权落在Redis身上。 他在响应测试中表现出色，我们在工作中也将其紧密使用，这意味着如果成功，该项目可以轻松地转移到公司（和破坏者-我们将其转移了）。 作为密钥，您可以使用技能中的用户标识符（在请求中指示），并将状态数据以JSON格式存储在值中。 Redis的免费副本可以在Heroku上部署，并且一段时间以来， Yandex.Cloud支持它 。

现在，我们将更详细地分析技能的各个阶段。 刚开始时，用户会看到通常的欢迎词。 接下来，他必须命名自己的名字，然后该技能将根据该名字查找个人资料。



如果存在，则应将其名称写入状态，并且由于使用了高速缓存，因此可以将有关概要文件的其余必要信息放入其中。 现在，当客户恢复技能时，他会看到个人问候。 如果同一个人从另一台设备登录并命名自己的名字，则还将在缓存中找到其个人资料，这意味着避免重复搜索API，从而节省了处理请求的时间。

接下来，接收跳闸参数。 作为语音技能的使用者，我想按自己的名字命名城市和日期，例如“彼得”和“一周内”。 该技能必须能够识别此类短语，以便在API中转移城市的全名并在所需的日期执行搜索。 现在，技能网络服务将立即在请求中直接接收此信息：



但是这样的功能大约在2018年10月出现 ，并且该技能是在较早之前开发的，因此选择Dialogflow来理解自然语言。 它具有出色的标记系统，您可以不时地进行培训，以指示用户在给定短语中的含义。

因此，客户端以自己的方式命名城市和日期，该技能将其单词传递给Dialogflow，然后将识别出的城市名称发送给API，并从中接收必要的标识符。 链很长，因此很可能又不能满足要求的1500 ms。

显而易见的解决方案是缓存。 作为关键字，您可以准确指定用户说的内容，并在值中存储我们系统中的城市标识符。 然后，在缓存中可能有一个城市的多个条目，例如，单词“ Peter”和“ St. Petersburg”。 但是，如果该值不表示太多信息，则这不是至关重要的。 无论如何，这种方法都可以用其他用户请求的热门城市填充缓存，或者提前“预热”。 这样一来，您以后就可以减少使用Dialogflow和API的频率，这又可以节省时间。

最有趣的步骤是开始搜索。 有所有必要的参数，但是为了使结果正确的人，您必须以某种方式“拉”内部搜索服务。 另外，搜索本身需要相当长的时间，因此最好不要在同一Web服务中而是在单独的应用程序中执行长期操作。

现在该使用公司的可用服务器了。 您可以在其上部署一个应用程序，该应用程序将以某种方式从外部“获取”信息并执行长期任务，包括开始搜索。

这样的应用程序很可能是后台服务。

从名称可以明显看出，这是一个没有UI的应用程序，应与启动服务器一起开始其工作，并执行计划的操作或对特定命令（消息）的操作。 我们通常在Topshelf框架上组织这样的服务，并且它可以从基于AMQP协议的消息队列中接收命令。

简而言之，队列的工作原理是这样的：有一个代理，发件人在其中添加某种类型的消息。 并且有些读者可以连接到代理并获取必要的信息。
例如，可以在本文中找到更详细的描述。

在Internet上发现了一个很好的云解决方案，它提供了消息队列即服务-CloudAMQP 。 他有免费关税，但运作稳定。 他选择的另一个论点是，该服务基于RabbitMQ进行工作，我们也在工作中大量使用了RabbitMQ 。

因此，让我们看一下整个技能的工作：技能Web服务与移动应用程序的API和Dialogflow交互。 调用它们的结果存储在Redis中，并将状态存储在其中。 在确认行程的参数后，该技能会向经纪人发送一条消息，其中包含所有必要的信息。 测试服务器上的后台服务连接到它，并在出现消息时开始搜索，并将结果发送到移动应用程序。


当客户端下载并安装时，它将在其请求中找到它们：



这样就完成了这项技能的工作。

总结

接下来发生了什么？ 向数位客户展示了此技能，以征询他们的反馈，这就是我们发现的内容：用户本身都不愿意切换到移动应用程序，无论它多么酷。 他们中的一些人可以更轻松地通过电话给我们的代理商打电话，让他​​寻找所需的东西。

如实践所示，在这种特定情况下，用户对与语音助手进行交互更感兴趣。 在这种情况下，他替换了代理，从而节省了一些时间，同时激励客户下载该应用程序，以便继续使用其中的选项。

事实证明，由于这项技能，可以节省某些资源并增加一些关键指标，也就是说，可以肯定该技能对我们公司的好处。

我想强调一些结论。 显而易见：要跟上1500毫秒，避免对Web服务进行不必要的请求缓存。 您可以将不同的缓存键用于相同的信息。 如果至少一个人进入了另一个用户生成的缓存，这是合理的。 最重要的是：最好在单独的后台服务中执行冗长的操作：除了分散技能外，多线程问题也更少，如有必要，可以“部署”在公司的封闭网络内部，并从外部“拾取”消息。

而不是结尾

聊天机器人和技能通常是用JavaScript和Python编写的（根据GitHub上“聊天机器人”的存储库数量来判断）。 这也是由于服务器上的发布容易。 该项目是用C＃在.net内核下编写的。 对于经典的.net框架，发布存在某些困难（它主要在Windows等环境下工作），但是随着.net核心的出现，它已经发生了许多变化。 对于上述每个服务或框架，都有一些库完全支持该技术。 因此，该技能可以在Linux服务器上运行，甚至可以在支持Docker的任何主机上运行。 如果您突然开始进行创造性的搜索，我建议您注意这个框架，它成为开发聊天机器人的不错选择。

聚苯乙烯
UPD 08/01/2019：从现在开始，技能的超时时间为3秒 。