与Dialogflow相比，Rasa框架的技术优势

Question

我一直在使用Rasa来构建具有一些复杂故事的机器人。我什至开始在管道中使用经过稍微修改的自定义培训组件。

但是，我被要求对Rasa与Dialogflow进行详细的比较，并且我没有足够的时间和经验来熟悉DF。我知道Rasa + SDK可以实现极高级别的自定义，并且我已经习惯了它。我向本论坛的拥有Dialogflow经验的用户提出的问题是，与Rasa堆栈相比，Dialogflow是否存在已知的技术限制？我遇到过这个https://blog.rasa.com/how-to-migrate-your-existing-google-dialogflow-assistant-to-rasa，但是在比较中它缺乏技术深度。除了开源和数据所有权问题之外，我还能引用Dialogflow的任何基本限制吗？

基本上，如果您知道如何破坏DF或由于某些原因而讨厌它，请发表一些评论。 （最初发布在Rasa社区论坛上，但认为这个问题可能会得到公众的更好回答）

谢谢

Answer 1

我发现DialogFlow具有以下限制：

• 这是一项云服务，因此您的聊天机器人发起的所有对话（和数据）都将通过Google云
• 它具有良好的NLP功能，但您无法控制：与Rasa不同，您无法更改NLU阶段涉及的管道和模型
• 对话是使用DialogFlow用户界面设计的，该界面运行良好，但不允许（轻松地）自动化或集成用于设计流程的外部应用程序
• DialogFlow Web聊天插件非常基础，不适合生产使用（仅用于测试）
• 如果开发Webhook（任何非平凡的聊天机器人都需要一个），则必须将DialogFlow请求传送到本地开发环境（笔记本电脑），因此需要NGROK或其他传送软件