I'm quite experienced with LUIS, and learning QnA now. To the extent I know LUIS, for this scheme to work, you would have to add all your HR questions to the HR intent in LUIS as utterances, the Payroll questions to the Payroll intent, and so on. This looks like allot of duplication. Am I wrong?
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
@tsahi Thanks for the feedback! We are currently investigating and will update you shortly.
@tsahi In this document, it means type messages from different intents to get the response from the corresponding knowledge base, which means that if it depends on if there is a lot of duplication between the two KBs you built.
I'm sorry, I didn't get what you mean. Again, how would LUIS know the intent, if it isn't trained with the question from the KB?
@tsahi Hi, what I mean is for different questions, QnA Maker first gets the intent of the incoming question from a LUIS model, then we will need some logic to route the incoming question to the appropriate knowledge base. So you need to build different knowledge base according to your logic, and make the duplication between different knowledge base as less as possible.
But for LUIS to give an intent of a question, it needs to be trained with it (or a close enough question), no? doesn't it mean the questions from the KB should also be loaded to LUIS?
I also don't follow this. @YutongTie-MSFT are you suggesting that you have a simple intent (such as saying "HR" or "Payroll") that then prompts the user to then ask their question for that specific system? Otherwise I'm with @tsahi in that surely you've just got a load of duplication. Wouldn't it be easier to just call out to each knowledge base and get the highest match out of them all - or is that too inefficient?
@tsahi @stenoid Hi guys, let me assign the author to give us more specific explanation and more details.
@nstulasi Hi, can you please explain more details for our customers? And also can you please also update the document for more information to make the document more understandable? Thanks very much for your help.
I haven't walked through the whole thing with an actual sample yet, but here's how I understand this /should/ work.
In order not to duplicate questions from the various knowledge bases, the bot only serves as a front desk. You can probably deal with routing to the correct KB endpoint in at least two different ways if you don't want to maintain a large number of intents duplicating the questions from the KB (and this is how I would approach those).
Use LUIS in the bot to implement the front desk. This implicates a two-step process. The first step is the user providing his intent (in other words, what knowledge area his question refers to). The bot should probable open the conversation with an overview of topics it covers. Heck, you might not even use LUIS for this. Looking at the sample, the various KB endpoints are already hard-coded in the bot. You could just present a multiple choice dialog from within the bot framework as users initiate a conversation with the bot, they choose from that and the bot then knows to route the question to the chosen KB endpoint. If you want users to allow switching KB endpoint context within an application you can either display the same multiple choice dialog after each KB response transaction or use LUIS to enable free text context switching. Or use a mix of both strategies.
The other approach would not have the bot act as a front desk but more of a router/filter. A user would type their question without any prior steps. The bot would concurrently query all known KB endpoints and collect the responses from them all, then comparing the confidence scores of each and only present the one with the best confidence score from the KB.
That being said, my feedback to this documentation content page:
The title of the page should probably be "Strategies for exposing multiple KB endpoints in a single bot application" rather than assuming that a LUIS approach is what developers want/need. The page should have various approaches (as above) described and then include links to implementations of each somewhere in a public Github repo.
I've spent some more time diving into the details. This documentation page is not very clear or easy to follow.
The class QnAMakerService displayed in the documentation, is that class meant to replace the sealed class Microsoft.Bot.Builder.CognitiveServices.QnAMaker.QnAMakerService that's probably already in the project's references? Or is this just an unfortunate naming conflict?
I opened a ticket for this here as well.
Thank you @polarapfel. That was really useful, and I see how the 'front desk' is the best approach for having a LUIS + QnA M bot. But I feel that you would have to implement a FormFlow type activity first that asks the user to select either of the three KB first, then allowing the user to ask questions about that specific KB.
@tsahi Please refer to https://github.com/Microsoft/BotBuilder-CognitiveServices/issues/129 for more details of this issue.
We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.
Most helpful comment
I haven't walked through the whole thing with an actual sample yet, but here's how I understand this /should/ work.
In order not to duplicate questions from the various knowledge bases, the bot only serves as a front desk. You can probably deal with routing to the correct KB endpoint in at least two different ways if you don't want to maintain a large number of intents duplicating the questions from the KB (and this is how I would approach those).
Use LUIS in the bot to implement the front desk. This implicates a two-step process. The first step is the user providing his intent (in other words, what knowledge area his question refers to). The bot should probable open the conversation with an overview of topics it covers. Heck, you might not even use LUIS for this. Looking at the sample, the various KB endpoints are already hard-coded in the bot. You could just present a multiple choice dialog from within the bot framework as users initiate a conversation with the bot, they choose from that and the bot then knows to route the question to the chosen KB endpoint. If you want users to allow switching KB endpoint context within an application you can either display the same multiple choice dialog after each KB response transaction or use LUIS to enable free text context switching. Or use a mix of both strategies.
The other approach would not have the bot act as a front desk but more of a router/filter. A user would type their question without any prior steps. The bot would concurrently query all known KB endpoints and collect the responses from them all, then comparing the confidence scores of each and only present the one with the best confidence score from the KB.
That being said, my feedback to this documentation content page:
The title of the page should probably be "Strategies for exposing multiple KB endpoints in a single bot application" rather than assuming that a LUIS approach is what developers want/need. The page should have various approaches (as above) described and then include links to implementations of each somewhere in a public Github repo.