Get best of the week

正如我们所做的那样，下一个聊天机器人的设计师。第1部分



嗨哈布罗米尔！去年，我和团队花了很多钱来创建我们的初创公司Botlify Chatbot Constructor for Business，我想与观众分享该项目的简短历史和所做出的技术决策。在这篇文章中，尽管我在这个项目中我的角色与开发和技术的联系要少得多，但我将尝试尽可能地将精力集中在技术细节上，而较少地深入产品和业务。这些材料基于我的个人经验，我不是初学者，也不假装自己是一名优秀的程序员，经理，架构师或企业家。我们是一个相对年轻的初创企业，用户很少，因此大型项目的工作量和问题将一无所获。在削减的基础上，我将告诉您我的项目是如何开始的，我们所进行的开发工作是什么，我们得出了哪些结论。

我叫安德烈（Andrey），有一段时间，我主要是在PHP中担任开发人员，然后是团队负责人，然后在几家小型初创公司担任技术总监，在那里我爱上了NodeJS。但是碰巧的是，最近我更可能是一位企业家。这不是我创办的第一家创业公司，更不是我参与的第一家创业公司。我碰巧在几个成功的项目中工作，但失败很多。我自己创建了更多失败的项目。每次，失败的原因以及失败的阶段都是完全不同的，但是我以某种方式在这个项目中运用了这种经验。

目标


在开始有关该项目的故事之前，我想谈一谈我们从一开始就追求的目标，开始这次冒险。实际上，我们的设计师最初是一个宠物项目，用于学习产品管理，客户开发的基础知识，获得新的管理技能和创业经验。我听到并尝试过很多次以应用LEAN Startup方法，每次结果都完全不同。当然，我们梦想着以此为基础开展业务并赚取丰厚的利润，但是我们并没有幻想这是一种简单而短暂的方式。甚至更多，我们没有尝试制作某种WOW！-创新。我的共同创始人和我一直在全职工作，我们知道我们将不能花很多时间。主要的动机恰恰是机会，使他们能够完全掌握IT行业的新领域并在实践中应用新知识，同时还能赚钱。


作为一名程序员，我真的很喜欢绘制类图，序列，流程图。对我来说，可视化过程本身就是理解问题和解决方案的一个阶段，它使我可以大致了解正在发生的事情。在进行下一个项目时，我再次面临需要在站点上插入带有在线聊天的小部件，并查看该领域中现成的解决方案的需求。因此，在我寻找的东西中，我遇到了多个平台，这些平台不仅允许为站点创建带有在线聊天的小部件，而且还允许在其中嵌入聊天机器人。我和其中一个机器人聊天，他给我留下了很好的印象。然后，我开始尝试提出对我的项目有用的不同聊天机器人脚本。幻想刚倒在桌子上：与美甲沙龙约会，帮助在在线商店中进行选择，在文档中指出正确的位置，接受对支持服务的请求。我只是没想到。

然后，我爬上去看看各种设计师，几乎所有人都愿意给我填写表格，然后填写表格，然后再次填写表格。通常，通过填写表单来创建机器人。结果，这给我带来了极大的不便，我不断丢失正在发生的情况的上下文，我不得不返回到先前的步骤来恢复上下文，并且没有通过逻辑和设计脚本进行便捷思考的问题。好吧，我想，我将首先尝试在外部工具中“设计”我的机器人，然后将其转移到所需的平台上。

在这里，我遇到了第一个问题：如何以一种清晰的方式描述与机器人的对话，以及机器人为什么做出响应，同时又将整个动作序列摆在面前？最初，我尝试使用xmind和其他工具创建思维导图。原来是这样的。

思维导图聊天机器人示例

后来很明显，聊天机器人作为一个整体非常适合描述状态和它们之间的状态的概念，事实证明，即使在对话分支很多的地方，在对话分支中导航也非常方便。

发现只有少数竞争对手提供了视觉机器人设计师。对于某些人来说，它更直观，对于更少的人来说，但总的来说，这样的构造函数对我来说似乎更加友好。尝试做类似的事情对我们来说变得很有趣，我们想要创建一个工具，您可以使用它无需编程技能就能创建聊天机器人，只需以图表的形式对其进行描述即可。当然，仍然需要一些技术技能，但是创建思维导图并不困难。

机器人是一个相当复杂而又庞大的话题，我们的资源非常有限。因此，对我们来说至关重要的是，尽可能简化决策，以便它能够看到市场。“ 越快越好 ”-在初创企业的背景下，我不会厌倦重复这一口头禅。

人工智能和机器学习


聊天机器人中有关人工智能的问题仍然对我开放。但是现在，我们从一个早期创业公司开始，我们团队中没有AI和ML的能力，我们已经同意，我们只想绘制图表而不准备数据集，训练神经网络，仅此而已。目前，我们不在机器人中使用人工智能和机器学习。也许有一天，将来会有钱。

重要的是要理解，相同的机器人在本质上可以有很大不同。粗略地说，可能有一个机器人写着：“ 您在做什么？ ”，并希望用户本着以下精神任意响应：“ 了解罗宋汤 ”，“ 我要订购罗宋汤 ”，“现在几点了？“。收到答案后，机器人会尝试识别答案，确定意图并为对话的发展选择合适的分支。不用说，给定错别字，各种形式和表达方式，这可能会很昂贵。

另一方面，当涉及到错误时，我们可以使用封闭式问题例如，选择一个机器人可以写：“ 您愿意做什么？ “并提供选项：“ 了解罗宋汤 ”，“ 订购罗宋汤 ”，“ 找出时间”“一方面，用户失去了行动自由，但另一方面，我们不仅大大简化了计算，而且可以通过向正确的方向转向对话上下文来更轻松地管理对话上下文。我们更喜欢在收集用户文本数据的上下文中使用开放式问题：输入电子邮件，打电话，写下您的问题以支持等等。

聊天机器人vs男人


反对让用户以自由形式与bot通信的另一个论点是，认为聊天bot不应在一个人中“玩”。我认为，与机器人进行通信时，一个人应该清楚地了解与机器人进行通信的内容，知道它具有哪些机会以及如何利用它们。而且，如果一个人知道他正在与机器人进行通讯-自由文本通讯的意义何在？当聊天机器人成为一个人的助手，而不是代替它并且不畏惧它时，情况会好得多，并且该人清楚地知道他与聊天机器人进行通信以及它的功能是什么。在这种情况下，交流变得更加有效。

处理


我是udalenki的粉丝。不要喂我面包，让我组成一个远程团队并开始使用它。我对自己在远程工作感到很舒服，我知道如何组织工作并找到可以独立高效地工作的人。我完全理解这并不适合所有人，我完全同意这一点，但是我认为在光明的未来，将会有越来越多的udalenki。只是经济学不是私人的。由于这是我的项目，因此我为其订购了音乐-这里也是一个遥远的项目，因此留下了一定的烙印。

在任何项目的开始工作时，我都认为尽可能使我的想法形式化非常重要。尽管该想法尚未在纸上找到其形式，但没有文字，注释，绘图的形式，根本不存在任何想法。同时，团队中的所有流程应尽可能简单，自然和快速，并且沟通有效。如果整个团队都是您和您的朋友，则不应使用大型笨重的工具来管理您的团队，例如Jira或Redmine。但是也不要使用任何东西，否则一切都会很快失去控制，并且会出现混乱，遏制这比简单地不允许这样做要困难得多。即使是一个人的脑袋，也可以根据项目形成这样一个混乱的局面，即使只有2-3人，我也不想告诉您关于团队的看法。

我们像真正的初创公司一样，使用Trello来组织任务和存储项目的重要链接，并且想法也被扔在那里。对于商业文档，可以通过markdown很好地创建Google Docs（技术文档），并将其放入相应的存储库中。全天交流- 电报，以及日常站立Google Hangouts。每日站起来是远程团队存在的基石之一。如果不存在，就没有团队，有人必然会开始感到孤独，疲倦，误解和不满，这不仅会控制局势，还会失去团队关系。

从发展过程的角度来看，美国也不必被发现。我们确定冲刺的长度，根据启动目标计划冲刺。我们困惑并开始做香肠。一个新的挑战是您喜欢的版本控制系统中的新分支。你好了吗？我们发出请求请求，请等到有人审查。审查进行了吗？ CI工作正常吗？好了，您可以将所有内容保存在开发分支中，等待开发程序集获得批准并更新测试服务器。我们存储在GitHub上的代码。在第一个付费客户之前，这些都是公开开放的存储库。作为过去尝试推广几种开放源代码解决方案的人，每当一家初创公司在开始赚钱之前就其代码的安全性而开始动摇，我都会感到由衷的愤慨。如果您尝试复制-这显然是商业上的成功。以后关闭存储库无需花费任何费用。众所周知，业务通常是远离代码的。我可以使用许多代码，包括非常成功的产品，但是值得一提的是，拥有它们我将不会再重复他们的成功吗？为了构建Docker容器并运行自动测试，我们决定尝试GitHub Actions，幸运的是，它们提供了初步的访问权限。总的来说，印象仍然相当令人满意，装配速度令人满意。唯一不愉快的是更新，并且失去了与以前版本的兼容性。有几次，他们非常认真地更改了动作描述方案，不得不重新配置所有内容。但是，当我们同意试用现有产品时，我们就知道自己在做什么Beta版。

从头开始，从字面上看，从开发用于需求测试的登录页面开始，我们试图每周至少发布一次发行版，并测试至少一个假设。最初，这些假设更具全局性，我们试图发现各种问题，定位目标受众并提出建议。但是产品开发得越远，它们变得越没有全球化，并且本质本身就不太可能改变。该项目从头开始，具有通常的登录页面，然后在膝盖处创建了聊天机器人的演示客户端，该客户端仍挂在我们的主页上。该演示可以重现严格编程的对话，并向我们演示了可以对我们的构造函数执行的操作-他工作的结果，而不是构造函数本身。诀窍是我们认为机器人设计师不会从事这项业务，但对于某些结果，他将给予优势。我们想向客户倒一杯我们的咖啡机生产的咖啡，而不是展示咖啡机本身。很容易猜到煮一杯咖啡比收集咖啡机更快更便宜。在这一原则的指导下，我们决定首先进行客户演示，特别是因为有了许多现成的工具，我们花了不超过两个晚上的时间，包括开发对话方案。

当我们看到着陆者的兴趣和演示所产生的额外转化时，我们决定走的更远。我记得我们的构造函数的第一个版本是带有登录表单的注册表单，此后，用户被带一个歉意的页面带到一个页面，并答应告知其他操作何时可行。我一生中进行了数百次登录和注册，我什至无法想到在这里我们会立即发现很多问题。大约60％的第一批用户根本无法完成注册过程。该按钮对谁不起作用，对谁不发电子邮件，对谁有用。起初，我非常怀疑地想到了只发布几种形式的想法，但是乍一看Yandex.Metrica明确表明这是正确的决定。用户意识到自己的行为方式与您期望的有所不同，有时甚至以您认为自己无法做到的方式，对我们接下来所做的一切都产生了重大影响。作为一种业余爱好，我每周在网络浏览器中花几个小时几个小时，只是观察用户如何使用我们的手工艺品。

因此，我们一点一点地增加了功能，使我们的产品不仅对我们而且对我们的用户仍然有价值，其中一些甚至为我们带来了收益。从长远来看，我们不了解我们想要实现的目标，产品的外观。那时我们唯一了解的是我们什么都不了解，处于不确定状态。

结果


这个实验使我和我的团队从MVP建立的朋友，家人，傻瓜类别中进行了天使般的投资，第一笔销售，丰富的经验，许多欢乐和失望。我们还不是真正的企业，但我们努力成为一体。当我这样说时，我的意思是我们仍在寻找可持续的商业模式和产品市场契合度。我们再次计划寻找合适的产品概念，我们的客户，我们的市场。

最初的目标并没有完全实现，但该项目从家庭兴趣发展为全职工作，并向投资者，用户和员工显现了责任。当然，该项目在概念和技术上都存在很多问题，但是没有什么不能解决的，我们计划继续开展工作。

在开始我的作品的更多技术性部分之前，可能有必要简要介绍一下该产品允许您做什么。

  • 管理您帐户中的聊天机器人
  • 可视聊天机器人编辑器
  • 控制对聊天机器人的访问（编辑访问，公共访问）
  • 能够在网络上发布聊天机器人（小工具，嵌入式，全屏）
  • Chatbot设置（设计，名称，指标，小部件位置等）
  • 支持通过GET和POST请求将聊天机器人与外部服务集成
  • 机器人对话分析
  • 帐户管理
  • 订阅模型，订阅管理


建筑


现在，在了解了指导我们进行开发的背景，目标，思想和原则之后，我可以开始对这一切的工作原理进行一般性描述。由于我们最初的选择是为站点和全屏聊天机器人创建聊天机器人，例如app.botlify.io/bot/5de53dbf9b9bae002b319600，因此很明显，大部分工作都在前端。结果，客户机上的工作前端形成了有意义的任务列表和愿望清单：

  1. 创建/查找客户端库，这是一种浏览器中的聊天机器人的“引擎”，该浏览器理解接收到的json指令并与用户保持对话。
  2. 创建一个用于编辑bot节点的应用程序，该应用程序会将节点列表和它们之间的链接保存在某个json对象中（客户端库将在此基础上进行对话框）。
  3. , , , - . , , , . , , , ..
  4. , , . id , :

    <script defer src="https://app.botlify.io/botlify.min.js"
    onload="Botlify({ bot: '5de53dbf9b9bae002b319600', type: 'widget'})"
</script>
  5. , , ( )

前端处理从创建聊天机器人（节点和连接）到在Web客户端中直接使用它们的对话框的整个逻辑。后端的作用更多是关于管理访问，订阅，新闻通讯，通知以及存储从许多Web客户端传输的数据。

前端


对于前面，我们使用Reactjs。我们将所有内容打包在Docker中（我们将其构建并推送到nginx容器中），这是Github上私有存储库中的代码，对于CI，我们使用Github Actions。我们使用简单的bash脚本在普通VPS服务器上启动容器。为了简化UI的开发，使用了Blueprint。

  • Web — javascript , - . json -, . -(, , , , , .).
  • Web — javascript . id , , Web- .
  • — , . json, -. , «» , — -.
  • 用户帐户-用于管理您的帐户，订阅和漫游器的Web应用程序。
  • 管理面板是面向管理员的Web应用程序。通过分析管理用户，机器人，订阅，仪表板。


下图显示了前端的组件以及它们之间的交互方式。Webclient和bot编辑器仅在其他应用程序的上下文中使用，而如果编辑器仅在我们的应用程序中使用，则Web客户端也可以被我们的客户端用作Web模块。生成项目时，带有Webclient和Editor的软件包将添加到Dashboard和Admin应用程序中。此外，Web模块是使用Webpack构建的，以交付给用户。



MVP 1. Web客户端


作为一家初创企业，我们始终努力以最少的资源获得最大的收益。在我看来，第一个MVP的一个相当合乎逻辑的步骤是从代表“产品面”的角度创建一个Web客户端，这表明设计师的工作成果，而不是创建机器人的过程-一杯咖啡，而不是一台咖啡机。为了最大程度地缩短解决方案的开发时间，我们决定寻找适合我们要求的库，然后突然发现了！lucasbassetti.com.br/react-simple-chatbot是一个反应组件，几乎满足了我们的所有需求！

该组件建议以一系列步骤的形式描述聊天机器人逻辑，读取用户输入的值，自定义外观，验证数据，并且看起来足够灵活。最简单的步骤说明如下所示：

<ChatBot
      steps={[
        {
          id: '1',
          message: 'What is your name?',
          trigger: '2',
        },
        {
          id: '2',
          user: true,
          trigger: '3',
        },
        {
          id: '3',
          message: 'Hi {previousValue}, nice to meet you!',
          end: true,
        },
      ]}
    />

我们首先尝试以这种方式组成一个聊天机器人来介绍我们的项目，其思维导图显示在本文开头。当然，手动描述这样的json确实很不方便，我不得不编写许多自定义函数，但是总的来说，此过程使您可以了解组件的工作原理，以及如何使用该组件实现所需的结果。

此外，我的同事定制了外观，提供了几种显示选项，我们以理发店和梵高展览为例。您可能甚至注意到我们甚至都没有考虑图像优化。是的，这是必须的，而且不是必须的。在工作过程中，我们对客户的工作方式形成了大致的了解，并且我们开始为设计师自己寻找解决方案，以便尽快利用可视化编辑的优势。

MVP 2.构造函数


根据与客户合作时所看到的内容，我们得出了一个普遍的结论，即该机器人可以具有多种类型的动作：发送内容，等待用户动作，向外部服务发送请求。对于最低限度的机器人编辑器，我们决定将自己限制在以下范围内：

  • 开始-开始新会话的技术部门
  • 结束-结束会话
  • 消息-到达代码块后，机器人会发送在代码块主体中指定的消息
  • — . ,

假定这些块将通过箭头或线条互连。除“启动”块外，所有块均具有一个输入端口（插座）。许多线路可以连接到输入端口，从而将本机与其他端口相连。除结束块外，所有块均具有一个到几个输出端口。输出端口确定当前块的逻辑完成后将控制权转移到哪个块。

在对可用解决方案进行简短检查之后，我们选择了Rete.js（https://rete.js.org）。我熟悉了文档和示例，并在其中找到了我们开始所需的一切。他们甚至使用聊天机器人举了一个例子，这是最后一个触发条件

Rete . . , — , JSON


Rete.js中的节点

所有节点都可以包含名称，输入，输出和控件。输入和输出应分别位于节点的左侧和右侧（对于自定义节点，可能会有例外）。它们由套接字表示，并且可能具有名称。对于输入，我们允许无限数量的连接（您可以通过多种方式到达节点），对于输出，我们将自己限制为仅一个连接，但是，与输入套接字不同，某些块具有许多输出套接字。

Rete.js的构建方式是通过创建自定义节点，控件，组件来扩展其功能，这使我们能够快速准确地获得我们想要看到的图片，为此我感谢Rete的创建者！当然，最重要的一个是现成的编辑器！

如写说明文件：
编辑器是一个在其套接字之间具有节点和连接的区域。提供以下选项：

  • 与工作空间的交互（移动，缩放）和节点管理（移动，添加，删除）
  • 显示连接，节点，其输入/输出和控件
  • 处理编辑器事件
  • 导入/导出JSON格式的架构
  • 使用插件扩展功能
  • 自定义工作空间，节点和连接


在与Rete融合在一起并研究了更详细的示例之后，我们设法构建了一些东西，使我们能够创建和删除“开始”，“结束”，“消息”，“键盘输入”块。在输出中，我们收到了带有节点，套接字和连接它们的行的描述的json。

编辑器的第一个版本

已经存在，但这还不够，因为我们的Web客户端不了解此json。他需要自己的某种东西，并带有步骤的描述。决定在客户端中嵌入从一种json格式到另一种json格式的转换器。

杰森变压器


该实用程序接收由编辑器编译的NodesMap作为输入，并返回客户端可以理解的StepsMap。整个转换器的代码大约需要100行，具体取决于节点和数据的类型，一个合适的步骤，触发功能以及在其中创建要在该步骤中执行的一组指令（动作）的过程。有些指令将变量保存为chatbot状态，有些指令替代了文本中的变量，或者向我们的服务器发送了请求。

将组件捆绑在一起后，我们开始测试最终的工具。即使没有后端，也非常令人兴奋。我们在编辑器中建立了对话框，并通过开发工具将json插入客户端，结果得到了一个机器人，该机器人说出了我们的需求！他还知道如何保存变量并使用它们，该死！最初的胜利给我们带来了巨大的轰动。在我的脑海中，实际上已经形成了我们应用程序设备的镶嵌图，我们在将来想要使用的原理上有所发展。我们有了一个确定的骨架，可以围绕它构筑“肉”。最重要的是-清楚如何做到这一点：

  1. 更改编辑器，添加所需的节点类型
  2. 我们教json转换器将新节点转换为新步骤
  3. 我们教会客户迈出新的一步

另一方面，有必要开始使用用户的个人帐户，以便可以创建机器人，保存它们，进行管理，我们决定专心于此，以便快速向用户展示概念而非产品。

用户帐号


上述库执行了与聊天机器人逻辑（编辑器）的创建，其解释或复制（客户端）有关的某些功能。数据存储，加载已创建的机器人，管理它们以及设置与逻辑无关的属性的能力仍然存在问题，应用程序应该为用户解决了这些问题。借助blueprintJS，我们绘制了一个个人帐户的原型，可以在其中注册和创建多个机器人。当您单击该机器人以创建一个人时，必须使用一个新的机器人进入编辑器，而当您单击该机器人的编辑器中的该机器人卡时。我们决定将通过后端API加载和保存bot的功能委托给该层，以使bot编辑器独立于后端。



用户帐户的应用程序能够下载编辑器程序包，并传输准备显示的数据。此应用程序还管理用于设置漫游器属性（名称，API键，头像，发布设置）的表单，并允许您查看统计信息。为了让用户立即看到编辑器的结果，我们在用户办公室添加了一个Web客户端，并为其提供了json bot方案，他逐步解释该方案并在“预览”选项卡上播放。总的来说，这是一个非常经典的管理面板，其中包含几个有趣的组件（机器人编辑器和Web客户端），我想很多人都做过。但是正是在这个阶段，开发我们的应用程序变得很不方便。

最初，在我们看来，将产品组件包含在不同的存储库中似乎是一个好主意，但是我们没有发现任何特殊的问题。但是，很快就很清楚，使许多存储库保持最新是有问题的，更不用说在开发时需要与铃鼓跳舞了，因为它们在某种程度上是相互依赖的。鉴于我们只有一名全职开发人员，因此这种方法非常麻烦。由于库，应用程序的组装和发布，向后兼容性问题的差异，任何部署都变成了地狱的分支。因此，这是一个平庸但并非最无用的结论：模块的过早分配弊大于利我已经在后端多次相信了这一点，而我又来到了这里，但在最前面。是的，而且我在后端没有错过任何机会：=）

我的一位同事将自己的意志扎成拳头，将所有内容组合到一个由lerna管理的单一存储库中。现在，我们唯一的前端存储库分为以下软件包：管理员，客户端，通用，仪表板，编辑器，Web模块。它们内部可能具有不同的程序集，但是lerna允许它们链接在一起并更新程序包之间的依赖关系。之后，前端的开发和部署变得更快，更容易，一切都在眼前，但仍然存在分歧。 创建橱柜后，我们花了一些时间在编辑器中的新块上以及客户端对它们的处理：



  • — . ( ),
  • — -
  • Email — email

关于管理面板和网络模块，我没有太多要说的，那里的一切都很标准。请注意，管理面板也不应该提前完成。我们拥有它，但是没有人使用它，因为就我个人而言，立即在数据库中看到我感兴趣的所有内容并不困难。团队中没有任何人文需要我们的管理面板，并且保持最新状态实质上比维护用户帐户要少一些。随着时间的流逝，在那里添加了一个简单的仪表板，以显示付款，新注册和该应用程序的访问，但是对于整个管理员来说，这些信息几乎不值得开发。带有表格，表格和单独身份验证的面板

结果呢？


我们能够非常快速地构建原型和登录页面。是的，这根本不是许多人以MVP为幌子想象的。但是，在这个想法产生后的仅仅两个晚上，我们就可以开始向人们展示它并进行测试。机器人中的不同目标网页，广告，文字-我们可以进行测试和搜索。我强烈建议任何参与启动开发的人员考虑如何尽快完成工作。我们制作了第一个在大约三个月内实现增值的产品，然后开始逐步进行定期改进。当然，现在构造函数中有更多的块，我们添加了验证，数据类型，GET和POST请求，许多任何设计和显示设置，但是您可以不做所有这些而开始。

随着时间的流逝，该系统开始变得越来越复杂并不断发展，我什至无法精确描述实际发生的一切。从小处开始，必要时事情会随着时间而复杂化。任何额外的组件都可能导致很高的成本，因为不仅需要创建和集成，而且还需要对其进行支持，测试，记录，部署，监视和介绍其他团队成员。也许您不应该在RabbitMQ上打扰队列，如果在那之前您的应用程序中没有队列。最有可能的是，基于已经存在的技术的解决方案将足以开始。任何新组件都是集成，操作，测试，支持，文档，部署等的额外费用。

我希望我的经验至少对某人有用。很长一段时间，我试图找出哪个枢纽来确定这一点，但是我不明白。让我知道是否值得写第二部分，在该部分中我想谈一谈后端，外部服务和开发计划

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles