Wat als chatbots ons begrepen en niet alleen een antwoord geven

In een recent verleden hebben we ons bezig gehouden met chatbots. Een daarvan heette ELS  en zij gaf antwoorden en tips rondom vragen die je aan een woningcorporatie kunt stellen. Heel eenvoudig, een text-mining  tool loslaten op een kennisdatabase die bestaat uit kenniskaarten en die combineren met chatbox software voor de dialoog met de gebruiker. U stelt de vraag (zoveel mogelijk in natuurlijke taal) en de tekst-mining machine gaat op zoek naar antwoorden die het dichtst bij de vraag liggen. En als side-kick wat scripting gebaseerd op Regular Expressions om niet-relevante vragen en schuttingtaal af te vangen en te beantwoorden. Denk aan vragen als ‘hoe oud ben je’, ‘waar woon je’, ‘wil je met me trouwen’, etc.  Uit de bijgehouden statistieken scoorde de chatbot best redelijk. Ook door het fine-tunen van ELS door steekwoorden uit de vragen toe te voegen aan de kenniskaarten uit de kennisdatabase, werd ELS steeds beter in het beantwoorden van de vragen.

Maar in de praktijk is het net wat ingewikkelder. Simpele vragen als ‘wanneer kan ik een afspraak maken’, ‘hoeveel huursubsidie kan ik ontvangen’ of ‘mijn buren maken wel veel herrie’ zijn goed te ondervangen met een text-mining tool die slim zoekt in de kennisdatabase. Vragen die meer interpretatie en context vereisen zijn lastiger.

Bijvoorbeeld de vraag:’ kan ik met mijn rolstoel het appartement dat u verhuurt, bewonen’. Misschien dat ELS een antwoord kan geven dat gaat over toegankelijkheid voor invaliden van het appartementsgebouw. Maar dat zal in veel gevallen een vooraf gescript antwoord of dialoog zijn. Een echte (menselijke) klantservice agent zal meteen begrijpen dat het om meer gaat dan alleen een feitelijk antwoord op deze vraag. Hier is een probleem op te lossen van iemand die fysieke beperkingen heeft en wil wonen in het appartement dat de verhuurder aanbiedt.

Het gaat niet alleen om te antwoorden dat de corporatie geheel voldoet aan de toegankelijkheidseisen zoals die wettelijk zijn vastgelegd. Denk aan brede deuren en op- en afritten voor rolstoelen en de beschikbaarheid van een lift. Het gaat ook om de vraag of het een tijdelijk probleem is waarmee de vrager te maken heeft, of er een begeleider is (medehuurder of hulphond),  zijn de alle kamers en toilet toegankelijk voor een rolstoelgebruiker, etc. Veel vragen die je niet zo makkelijk met een slimme zoekmachine oplost. Het gaat niet om het antwoord op de vraag, maar om het oplossen van een probleem: ik wil als rolstoelgebruiker wonen in een van jullie woningen. Een oplossing is niet direct eenvoudig maar een oplossingsrichting is wellicht te vinden in de combinatie van text-mining en concept maps. Met een concept map kun je een beeld van de context van een vraag construeren aan de hand van begrippen/steekwoorden in de vraag. De concept map geeft je vervolgens de ‘inference’ (redeneer)ruimte om het probleem aan te pakken en te beantwoorden.

Een voorbeeld. Stel we hebben een chatbot die vragen over Sinterklaas kan beantwoorden. En je stelt aan de chatbot de volgende vraag: “Kan Sinterklaas dit jaar wel bij ons thuis komen?”. De tekst-mining tool gaat aan de slag met de vraag en komt met het volgende antwoorden: Sinterklaas is op 5 december jarig en er zijn hulp-sinterklazen die je kunt huren voor een bezoek aan huis. Met een concept-map over Sinterklaas kun je ook de discussie rondom Sinterklaas en Zwarte piet in beeld krijgen. Misschien bedoelde de vraagsteller wel of het acceptabel is om Sinterklaas een huisbezoek te laten afleggen, gezien de discussie over zijn ‘medewerkers’. Met een concept-map kun je niet alleen de feitelijke, naïeve vraag over Sinterklaas beantwoorden maar ook de actuele achtergrond toelichten en de discussie presenteren. Op deze manier geeft de chatbot niet eenvoudigweg een antwoord op de vraag maar wordt ook een problematische situatie meegenomen in zijn antwoord.

Waar kun je het beste wonen in Eindhoven

Stel je gaat naar Eindhoven verhuizen. Bijvoorbeeld omdat je een leuke baan in de slimste regio van de wereld hebt gevonden. Dan moet je op zoek gaan naar een huis in een geschikte buurt. Welke buurt is het meest geschikt? Dat is natuurlijk afhankelijk van jouw eisen en wensen. In veel gevallen gaat het dan om een beoordeling hoe sociaal, veilig en schoon een buurt is. Ook inkomen speelt een rol, immers je wilt wonen in buurt met buurtgenoten die een beetje qua welstand gelijk gestemd zijn. Dus niet veel rijker maar ook niet veel armer dan jijzelf bent.

RPA

De gemeente Eindhoven heeft een buurtmonitor laten maken. Daarin kun je veel informatie vinden over de afzonderlijke buurten in Eindhoven. Echter je kunt met deze buurtmonitor niet buurten met elkaar vergelijken. In de vorige blog heb ik laten zien hoe met Robotic Process Automation (RPA) de gegevens van de buurtmonitor van Eindhoven van het scherm kunt halen en kunt opslaan in een Excel file.

Tableau dashboard

Deze buurt gegevens heb ik gebruikt om met Tableau een soort Buurt-Selectie-Dashboard te maken. In het dashboard kun je aan een aantal parameters draaien om te zien welke buurten in Eindhoven voldoen aan jouw criteria over Inkomen, Economie, Sociale Samenhang, Veiligheid, Ruimte (milieu, verkeer, e.d.) en de totale Buurtscore.
De waarden waaruit je kunt kiezen zijn: All(e), Ruim Benedengemiddeld, Benedengemiddeld, Gemiddeld, Bovengemiddeld, Ruim Bovengemiddeld.

Hieronder staat het buurtmonitor dashboard. Klik op de afbeelding en je gaat naar het dashboard.

RPA, de `banenkiller` van de middelbaar opgeleide medewerker?

RPA

Robotic Process Automation oftewel RPA. Sneller dan gedacht en als een sluipmoordenaar wordt bij verzekeraars, banken, (semi)overheden en uitvoeringsorganisaties RPA ingezet om allerlei werkprocessen te automatiseren. En het ziet er naar uit dat de middelbaar en wellicht ook de hoger opgeleide medewerker het ‘bokje’ is. Veel werkprocessen waarbij het vergaren, combineren en beoordelen van gegevens uit verschillende gegevensbronnen een rol spelen, liggen of lagen binnen de skills en competentie van de middelbaar en hoger opgeleide medewerker. Immers het kritisch beoordelen van de verzamelde gegevens heeft menselijke intelligentie nodig. Meer en meer worden deze werkprocessen geheel of gedeeltelijk gedigitaliseerd met RPA software waarbij de software de acties van de gebruiker simuleert. Denk aan inloggen, keyboard- en muisinput genereren, scherminformatie lezen en verwerken, etc.

RPA Robots

Glad en Niet-glad

Een voorbeeld uit de praktijk waarbij gebruik wordt gemaakt van RPA.
Bij een semi-overheidsorganisatie wordt de aanvraag voor een bepaald product (dienst) verwerkt in een geautomatiseerd systeem. In het verwerkingssysteem worden regels toegepast. Voldoet de aanvraag aan de regels, dan wordt de dienst automatisch (‘glad’) geleverd. Gemiddeld wordt ongeveer 80% ‘glad’ verwerkt. De resterende 20% die niet voldoet aan de regels (‘niet-glad’) wordt apart gezet ter beoordeling van een medewerker. De medewerker bekijkt vervolgens of de aanvrager de juiste informatie heeft ingevoerd en of de aanvraag niet gerelateerd is aan fraude. Hiervoor worden verschillende bronnen (denk aan Belastingdienst, KvK, UWV, Sociale Dienst, etc.) via de desktopcomputer geraadpleegd. D.w.z. de medewerker logt in, start de applicaties op, voert gegevens in, bekijkt de resultaten, beoordeelt en maakt de beslissing kenbaar aan het centrale systeem. De medewerkers voeren deze handelingen (substantieel onderdeel van hun werk) handmatig uit.

Met RPA worden deze als ‘niet-glad’ beoordeelde gevallen geautomatiseerd. In de praktijk blijkt dat in bovengenoemde casus ongeveer 60% van de ‘niet-glad’ verwerkte aanvragen door de RPA aanpak gekenmerkt wordt als correct. Dat betekent dat 40% van de 20% initiële ‘niet-glad’ verwerkte gevallen (dat is 8% van het totaal aantal aanvragen) een ‘menselijke beoordeling’ nodig hebben.
Met andere woorden: waar we eerst 20 van de 100 aanvragen handmatig moesten bekijken, is dat aantal met RPA gereduceerd tot 8 aanvragen van de 100. Als we er vanuit gaan dat een medewerker ongeveer de helft van zijn/haar tijd bezig is met het beoordelen van een aanvraag, dan levert het toepassen van RPA een aanzienlijke besparing in mensuren op. Maar gelukkig, er blijft toch nog een aantal gevallen over die menselijke beoordeling nodig heeft.

RPA Software

Er zijn verschillende RPA platformen beschikbaar. Een van de toppers volgens Forrester (Forrester Wave RPA 2018) is UiPath. UiPath is ontwikkeld door een Roemeense ingenieur en is in 2015 internationaal doorgebroken. Het platform bestaat uit een drietal componenten: UiPath Studio (IDE), UiPath Orchestrar en UiPath Robot. Als voorbeeld is met UiPath onderstaande robot gebouwd die gegevens op een website invoert en vervolgens de gepubliceerde gegevens leest en opslaat in een bestand.

Buurtthermometer

Veel gemeenten publiceren tegenwoordig op hun website statistische informatie over hun wijken en buurten. Vaak in de vorm van een soort ‘thermometer’ die aangeeft hoe het ermee staat met het inkomen, werk, sociale samenhang, ruimte en veiligheid. De gemeente Eindhoven heeft hiervoor een website ingericht www.buurtthermometer.nl . Op deze site kun je de scores zien van de buurten in  Eindhoven. Stel dat je als geïnteresseerd burger of professional de verschillende buurten wilt vergelijken of analyseren. Dan is dat lastig omdat de buurtthermometer website wel de afzonderlijke gegevens per buurt laat zien, maar je geen mogelijkheid biedt om gegevens te combineren of te vergelijken.

Met RPA kunnen we wel de gepresenteerde gegevens van de site halen. Gewoon door een robot te bouwen die de gepresenteerde informatie voor elke buurt van het scherm ‘schraapt’ en wegschrijft naar bijvoorbeeld een CSV bestand.

Robot

Hoe ziet zo’n robot er nu uit? Het bouwen van een robot kan op verschillende manieren, maar een manier die goed aansluit bij de werkwijze van mensen, is het ‘recorden’ (opnemen) van de handelingen die een gebruiker uitvoert om de gegevens van een buurt op het scherm te tonen. UiPath kent deze functie uiteraard en die hebben we gebruikt om het basisproces vast te leggen. Alle handelingen die de gebruiker verricht worden vastgelegd. Als je het vastgelegde proces afdraait, dan zie je op het scherm in de ‘herhaling’ de uitgevoerde acties.

Met UiPath kun je vervolgens het vastgelegde proces parametriseren en aanpassen. Bijvoorbeeld door de interactief ingevoerde naam van de buurt te vervangen door het inlezen van een Excelbestand met de namen van de buurten. De gepresenteerde gegevens op het scherm kun je kopiëren en opslaan in variabelen. Deze variabelen schrijf je vervolgens weg naar een bestand of sla ze op in een datatable voor verdere verwerking.

In de video hieronder zie je de robot aan het werk. Eerst wordt een Excelbestand met de namen van de buurten ingelezen in een datatable. Daarna wordt er een webbrowser geopend met de URL van de buurtmonitor. De datatable wordt doorlopen en de buurtmonitor wordt gevoed met de successievelijke buurtnamen. Per buurt worden de gegevens van het scherm gelezen en weggeschreven in CSV formaat naar een bestand. Klaar is Kees.

En als kers op de taart kunnen we met Tableau een alternatief dashboard bieden. Met het dashboard kun je op een interactieve manier gegevens combineren en kun je bijvoorbeeld de rijkste, armste, gezelligste, engste en rustigste buurten in Eindhoven zien. Daarover meer in deze blog.

Zorguitgaven Vektis 2015 met Tableau

Uit de Vektis-gegevens van de zorguitgaven in 2015, zijn aardige patronen te ontdekken. In de afbeelding hieronder zien we zorguitgaven per verzekerd jaar voor verschillende leeftijdsgroepen. We zien bijvoorbeeld dat de zorguitgaven van pasgeborenen, 0-jarigen (1) een factor 5 hoger zijn dan bij 1-jarigen. In 2015 waren de zorguitgaven per verzekerd jaar voor een 0-jarige € 7.101. Voor een 1-jarige zijn de zorguitgaven per verzekerd jaar € 1.401. Het goedkoopst zijn de 5 tot 9-jarigen (2) en na je 50-ste jaar (4) stijgen de zorguitgaven snel. Bij (3) zie je een piekje bij de dertigers. Dat wordt veroorzaakt door vrouwen die rond die leeftijd zwanger raken en kinderen baren. Naarmate we ouder worden, boven de 85 jaar (5) dan vlakt de grafiek wat af. Wat daaraan ten grondslag ligt is moeilijk te zeggen. Waarschijnlijk spelen meerdere oorzaken een rol. Bijvoorbeeld dat mensen die zo’n hoge leeftijd bereiken relatief gezond zijn, dat er minder zorg besteed wordt vanwege het naderend levenseinde of dat de zorgopnamecapaciteit bij personen met zo’n hoge leeftijd, afneemt.

Om wat meer inzicht te krijgen hebben we met Tableau Public wat extra grafieken gemaakt. Elke grafiek heeft filters die je kunt gebruiken. Naast een staafgrafiek zijn er in de tabbladen ook andere presentaties van de gegevens te zien. Om het geheel goed te kunnen zien en te gebruiken, kun je rechtsonder op het Full Screen icoon klikken.

Door de verschillende filters toe te passen zie je onder andere dat per verzekerd jaar de mannen vanaf hun 60-ste levensjaar meer zorguitgaven voor hun rekening nemen dan vrouwen.

Met de parameter ‘Kosten per verzekerd jaar’:

  • Yes = bereken de zorguitgaven per verzekerd jaar (lees per individu)
  • No = bereken de zorguitgaven voor de hele leeftijdsgroep

en met het gebruikmaken van de verschillende filters, kun je zien wat de verschillen zijn per individu of per leeftijdsgroep, geslacht, gemeente of soort zorguitgave (huisarts, specialist, tandarts, etc.). Dit levert leuke inzichten op of bevestigt je (voor)oordelen m.b.t. de zorguitgaven.

LET WEL: de Vektis dataset bevat alleen de zorguitgaven die door de zorgverzekeraars zijn aangemeld/gedeclareerd.

Frauduleuze transacties en RapidMiner

Het ontdekken van financiële fraude is een belangrijk tak van sport binnen de Machine Learning wereld. Probleem is de publieke beschikbaarheid van real-life data. De banken beschikken uiteraard over hun eigen data-sets, maar voor buitenstaanders is het lastig om aan goede data te komen vanwege allerlei privacy-regels en dergelijken.

De data-set die ik heb gebruikt is afkomstig van Kaggle en is gegenereerd door simulatie van financiële transacties. Voor een detail-beschrijving van de data-set, zie http://bth.diva-portal.org/smash/get/diva2:955852/FULLTEXT06.pdf

In het kort bestaat de data-set uit een aantal transacties (ongeveer 6 miljoen) die voor een periode van 30 dagen zijn gegenereerd. De transacties zijn afkomstig van een mobiel-betalen provider. Het zijn betalingen van klanten onderling en van klanten naar merchants (winkeliers?) die diensten rondom het mobiele betalen aanbieden. Denk aan diensten als het storten of opnemen van cash geld en het uitschrijven van cheques voor klanten die geen mobiel-betalen account hebben.

In de data-set zijn twee fraude-scenario’s opgenomen. Het eerste scenario is dat de boeven via phishing de rekeninggegevens van een klant hebben achterhaald en vervolgens de rekening leeghalen door het geld over te maken naar muilezel-rekeningen en het geld vervolgens als cash bij de merchant opnemen. Het tweede scenario bestaat uit scamming waarbij klanten overgehaald worden rekeninggegevens, inclusief PIN-codes bekend te maken voor een of ander doel en waarna ook de rekening geplunderd wordt.

Deze blog is gebaseerd op een artikel op Kaggle van Arjun Joshua: https://www.kaggle.com/arjunjoshua/predicting-fraud-in-financial-payment-services/notebook. In het artikel van wordt gebruik gemaakt van Python. Mijn benadering is iets anders en ik probeer met de data-set en RapidMiner een model te ontwikkelingen om fraude in de transactie-log op te sporen/te voorspellen.

Data exploratie

De eerste stap is het analyseren en opschonen van de data. Hiervoor heb ik Excel gebruikt. Nadeel is dat Excel maximaal 1 miljoen rijen (1.048.576) aan kan. We werken dus met 1/6 van de gehele dataset (is ongeveer 4 dagen logging). We veronderstellen dat de verdeling van de fraudegevallen ‘uniform’ is over de gehele periode 30 dagen. Voordeel is dat we het ontwikkelde machine learning model kunnen testen op de resterende 5 miljoen transacties.

Hieronder staat een voorbeeld van de data-set.

  • Step: het nummer geeft het uur aan. Step = 1 betekent het 1e uur van de logfile;
  • Type: dit is het soort transactie:
    • CASH-IN: contant geld storten bij de merchant
    • CASH-OUT: content geld opnemen bij de merchant
    • DEBIT: is geld opnemen van de rekening naar een bankrekening.
    • PAYMENT: betaling voor goederen of diensten
    • TRANSFER: mobiel betalen van geld tussen klanten
  • Amount: dit is het bedrag van de transactie; waarschijnlijk in Zweedse kronen omdat de ontwikkeling van deze data-set als promotie onderzoek is uitgevoerd aan een Zweedse Universiteit;
  • Name Orig, Name Dest: zijn de klant of merchant namen. C….. is Client en M….. is Merchant;
  • Oldbalance Org en Dest, Newbalance Org en Dest zijn de saldo’s voor en na de transactie van de betreffende klant of merchant;
  • isFraud: is de indicatie dat de betreffende transactie fraude betreft;
  • isFlaggedFraud: is niet relevant.

Voor het analyseren van de data, is het zaak om te ontdekken of er bepaalde patronen aanwezig zijn. Hiervoor hebben we het data filter in Excel gebruikt.

Onbalans

Als je alle transacties die als frauduleus zijn gekenmerkt (isFraud = 1) filtert, dan zie je dat het in alle gevallen gaat om de transacties TRANSFER en CASH-OUT. Het aantal fraudegevallen bedraagt 1.142 op een totaal van 1.048.576 transacties, overeenkomend met ongeveer 0,1 %. Dat is een duidelijke onbalans in de data-set en in principe een probleem bij dit soort classificatie vraagstukken. Voor het verdere verloop laten we het even buitenbeschouwing. We kunnen er later nog op terugkomen.
Verder zie we dat deze transacties vaak opeenvolgend zijn en gelijke bedragen betreffen.

Zie onder.

Uit verder onderzoek (bv. komen bepaalde nameOrig of nameDest vaker voor dan je zou verwachten of zijn er patronen te ontdekken rondom de kolommen die de bedragen voorstellen e.d.) blijkt dat de kolommen van de personen niet van belang zijn. Ook de rol van de merchants is niet van belang. Als je zoekt in de nameOrig en nameDest kolommen naar strings die beginnen met een “M”, zie je dat bij de fraude transacties geen merchants betrokken zijn. Wat op zich merkwaardig is omdat de CASH-OUT transactie volgens de toelichting op de data-set alleen via een merchant plaatsvindt. In het algemeen lijkt de data-set op bepaalde aspecten niet consistent. Dit is niet onoverkomelijk omdat in real-life situaties de data-sets meestal ook niet ideaal zijn.

Feature engineering

De constatering met Excel data filtering dat fraude transacties vaak achtereenvolgens worden uitgevoerd en waarbij de betrokken bedragen gelijk zijn, kan gebruikt worden om een nieuwe feature aan de data-set toe te voegen.

Om de tijdvolgordelijkheid te introduceren voegen we een kolom Ordinal met ordinaalgetallen 1,2,3,…. Als eerste indicatie voor fraude voegen we een kolom Equal Amount Successor toe die vastlegt of het bedrag van de transactie gelijk is aan het bedrag van de volgende transactie.

De kolommen Ordinal en Equal Amount Successor gebruiken we om een nieuw kolom Suspicious Transaction te introduceren die als nieuwe feature gaat dienen. De waarde drukt uit dat een transactie verdacht is en dat er samenhang is met de vorige of volgende transactie. Op deze manier krijgen we gepaarde transacties die als verdacht gekenmerkt kunnen worden. De waarde van het nieuwe feature wordt in Excel als volgt bepaald:

= IF ( AND((Ai-Ai-1=1); OR(Di=Di-1;Di=Di+1)) ; TRUE ; Ni-1)
Met:

  •  i de lopende rij;
  • A de kolom met Ordinal;
  • D de kolom voor amount;
  • N de kolom met boolean Equal Amount Successor: (amount(i-1) = amount(i)).

Hieronder staat een voorbeeld van het resultaat.

Van de 1.142 fraudegevallen zijn er 27 die niet voldoen aan het Suspicious Transaction criterium maar toch als fraude zijn gekenmerkt. Dat is ongeveer 2% van het totaal. Deze afwijkende gevallen laten we even liggen omdat ze qua aantal statistisch gezien verwaarloosbaar zijn.

De volgende stap is om met RapidMiner een model te ontwikkelen en te valideren. Globaal worden de stappen: Inlezen Data, Selecteren Attributen, Algoritme kiezen, Cross Valideren, resultaten bekijken.

Voor het opsporen van fraude worden verschillende ML technieken gebruikt. De Decision Tree (DT) methode komt vaak voor omdat die een goed beeld geeft van de situatie. Zie afbeelding onder. Dit in tegenstelling tot bijvoorbeeld Deep Learning dat eigenlijk een black-box is met een partij geheimzinnige parameters die je vertellen wat er binnen de box gebeurd is.

Met DT zie je meteen op welke kenmerken (attributen) het DT algoritme onderscheid maakt tussen de aangeboden gegevens. Uiteraard heeft ook DT een aantal knoppen waar je aan kunt draaien en die vorm en diepte van de Tree bepalen.  Wat opvalt is dat met Suspicious Transaction al meteen het merendeel (66) van de vermoedelijke fraude transacties onderscheiden wordt. Daarna wordt er in de resterende transacties gekeken naar een nieuw ingevoerd berekend eindsaldo (errorBalanceNew, zie artikel van Arjun Joshua) na uitvoering van een transactie. Hier wordt nog maar 1 transactie als frauduleus beschouwd.

Om te voorkomen dat een Tree tot in verre hoogtes groeit of overfitted wordt (veel takjes en blaadjes), kun je bijvoorbeeld de diepte van de Tree of het aantal blaadjes maximeren. Dit noemen ze pruning (snoeien). Binnen RapidMiner (RM) wordt standaard een aantal pruning parameters gezet voor het DT algoritme.

In het RapidMiner proces worden extra attributen errorBalanceOrg en errorBalanceNew (zie artikel Arjun Joshua) toegevoegd met de operator Generate Attributes. Deze nieuwe Features (extra attributen) zijn gebaseerd op de waarneming dat bij de transacties die als fraude worden gekenmerkt, de eindsaldo’s veel vaker kleiner, gelijk aan 0 zijn dan bij de niet-fraude transacties. Wat natuurlijk niet zo verwonderlijk is.  De reden dat we deze Features ook gebruiken is om te kijken in hoeverre ze de Feature Suspicious Transaction out-performen. In RapidMiner wordt met de operator Cross Validation het model geoptimaliseerd met een Trainings- en Validatieset.

We maken gebruik van het DT algoritme met de standaard parameter instellingen. Als we het proces runnen dan levert dat de volgende resultaten op.

true false true true class precision
pred. false 9931 2 99.98%
pred. true 0 66 100.00%
class recall 100.00% 97.06%

Wat we zien is dat de standaardinstelling voor DT (met name de pre-pruning instelling) de Tree minimaliseert met maximaal resultaat. Recall en Precision zijn hoog. De Recall zegt iets over de trefkans dat een echte frauduleuze transactie daadwerkelijk gevonden wordt. De Precision zegt iets over de mate van nauwkeurigheid oftewel de verhouding tussen de echte fraudegevallen en alle gevonden (echte en foutieve) fraudegevallen.

Voorlopige conclusie: invoeren van het Feature Suspicious Transaction lijkt een goede voorspeller te zijn voor fraude. Wat achteraf niet verwonderlijk was. Bij de Excel exercitie zagen we al dat 98% van de fraude gevallen ontdekt werden met het Suspicious Transaction feature.

Content Intelligence met RapidMiner

Elk CMS zou eigenlijk tools moeten hebben om content te analyseren. Bijvoorbeeld om content te classificeren, trefwoorden eruit te halen, of inhoudelijk gerelateerde content te suggereren. Helaas is het nog geen gemeengoed onder de CMS software leveranciers om dergelijke functionaliteit integraal aan te bieden. Als je toch content wilt analyseren ben je vaak aangewezen op gespecialiseerde software. Bijvoorbeeld RapidMiner. RapidMiner is een data-science platform voor o.a. data bewerking, machine learning en text mining. Oorspronkelijk is het pakket ontwikkeld aan de TU van Dortmund. RapidMiner heeft een gratis demoversie met alle functionaliteit die echter beperkt blijft tot datasets van maximaal 10.000 records.

We hebben een data-set van 128 door mensen geclassificeerde nieuwsberichten als input gebruikt. De records uit deze data-set zijn verdeeld over de volgende categorieën: Auto, Economie, Politiek en Sport. Het oorspronkelijke format was XML, afkomstig van een export uit een CMS systeem. Hieronder staat het RapidMiner model met de Performance resultaten uitgedrukt in Precision en Recall.


Performance resultaat

Uit de XML data zijn de Titel, Tekst en Categorie gehaald en na wat bewerkingen zoals tokenizing, case-conversion en stopword-filtering, aangeboden als trainingsdata aan k-NN, Naive Bayes en Deep Learning (DL) neural network. Het Crossvalidation subproces is bedoeld om een deel van de aangeboden trainingsdata te gebruiken als trainingsdata en een deel van de trainingsdata te gebruiken als test-data.
Van elk algoritme zijn de Recall Re en Precision Pr bepaald en daarmee de F1 score (2*Re*Pr/(Re+Pr). F1 is een maat voor de accuraatheid van het algoritme gegeven de dataset waarmee getraind en getest wordt. Hieronder staan de F1-scores.

Uit het F1 overzicht zien we dat k-NN (groen) over het algemeen de hoogste F1 score heeft. Naive Bayes (bruin) presteert vergelijkbaar. Bayes doet het iets slechter bij Economische content en beter bij Politieke en Sport content. Deep Learning (blauw) scoort aanzienlijk lager over alle categorieën. Alleen bij Sport komt het in de buurt van k-NN en Bayes.
De solid lijnen presenteren de F1-scores met N-Gram gelijk aan 1. De gestippelde lijnen zijn de resultaten met N-Gram=2 (NG=2). Met N-Gram generatie kun je samengestelde woorden als een eenheid meenemen in de analyse. N-Gram=2 betekent dat je twee woorden die bij elkaar staan als een eenheid meeneemt. Bijvoorbeeld air france genereert bij N-Gram =2, ook air_france als woord.

Een mogelijke verklaring voor die lagere score van DL is dat DL gevoeliger is voor de mix van de verschillende categorieën. Nieuwsberichten over auto’s kunnen ook Economie gerelateerde onderwerpen bevatten.
Evenzo en wellicht nog sterker is dit bij berichten over economie en politiek. Beide domeinen zijn vaak verwant aan elkaar. Bij het beoordelen van een bericht door een mens is het goed mogelijk dat een bericht dat over economie en politiek gaat door de beoordelaar die twijfelt tussen de categorie Economie of Politiek, in de categorie Economie geplaatst wordt omdat de inhoud net iets meer neigt naar Economie en er nu eenmaal één van de categorieën gekozen moet worden. Dat DL beter scoort bij Sport is met dezelfde redenering te verklaren omdat in het algemeen sportberichten minder vaak vermengd zijn met de andere categorieën.

De lagere F1 score van het Deep Learning algoritme betekent dus niet dat het resultaat slechter is. Sterker, je kunt redeneren dat Deep Learning eigenlijk een betere voorspelling doet over de ‘aboutness’ van het bericht omdat het rekening houdt met de verschillende domeinen die in een bericht aan bod komen.
Hoe zou je dit kunnen ondervangen? Een oplossing kan zijn om toe te staan dat er meerdere categorieën aan een bericht toegekend kunnen worden. Probleem is dan wel dat alle categorieën even zwaar meetellen en dat willen we ook weer niet. Een ander oplossing is om ‘tussencategorieën’ of een soort fuzzy (vage) classificatie in te voeren. Bijvoorbeeld uitgedrukt in percentages. Een bericht krijgt dan de kwalificatie van 20% Economie en 80% Politiek in plaats van Politiek. Dit gaan we nog een keer onderzoeken.

Voorlopige conclusie: k-NN en Naive Bayes presteren goed, echter het is de vraag of ze de content goed begrijpen. Deep Learning is wellicht beter in staat de verschillende aspecten in een tekst te onderkennen.

Het herkennen van katten, muziek, teksten en klanten

Artificial Intelligence, Algoritmes, Machine en Deep Learning. Deze termen vliegen je vandaag zo’n beetje overal om je oren. Niet alleen op de IT sites en blogs, maar ook op tv, radio en zelfs in de reclamespots zijn ze gemeengoed geworden van de journalisten en presentatoren.

Ook bij CMEdge kunnen we er geen genoeg van krijgen. Begin van deze eeuw zag het er veel belovend uit. Het herkennen van afbeeldingen, het omzetten van gesproken tekst naar geschreven tekst en vice versa. Dat alles was mogelijk op je computer. Hoopvol gingen we praten tegen onze vers geïnstalleerde Word Speech2Text applicatie. Er moest wel wat getraind worden (een dag of veertien), maar dan konden we teksten inspreken die in vrijwel foutloos Nederlands op het scherm verscheen. Ook het zoeken naar katten, honden, tafels en stoelen aan de hand van een voorbeeldplaatje of -tekening werd ons in de schoot geworpen. Helaas, we hebben toen veel zaken uitgeprobeerd en we zijn ook even vaak teleurgesteld.

Maar het wonder is geschied. De laatste jaren zijn de beloften waargemaakt. Start Google Now of Keep, praat er tegen en je wordt begrepen (wel een beetje ABN spreken, hoewel Google de noordelijke accenten redelijk goed verstaat). Voor een belangrijk deel hebben we dit te danken aan de ontwikkelingen rondom neurale netwerken. Neuraal netwerk, klinkt interessant maar hoe werkt dat nu precies en hoe kun je dat gebruiken om bijvoorbeeld een gezicht of een tekst te herkennen. Belangrijk is dat een neuraal netwerk leert van (veel) voorbeelden. Je moet het trainen, trainen en nog eens trainen. Neurale netwerken zijn goed in het herkennen van afbeeldingen, muziek, spraak en ook tekst. Waarom dat zo is, wordt hopelijk straks duidelijk.

Het basis idee achter neurale netwerken is de werking van onze hersenen. Die bestaan uit miljarden neuronen die met elkaar verbonden zijn en signalen uitwisselen. Een kunstmatig neuraal netwerk is een simpele afspiegeling van onze hersenen. Wat in onze hersenen een neuron is, wordt in kunstmatig neurale netwerken een perceptron genoemd. Gewoon een bolletje dat input actief verwerkt tot output. De input is afkomstig van alle omringende andere perceptrons. Die verschillende inputs hebben allemaal hun eigen weegfactor. Om te voorkomen dat de hele zaak vastloopt, wordt er bij de ontvangen inputs een ‘bias’ toegevoegd. Zeg maar een beetje vervuiling. Hiermee wordt voorkomen dat er een soort deadlock ontstaat waarbij alle inputs gelijk aan nul zijn.

Wanneer een perceptron input krijgt dan zal die afhankelijk van zijn activatiefunctie output geven die vervolgens wordt doorgegeven aan andere perceptrons. Vaak wordt dit voorgesteld in een gelaagd model waarbij de input (input layer) via tussenstappen (hidden layers) leidt tot het eindresultaat (output layer). De perceptrons bevatten dus simpelweg getallen. Door afspraken te maken kun je ervoor zorgen dat de getallen tussen 0 en 1 liggen. Bij het trainen van het netwerk zorg je ervoor dat uitkomsten die in de buurt van 1 liggen de goede uitkomsten zijn. Hieronder een voorbeeld van een geschreven getal 7 waarbij het netwerk bij de gewenste uitkomst van het cijfer 7, een output van 0.9 geeft om aan te geven dat de geschreven 7wel erg veel lijkt op het cijfer 7.

Met het trainen van het netwerk wordt aldus de ‘mechanica’ van het netwerk ingericht. Wanneer er nieuwe input wordt gegeven, dan wordt die verwerkt volgens de getrainde ‘mechanica’ van het netwerk. Dat zal niet altijd goed gaan. Van verkeerde conclusies leert het netwerk door de parameters van het netwerk (bijvoorbeeld weegfactoren en/of activatiefuncties) aan te passen en de foutmarge te minimaliseren. Op deze manier leert het netwerk van zijn fouten zodat het beter en beter wordt.

Een model van een neuraal netwerk is het Convolutional Neural Network (CNN). Dit type wordt veel gebruikt om afbeeldingen te herkennen. Hierbij wordt het onderwerp van onderzoek ‘verpixeld’ in rijen en kolommen. Bij een afbeelding is dat goed voor te stellen. Een voorbeeld om de werking van neurale netwerken uit te leggen is het herkennen van geschreven letters. Bijvoorbeeld de letter X. Deze wordt op verschillende manieren geschreven. Maar een X bestaat toch uit een aantal basiselementen. (zie onder).

Door die basiselementen van de X over de te onderzoeken, handgeschreven X stapsgewijs te schuiven, en tegelijk te berekenen welke pixels van het basiselement samenvallen met de pixels van het handgeschreven X , ontstaat een getallenpatroon die als het ware de score van de matching van het X-onderdeel met de handgeschreven X presenteert.

Door het verschuiven van basiselementen over het te onderzoeken onderwerp, is de volgorde van de kolommen (en rijen) van belang. CNN’s zijn goed in het herkennen van dingen die lokaal samenhang hebben. Zoals een afbeelding of geluid en ook een tekst. Bij een tekst kun je alle relevante woorden op een rij zetten en vervolgens in de kolommen aangeven wat de volgorde is van de woorden.

Verwisselen van kolommen zal bij een afbeelding het beeld verminken en bij een tekst de betekenis van de tekst veranderen.

Bij klant-data is in veel gevallen de volgorde van kolommen niet van belang. Zet je de klant-data in de kolommen en de klanten in de rijen, dan zal het verwisselen van kolommen waarin deze gegevens staan niets aan de ‘betekenis’ van de data veranderen. CNN’s zijn voor dit type data niet goed bruikbaar.
Vuistregel: als de data die je gebruikt na het verwisselen van kolommen (en rijen) nog goed bruikbaar is, dan zijn CNN’s niet toepasbaar. Waar Convolutional Neural Netwerken goed in zijn is het herkennen van patronen (afbeeldingen, geluid, tekst).

Wil je meer weten over CNN’s ga dan naar https://www.youtube.com/watch?v=FmpDIaiMIeA . In deze video wordt het nog eens haarfijn uitgelegd.

 

Papier en Digitaal integreren

Nog steeds hebben veel mensen naast een elektronische agenda op hun werkplek of Smartphone, ook een papieren agenda.

Uit een onderzoek dat een Belgische leverancier van agenda’s in 2015 heeft uitgevoerd onder bijna 3.000 personen uit Nederland, België en Frankrijk, blijkt dat 68% van de ondervraagden een papieren agenda heeft. Verder blijkt dat ongeveer 20% van de Nederlanders een digitale agenda gebruikt. Voor Nederland zou dat betekenen dat enkele miljoenen mensen een papieren agenda heeft of gebruikt en daarnaast een digitale agenda heeft. Van die groep zal een aanzienlijk deel worstelen met het gelijktijdig gebruik van de papieren agenda en de digitale agenda. Een ander deel zal bij het 100% gebruik van een papieren agenda, de voordelen missen van digitale agenda. Bijvoorbeeld de signaleringsfunctie. Immers een papieren agenda begint niet een kwartier voor de afspraak te piepen.

Al jaren geleden heb ik mij met dit probleem beziggehouden en verschillende app ontwikkelaars gevraagd of ze hier wat aan konden doen. Tot ik vorig jaar op een Kickstart programma stuitte: Slice Planner. Slice Planner is een app die in combinatie met een geformateerde papieren agenda, jouw ‘papieren’ afspraken in je digitale agenda (bv. Google, Outlook, Android) zet. Een prima idee en een werkende app. Probleem is dat je een specifieke agenda moet gebruiken. Zie figuur onder.

Na enige experimenten met de ‘Slice Planner’ (wellicht moeten we dat ding de ‘Pizza Planner’ noemen), heb ik een eigen draai gegeven aan de Slice Planner. Gewoon door de Slice Planner toe te voegen aan een gewone agenda.

Met de app kun je in ieder geval de papieren afspraken digitaliseren. Zie de video hieronder.

De Slice Planner app houdt rekening met overlappende afspraken. Deze worden dan in rood aangegeven en die kun je vervolgens aanpassen.
Een probleem dat nog opgelost moet worden is het verwerken van je afspraakteksten. Misschien moet je hiervoor gewoon een scan-image maken en die in de digitale agenda plakken. Een ander punt is dat je elke dag moet inscannen. Het zou mooi zijn als je een hele week kunt inscannen.

 

Process Mining en bezoekersgedrag

Het analyseren van het bezoekersgedrag op een website is een van de fundamenten van content-marketing en content-targeting. Daarvoor zijn verschillende tools beschikbaar zoals Google Analytics. Een softwaretool die misschien niet voor de hand ligt maar wel goed toepasbaar is, is de Process Mining tool Disco van Fluxicon. Disco is een applicatie waarmee processen geanalyseerd kunnen worden. We kunnen het gedrag van een bezoeker zien als een proces. Immers tijdens een sessie voert hij verschillende acties uit, namelijk het bezoeken van pagina’s op een website. Voor een ‘process-mining’ analyse heb je drie elementen nodig: Cases, Events en Timestamps. En al deze elementen hebben we tot onze beschikking wanneer we het klikgedrag van een bezoeker vastleggen, namelijk de bezoekerssessie als Case, de bezochte pagina’s als Events en de bezoektijd als Timestamp. Hieronder staat een voorbeeld van dergelijke data.

Importeren we deze data in Disco dan kunnen we een ‘process map’ maken. Hierin zien we het verloop van de bezoeken aan de website. De donker gekleurde pagina’s worden veel bezocht. Ook zie je in dit overzicht langs welke paden de bezoeker de pagina’s bezoekt.

Met Disco kun je Case varianten analyseren. Een Case variant is in onze web toepassing een typisch klik-pad dat door een aantal bezoekers is afgelopen. Disco laat zien welke Case varianten er zijn, welke pagina’s er per Case worden bezocht en door hoeveel bezoekers de Case variant wordt bewandeld. Ook de verdeling in de tijd wordt getoond. Zie de afbeelding hieronder.

Case varianten zijn interessant omdat je hiermee het klikgedrag van bezoekers classificeert in verschillende ‘type klikpaden’. Elke variant stelt in feite de uitvoering van een taak/transactie voor die een groep bezoekers heeft uitgevoerd. Met de filter-functie kun je Case varianten filteren. Bijvoorbeeld dat een pagina of groep van pagina’s altijd voorkomt in het klikpad. Op deze manier kun je succesvolle taken/transacties eruit filteren. Of juist de niet-geslaagde taken/transacties. Een voordeel van het toepassen van een process-mining tool als Disco is dat je het individuele gedrag van bezoekers aan de hand van uitgevoerde ‘Cases’ (lees klik-gedrag)  in kaart brengt en kunt analyseren. Meer weten? Stuur een e-mail naar Info CMEdge.

R …….

Het automatiseren van statistiekberekeningen is waarschijnlijk een van de vroegste computertoepassingen. In de jaren 60-70 zijn er al bibliotheken van ponskaarten om statistiekberekeningen te maken met een taal als Fortran.

Later zijn er specifieke talen en pakketten ontwikkeld voor het statistiek domein. Denk aan SPSS, R en SAS. R is open source programmeertaal die zich sterk richt op het bewerken, verwerken en analyseren van (statistiek) data. Binnen R zijn veel bibliotheken beschikbaar.

Kenmerk van R is dat het een interactieve omgeving is die gericht is op de ‘eindgebruiker’ en deze gebruiker zomin mogelijk te belasten met typische programmeer zaken. R is ontstaan als een open source nakomeling van de commerciële programmeer taal S. Om het gebruik van R makkelijker te maken, is RStudio ontwikkeld. RStudio is de IDE van R.

Binnen R spelen vector, list en data frame een hoofdrol. Een vector is een ‘lijst’ van gelijksoortige objecttypen (character, number, boolean, integer, complex),  een list is een ‘vector’ die kan bestaan uit verschillende objecttypen en een data frame is een datastructuur van rijen en kolommen waarbij elke rij een ‘waarneming’ is en de kolommen een variabele voorstellen.

De kracht van R is dat er voor het manipuleren van de objecten een groot aantal bibliotheken is die het leven in R makkelijk maken. Een voorbeeld is R/igraph. Igraph is een bibliotheek van functies om netwerk analyses te doen. Voor het presenteren van netwerken heeft igraph veel functies. Een voorbeeld daarvan is het presenteren van een netwerk op basis van simpele ‘literals’ die een volgorde van knooppunten en relaties voorstellen. Met eenvoudige symbolen wordt de relatie tussen knooppunt A en knooppunt B vastgelegd.  A  -+  B betekent dat vanuit A er een relatie is naar B. Oftewel A => B. de weg terug is +- oftewel <=. Wil je geen richting aangeven, dan gebruik je gewoon het liggend streepje:  —


Een netwerk bestaande uit A=>B =>C =>D en A=>F=>C=>D en  A=>F=>G=>D, zie figuur hierboven, wordt door de igraph functie:

graph_from_literal(A -+ B -+ C -+ D,A -+ F -+ C -+ D, A -+ F -+ G -+ D)

Om deze ‘graaf’ te plotten kun je plot() (standaard R) of tkplot() (onderdeel van igraph) gebruiken. Met tkplot() kun je interactief het netwerk bewerken. Een aardige toepassing is om klikpaden van een website visueel te presenteren. Veel webstatistieken presenteren klikpaden op een CSV-achtige manier waarbij de opeenvolgende pagina’s gescheiden worden door komma’s. Hieronder is een voorbeeld van Comscore.


Met wat bewerkingen kan dit omgezet worden naar een voor de igraph functie: graph_from_literal() leesbaar geheel.


Deze gegevens kunnen in graph_from_literal() worden ingevoerd.


Daarna kan de ‘graaf’ met tkplot() geplot worden en interactief worden bewerkt door de knooppunten te positioneren, kleuren van de lijnen aan te passen, etcetera.


Op een eenvoudige manier kun je met RStudio snel een netwerk visualiseren.