我的公司目前正在尝试使用Google Dialogflow构建多租户聊天机器人。我们正在探索可使用的工具,但是有关该主题的文档仍然很少。在这种情况下,我们对多租户的理解和定义将使我们根据最终用户所在的公司而拥有稍微不同的对话流程。例如:
Foo公司的用户A要订购冰淇淋。 Foo公司提供一组口味(巧克力,香草,薄荷),仅提供蛋卷冰淇淋,但允许用户在冰淇淋中添加装饰(巧克力片,糖粉)。
Bar公司的用户B要订购冰淇淋。 Company Bar提供一组口味(草莓,开心果,柠檬),并提供冰淇淋甜筒和杯子,但不提供装饰。
两个用户都应该进行相同的准确对话,除外口味和冰淇淋容器的可用列表将取决于租户。此外,还应该选择扩展此对话流的一部分,例如提供添加装饰的能力的公司A。两种对话都应以相同的意图开始和结束(我想要冰淇淋/我准备付款)。
我们的次要目标是最小化Dialogflow端的冗余:理想情况下,将只有一个代理,理想情况下,不应复制不需要重复的意图。
我们的架构不是客户端驱动的;客户端始终被我们的后端服务器(C#)拦截,该后端服务器负责处理与Dialogflow的互操作。我们认为这为我们提供了更大的灵活性,并且可以更好地与现有堆栈集成。
我们已经确定了这些有希望的特征:
但是我们还没有找到一条清晰的道路。我们也在考虑可用的替代方案,例如微软的BotBuilder,亚马逊的AWS Chatbot和开源的ChatterBot。
简而言之,是否有最佳实践?如果没有,那么对此事任何想法和想法都将受到欢迎。
那是一个非常有趣的问题:-)。首先,我要说的是尚无完善的指导方针,聊天机器人世界在不断发展。
我个人看到2种方法:
在第一种情况下,使用DialogFlow具有多个优点,但您有两个主要限制:云依赖性(所有用户流量都通过Google进行),并且对话设计的灵活性有限。如果您能够维持一个对话流程,那么您的Webhook可以按需填充数据(即,不同的风格,不同的选项),那是非常可行的。您的对话还可以包含分支(添加装饰),您可以通过事件(如果公司数据具有特定标志从Webhook生成)激活该分支,这也是可行的,但它开始使对话变得更加麻烦。
在第二种方法中,您具有更大的灵活性(所有对话流都在您的代码中),但是显然您需要“提供”缺少的功能,例如将LUIS集成到NLU等。如果您觉得这种方法很有趣,Rasa是一个很好的框架:它是基于Python的,并且提供内置的NLU功能以及通道集成。]
希望有帮助,祝您好运!
哔哔