If you cannot build a system that answers a 'how-to' question as easily as it handles a 'book a flight' request, your Azure AI solution will feel useless and frustrating to users. This chapter unpacks the two core services that let machines understand human language—both the simple 'ask and answer' kind and the more complex back-and-forth conversation—so you can design solutions that actually work.
Jump to a section
A simple way to picture Question Answering and Conversational Language Understanding
A busy hotel lobby, late Sunday afternoon. A queue of weary travellers stretches back from the reception desk. The single receptionist, Ahmed, handles each guest differently. One guest marches up and asks, 'What time is the pool open until?' Ahmed quickly scans the printed FAQ sheet taped to his monitor — it says 'Pool closes at 9 PM.' He answers instantly. That is a Question Answering solution: a direct, factual answer to a clear, single-shot query.
Next, a confused guest shuffles forward and says, 'I need to check out, but, uh, I lost my key card... and I think I left my phone charger in the room — can someone check?' This is a different beast. Ahmed cannot just read a static answer. He has to ask clarifying questions: 'What room number, sir? Did you leave the 'Do Not Disturb' sign up?' He checks the system, calls housekeeping, and navigates a whole conversation to achieve the guest's goal (getting his deposit back, retrieving his charger). This is Conversational Language Understanding. The system (Ahmed) must interpret an incomplete, multi-intent request and manage a back-and-forth dialogue.
The hotel's 'knowledge base' is Ahmed's printed FAQ sheet for simple questions. His own brain, trained by experience, is the conversational engine that handles the messy, real-world dialogue. In Azure, these are two separate but related services: a fixed knowledge base for QnA, and a trained Language Understanding model for conversation. Both sit behind the same front desk — the customer-facing application — but they serve fundamentally different functions.
When you talk to a computer, the computer has no natural understanding of your words. It sees only strings of text. To make sense of them, it needs specialised tools. For the AI-102 exam, Microsoft expects you to understand two such tools: Question Answering and Conversational Language Understanding (CLU). They sound similar but solve entirely different problems.
Question Answering (often called QnA Maker in older versions, now part of the Azure AI Language service) is designed for exactly what it sounds like: you ask a question, and the system gives you a direct answer. Think of it as a smart FAQ. It does not 'understand' your question in a human sense. Instead, it takes your question text, converts it into a mathematical representation (a vector), and compares it against a database of pre-written question-answer pairs (a knowledge base). It finds the closest match and returns that answer. This is extremely useful for customer support portals that need to answer repetitive questions like 'How do I reset my password?' or 'What are your return policies?'
Conversational Language Understanding (CLU) is far more sophisticated. It is designed to manage a dialogue, not just answer a single question. CLU works with two core concepts: intents and entities. An intent is the user's goal — what they want to accomplish. For example, 'BookFlight' is an intent. Entities are the specific pieces of information the user provides to fulfil that intent — for example, the destination city, the departure date, and the number of passengers. When a user types 'I want to fly to London next Tuesday,' CLU identifies the intent (BookFlight) and extracts the entities (destination: London, date: next Tuesday).
CLU does not stop there. It tracks the state of the conversation. If the user says 'London' but the system has already asked for the destination in a previous turn, CLU knows not to ask again. This ability to maintain context across multiple turns is called dialogue state management. It is what makes a conversation feel natural rather than robotic.
Why do these two services coexist? Because they are optimised for different scenarios. QnA is fast, cheap, and deterministic for simple queries. CLU is slower and more expensive but handles complexity and ambiguity. In a real application, you often use both: a CLU model to handle the first few conversational turns, and when the user asks a factual question, the system hands off to a QnA knowledge base to retrieve the exact answer.
For the exam, you must know the difference between a knowledge base (used by QnA) and a CLU model (used by CLU). A knowledge base is a static collection of question-answer pairs that you build manually or import from a website. A CLU model is a machine learning model that you train with example conversations (labelled utterances) to recognise intents and entities. You deploy both as endpoints that your application calls via REST APIs or SDKs.
The key components of a QnA solution include:
- The knowledge base itself (the set of QnA pairs). - Active learning (the system suggests alternative phrasings to improve accuracy over time). - Chit-chat (pre-built conversational personality to handle small talk). - Multi-turn extraction (the ability to create follow-up prompts that guide the user to more specific answers). For CLU, the key components are:
- The project (the container for your model). - Intents (the goals you want to recognise). - Entities (the data points you want to extract). - Utterances (example phrases you provide to train the model). - The evaluation (a test run that tells you how accurate your model is). Both services are part of the Azure AI Language umbrella. You access them through the Language Studio portal, which provides a visual interface for building, training, and deploying your models without writing code. A common exam scenario: a company has a customer support chatbot. The requirements say it must answer common questions about shipping times and also handle a full booking flow for returns. You need both services. The FAQ part is QnA. The booking flow requires CLU to understand the user's intent at each step ('I want to return a shirt' then 'Why are you returning it?' then 'What colour was it?'). The CLU model guides the conversation, and at the end, it might call the QnA knowledge base to pull up the exact return policy. In summary: QnA answers a single question. CLU understands a conversation. Both are crucial for building AI solutions that interact with people naturally.
Analyse the user's request type
Before building anything, determine if the request is a single factual question (e.g., 'What is your return policy?') or a multi-turn task (e.g., 'I want to return a shirt'). This decision determines whether you need QnA or CLU. If it is a task, you will also need to identify the entities (data points) required to complete it.
Create a knowledge base (for QnA) or a project (for CLU)
In Azure Language Studio, you create a new resource. For QnA, you build a knowledge base by importing FAQs, web pages, or manually entering question-answer pairs. For CLU, you create a project, define the intents (goals) and entities (slots of data), and add example utterances (the phrases users will type) for each intent.
Train and evaluate the model
For QnA, you train the knowledge base and test it with sample questions to see if it returns the correct answer with a high confidence score. For CLU, you train the machine learning model on your utterances, then evaluate it on a test set to measure accuracy, precision, and recall. You iterate by adding more utterances until the model meets your threshold.
Deploy the solution to an endpoint
You publish the QnA knowledge base to an Azure Bot Service runtime endpoint. You deploy the CLU model as a prediction endpoint. Both endpoints return JSON responses containing the answer (QnA) or the identified intent and entities (CLU). You then configure your bot or application to call the appropriate endpoint based on the user's input.
Implement orchestration logic
In your application code (often using the Bot Framework SDK), you write logic that decides which service to call. A common pattern: first try the QnA endpoint. If the confidence score is high (e.g., above 0.7), return that answer. If not, fall back to the CLU endpoint to understand the user's intent and proceed with the conversational flow. You must also handle handoffs to human agents for unrecognised intents.
You are an AI engineer at a medium-sized e-commerce company called 'StyleBox'. They sell clothing online. Their current customer service team is drowning in chat messages. They want a chatbot to handle first-level support. The boss says, 'Just make it answer all the questions.' You know that is impossible with one single approach. Here is exactly what you would do.
First, you audit the most frequent customer queries. You find three categories:
- Factual questions: 'Where is my order?', 'Do you ship to Canada?', 'What size chart should I use?'. These are perfect for QnA. They have a single, definitive answer. You will build a knowledge base. - Procedural questions: 'How do I start a return?', 'Can I change my delivery address?'. These are multi-step. The user needs a guided conversation. You will build a CLU model. - Troubleshooting: 'My item arrived damaged', 'The colour does not match the photo'. These are highly variable and often require a human agent. You will let the chatbot gracefully hand off to a human. Next, you open Azure Language Studio. You create a new QnA project. You import your existing FAQ page from the company website. It already has 50 questions and answers. Azure automatically extracts them and builds a knowledge base. You also enable 'multi-turn extraction' so that when a user asks 'How do I return something?', the bot can follow up with 'What was the reason for the return?' and give a different answer for 'wrong size' versus 'damaged'.
Then, you create a CLU project. You define the intents: 'TrackOrder', 'StartReturn', 'ChangeAddress', 'TalkToAgent'. You train the model with 15 example utterances per intent. For 'TrackOrder', you include phrases like 'Where is my package?', 'Order status', 'Has my item shipped?'. You also define entities: 'OrderNumber', 'ProductName', 'ReasonForReturn'. You label the entities in your utterances. You train and evaluate the model until the accuracy score is above 90 percent. You build a single bot using the Azure Bot Framework. The bot receives a message. It first sends the message to the QnA endpoint. If the QnA service returns a high-confidence answer (score above a threshold, say 70 percent), the bot sends that answer to the user. If QnA is not confident, the bot passes the message to the CLU endpoint. The CLU model identifies the intent and entities. The bot then executes the appropriate logic: for 'StartReturn', it walks the user through the return steps, asking for the order number and reason. You deploy the bot to Azure App Service and connect it to a web chat channel on the StyleBox website. You monitor the logs. Over the first month, the bot handles 60 percent of all queries without human intervention. The customer satisfaction score rises because users get instant answers. You now have a production conversational AI solution that uses both QnA and CLU working together.
The AI-102 exam tests your ability to distinguish between Question Answering and Conversational Language Understanding, and to know when to use each. They love to give you a scenario and ask: 'Which service should you use?' The trap is that many scenarios sound like they need conversation but actually just need a simple answer. Memorise this rule: if the user is asking for a static piece of information (a policy, a fact, a number), it is QnA. If the user is performing a task that requires multiple steps and the system needs to ask clarifying questions, it is CLU.
They also test the specific terminology. You need to know:
- 'Knowledge base' is the collection of QnA pairs. - 'Active learning' is the feature in QnA that suggests phrasings to improve accuracy. - 'Chit-chat' is a pre-built set of casual conversation answers (e.g., 'Hi', 'How are you?'). - 'Multi-turn extraction' in QnA means creating a tree of follow-up questions. - 'Intents' are the user's goals in CLU. - 'Entities' are the data points extracted from the user's utterance. - 'Utterances' are the example phrases you use to train the CLU model. Exam traps:
- They might describe a QnA feature and call it a CLU feature. For example, 'active learning' belongs to QnA, not CLU. - They might ask about 'pre-built domains' — those are only for QnA, not CLU. - They might ask about 'evaluation' — both services have evaluation, but the metrics are different. For QnA, the metric is 'rank score' (how confident the answer is). For CLU, the metric is 'accuracy' (how often the model correctly identified the intent). - They might present a scenario that requires a 'follow-up prompt' — that is always QnA, not CLU. You must also know the deployment workflow for each service. For QnA: you create a knowledge base, train it, test it, and then deploy it to a runtime endpoint. For CLU: you create a project, define intents and entities, add labelled utterances, train the model, evaluate it, and then deploy it to a prediction endpoint. Both can be accessed via REST APIs.
A specific exam question pattern: 'A company wants to build a chatbot that helps customers track orders and also answer questions about shipping policies. Which combination of services should they use?' Correct answer: Use CLU for the order tracking flow (because it requires extracting the order number and potentially asking follow-ups) and QnA for the shipping policy questions. Wrong answer: Use only QnA, because the order tracking flow is not a single QnA pair. Another wrong answer: Use only CLU, because the shipping policy questions are static facts that do not require a multi-turn dialogue.
Finally, they test the concept of 'orchestration'. You can use a service called 'Orchestrator' (part of the AI Language service) to route a user's request to either QnA or CLU based on the intent. This is a high-level topic they like to ask about. Remember: Orchestrator does not replace QnA or CLU; it sits in front of them and directs traffic.
Question Answering returns a single, static answer from a knowledge base; Conversational Language Understanding manages a multi-turn dialogue by identifying intents and entities.
A knowledge base is a collection of question-answer pairs; a CLU model is a machine learning model trained on labelled utterances.
Use QnA for factual queries that have one correct answer; use CLU for tasks that require clarifying questions and extracting variable data.
Active learning is a QnA feature that improves your knowledge base by suggesting alternative phrasings based on user behaviour.
CLU maintains dialogue state — it remembers what the user said in previous turns so it does not ask for the same information twice.
In AI-102, the most common trap question asks you to choose between QnA and CLU for a scenario that requires both — always identify if the user needs a guided conversation or a simple lookup.
You deploy both QnA and CLU as prediction endpoints that your bot application calls via REST API.
Pre-built chit-chat (greetings, small talk) is available only in QnA, not in CLU.
These come up on the exam all the time. Here's how to tell them apart.
Question Answering (QnA)
Answers a single, isolated question with a pre-written answer.
Uses a static knowledge base of question-answer pairs.
Cannot maintain conversation state or ask follow-up questions on its own.
Conversational Language Understanding (CLU)
Manages a multi-turn dialogue to complete a user task.
Uses a trained ML model to identify intents and extract entities.
Tracks conversation state to avoid repeating questions.
Knowledge Base
A collection of question-answer pairs, built manually or imported.
Uses text similarity (search) to find the best matching answer.
Improved through active learning (suggested alternative phrasings).
CLU Model
A machine learning model trained on labelled utterances.
Uses pattern recognition to identify user intent and extract data.
Improved by adding more diverse example utterances and retraining.
QnA Active Learning
Automatic suggestion of alternative phrasings based on user queries.
Does not require manual labelling — the system proposes candidates.
Only modifies the knowledge base, not a machine learning model.
CLU Model Retraining
Requires manual review and labelling of new utterances.
You explicitly add new labelled examples to the training set.
Retrains the entire machine learning model from scratch.
Mistake
Question Answering and Conversational Language Understanding are the same thing, just different names from different versions of Azure.
Correct
They are fundamentally different services. QnA gives a direct answer from a static knowledge base. CLU understands the user's intent and extracts entities to manage a multi-turn dialogue. They serve different purposes and you often use both together.
The names sound similar and both involve language. Beginners assume 'language understanding' includes answering questions, which causes them to overlook the architectural difference.
Mistake
You must train a CLU model for every single thing the user might say, including 'Hello' and 'Goodbye'.
Correct
CLU only needs to be trained for the specific intents you want to handle. Greetings and small talk can be handled by pre-built chit-chat functionality in QnA or by a simple greeting handler in the bot logic. Training unnecessary intents wastes time and can confuse the model.
Newcomers believe they need to manually cover every possible phrase, but the model is designed to generalise from a small set of examples.
Mistake
QnA knowledge bases can understand natural language because they use AI.
Correct
QnA does not 'understand' language. It uses a text similarity algorithm (a type of search) to find the closest match between the user's question and the questions in the knowledge base. It does not extract meaning or intent. It is a search engine with a conversational interface, not an AI that comprehends.
Microsoft markets QnA as part of the 'AI Language' service, so beginners assume it possesses genuine language understanding.
Mistake
You cannot use QnA and CLU together in the same application.
Correct
You can and should combine them. A common architecture is to route simple factual queries to QnA and complex multi-turn tasks to CLU. They are complementary, not mutually exclusive.
Because they are presented as separate services in the exam curriculum, beginners think they are alternatives to each other rather than tools for different jobs.
Mistake
Entities in CLU are optional — you can build a model with only intents.
Correct
Entities are optional in theory, but almost every practical CLU application requires them. Without entities, the model knows the user wants to 'BookFlight' but has no idea about the destination or date. The exam assumes you will use entities for any data that varies between requests.
Beginner documentation sometimes omits entities to simplify initial examples, leading learners to underestimate their importance.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
QnA Maker (now called Question Answering in the AI Language service) is for direct factual answers from a static knowledge base. Conversational Language Understanding (CLU) is for multi-turn dialogues where the system needs to identify the user's goal (intent) and extract details (entities).
Not effectively. QnA is excellent for FAQs but cannot handle multi-step tasks like booking a return or changing an address, because it does not maintain conversation state or extract entities. You would need to combine QnA with CLU for a complete solution.
For the AI-102 exam, you need to understand the concepts and how to deploy them. In practice, you can build both in Azure Language Studio without writing code. However, integrating them into a bot typically requires some code using the Bot Framework SDK.
An intent is the user's goal, such as 'BookFlight' or 'CancelOrder'. An entity is a piece of data extracted from the user's utterance, like a date, city name, or order number. Intents tell the system what to do; entities provide the details to do it.
Active learning is a feature that monitors user queries and suggests alternative phrasings for your knowledge base questions. When users ask questions that are close to existing questions but not exact matches, the system proposes adding those phrasings to improve future accuracy.
Yes, for good accuracy you typically need at least 15-20 example utterances per intent. More complex entities may need even more examples. The quality of your examples matters: they should cover the variety of ways real users will phrase their requests.
You've finished Question Answering and Conversational Language Understanding. Continue through the AI-102 study guide to build a complete picture of the exam.
Done with this chapter?