Kap*_*aG3 5 chatbot multi-tenant botframework chatterbot dialogflow-es
我的公司目前正在尝试使用 Google Dialogflow 构建一个多租户聊天机器人。我们正在探索我们可以使用的工具，但关于该主题的文档仍然有点稀缺。在这种情况下，我们对多租户的理解和定义将允许我们根据最终用户工作的公司拥有略有不同的对话流程。例如：
Foo 公司的用户 A 想要订购冰淇淋。Foo 公司提供了一系列口味（巧克力、香草、薄荷）并且只提供蛋卷冰淇淋，但允许用户在他们的冰淇淋中添加装饰物（巧克力片、糖屑）。
Bar 公司的用户 B 想要订购冰淇淋。Company Bar 提供一系列口味（草莓、开心果、柠檬）并供应冰淇淋蛋筒和杯子，但不提供配菜。
两个用户应该有完全相同的对话，除了口味和冰淇淋容器的可用列表取决于租户。此外，还应该可以选择扩展此对话流程的一部分，例如 A 公司提供添加装饰的功能。两个对话应该以相同的意图开始和结束（我想要一个冰淇淋/我准备付钱）。
我们的次要目标是最小化 Dialogflow 端的冗余：理想情况下，只有一个代理，理想情况下，不需要重复的意图不应该被复制。
我们的架构不是客户驱动的；客户端总是被我们的后端服务器 (C#) 拦截，它负责处理与 Dialogflow 的互操作。我们认为这为我们提供了更大的灵活性并更好地与我们现有的堆栈集成。
我们已经确定了这些有前途的功能：
但我们还没有确定明确的路径。我们也在考虑可用的替代方案，例如微软的 BotBuilder、亚马逊的 AWS Chatbot 和开源 ChatterBot。
简而言之，在这方面有最佳实践吗？如果没有，将非常欢迎有关此事的任何想法和想法。
首先让我说没有完善的指导方针，聊天机器人世界在我们说话时正在发展。
我个人认为有两种方法：
在第一种情况下，使用 DialogFlow 有几个优点，但您有两个主要限制：云依赖（所有用户流量都通过 Google）和对话设计的灵活性有限。
如果您实现了维护一个对话流，那么您的 webhook 可以按需填充数据（即不同的风格、不同的选项），这是非常可行的。
您的对话还可以包含您通过事件激活的分支（添加装饰）（如果公司数据具有特定标志，则从 webhook 生成），这也是可行的，但它会使对话变得更加麻烦。
在第二种方法中，您有更大的灵活性（所有对话流程都在您的代码中），但显然您需要“提供”缺少的功能，例如 NLU 的 LUIS 集成等。如果这种方法看起来不错，那么
Rasa是一个很好的框架您很感兴趣：它是基于 Python 的，它提供内置的 NLU 功能以及通道集成。