AI optimization in Qlik Answers

Introduction

Earlier this year I wrote a blog with five tips to get more out of Qlik Answers. That blog came out just before Qlik Answers became widely available, and the tips were mostly manual work: renaming fields, hiding technical fields, writing descriptions for your master items and adding vocabulary. Those tips are still relevant, but the technology underneath has changed quite a bit since then.

On September 1st, Qlik introduced a new screen in Qlik Cloud called AI optimization. It brings together all the settings that determine how Qlik Answers and the Qlik MCP server understand your app. Two weeks later, the choice between a quick (“fast”) and a more thorough (“thinking”) mode was added. A good moment to look at what you can do with these settings, and above all why you make certain choices.

Where do you find AI optimization?

You open AI optimization from the Qlik app, via the same menu where you also find the data manager and the load script editor. Previously, the settings for natural language were spread across the business logic and the vocabulary of Insight Advisor. Now they are together in one place, divided over five tabs: Overview, Fields & master items, Semantic understanding, Synonyms and Settings.

Important to know: Qlik Answers works with an index of your app. Every time you change something in AI optimization or in your data model, you need to sync the app again before Qlik Answers picks up the change. The button for this is on the Overview tab. There you can also see when the app was first indexed and when it was last synced.

Overview: the description of your app

The first thing you notice on the Overview tab is a description of your entire app. You didn't write it yourself. As soon as you activate AI optimization, the language model behind Qlik Answers reads your data model, your master items and your visualizations, and summarizes what the app is about: which topics, which KPIs and which dimensions.

Why does this description matter? Because Qlik Answers often has multiple apps at its disposal. An assistant can be linked to several apps, and for every question the model first has to determine which app holds the answer. It makes that choice based on this description. If it only contains a technical summary, the chance increases that a question about sales figures ends up in the wrong app. So make sure to add who the app is intended for, which questions it answers well and, just as important, which questions it doesn't. That last part prevents Qlik Answers from trying to construct an answer from data that isn't meant for it.

On the right side of this tab you can see how many fields and master items are visible, hidden and excluded. That number is a good first indicator. If you see that a hundred fields are visible and none are hidden, chances are that Qlik Answers also includes your key fields, IDs and helper fields in its analysis.

Fields & master items: what is the model allowed to see?

This tab shows every field and master item in your app with four settings: visibility, classification, data value lookup and default aggregation. These are the settings that give you the most control, so I'll go through the four of them one by one.

Visibility

A hidden field simply remains part of your app. It stays available in visualizations, expressions and set analysis. The only thing that changes is that Qlik Answers no longer uses the field as a building block when answering questions.

The question to ask yourself for every field is simple: would an end user ask a question about this? A key field that links two tables, a load timestamp or a helper field you only use in an expression: nobody asks about those, so you can hide them. The same goes for fields for which a better variant exists. If you have a field Revenue and a master measure Revenue that neatly subtracts returns, hide the separate field. Otherwise the model has to guess which of the two you mean, and part of the time that guess will be wrong.

A useful rule of thumb: if you wouldn't show the field to a user in a table visualization, Qlik Answers doesn't need to see it either. By the way, you can already take care of this in your load script by giving fields a prefix and setting that prefix as the HidePrefix. Fields with that prefix show up as hidden in AI optimization by default.

Classification

The classification tells the model what kind of field it is. Qlik determines it automatically, but the automatic choice isn't always right. A field with postal codes is easily seen as a number, a field with years as a regular dimension, and a date you loaded as text doesn't become a date.

The classification determines which operations Qlik Answers can apply to the field. A field classified as a date can be used for questions like 'compare with last year' or 'per quarter'. A field marked as geographical can be shown on a map. A field known as a percentage or an amount is formatted properly in the answer. And a field classified as a measure is summed, while a dimension is used for grouping.

So adjust the classification when you see a field being interpreted incorrectly, and pay extra attention to fields that play two roles in practice. A field Number of employees can be both a measure (how many employees in total) and a dimension (group companies by size). In that case it's smarter to turn it into two fields, each with its own classification. That feels like extra work, but it saves you a lot of wrong answers.

Data value lookup

When a user asks 'what is the revenue in Germany?', Qlik Answers needs to be able to link the word Germany to a value in a field. Data value lookup determines in which fields the model is allowed to search for such values.

Turn this on for fields whose values users will literally mention in their questions: countries, product categories, customer segments, departments, statuses. Turn it off for measures and for fields with a large number of unique values that nobody asks about, such as order numbers or free text fields. Every field the model is allowed to search costs time when answering, and increases the chance that a word from the question happens to resemble a value and gets matched incorrectly. Less is more here.

Default aggregation

For fields used as a measure, you can specify how they should be aggregated by default: sum, average, count, minimum or maximum. A field Unit price should be averaged, not summed. A field Quantity, on the other hand, should be summed. Without a default aggregation the model chooses for itself, and when in doubt it goes for the sum. For master measures this setting isn't needed, because the aggregation is already part of the expression.

Semantic understanding: descriptions for the language model

This is the most interesting new tab. For every visible field and master item there is a description here that Qlik Answers uses to determine whether this is the right field for a question. And just like the app description, you didn't write it yourself.

Where does that description come from? The language model looks at everything it can find about a field: the field name, the title and description of the master item, the expression behind it and any synonyms you've added. It also looks at the data itself: the format of the values, the range, the distribution and common values. From all that information, it writes a description. For a master measure for the average order value in the current year, the model recognized from the expression that cancelled orders are excluded and that the current year is capped at today.

Now you might be wondering: why a separate description? My master item already has a description, right? The description of a master item is meant for people: a self-service user who drags a measure into a chart in the front end and wants to know what it means, or a fellow developer who takes over the app. That description is short and readable. The semantic understanding is meant for a language model that has to decide which field to use for every question. That model needs different information: how a user might refer to this field, which values it contains, what the field is not, and which business rules are hidden in it.

An example. For a master item “Active customers”, the description for users might be 'Number of customers with an active subscription'. For the language model it's useful to add that a subscription is active as long as the end date is in the future, that trial subscriptions don't count, and that users often refer to this as 'customer base' or 'subscribers'. That last part helps the model link the question 'how big is our customer base?' to this master item instead of to the separate field Customer ID.

Important to know: descriptions you edit yourself are kept at the next sync, while the automatically generated descriptions are regenerated. You can always discard your own edit with Clear edit.

Also good to know: there's no point in putting instructions in a description along the lines of 'always use this field for revenue questions'. Qlik ignores that kind of sentence. Describe what the field is, not what the model should do with it.

You don't have to check every description. Start with the master measures and dimensions users ask about most often, and with fields whose names aren't immediately clear to an outsider.

Synonyms: the jargon of your organization

The language model behind Qlik Answers knows English and knows business terms in general. What it doesn't know is the jargon of your organization. That 'the pipeline' means your open quotes, that 'AOV' means something different to you than to a web shop, or that some of your users use terms in a different language than your field names. That kind of knowledge is what you capture on the Synonyms tab.

You link a synonym to a field or master item. You can add multiple terms at once, separated by two vertical bars, and you can bulk import them from Excel. The conditional synonyms are interesting: for example, you can link the term 'youth' to the field Age with the condition less than 18. This way you give the model a definition that doesn't exist anywhere in your data.

Qlik doesn't generate the synonyms itself, because it doesn't know your organization. So you'll have to put together the list of synonyms yourself. Depending on your situation, that list can make a real difference in how effective the language model is.

If you're going to add synonyms, don't add synonyms that already appear as values in your data, and don't link the same synonym to multiple fields. That only makes the model less certain. And avoid vague terms like 'best' or 'biggest', which mean something different to every user.

Settings: how does the assistant behave?

The last tab isn't about your data, but about how Qlik Answers behaves within this app. You choose which assistant is used by default when a user opens Qlik Answers, and whether users are allowed to switch assistants themselves. Since mid-September you also choose the default reasoning mode here.

Where does that description come from? The language model looks at everything it can find about a field: the field name, the title and description of the master item, the expression behind it and any synonyms you've added. It also looks at the data itself: the format of the values, the range, the distribution and common values. From all that information, it writes a description. For a master measure for the average order value in the current year, the model recognized from the expression that cancelled orders are excluded and that the current year is capped at today.

Now you might be wondering: why a separate description? My master item already has a description, right? The description of a master item is meant for people: a self-service user who drags a measure into a chart in the front end and wants to know what it means, or a fellow developer who takes over the app. That description is short and readable. The semantic understanding is meant for a language model that has to decide which field to use for every question. That model needs different information: how a user might refer to this field, which values it contains, what the field is not, and which business rules are hidden in it.

An example. For a master item “Active customers”, the description for users might be 'Number of customers with an active subscription'. For the language model it's useful to add that a subscription is active as long as the end date is in the future, that trial subscriptions don't count, and that users often refer to this as 'customer base' or 'subscribers'. That last part helps the model link the question 'how big is our customer base?' to this master item instead of to the separate field Customer ID.

Important to know: descriptions you edit yourself are kept at the next sync, while the automatically generated descriptions are regenerated. You can always discard your own edit with Clear edit.

Also good to know: there's no point in putting instructions in a description along the lines of 'always use this field for revenue questions'. Qlik ignores that kind of sentence. Describe what the field is, not what the model should do with it.

You don't have to check every description. Start with the master measures and dimensions users ask about most often, and with fields whose names aren't immediately clear to an outsider.

Synonyms: the jargon of your organization

The language model behind Qlik Answers knows English and knows business terms in general. What it doesn't know is the jargon of your organization. That 'the pipeline' means your open quotes, that 'AOV' means something different to you than to a web shop, or that some of your users use terms in a different language than your field names. That kind of knowledge is what you capture on the Synonyms tab.

You link a synonym to a field or master item. You can add multiple terms at once, separated by two vertical bars, and you can bulk import them from Excel. The conditional synonyms are interesting: for example, you can link the term 'youth' to the field Age with the condition less than 18. This way you give the model a definition that doesn't exist anywhere in your data.

Qlik doesn't generate the synonyms itself, because it doesn't know your organization. So you'll have to put together the list of synonyms yourself. Depending on your situation, that list can make a real difference in how effective the language model is.

If you're going to add synonyms, don't add synonyms that already appear as values in your data, and don't link the same synonym to multiple fields. That only makes the model less certain. And avoid vague terms like 'best' or 'biggest', which mean something different to every user.

Settings: how does the assistant behave?

The last tab isn't about your data, but about how Qlik Answers behaves within this app. You choose which assistant is used by default when a user opens Qlik Answers, and whether users are allowed to switch assistants themselves. Since mid-September you also choose the default reasoning mode here.

As a developer you can see there, for each question, what the user asked, which answer they got, which sources and fields were used and what reason the user gave for their feedback. If the model keeps picking the wrong field for 'revenue', you hide the separate field or sharpen the semantic understanding of the master measure. If users turn out to use a term the model doesn't recognize, you add a synonym. If a date isn't recognized as a date, you adjust the classification. Then you mark the question as reviewed, sync the app and check again after a few weeks.

A good improvement cycle makes the difference between a fun feature to try out once and an assistant that really adds value. If you're making Answers available for the first time, explain to your users that they should actually give this feedback, especially when an answer wasn't correct. You'll see the assistant get better and better after a few review rounds.

What changes in the way you work?

With AI optimization, part of the manual work has been automated. You no longer write descriptions for your master items from scratch; you check and improve what the model has written. The insight into which part of your data model is visible to the AI now comes for free on the Overview tab.

But the foundation hasn't changed. Clear field names, one truth per KPI, dates loaded as dates and a vocabulary that fits your organization: that remains the developer's job. AI optimization makes that work more visible and easier, but as a developer you still make the difference yourself. And that doesn't just apply to Qlik. Whether your dashboards are queried through Qlik Answers, through the Qlik MCP server in Claude, or through another AI platform, a language model needs the same things in every case: names that say what's in them, descriptions that explain how something is calculated and what it's meant for, and a glossary that translates the language of your users into the language of your data.