Bot App with LUIS & QnA Maker
Quick Summary
In my previous post, I have demonstrate BOT framework V3 with LUIS integration. here i am posting blog for LUIS with QnA maker using Bot framework V4.
Purpose:
In an organization, there are numbers of policies which is created by management and maintain by employees and company’s staff. and those policies could be change or modify by management as per new rules and guild line by time.
By maintaining those policies at one place, HR can use QnA makers which have necessary questions n related answers.
New employees or existing employees could have a queries regarding companies policies and rules which can be accomplish by Bot App. A bot App which is trained with LUIS intent and find answers from QnA maker.
what is new in to Bot Framework V4
There are several new concepts in BFv4 which bring new terminology with them. The concepts are covered in some detail in the docs, but here are some of the key new terms you’ll hear and need to understand to build BFv4 bots.
Adapter: The Adapter is like the orchestration engine for the bot and is responsible for directing incoming and outgoing communication, authentication, and so on. When your bot receives an activity, the adapter wraps up everything about that activity, creates a TurnContext object, passes it to your bot’s application logic, and sends responses generated by your bot back to the user’s channel. We don’t typically work directly with the adapter. Read about activity processing and the adapter here
Middleware: Middleware is a pipeline which sits between the adapter and the bot code. The pipeline can contain multiple middleware components and many of the built in capabilities are represented as middleware such as state. Read more about middleware here
Turn: A Turn is the action of the bot receiving an activity (i.e. a message from the user), and subsequently processing it, normally involving the bot replying back to the user and awaiting further input. A Turn carries a TurnContext object which contains useful information such as Conversation, Activity, Intent, State and other information.
Dialogs and Conversation flow: The way conversation flows through the bot has changed significantly compared to BFv3. Key docs include Manage conversation flow with dialogs and Create modular bot logic with a dialog container. These are some of the key concepts:
Dialog: A Dialog is a little different to BFv3. In BFv4, a Dialog is used for very simple, single turn interactions. For example if you ask the bot “what is 2 + 2”, it would reply “4” and that would be the end of the dialog. A Dialog can receive data either via arguments passed in from the OnTurn function or via state. Dialogs cannot contain child dialogs so cannot be used on their own for complex branched conversations, that is where the DialogContainer is used as it contains a collection of Dialogs.
Prompt: A Prompt is a type of built-in dialog intended to capture and verify specific pre-defined data from the user such as text, numbers, dates, confirmation or choices. Conceptually this is the same as BFv3.
DialogContainer: A DialogCointainer is a collection of Dialog or Prompt which are executed sequentially in WaterfallStep. DialogContainers can and do contain child dialogs and are the logical equivalent to the Dialog in BFv3.
DialogSet: A DialogSet is a collection which can contain child Dialog, Prompt or DialogContainer. DialogSets are generally used to manage the top level menu for your bot and then branch out to different DialogContainers for different branches of the conversation. This is often known as a “root dialog”, but should more accurately be described as “root dialog set”.
WaterfallStep: A WaterfallStep step can be thought of as a granular step in the conversation either prompting the user for an utterance or processing what the user said.
State: State is conceptually similar to BFv3 in that it stores data relating to either the conversation or the user. State is a middleware component. Read about Managing conversation state here.
BFv4 as it really is a big change in terms of terminology, capabilities and overall architecture. However, as with all platform re-writes of this nature, BFv4 is a very good developer platform and once the initial learning curve has been overcome, I think it is a much easier and overall better platform for writing bots compared to BFv3.
Create Bot:
you should have azure credential to login azure portal for creating bot application. you can create web bot service using this link how to create bot with azure bot service
LUIS Middleware:
As with BFv3, almost every bot will need some level of natural language processing which is where Cognitive Services Language Understanding Service (LUIS) comes in. LUIS extracts intent and entities from a user’s utterance and makes that data available to the bot to inform teh application logic.
In BFv4, there is a middleware component called LuisRecognizerMiddleware. You can read about how to use it at Using LUIS for Language Understanding.
In our demo application, we are using LUIS as based on top scoring intent, generate answer from QnA maker API. Considering score based on ratio of 100 to 80, Direct answer fetch from QnA Api,
A top intent which comes ratio between 80 to 40 multiple intents will generate answers from QnA knowledge base and if ratio goes down below 40 no answer will be display.
QnA maker:
QnA maker role in to application is find answer based on intent passed. you can read more about how to configure QnA maker in to bot.
train knowledge base of QnA as answers of questions which are stored as intent in to LUIS application.
Conclusion :
Create Bot App service and use LUIS, QnA app credentials for implement code. Deploy bot app on to azure bot web app and configure with convenient channel. pass that channel url with employees so they can use it whenever they need.