Botpress 2022 年 Dialogflow ES 与 Dialogflow CX 的对比 [第一部分］

比较 Dialogflow 和Botpress既令人生畏又浪费时间。这两个聊天机器人生态系统都有无数的功能和不同的工作方式，即使是业内人士也很难进行正面比较。如果你要为下一个项目在两者之间做出选择，只有一个真正的因素会根据你的要求迫使你做出这样或那样的选择（Botpress 不是 SaaS，而 Dialogflow 是托管的）。在大多数情况下，你会发现这两种选择都是合法的，但你可能会发现自己的偏好。

为了帮助您了解使用 Dialogflow 或Botpress 构建机器人的情况，我列出了一些要点，并截取了一些截图，以便您能直观地看到实际差异。我的重点是：平台的一般易用性、入职和与新团队成员合作、执行常见操作和大规模管理。

需要注意的是，在某种程度上，当您选择 Dialogflow 时，您实际上是在投资 GoogleCloud Platform，因此我将 Dialogflow ES（精华）和 CX（客户体验）归为一类。另外，为了公平起见，我将与Botpress Enterprise 进行比较，以确保比较的是付费解决方案。

TLDR

对于纯粹的常见问题式机器人，Dialogflow ES 可以胜任！要完全控制能力和数据，您需要访问Botpress Enterprise 并自行托管。除此之外，Dialogflow CX 和Botpress 可以很好地处理大多数项目，而且三者都有类似的语言理解能力。Dialogflow CX 的功能总体上略多一些，而且经过谷歌的打磨，而Botpress 则更容易理解和使用。价格很难比较，因为 Dialogflows 是按消息定价的（CX 比 ES 贵得多），而Botpress的定价模式更面向服务。

差异对照表

‍

全面比较

‍

添加按钮和选择

按钮、选择和建议都非常好，因为它们能让用户知道有哪些选项，并让他们更容易选择自己想要的东西。即使在电话中，选项也能帮助用户浏览菜单。在其他不支持按钮的文本平台上，速记功能可以让用户更容易回答问题。

Dialogflow ES

• Dialogflow ES 的默认响应类型不包含任何类似按钮的内容！

• 当你选择像 Slack 这样支持类似按钮功能的平台时，你可以看到它的内置回复类型。Slack 有默认（无平台）选项所没有的图片、卡片和快速回复。

• 快速回复和卡片是在 Slack 中添加按钮的简单方法。

• 在聊天模拟器中，特定平台的预览会显示两者之间的区别。在 Dialogflow 本身就有这样的功能，非常方便。

• 您可以轻松添加链接或文本。快速回复的值等于文本。值用于自然语言理解意图检测。

• 处理回复有两种方法。第一种是创建一个意图，其中包含与卡片/快速回复中使用的训练短语类似的短语。Dialogflow 会捕捉它并将用户发送到回复。

• 第二种方法是使用 "履行"，这是事后执行操作的一种花哨说法。具体来说，履行网络钩子的意思就是：用代码处理响应。

• 遗憾的是，您必须转到另一个页面来处理您的所有订单。

1 of 8

在这一点上，你必须使用谷歌cloud 函数或自己的服务器来处理自定义逻辑。这里有一个集成的代码编辑器，但非常有限。在紧要关头，它可以完成一两个操作，但你不会想把全部代码都放在这里。

如果计划支持多个平台（包括网络），则必须为每种类型创建响应。这样做的好处是不容易出错。另一方面，您将有更多的重复工作。特定平台预览非常适合测试。从一个意图到另一个意图，要了解点击按钮的真正作用是很困难的。如果响应处理的是代码，也很难看出发生了什么，即使只是大致了解发生了什么。

Dialogflow CX

Dialogflow CX 对按钮的处理方式既相似又不同。

• 在页面中，您需要编辑履行。将其视为在该页面内发生的操作（用户在对话中的位置）。

• 添加对话框选项的菜单。文本选项简单明了，但没有明确的按钮选项。

• 如果要添加按钮，则需要 "自定义有效载荷 "选项。这不是很直观。

• 例如，这就是添加按钮/芯片的方法。您需要浏览文档。

• 如果点击测试代理按钮并进行尝试，就会得到类似下面的结果。没有按钮，也无法看到按钮在不同平台上的样子。帮助不大！

• 要测试流量，请转到管理，然后转到集成，再转到 Dialogflow messenger 的连接按钮。

• 启用，然后点击完成

• 点击微妙的 "立即尝试 "按钮，然后打开右下角的聊天气泡，尝试查询。如果您想更方便地试用，似乎需要创建一个 html 文件并添加他们给您的代码。

1 of 8

祝你好运！用户界面并没有让这一问题变得显而易见，搜索答案会得到基于代码的解决方案和 Dialogflow ES 的结果。丰富的回复功能非常强大，但由于某些原因，还没有得到适当的图形用户界面处理。这是一种基于代码的解决方案，您不得不在图形用户界面中使用它。最后，在模拟器中进行测试并不能显示它在 Dialogflow ES 等不同平台上的效果，也不能显示它在 webchat 上的效果。

Botpress v12

• 从左侧菜单拖放选择图标。

• 问题可以重复使用，因此有一个选择器

• 选择问题和答案。注意禁用自由文本。当然，这只适用于允许自由文本的平台。

• 创建或选择问题/答案配对后，您将看到以下内容。

• 高级部分允许您在用户写出不匹配的答案时给出一定次数的提示。

• 在流程编辑器中，您可以轻松地可视化和处理选择的后果。失败时是指用户的错误回答达到上限时。

• 如果不想强迫用户做出选择，而只是向他们提供建议，则可将最大重试次数设为 0，然后在 "User_failed_input "元素中检测用户输入，从而触发 "On failure"（失败时）。

1 of 7

总的来说，只要掌握了方法，在Botpress 上做出所需的选择是很容易的，也很容易可视化。提供建议就不那么直观了，感觉像是对选择技能功能的计划外使用。如果您计划支持多个平台，按钮可以跨平台使用，这可以节省您的时间。

比较

Botpress 在这里有点不直观，因为即使您想显示建议，也需要使用选择技能。这样做的好处是可以验证；您可以强制用户对其中一个选项做出反应。将建议功能从选择技能中分离出来可能会让这一切变得更容易。Dialogflow ES 更简单一些。问题是没有适用于所有支持平台的按钮功能。您需要打开特定平台选项卡才能尝试。找到它的难度适中。Dialogflow CX 在这方面是个失败者，因为它没有基于图形用户界面的添加按钮的方法。并不是所有东西都能用代码实现，这有点难以理解他们为什么要这样做。Botpress 和 Dialogflow ES 都可以更清楚地说明如何添加按钮，Botpress 提供了方便的跨平台按钮和验证，而 Dialogflow ES 则更容易提出建议。

按钮按压流程可视化

Botpress 在这方面首屈一指。因为它的单一适用解决方案可以轻松查看点击按钮后发生的情况。Dialogflow 的按钮提供了方便的链接功能，但就对话流程而言，这可能很难可视化。Dialogflow ES 没有像 Dialogflow CX 或Botpress 那样的可视化流程，因此也很难实现。

测试按钮

Botpress Botpress 假定所有内容都是相似的，所以只显示一个总视图，而 Dialogflow 假定所有内容都是不同的，所以分别显示每个版本。出于某种原因，Dialogflow CX 似乎走了一条默认模拟器既不显示也不显示的路，而是显示数据。无论是为单一平台还是为多个平台开发，这都相当不方便。这是 CX 不仅仅是 ES 升级版的一个例子。

自然语言理解能力

聊天机器人制造商的解决方案经常吹嘘自己拥有业界一流的 NLU（自然语言理解）能力，但这在构建对话时又是如何体现的呢？如果您打算使用 NLU，您应该问两个关于 NLU 的问题。它支持 X 种语言吗？

NLU 通常会出现两种错误。引擎检测到了不应该检测到的东西（假阳性），或者检测到了应该检测到的东西却没有检测到（假阴性）。实际上，这两个问题的解决方案都是给机器学习引擎提供更多的示例和反例。当两个引擎的基准相似时，区别在于准确度较低的引擎可能需要添加更多的例句来覆盖边缘情况，才能达到同样的准确度。实际情况可能并非如此，这取决于您要处理的主题。

Botpress 在本地使用时，开放源代码提供的语言引擎比 Dialogflow 少（开箱即有 12 个）。如果您想使用的语言不在这 12 种语言之列，您也可以使用 FastText 模型（Facebook 开源，语言列表可在此处找到）进行 NLU，如果您需要调整语言模型，也可以这样做。如果你愿意让谷歌托管你的数据，也可以使用 Dialogflow 引擎进行 NLU。这并非非此即彼。这两个平台都在不断改进。既然Botpress 可以使用 Dialogflow 进行 NLU，那么公平的比较就是Botpress NLU 能做什么而 Dialogflow NLU 不能做什么。

流行语言的 NLU 在两个平台上的质量可能差不多，而不太流行的语言会比较麻烦。

话虽如此，如果您希望获得希伯来语或阿拉伯语支持，请注意 Dialogflow ES 目前不支持这些语言。

认识句子成分

通常，自然语言理解分为两个部分：意图检测和实体识别。您可以将意图视为句子，将实体视为您希望理解的句子的一部分。日期、时间和地点都是实体。

以这个句子为例进行说明："查找 6 月 11 日从东京飞往纽约的机票"。意图是购买机票，句子本身称为语篇。一个意图通常会有许多语句来为机器学习引擎提供信息。东京、纽约和 6 月 11 日都是实体。机票不是一个实体，因为这种句子结构不能真正用于机票以外的其他东西。但是，如果您有 "购买某样东西 "的意图，则可以将其作为一个实体。至于你想提取什么，就看你的决定了！

Dialogflow 和Botpress 具有大致相同的功能，但在用户体验方面有所改变，并有现成的选项。

Dialogflow ES

要在 Dialogflow ES 中创建实体，您可以先分配实体，也可以在编写语篇后添加实体。

• 要根据意图语句创建实体，只需选中您想要的部分（在本例中为 #14147），弹出窗口就会出现。

• 开箱即有很多默认选项。

• 如果搜索结果为空，创建新按钮就很方便。

• "允许自动扩展 "允许用户写下 "苹果、梨、香蕉 "这样的内容，而 NLU 也可以匹配 "橘子"。

• 一旦您定义了实体，并创建了语篇，Dialogflow 就会自动标记内容。在本例中，自动标记有点过度热情，但删除标记比添加标记更容易，所以一切正常。

1 of 5

Dialogflow CX

• 有趣的是，Dialogflow CX 在实体方面并不遵循 Dialogflow ES。新实体按钮不见了，因此您必须到其他地方添加它。

• 相反，你会在意向页面的底部看到这个。"Is list "允许你输入一系列值（苹果、梨和香蕉），而 "Redact in log "则允许开发人员在日志中隐藏敏感信息，如信用卡号。

• 在 Dialogflow CX 实体页面，您可以创建实体。这与 Dialogflow ES 基本相同，只是顺序不同。主要的例外是高级中的 "在日志中重新编辑 "选项。

• 这是 Dialogflow CX 的独特之处。

1 of 4

模糊匹配和自动添加实体会造成误报问题。例如，如果您想检测苹果、梨和甜瓜等圆形水果，并选择了该选项，那么香蕉也会匹配，尽管它不是圆形的。可以使用实体排除法来解决这个问题，尽管命名所有非圆形水果是不切实际的。具体情况会有所不同。

Botpress v12

• 在Botpress 中创建实体非常简单，但并不是即时完成的。

• 高亮显示某些内容并不能像 Dialogflow ES 那样提供创建新标签的选项。至少您可以按键盘上的数字（本例中为 0），以便快速标记所有内容。

• 如果要标记某个内容，需要先创建一个槽。这一点与 Dialogflow 不同。

1 of 3

比较

实体对每个人来说都是抽象的，没有一个平台能像意图一样将其作为一个直观的概念。用户需要自己搜索，或在文档/教程中发现它。这通常需要开发人员来完成。这是因为许多自定义实体（如订单号）需要使用正则表达式。

Dialogflow 中的模糊匹配功能似乎更强大一些，因为它还能对重新排序的词语进行模糊匹配，但除非语言允许词语重新排序，否则这似乎并不是很有用。

Dialogflow 与Botpress 的真正区别在于自动扩展。您可以提供同义词列表，Dialogflow 仍然能够理解。如果给定一个购物清单：以苹果、梨、香蕉为例，并给出 "我想买芒果 "的句子，Botpress 将无法正确检测，而 Dialogflow 则可以。您可以通过添加更多异常来解决这个问题，但这需要更多的工作。这还会产生一个新问题，因为您现在面临过度检测的风险。Dialogflow CX 中的异常字段就是为了处理这个问题而设计的。总的来说，由于该异常字段是可选的，因此将其包含在内是有利于对话流的。

对于普通用户来说，Dialogflow ES 的优势在于拥有最多的默认选项、自动扩展和更方便的标记。

Dialogflow CX 以句内实体列表取胜。Botpress 也能做到这一点，但要复杂得多。Dialogflow CX 的另一个优势是可以从日志中隐藏信息，这一点可能重要也可能不重要，这取决于您的使用情况，但这只是比 Dialogflow ES 的优势，因为您可以完全控制Botpress 。

在 Dialogflow 中，实体会被自动标记，如果用户想要区分，可以修改名称。这样做既直观又不太直观，但对于初学者来说，就少了一件操心的事。在Botpress 中，用户需要先创建实体，然后才能在语篇中标记它们。

部署生产就绪状态chatbots

您可以说Botpress 必须自己托管，而 Dialogflow 已经为您托管了，但这并不能说明问题。实际上，Botpress Enterprise 提供托管服务，您可能需要在 Dialogflow 上进行一些部署。为什么呢？因为虽然 Dialogflow 可以从cloud 上完全运行，但一旦您想添加自定义功能，就必须自己在建议的 GoogleCloud 或其他地方部署该功能。

Dialogflow ES

只要不添加自定义功能（如从远程数据库获取订单信息），就不需要进行代码部署，但仍需要进行机器人版本部署（全部在cloud 中）。

• 准备好部署后，进入设置，然后点击 "发布版本"。

• 给它起个名字，比如初始版本或 v1.0。

• 您可以将您的环境称为 "生产环境"。Cloud 功能实现选项与 Webhook 相同，但与 GoogleCloud 集成。

• 在 "集成 "页面，选择你想要的集成，然后选择你创建的环境。就是这样！

1 of 4

要部署自定义代码，您可以选择其他平台，但所有文档都将指向使用 GoogleCloud的无服务器功能。您将使用此 api 部署您的代码。

实际上，如果您的机器人有一点复杂，它就会访问 API，如果这样做，您就需要自定义代码。虽然这很简单（只需一条命令就能上传代码），但如果你想在修改代码之前进行任何可用性测试，那么你很可能需要在 Dialogflow ES 中创建一个代理副本来进行测试。在这方面没有简单的办法。

Dialogflow CS

这与 Dialogflow ES 非常相似。

• 您需要先为环境创建一个版本。

• Dialogflow CX 在创建版本后的组织结构与 Dialogflow ES 几乎相同。创建一个环境（本例中为生产环境），然后导航到集成。

• 在 "集成 "页面，您可以再次选择 "生产 "进行部署。与 Dialogflow ES 一样，在部署自定义代码时，您可以选择其他平台，但所有文档都指向使用 GoogleCloud的无服务器功能。

• 这就是在 Dialogflow CX 中连接功能的方式。虽然没有像 Dialogflow ES 中那样的 GoogleCloud 函数快捷方式，但您可以使用所有相同的功能。

Botpress v12

Botpress 的部署通常由用户完成，以维护数据所有权，但Botpress 可根据您的需求托管或协助托管。在撰写本文时，还没有自助托管功能。自定义功能附在Botpress 实例上，因此这在一定程度上降低了部署 Dialogflow 的复杂性。要实现可扩展的部署，您需要一位精通托管软件的软件工程师，或者使用Botpress Enterprise 服务。

Botpress 企业版确实包含管道，可让你识别机器人并将其从草稿移至生产版，但这需要你已经托管运行了一个生产就绪实例。

• Botpress 提供了一份生产核对表，使部署工作更加轻松。

• 由于功能存在于Botpress 中，因此所有功能都可以一起测试，您可以将所有功能移至审核阶段，然后再移至生产阶段。

要与集成进行连接，您必须遵循文档。大部分工作都是在配置文件中完成的，因此你需要开发人员来处理，或者使用Botpress Enterprise Services。

比较

如果您不需要任何自定义代码，Dialogflow ES 将是您的最佳选择。它直观、快速。如果确实需要部署功能，则需要额外的步骤。Dialogflow CX 在部署到生产环境时稍显困难（多了一个步骤，错误信息也不明显），在自定义代码方面也有同样的问题。使用 GoogleCloud Platform 的好处是，您有可能使用cloud 函数。虽然它们不是托管代码的最便宜方式，但却是拥有高度可扩展功能的最简单方式。

为 Dialogflow 部署函数的过程是创建一个新函数、托管它、获取链接、在 Dialogflow webhook / fulfillment 中更新它、测试新版本以确保它能正常工作，如果能正常工作，就部署新版本。第一次应该不会太麻烦，但如果你认为要经常更新代码以匹配对话逻辑，那就会增加额外的复杂性。在Botpress 中，代码和对话逻辑生活在同一个世界里，因此更新、测试和部署都会容易得多。缺点是开发人员必须使用 Nodejs，因此如果他们不熟悉 Nodejs，就会有一个学习曲线，这取决于他们以前使用过什么。这样做的好处是，由于只有一个库，理论上文档应该更及时。

如果没有自定义代码，Botpress 在这一类别中将是最差的，因为您实际上必须托管一些东西，而不是不托管。虽然Botpress 提供了部署服务，因此从技术上讲您什么都不用做，但它永远不会像自助服务模式那样方便。自定义代码否定了 Dialogflow 的优势。

自己托管会遇到扩展管理问题。当然，如果您的项目不能包含外部服务，那么Botpress 显然是个不错的选择。Botpress 的开源版本确实有关于部署的文档，但它并不是一个完整的自动扩展架构，您可以选择 Dialogflow。

本部分到此为止。以下是Botpress vs Dialogflow ES vs Dialogflow CX 的第二部分。