AI optimization in Qlik Answers

Inleiding

Begin dit jaar schreef ik een blog met vijf tips om meer uit Qlik Answers te halen. Dat blog kwam uit vlak voordat Qlik Answers breed beschikbaar werd en de tips waren vooral handwerk: velden hernoemen, technische velden verbergen, beschrijvingen schrijven bij je master items en vocabulaire toevoegen. Die tips zijn nog steeds actueel, maar de techniek eronder is sinds die tijd flink veranderd.

Op 1 september introduceerde Qlik een nieuw scherm in Qlik Cloud met de naam AI optimization. Daarin staan alle instellingen bij elkaar die bepalen hoe Qlik Answers en de Qlik MCP-server jouw app begrijpen. Twee weken later kwam daar de keuze bij tussen een snelle (“fast”) en een uitgebreider denkende (“thinking”) modus. Een goed moment om te kijken wat je met deze instellingen kunt, en vooral waarom je bepaalde keuzes maakt.

Waar vind je AI optimization?

AI optimization open je vanuit de Qlik app, via hetzelfde menu waar je ook de data manager en de load script editor vindt. Voorheen stonden de instellingen voor natuurlijke taal verspreid over de business logic en de vocabulaire van Insight Advisor. Nu staan ze samen op één plek, verdeeld over vijf tabbladen: Overview, Fields & master items, Semantic understanding, Synonyms en Settings.

Belangrijk om te weten: Qlik Answers werkt met een index van je app. Elke keer dat je iets verandert in AI optimization of in je datamodel, moet je de app opnieuw synchroniseren voordat Qlik Answers de wijziging meeneemt. De knop daarvoor staat op het Overview-tabblad. Je ziet daar ook wanneer de app voor het eerst is geïndexeerd en wanneer de laatste synchronisatie was.

Overview: de beschrijving van je app

Het eerste dat opvalt op het Overview-tabblad is een beschrijving van je hele app. Die heb je niet zelf geschreven. Zodra je AI optimization activeert, leest het taalmodel achter Qlik Answers je datamodel, je master items en je visualisaties en vat het samen waar de app over gaat: welke onderwerpen, welke KPI's en welke dimensies. 

Waarom is die beschrijving belangrijk? Omdat Qlik Answers vaak meerdere apps tot zijn beschikking heeft. Een assistent kan aan meerdere apps gekoppeld zijn en bij elke vraag moet het model eerst bepalen in welke app het antwoord te vinden is. Die keuze maakt het op basis van deze beschrijving. Staat er alleen een technische samenvatting, dan wordt de kans groter dat een vraag over verkoopcijfers in de verkeerde app terechtkomt. Voeg dus vooral toe voor wie de app bedoeld is, welke vragen hij goed kan beantwoorden en, minstens zo belangrijk, welke vragen juist niet. Dat laatste voorkomt dat Qlik Answers een antwoord probeert te construeren uit data die er niet voor bedoeld is.

Rechts op dit tabblad zie je hoeveel velden en master items zichtbaar, verborgen en uitgesloten zijn. Dat getal is een goede eerste indicator. Zie je dat honderd velden zichtbaar zijn en nul verborgen, dan is de kans groot dat Qlik Answers ook je sleutelvelden, ID's en hulpvelden meeneemt in zijn analyse.

Fields & master items: wat mag het model zien?

Dit tabblad toont elk veld en master item in je app met vier instellingen: zichtbaarheid, classificatie, data value lookup en standaardaggregatie. Dit zijn de instellingen waarmee je het meest kunt sturen, dus ik neem de vier instellingen één voor één door.

Zichtbaarheid

Een verborgen veld blijft gewoon bestaan in je app. Hij blijft beschikbaar in visualisaties, expressies en set analysis. Het enige dat verandert is dat Qlik Answers het veld niet meer als bouwsteen gebruikt bij het beantwoorden van vragen.

De vraag die je jezelf bij elk veld stelt is simpel: zou een eindgebruiker hier een vraag over stellen? Een sleutelveld dat twee tabellen aan elkaar koppelt, een laadtijdstip of een hulpveld dat je alleen in een expressie gebruikt, daar vraagt niemand naar, dus die kan je verbergen. Hetzelfde geldt voor velden waarvan een betere variant bestaat. Heb je een veld Omzet en een master measure Omzet die netjes de retouren aftrekt, verberg dan het losse veld. Anders moet het model raden welke van de twee je bedoelt, en die gok gaat een deel van de tijd fout.

Een handige vuistregel: als je het veld niet in een tabelvisualisatie aan een gebruiker zou tonen, hoeft Qlik Answers het ook niet te zien. Je kunt dit trouwens ook al in je load script regelen door velden een prefix te geven en die als HidePrefix in te stellen. Velden met die prefix komen standaard als verborgen in AI optimization terecht.

Classificatie

De classificatie vertelt het model wat voor soort veld het is. Qlik bepaalt die automatisch, maar de automatische keuze klopt niet altijd. Een veld met postcodes wordt makkelijk als getal gezien, een veld met jaartallen als een gewone dimensie, en een datum die je als tekst hebt ingeladen wordt geen datum.

De classificatie bepaalt welke bewerkingen Qlik Answers op het veld kan toepassen. Een veld dat als datum geclassificeerd is kan worden gebruikt voor vragen als 'vergelijk met vorig jaar' of 'per kwartaal'. Een veld dat als geografisch is gemarkeerd kan op een kaart. Een veld dat als percentage of als bedrag bekend is wordt netjes geformatteerd in het antwoord. En een veld dat als measure geclassificeerd is wordt opgeteld, terwijl een dimensie juist wordt gebruikt om op te groeperen.

Pas de classificatie dus aan wanneer je ziet dat een veld verkeerd wordt geïnterpreteerd, en let extra op velden die in de praktijk twee rollen spelen. Een veld Aantal medewerkers kan zowel een measure zijn (hoeveel medewerkers in totaal) als een dimensie (groepeer bedrijven op grootte). In dat geval is het slimmer om er twee velden van te maken, elk met een eigen classificatie. Dat voelt als extra werk, maar het scheelt een heleboel verkeerde antwoorden.

Data value lookup

Als een gebruiker vraagt 'wat is de omzet in Duitsland?', dan moet Qlik Answers het woord Duitsland kunnen koppelen aan een waarde in een veld. Data value lookup bepaalt in welke velden het model naar zulke waarden mag zoeken.

Zet dit aan voor velden waarvan gebruikers de waarden letterlijk in hun vraag zullen noemen: landen, productcategorieën, klantsegmenten, afdelingen, statussen. Zet het uit voor measures en voor velden met heel veel unieke waarden waar niemand naar vraagt, zoals ordernummers of vrije tekstvelden. Elk veld waarin het model mag zoeken, kost tijd bij het beantwoorden en vergroot de kans dat een woord uit de vraag toevallig op een waarde lijkt en verkeerd wordt gematcht. Minder is hier beter.

Standaardaggregatie

Voor velden die als measure worden gebruikt, kun je aangeven hoe ze standaard moeten worden geaggregeerd: som, gemiddelde, aantal, minimum of maximum. Een veld Prijs per stuk moet je middelen, niet optellen. Een veld Aantal moet je juist wel optellen. Zonder standaardaggregatie kiest het model zelf, en kiest het bij twijfel voor de som. Voor master measures is deze instelling niet nodig, want daar staat de aggregatie al in de expressie.

Semantic understanding: beschrijvingen voor het taalmodel

Dit is het meest interessante nieuwe tabblad. Voor elk zichtbaar veld en master item staat hier een beschrijving die Qlik Answers gebruikt om te bepalen of dit het juiste veld is voor een vraag. En net als de beschrijving van de app heb je die niet zelf geschreven.

Waar komt die beschrijving vandaan? Het taalmodel kijkt naar alles wat het over een veld kan vinden: de naam van het veld, de titel en de beschrijving van het master item, de expressie erachter en eventuele synoniemen die je hebt toegevoegd. Daarnaast kijkt het naar de data zelf: het formaat van de waarden, het bereik, de verdeling en veelvoorkomende waarden. Uit al die informatie schrijft het een beschrijving. Bij een master measure voor de gemiddelde orderwaarde in het lopende jaar herkende het model uit de expressie dat geannuleerde orders worden uitgesloten en dat het lopende jaar wordt afgekapt op vandaag. 

Nu vraag je je misschien af: waarom een aparte beschrijving? Er staat toch al een beschrijving bij mijn master item? De beschrijving van een master item is bedoeld voor mensen: een self-service gebruiker die in de front-end een measure sleept en wil weten wat hij betekent, of een collega-developer die de app overneemt. Die beschrijving is kort en leesbaar. De semantic understanding is bedoeld voor een taalmodel dat bij elke vraag moet beslissen welk veld het pakt. Dat model heeft andere informatie nodig: hoe een gebruiker naar dit veld zou kunnen verwijzen, welke waarden erin zitten, wat het veld niet is, en welke bedrijfsregels erin verstopt zitten.

Een voorbeeld. Bij een master item “Actieve klanten” staat als beschrijving voor gebruikers misschien 'Aantal klanten met een actief abonnement'. Voor het taalmodel is het nuttig om daaraan toe te voegen dat een abonnement actief is zolang de einddatum in de toekomst ligt, dat proefabonnementen niet meetellen en dat gebruikers hier vaak naar vragen als 'klantenbestand' of 'abonnees'. Dat laatste helpt het model om de vraag 'hoe groot is ons klantenbestand?' aan dit master item te koppelen in plaats van aan het losse veld Klant-ID.

Belangrijk om te weten: beschrijvingen die je zelf aanpast blijven staan bij een volgende synchronisatie, de automatisch gegenereerde beschrijvingen worden wel opnieuw gemaakt. Je kunt je eigen aanpassing altijd weer weggooien met Clear edit. 

Daarnaast goed om te weten: het heeft geen zin om instructies in een beschrijving te zetten in de trant van 'gebruik dit veld altijd voor omzetvragen'. Qlik negeert dat soort zinnen. Beschrijf wat het veld is, niet wat het model ermee moet doen.

Je hoeft niet alle beschrijvingen te controleren. Begin bij de master measures en de dimensies waar gebruikers het vaakst naar vragen, en bij velden met een naam die voor een buitenstaander niet meteen duidelijk is.

Synonyms: het jargon van jouw organisatie

Het taalmodel achter Qlik Answers kent het Nederlands en kent bedrijfstermen in het algemeen. Wat het niet kent is het jargon van jouw organisatie. Dat 'de pijplijn' bij jullie de openstaande offertes zijn, dat 'AOV' bij jullie iets anders betekent dan bij een webshop, of dat een deel van de gebruikers Engelse termen gebruikt voor Nederlandse veldnamen. Dat soort kennis leg je vast op het Synonyms-tabblad.

Een synoniem koppel je aan een veld of master item. Je kunt meerdere termen tegelijk toevoegen, gescheiden door twee verticale streepjes, en je kunt ze in bulk importeren vanuit Excel. Interessant zijn de voorwaardelijke synoniemen: je kunt bijvoorbeeld de term 'jongeren' koppelen aan het veld Leeftijd met de voorwaarde kleiner dan 18. Zo geef je het model een definitie die nergens in je data staat.

Qlik genereert de synoniemen niet zelf, want het kent jouw organisatie niet. Je zal dus zelf de synoniemenlijst moeten samenstellen. Afhankelijk van jouw situatie kan de synoniemenlijst wel echt een verschil maken in de effectiviteit van het taalmodel.

Ga je synoniemen toevoegen, voeg dan geen synoniemen toe die al als waarde in je data voorkomen, en koppel niet hetzelfde synoniem aan meerdere velden. Daarmee maak je het model juist onzekerder. En vermijd vage termen als 'beste' of 'grootste', die betekenen voor elke gebruiker iets anders.

Settings: hoe gedraagt de assistent zich?

Het laatste tabblad gaat niet over je data, maar over het gedrag van Qlik Answers binnen deze app. Je kiest welke assistent standaard wordt gebruikt als een gebruiker Qlik Answers opent, en of gebruikers zelf van assistent mogen wisselen. Sinds half september kies je hier ook de standaard redeneermodus.

In Fast mode geeft het model snel antwoord met weinig tussenstappen. In Thinking mode neemt het meer tijd om na te denken voordat het antwoordt. Voor een app met eenvoudige KPI-vragen is Fast mode prima en prettiger in gebruik. Voor een app waar gebruikers vergelijkingen maken over meerdere dimensies en perioden is Thinking mode betrouwbaarder. Je kunt gebruikers ook zelf laten kiezen per vraag. 

Daarnaast kun je maximaal vijf starter questions toevoegen. Dat zijn de voorbeeldvragen die een gebruiker ziet als hij de chat opent. Vul je ze niet in, dan toont Qlik algemene suggesties als 'Visualize some key trends'. Vul ze wel in, want dit is je kans om gebruikers te laten zien waar deze app goed in is. Een gebruiker die als eerste voorbeeld 'Wat was de omzet per regio in het afgelopen kwartaal?' ziet, begrijpt direct wat voor vragen hij kan verwachten.

Van eenmalige inrichting naar continu verbeteren

Alles wat hierboven staat kun je in een middag inrichten. Maar de echte kwaliteit komt pas als je er een proces van maakt.

Elk antwoord dat een gebruiker krijgt heeft een duim omhoog en een duim omlaag. Bij een duim omlaag kan de gebruiker aangeven waarom: het antwoord was onvolledig, het klopte niet, het verkeerde veld werd gebruikt. Die feedback komt terecht in het Feedback-overzicht van de assistent en, voor beheerders die over alle assistenten heen willen kijken, in het Answers review portal in het Analytics activity center. 

Als developer zie je daar per vraag wat de gebruiker vroeg, welk antwoord hij kreeg, welke bronnen en velden zijn gebruikt en wat de gebruiker als reden voor zijn feedback heeft opgegeven. Blijkt dat het model bij 'omzet' steeds het verkeerde veld pakt, dan verberg je het losse veld of scherp je de semantic understanding van de master measure aan. Blijkt dat gebruikers een term gebruiken die het model niet herkent, dan voeg je een synoniem toe. Blijkt dat een datum niet als datum wordt herkend, dan pas je de classificatie aan. Daarna markeer je de vraag als beoordeeld, synchroniseer je de app en kijk je na een paar weken opnieuw.

Een goede verbetercyclus maakt het verschil tussen een leuke feature om een keertje uit te proberen en een assistent die echt waarde toevoegt. Ga je voor het eerst Answers beschikbaar maken, leg dan je gebruikers uit dat ze deze feedback ook echt geven, zeker als het antwoord niet correct was. Je zal zien dat na een paar review rondes de assistent steeds beter werkt.

Wat verandert er voor je manier van werken?

Met AI optimization is een deel van het handwerk geautomatiseerd. Beschrijvingen schrijven voor je master items doe je niet meer vanaf nul, je controleert en verbetert wat het model heeft opgeschreven. Het inzicht in welk deel van je datamodel zichtbaar is voor de AI krijg je nu gratis op het Overview-tabblad.

Maar het fundament is niet veranderd. Duidelijke veldnamen, één waarheid per KPI, datums die als datum zijn ingeladen en een vocabulaire dat past bij jouw organisatie: dat blijft het werk van de developer. AI optimization maakt dat werk zichtbaarder en makkelijker, maar als developer maak je nog steeds zelf het verschil. En dat geldt niet alleen voor Qlik. Of je dashboards nu via Qlik Answers, via de Qlik MCP-server in Claude, of via een ander AI-platform worden bevraagd, een taalmodel heeft in alle gevallen dezelfde dingen nodig: namen die zeggen wat erin zit, beschrijvingen die uitleggen hoe iets berekend wordt en waarvoor het bedoeld is, en een glossary die de taal van jouw gebruikers vertaalt naar de taal van jouw data.