How to implement watson conversation with multiple workspaces

Question

In the webinar it has mentioned about using multiple conversation workspaces to handle different topics of a project (e.g. functional conversations vs off-topics). How should we implement this design?

Say if we have two workspaces, one is functional-topic and the other is off-topics. How to determine and the logic which workspaces should the request go into?

And this determination logic should be implemented in the server backend or in the workspace logic?

Thanks.

Worker

Answer 1

You create your first set of intents with what you want to classify. One of those intents should be "Offtopic" and hold all your off topic questions.

The second workspace is just your off topics but broken up into related topics.

When you make your call and get the Offtopic, then call the second workspace. It should return the nature of the off topic, so you can take action on it.

You will have to test/tweak your main intent set so that it doesn't interfere with on topic stuff. For example if the conversation relates to selling sports goods, then off topics relating to sports may be tricker to catch.

You may need to factor in confidences at that point.

Diary

Answer 2

Another approach suggested to me and I'm currently experimenting with is to have a master routing workspace and possibly multiple application workspaces. In the first instance the user's input goes to the master which has high level intents that work out which application workspace to route to. The application workspaces have intents that break into more detail.

The subtlety is to then send all subsequent input to both the selected app workspace and the master router in parallel. The potential advantage of this over the sequential approach described previously is that the master workspace can wrestle control rather than having to have it surrendered by off-topic or low confidence. This means as well as allowing off-topic to be centralised you can get dynamic routing to other workspaces using the same intents in the master as the initial routing.

I've done this by having the orchestration layer manage the session as an array of contexts like this

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

Input gets sent to the master workspace and whichever workspace is marked as current by the master (along with the relevant context object for that workspace). You can seamlessly switch back and forth between multiple chatbot applications without losing context in any of them.

Bullyboy