Azure Bot Service
Azure Bot Service is probably the most important Azure chatbot service. It allows the integration of all other services and defines how the chatbot should work; in fact, the development of Azure chatbots always starts from this service. This is the only “old” service that doesn’t have a replacement. However, it can integrate with other old services, like LUIS and QnA Maker. There are two ways to build a chatbot using Azure Bot Service:
- Using Bot Framework Composer
- Using Bot Framework SDK
Let’s review those options, so it’s easier to understand which is best suited for what cases.
Bot Framework Composer
You don’t need to be a software developer to develop a chatbot! Bot Framework Composer is a low-code platform for building chatbots using UI. You can install Bot Framework Composer on Windows, macOS, and Linux. The only prerequisites are installed Node.js with npm and .NET Core SDK.
Essentially, an Azure chatbot consists of dialogs. You can create a chatbot using only the main dialog, but best practices for creating Azure chatbots suggest that it’s better to split it into child dialogs. In this case, each dialog represents a functional part of the chatbot. For example, if you have a chatbot that takes surveys, each survey should be a separate child dialog. Each dialog consists of the following components:
- Recognizers allow chatbots to understand and extract information from users’ input. The simplest chatbots can be created without them, in which case, user interaction is limited to choosing options given by the chatbot. For example, a healthcare chatbot can ask what clients want and give two options as buttons: “Set up an appointment” and “Cancel an appointment.” If buttons, like in this example, are used, we can do without recognizers. But if we want to recognize a phrase like “I want to visit my doctor on July 4,” this is where recognizers shine. The decision to use recognizers or to go without often depends on the expected user experience. There are four types of recognizers: a. LUIS recognizer — allows connection to Azure LUIS service for user input recognition (we will describe LUIS service later in this article) b. QnA Maker recognizer — allows the use of Azure QnA Maker service for user input recognition (we will describe the QnA Maker service later in this article) c. Regular expression recognizer d. Custom recognizer
- Triggers set the conditions for which the defined actions should be performed. As an example, an action can be triggered if LUIS recognizes a certain user intent. Azure chatbot triggers include the following: a. Intent triggers are activated when the recognizer determines intent; e.g., the user can write “I want to contact a real person,” and the chatbot will interrupt the current flow and start a trigger that contacts a real person b. Dialog event triggers are activated when a dialog-related event happens; e.g., a dialog is started, a dialog is canceled, or an error occurs c. Activities triggers are activated when certain chatbot activities happen; e.g., a conversation ended, the user is typing, or the message was deleted d.Custom events are activated in case of custom user events
- Actions define how your chatbot reacts to triggers. The simplest action is to send a response, but actions get more complex and can allow interaction with users — such as asking a question and working with dialogs. Finally, more service actions are possible, like creating a condition, looping, setting properties, and debugging the chatbot.
- Language generators allow for the creation of responses with variables and templates. This is a powerful feature to enhance your Azure chatbot.
Bot Framework Composer provides convenient tools to test and deploy your chatbot. UI allows for both testing and deploying, so you don’t need to set up Azure CLI or ask DevOps for help. Even though Azure Bot Framework Composer is an amazing tool that allows you to create a chatbot fast and without programming skills, like any low-code tool, its functionality is limited and difficult to extend. If you can’t implement your chatbot using Composer, you can still implement it using Azure, but you need to implement it using Bot Framework SDK.
Bot Framework SDK
Language Understanding (LUIS) and Conversational Language Understanding (CLU) Services
LUIS and CLU are two similar Azure chatbot services. CLU is supposed to replace LUIS, but as of the summer of 2022, it still lacks functionality — so LUIS is not deprecated yet. We will review the LUIS service, then describe the differences between LUIS and CLU and how to migrate from LUIS to CLU. LUIS is an Azure natural language processing service that allows classification of text and extraction of important information from it. It can be used for different business cases, but when used with chatbots, it helps with understanding user intent. For example, if the user says, “Set up a meeting in Zoom tomorrow with Kevin at 8 am,” LUIS will recognize “set up a meeting” as intent, and extract additional entities like time (“tomorrow 8 am”), guest (“Kevin”), and location (“Zoom”). There are two ways to process results from LUIS: by creating custom software or, if LUIS is integrated with Azure Bot Service, the chatbot will handle it using triggers and actions. Both LUIS and CLU Azure chatbot services are very user-friendly and easy to use, even for non-developers from UI. This is a huge advantage, as a chatbot can be developed by developers and then somebody who understands the business domain can train it with utterances that are usually used by users.
LUIS and CLU Basic Concepts
First, to make LUIS work, intents should be defined. The intent is what the user wants from a chatbot: business-related intents like “Check the balance,” “Arrange a meeting,” or “Add reminder”; or service intents like “Cancel” and “Restart.” For each intent, at least several examples of utterances must be provided, such as:
- “Set up a meeting in Zoom tomorrow with Kevin at 8 am”
- “Arrange a meeting with Mark in Google Meet on July 8 at 1 pm”
- “Make an appointment next Monday at 2 pm with my team in my cabinet”
LUIS will use those utterances to train the natural language processing machine learning model. It’s better to provide as many examples as possible to obtain the most accurate results. Another concept for LUIS implementation is extracting entities: pieces of information relevant to intent. They may be a time, a place, or any other meaningful information. A chatbot can work without entities, but with them, it becomes really powerful. Their use allows avoiding additional questions, like, “At what time do you want to set up a meeting?” There are different types of entities:
- Machine learned — requires you to highlight words in utterances. Azure will train a model to extract them from user input.
- List entities — static lists. This is useful if you have predefined lists, like lists of countries or airports.
- Regex entities — allows the definition of regex expressions used to extract the entities.
- Pattern.Any entities — allows the creation of patterns to extract entities from predefined templates.
- Prebuilt entities — pre-trained entities for the most popular situations like email, phone number, money, etc.
- Prebuilt domain models — similar to prebuilt entities, but pre-trained for a certain domain, like calendar, restaurant reservation, weather, etc.
LUIS vs. CLU
Microsoft released CLU as a successor of LUIS. Microsoft claims that CLU uses much more reliable machine learning algorithms, but CLU doesn’t have all the functionality that LUIS has (yet!). Let’s review the differences between CLU and LUIS services:
- CLU doesn’t integrate with Azure Bot Service (including both Composer and SDK Framework). This means it’s not very useful when you want to create a complex chatbot with lots of workflows.
- CLU service doesn’t support several types of entities: Regex Entities, Pattern.Any entities, and Prebuilt domain models. Microsoft claims that because CLU has cutting-edge technologies, it doesn’t need Pattern.Any entities, so they won’t be implemented. At the moment, there is no information about the potential implementation of Entities and Prebuilt domain models, but it would be expected.
- Unlike LUIS entities, CLU entities can have several types. You can create a Prebuilt entity and then improve it as a machine learning entity.
- CLU service has a more sophisticated training process, based on machine learning best practices. First, your labeled data is split into training and testing datasets. Second, you can choose between fast training and advanced neural network training.
- CLU service doesn’t have Review Endpoint Utterances functionality. This is a very useful feature in LUIS that allows you to review user inputs, check to make sure they were recognized correctly, then fix them and add them to the training examples. As a result, it allows easy constant improvement of the recognition model.
Azure CLU service is created using all best practices and is much better suited for enterprise projects. However, as of Summer 2022, it still lacks some important functionalities. Microsoft will likely add them in the near future.
QnA Maker and Question Answering Services
The simplest way to create a chatbot using Azure service is to use Azure QnA maker or Azure Question Answering Cognitive services. Question Answering service is supposed to replace Azure QnA maker.
The Question Answering service itself has full functionality of Azure QnA maker. These Azure chatbot services allow the creation of a knowledge base used to answer user questions. In simpler words, these are user-friendly, no-code FAQ chatbot builders. You can fill in the potential user questions by hand, or import any URL, .pdf, or .docx files. Both services use the Azure Search service to import and answer questions. However, as with CLU, Microsoft claims that the Question Answering service uses more accurate SOTA models than QnA Maker. The disadvantage of the Question Answering service is that, as of Summer 2022, there is no possibility to integrate it with the Azure chatbot Composer. This means that there are two ways to use Question Answering for now: using REST API as a self-sufficient service, or using an orchestration service. Azure QnA maker will be retired on March 31, 2025, and from October 1, 2022, it won’t be possible to create any new QnA Maker resources. So, for now, there is a chance that Microsoft will add integration to Composer.
Orchestration Workflow Service
This is a new Azure chatbot service that allows its users to combine several CLU, LUIS, and Question Answering services. Unlike Orchestrator in Bot Framework SDK, the Orchestration workflow service runs in the cloud and uses easy-to-use, no-code UI to train a model. It’s very similar to CLU in that it has its own intents. But, in this case, the intents can be these four different types:
- CLU intent
- LUIS intent
- Question Answering intent
- Custom intent
When you create a custom intent, the flow is the same as with CLU — you need to provide examples of utterances. In all other cases, all you need to do is to choose the service. Orchestration workflow service is a powerful and easy-to-use service for creating chatbots. However, as of Summer 2022, there is no integration with Azure Bot Service, so the only possible way to use it is to implement custom integration.
Azure Chatbot Services Architecture
All Azure services are useful by themselves for certain business cases. However, greater value can be achieved by integrating them with each other. Microsoft provides a great way to build an Azure chatbot architecture by combining its services.
Azure Bot Framework Composer Chatbot Architecture
Bot Framework Composer has convenient two-way integration tools for both LUIS and QnA Maker services. Intent and QnA recognizers connect to LUIS and QnA Maker respectively. Best practices for developing chatbots with Azure Bot Framework Composer suggest using those services as a part of the chatbot. Furthermore, Composer provides an easy way to train LUIS and QnA Maker services by providing training utterances and QnA pairs. The new services — CLU, Question Answering, and Orchestration workflow — don’t have an integration with Composer. Still, it is possible to integrate using “Send an HTTP request action.” It’s not as convenient as using old services, though, so it’s better to wait until Microsoft creates full integration with new services.
Azure Bot Framework SDK Chatbot Architecture
Azure Bot Framework SDK provides classes for integration with LUIS and QnAMaker services. Unlike Azure Bot Framework Composer, there is no way to train those services from SDK. You need to create and train them from Azure Portal. The Bot Framework SDK provides an OrchestratorRecognizer Class, which recognizes what Azure chatbot service should be used – LUIS or QnA Maker. There are tools in the Bot Framework CLI that will help train the chatbot automatically. Finally, the Bot Framework SDK doesn’t support any integrations with new services — CLU, Question Answering, and Orchestration workflow. But it’s much easier to use HTTP requests to integrate with them in SDK than it is to use HTTP requests in Composer.
Developers need tools for fast development of powerful chatbots, and Azure chatbot services provide developers with what they need. First, Azure Bot Framework Composer, along with QnA Maker and Luis services, provides a no-code chatbot development method that concentrates on business needs. Second, the Azure Bot Framework SDK allows software developers to implement powerful and reliable enterprise-ready bots using popular programming languages. And finally, combining Azure services using integration tools gives developers even more possibilities.