如何实现具有多个工作空间的 Watson 对话

Posted 2023-02-16

【中文标题】如何实现具有多个工作空间的 Watson 对话

【英文标题】：How to implement watson conversation with multiple workspaces

【发布时间】：2016-12-13 03:05:00

【问题描述】：

在网络研讨会中，它提到了使用多个对话工作区来处理项目的不同主题（例如功能性对话与离题）。我们应该如何实现这个设计？

假设我们有两个工作区，一个是功能主题，另一个是非主题。如何确定请求应该进入哪些工作空间以及逻辑？

而这个判断逻辑应该在服务器后端还是在工作区逻辑中实现？

谢谢。

【参考方案1】：

您使用要分类的内容创建第一组意图。其中一个意图应该是“离题”，并保留所有离题问题。

第二个工作区只是您的非主题，但被分解为相关主题。

当您拨打电话并获得 Offtopic 时，请调用第二个工作区。它应该返回离题的性质，因此您可以对其采取行动。

您必须测试/调整您的主要意图集，使其不会干扰主题内容。例如，如果谈话与销售体育用品有关，那么与体育有关的话题可能更难抓住。

此时您可能需要考虑置信度。

【参考方案2】：

向我建议并且我目前正在试验的另一种方法是拥有一个主路由工作区和可能的多个应用程序工作区。在第一个实例中，用户的输入转到具有高级意图的主节点，该意图计算出要路由到哪个应用程序工作区。应用程序工作区具有更详细的意图。

微妙之处在于将所有后续输入并行发送到选定的应用工作区和主路由器。与前面描述的顺序方法相比，这种方法的潜在优势是主工作区可以争夺控制权，而不必因偏离主题或信心不足而放弃控制权。这意味着除了允许集中离题外，您还可以使用与初始路由相同的主意图来动态路由到其他工作区。

我通过让编排层将会话管理为这样的上下文数组来完成此操作

   currentWs: xxxx,
   contexts:  
      ws_idn: , // basically an array of conversation contexts,
      ....       // keyed on workspace_id's
     

输入被发送到主工作区，无论哪个工作区被主工作区标记为当前工作区（连同该工作区的相关上下文对象）。您可以在多个聊天机器人应用程序之间无缝地来回切换，而不会丢失其中任何一个应用程序的上下文。