AI in de adviespraktijk: Wat is AI en hoe start je (deel 1)
In deze rubriek legt AI strateeg Dennie van den Biggelaar uit hoe je specifieke AI en machine learning toepast op ‘advies in de praktijk’. In verschillende edities zullen de volgende onderwerpen worden uitgelicht:
- Starten met specifieke AI en ML
- Operationaliseren in bedrijfsprocessen
- Integreren in bestaand IT landschap
- Meten = leren: KPIs voor ML
- Ethiek, regelgeving en maatschappij
- AI en ML: een kijkje in de nabije toekomst
Logischerwijs starten we in deze eerste editie bij het begin: wat is het en hoe start je?
Hier vindt u de tekst van het artikel:
AI vs machine learning (ML)
AI is een machine of software die taken uitvoert welke van oudsher menselijke intelligentie vereisen. Machine learning (ML) is een specifiek onderdeel* van AI, waarmee een machine of software zelf kan leren van historische voorspellingen of acties.
Het bekendste en meest besproken voorbeeld van ML software is ChatGPT, dat specifiek is ontworpen om betekenisvolle stukken tekst te genereren voor de gebruiker. Er zijn echter talloze andere vraagstukken waarbij machine learning ons kan helpen. Er bestaat echter (nog) niet altijd een kant-en-klare oplossing die je direct kunt gebruiken, zoals ChatGPT.
Om zo’n bruikbare AI oplossing te bouwen, moet je de juiste competenties op het juiste moment bij elkaar brengen. Het is de taak van een AI strateeg om samen met een multidisciplinair team van business experts, ML engineers, data engineers en data scientists te bepalen wat je wilt voorspellen, hoe (accuraat) dat moet gebeuren, welke technieken je inzet en tenslotte hoe e.e.a. geoperationaliseerd en geborgd wordt, zodat het daadwerkelijk leidt tot de gewenste resultaten.
Voorbeeld: Royement voorspellen
Als kantoor wil je zeker weten dat de juiste klanten op het juiste moment de juiste aandacht krijgen van je adviseurs, zodat royement geminimaliseerd wordt. Het is ideaal als je dan weet welke klanten een hoge kans hebben dat ze gaan opzeggen. Maar hoe vertaal je dit naar het team?
Het komt vaak voor dat een klant royeert met één enkele polis. Dit is in de meeste gevallen gewoon een mutatie en hiermee wil je je ML model niet vervuilen. Stel dat een klant royeert met alle polissen binnen de hoofdbranche aansprakelijkheid, maar zegt de rest (nog) niet op. Is er dan sprake van een klant die weg dreigt te gaan? En wat als hij ook alles binnen de hoofdbranche brand opzegt, maar nog wel een rechtsbijstand en ORV heeft? Zijn er ook polissen intern overgesloten? Hoe hoog is het royement nu eigenlijk? Allemaal zaken die wilt vaststellen voordat je een team van ML engineers aan het werk zet.
Daarnaast moet je rekening houden met je forecast horizon: hoe ver wil je vooruit voorspellen? Wil je weten welke klanten gaan opzeggen de komende 1, 3, 6 of 12 maanden? Ook dit lijkt een detail, maar onder de motorkap betekent dit dat je een heel ander ML model gaat trainen.
Patronen vinden
Nadat je helder hebt gedefinieerd wát je wilt voorspellen, is het tijd om te kijken of je data daarvoor voldoende Accuraat, Beschikbaar en Consistent is (de ‘data ABC’). De belangrijkste reden waarom klanten opzeggen, komt er bottom line meestal op neer dat ze te weinig aandacht hebben gehad. De vraag is natuurlijk bij wie, wanneer en waarom er sprake is van ‘te weinig aandacht’. Deze informatie heb je niet in je datawarehouse staan en moet je dus zelf construeren door middel van feature engineering. Welke kenmerken (features) hebben een significant effect op de kans op royement? Dit is een analytisch én creatief proces waarbij kennis en ervaring van insurance experts en data scientists samenkomen.
Zodra er een deugdelijke eerste tabel met features is geboetseerd, kun je eindelijk aan de slag met machine learning. De ervaring leert dat het voorspellen van royeringen het beste te modelleren is met classification of survival analysis. Er zijn honderden verschillende ML technieken die hiervoor theoretisch geschikt zijn. In je keuze is het belangrijk om mee te nemen: in hoeverre moet het algoritme uitlegbaar zijn, hoe complex mogen de patronen zijn of hoeveel data is ABC?
Patronen valideren
Nadat de ‘machine’ aan het werk is gezet om patronen te vinden, waarmee voorspellingen gedaan kunnen worden, komt er altijd een spannend moment… hoe accuraat zijn de verschillende modellen? Hiervoor heeft de ML engineer een uitgebreide toolbox. Allereerst houdt hij een deel van de data apart om een getraind model te testen en valideren. Hiermee garandeer je de robuustheid van de gevonden patronen en voorkom je dat een model in de ‘echte wereld’ inaccurate voorspellingen geeft. Daarna wordt gekeken naar de false positives en false negatives en wat de kosten hiervan zijn.
Zo is een foutieve voorspelling dat iemand komende maand gaat opzeggen (false positive) niet zo erg. De adviseur belt de klant en trekt de conclusie dat er niets aan de hand is: het kost hem alleen 15 minuten van zijn tijd. Als het algoritme onterecht voorspelt dat iemand loyaal blijft (false negative), is dit veel duurder: je verliest een klant.
Op basis van o.a. precision, recall en AUC scores wordt het beste ML model bepaald. Daarnaast is het mogelijk om algoritmes strenger of minder streng af te stellen, zodat het beter past bij het beoogde bedrijfsproces. Dit heet parameter tuning en een ervaren ML engineer weet hoe je dit op een verantwoorde manier doet.
Hoe maak je het bruikbaar?
Vervolgens integreer je het algoritme in de operationele processen. Hoe kan de data op een veilige en efficiënte manier heen en weer, hoe kan de adviseur de voorspelling makkelijk gebruiken? Dat is het werk van data en software engineers. Tenslotte wil je ook dat de adviseur feedback kan geven op de kwaliteit van het algoritme, zodat het algoritme leert van de gebruiker. Het algoritme wordt dus steeds slimmer en steeds doelmatiger als het meer gebruikt wordt.
Dat is de echte ‘AI’ component, maar hierover meer in de volgende editie!
* AI is niet altijd ML. Zo is het algoritme Deep Blue (dat schaakgrootmeester Garry Kasparov versloeg) in 1997 geen ML, maar wel AI. ML is wel altijd AI.
Dennie is econometrist en heeft 12 jaar ervaring met het ontwerpen, bouwen en implementeren van machine learning oplossingen in de praktijk. Als mede-oprichter en CTO van Onesurance is hij verantwoordelijk voor de ontwikkeling van AI oplossingen en het succesvol operationaliseren bij opdrachtgevers in de verzekeringssector.
Post Tags :
Share :