Get the most out of Answers with the new AI optimization in Qlik

Introduction

Earlier this year I wrote a blog with five tips for getting 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 considerably since then.

On 1 September, 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, a choice was added between a quick (“fast”) mode and a more deliberate (“thinking”) mode. 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 within 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 scattered across the business logic and the Insight Advisor vocabulary. Now they are all in one place, spread 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 resynchronise the app 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 the last synchronisation took place.

Overview: the description of your app

The first thing you notice on the Overview tab is a description of your entire app. You did not 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 visualisations and summarises what the app is about: which topics, which KPIs and which dimensions.

Why does this description matter? Because Qlik Answers often has several apps at its disposal. An assistant can be linked to multiple apps, and for every question the model first has to decide which app holds the answer. It makes that choice based on this description. If there is only a technical summary, the chances increase 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 importantly, which questions it does not. The latter prevents Qlik Answers from trying to construct an answer from data that was never meant for it.

On the right 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, there is a good chance that Qlik Answers is also including 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 will go through the four of them one by one.

Visibility

A hidden field still exists in your app. It remains available in visualisations, 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 each 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 alternative exists. If you have a Revenue field and a Revenue master measure that neatly deducts 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 handy rule of thumb: if you would not show the field to a user in a table visualisation, Qlik Answers does not need to see it either. Incidentally, you can already arrange this in your load script by giving fields a prefix and setting that as HidePrefix. Fields with that prefix end up as hidden in AI optimization by default.

Classification

The classification tells the model what kind of field it is. Qlik determines this automatically, but the automatic choice is not always right. A field with postcodes is easily seen as a number, a field with years as an ordinary dimension, and a date you loaded as text does not 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 such as 'compare with last year' or 'per quarter'. A field marked as geographic can be shown on a map. A field known to be a percentage or an amount is formatted neatly in the answer. And a field classified as a measure is summed, whereas a dimension is used for grouping.

So adjust the classification when you see a field being misinterpreted, and pay extra attention to fields that play two roles in practice. A Number of employees field can be both a measure (how many employees in total) and a dimension (group companies by size). In that case it is smarter to turn it into two fields, each with its own classification. That feels like extra work, but it saves a whole 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 may search for such values.

Turn this on for fields whose values users will mention literally in their question: countries, product categories, customer segments, departments, statuses. Turn it off for measures and for fields with a very 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 in the question happens to resemble a value and is matched incorrectly. Less is more here.

Default aggregation

For fields that are used as a measure, you can specify how they should be aggregated by default: sum, average, count, minimum or maximum. A Unit price field should be averaged, not summed. A Quantity field, on the other hand, should be summed. Without a default aggregation the model chooses for itself, and when in doubt it opts for the sum. For master measures this setting is not needed, because the aggregation is already in 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 did not write it yourself.

Where does this 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 have 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 recognised from the expression that cancelled orders are excluded and that the current year is cut off at today.

Now you may be wondering: why a separate description? My master item already has a description, doesn't it? The description of a master item is intended for people: a self-service user who drags a measure 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. Semantic understanding is intended for a language model that has to decide with every question which field to use. 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 read 'Number of customers with an active subscription'. For the language model it is useful to add that a subscription is active as long as the end date lies in the future, that trial subscriptions do not count and that users often refer to this as 'customer base' or 'subscribers'. The latter helps the model link the question 'how big is our customer base?' to this master item instead of to the separate Customer ID field.

Important to know: descriptions you edit yourself are retained at the next synchronisation, whereas the automatically generated descriptions are recreated. You can always discard your own edit with Clear edit.

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

You do not need to check every description. Start with the master measures and dimensions users ask about most often, and with fields whose name is not immediately clear to an outsider.

Synonyms: your organisation's jargon

The language model behind Qlik Answers knows Dutch and knows business terms in general. What it does not know is your organisation's jargon. That 'the pipeline' means open quotes in your company, that 'AOV' means something different to you than to a webshop, or that some users use English terms for Dutch field names. You capture that kind of knowledge on the Synonyms tab.

You link a synonym to a field or master item. You can add several terms at once, separated by two vertical bars, and you can import them in bulk from Excel. Conditional synonyms are interesting: for example, you can link the term 'young people' to the Age field with the condition less than 18. This way you give the model a definition that appears nowhere in your data.

Qlik does not generate the synonyms itself, because it does not know your organisation. So you will have to compile the list of synonyms yourself. Depending on your situation, however, the list of synonyms can make a real difference to the effectiveness of the language model.

When adding synonyms, do not add synonyms that already occur as a value in your data, and do not link the same synonym to multiple fields. That only makes the model more uncertain. And avoid vague terms such as 'best' or 'biggest', which mean something different to every user.

Settings: how does the assistant behave?

The last tab is not 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.

In Fast mode, the model answers quickly with few intermediate steps. In Thinking mode, it takes more time to think before answering. For an app with simple KPI questions, Fast mode is fine and more pleasant to use. For an app where users make comparisons across multiple dimensions and periods, Thinking mode is more reliable. You can also let users choose for themselves per question.

In addition, you can add up to five starter questions. These are the example questions a user sees when opening the chat. If you leave them empty, Qlik shows generic suggestions such as 'Visualize some key trends'. Do fill them in, because this is your chance to show users what this app is good at. A user whose first example is 'What was the revenue per region last quarter?' immediately understands what kind of questions to expect.

From one-off setup to continuous improvement

Everything described above can be set up in an afternoon. But real quality only comes when you turn it into a process.

Every answer a user receives has a thumbs up and a thumbs down. With a thumbs down, the user can indicate why: the answer was incomplete, it was incorrect, the wrong field was used. That feedback ends up in the assistant's Feedback overview and, for administrators who want to look across all assistants, in the Answers review portal in the Analytics activity center.

As a developer, you can see there for each question what the user asked, which answer they received, which sources and fields were used and what reason the user gave for their feedback. If it turns out that 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 does not recognise, you add a synonym. If a date is not recognised as a date, you adjust the classification. Then you mark the question as reviewed, synchronise the app and check again after a few weeks.

A good improvement cycle makes the difference between a nice feature to try out once and an assistant that really adds value. If you are making Answers available for the first time, explain to your users that they should actually give this feedback, especially when the answer was not correct. You will see that after a few review rounds the assistant works better and better.

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. Insight into which part of your data model is visible to the AI now comes for free on the Overview tab.

But the foundation has not changed. Clear field names, one truth per KPI, dates loaded as dates and a vocabulary that fits your organisation: 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 does not only apply to Qlik. Whether your dashboards are queried via Qlik Answers, via the Qlik MCP server in Claude or via another AI platform, a language model needs the same things in every case: names that say what is in them, descriptions that explain how something is calculated and what it is intended for, and a glossary that translates the language of your users into the language of your data.