🧁 Forsikring og muffens

4 ting å tenkje på når du vil laga ein maskinlæringsmodell for å avgjere forsikringssvindel

Så, du er ein data scientist og nokon har gitt deg i oppdrag å laga ein maskinlæringsmodell for å avgjere om ei skadesak er forsikringssvindel?

Først, forsikring, kva er eigentleg det?

Forsikring er, heilt fundamentalt, eit spleiselag, der “alle” bidrar med eit (lite) innskot av pengar, slik at det samla er nok pengar til å hjelpe dei som er uheldige og kjem ut for ei ulukke, får ein skade på seg sjølv eller noko ein eig, eller på anna vis blir utsett for ei uventa hending der pengar kan brukast for å erstatte det som er tapt.

Forsikring er altså ei teneste, eller produkt, som fungerar fordi dei aller fleste hus brenn ikkje ned, dei aller fleste kræsjar ikkje bilen sin, får innbrot i huset, blir rana på reise, eller kjem ut for ulukker. Dei aller fleste får rett og slett ikkje bruk for forsikringa, men har tryggleiken av at dei er dekka dersom dei skulle vere uheldige.

Kva er så forsikringssvindel?

Forsikringssvindel, forsikringssvik eller forsikringsbedrageri er alle ord som blir nytta om det same. Det er når ein kunde i eit forsikringsselskap melder ein skade der opplysningane som er gitt ikkje er korrekte eller at skaden på eit vis er arrangert, med tanke på å få utbetalt ein forsikringssum til seg sjølv eller andre (Lovdata). Det kan vere alt frå å lyge om kva klesmerke det var på buksa som låg i bagasjen som forsvann på reise , til å arrangere ei fiktiv bilulukke. Kort sagt, kunden er uærleg og forsøkjer å få utbetalt pengar hen ikkje har krav på.

Ein veit ikkje heilt omfanget av forsikringssvindel eigentleg er. Samla sett blir det avdekka at krav på i underkant av 400 millionar i året er forsikringssvindel (FNO). Men dei aller fleste trur at det er store mørketal, og det totale omfanget har vore estimert til fleire milliardar kroner i året.

I og med at forsikringsselskap er som dei aller fleste andre selskap ynskjer dei mest mogleg profitt. Auka utbetaling på grunn av svik er eit tap som selskapa vil dekke inn. Måten det blir gjort på er som regel at alle kundar må betala litt meir for sine forsikringar. Det er altså dei aller fleste, som ikkje har gjort noko gale, som endar opp med rekninga for forsikringssvindel utført av eit lite mindretal.

Det er difor eit gode for alle om ein klarar å avdekkje og hindre meir forsikringssvindel.

Så her er fire ting å tenkje på dersom du vil laga ein maskinlæringsmodell for å avgjere forsikringssvindel.

1 — Du vil ikkje laga ein maskinlæringsmodell for å avgjere forsikringssvindel

Det å avgjere om ein forsikringsskadesak er svik er komplisert, tidkrevjande og vanskeleg. Frå ein skadesak er meldt til forsikringsselskapet kan det ta relativt lang tid før den endar opp som avdekka svik. Dei aller fleste sakene som ender opp som svik har vore innom ei utreiingsavdeling der saka har blitt etterforska, bevis samla inn og vurdert. Som regel har det vore gjennomført samtalar og avhøyr, påstandar har blitt sjekka og ein eventuell konklusjon om svik er godt grunngjeven.

Oftast veit du ikkje kva opplysningar som fører fram til konklusjonen om svik, eller du får ikkje den avgjerande brikka i puslespelet før etter tid og innhenting av fleire opplysningar. Det er difor ein utopi å tru at du skal klara å laga ein maskinlæringsmodell som kan avdekkje svik på ein vilkårleg skadesak.

Kva gjere du då? Du tenkjer gjennom prosessen og prøver å bryta den ned til mindre steg og ser om det er delar av den som ei maskin kan læra seg. Oppgåver som eignar seg godt for maskinlæringsmodellar er oppgåver med klåre utfall som eit menneske innan kort tid kan avgjere. Før ei sak blir sendt til utreiing er det ein sakshandsamar som har kombinert det hen veit om kunden og det kunden har sagt om skaden og tenkt «Her ser alt fint ut», eller «Hm, her er det eit eller anna muffens som vi bør sjå nærare på». Det er ikkje alltid ein spesifikk ting som fører til konklusjonen, men eit samla bilete av mange opplysningar som basert på fagkunnskap (og magekjensle) gjev ei sannsynsovervekt for at denne saka her bør sjekkast litt meir før den blir avgjort. Denne prosessen med å setje saman informasjon om kunden og skaden og så raskt vurdera om det er noko som er avvikande og grunn til å sjå nærare på er noko ei maskin kan trenast opp til.

Så, du vil ikkje laga ein maskinlæringsmodell for å avdekkje og bevise svik (sjå og punkt 2), men du kan laga ein maskinlæringsmodell som forsøkjer å tilnærma seg sakshandsamarane sin fagkunnskap og sei noko om muffens eller ei 🧁.

2 —Kartlegg dei etiske fallgruvene i jakta på muffens

Om du skal la ei maskin dele noko inn i ulike grupper basert på ei eller anna tolking av data er det mange ulike problemstillingar ein møter på og må ta stilling til. Mange av problemstillingane er reint praktiske (korleis får eg tak i data?, kva slags maskin treng eg for å trene modellen?) eller av meir akademisk art (kva maskinlæringsmodell er den optimale for akkurat denne problemstillinga?) og er kanskje dei problema det er lettast å tenkje på. Men minst like viktig, og spesielt når noko er menneske, er problemstillingar rundt etikk. Det er fleire lovmessige krav som avgrensar kva ein kan gjere. Eit minstekrav for etisk praksis er å følgje likestillings- og diskrimineringsloven (§6–9). Frå §6 går det klart fram at:

«Diskriminering på grunn av kjønn, graviditet, permisjon ved fødsel eller adopsjon, omsorgsoppgaver, etnisitet, religion, livssyn, funksjonsnedsettelse, seksuell orientering, kjønnsidentitet, kjønnsuttrykk, alder eller kombinasjoner av disse grunnlagene er forbudt.».

Og sjølv om §9 opnar for lovleg forskjellsbehandling dersom forskjellsbehandlinga

«

a. har et saklig formål

b. er nødvendig for å oppnå formålet og

c. ikke er uforholdsmessig inngripende overfor den eller de som forskjellsbehandles.

» betyr det ikkje at du skal gjere det.

Det er og viktig å være merksam på GDPR, som regulerer personvern og beskyttelse av personopplysningar. Forsikringsbransjen må vera spesielt forsiktig med å behandle sensitive personopplysningar på ein lovleg måte.

Finanstilsynet stiller og krav til forsikringsbransjen for å sikre at det ikkje skjer urimeleg forskjellsbehandling mellom kundegrupper. Dei ser midlertidig at bruk av avansert analyse med auka tal på forklaringsvariablar kan gi auka presisjon. Likevel er det risiko for at bruk av detaljerte data og meir avansert analyse kan føre til at enkelte kundar eller kundegrupper blir utelukka frå forsikringskollektivet. Dette kan være spesielt relevant for produkt med høg samfunnsnytte eller som kan påverke sårbare kundegrupper særskilt.

Kva om du lagar ein maskinlæringsmodell der det viser seg at t.d. kjønn eller alder er viktige forklaringsvariablar for resultatet av modellen? Kanskje data du har trent modellen med viser at kvinner i 50-åra oftare har saker det er noko muffens med (for å vere heilt klår, dette er eit reint hypotetisk eksempel)? Nokre moglege utfall av ein slik modell kan då vere at kvinner i 50-åra blir reelt forskjellsbehandla ved at dei:

- oftare må vente på manuell saksbehandling

- oftare må bruke ekstra tid og energi på å fylla ut skjema

- ikkje får utbetalt erstatning lika effektivt som andre.

Det er difor særs viktig å forstå modellen og data som ligg bak og vere klår over at det kan føre til reel forskjellsbehandling og diskriminering. Ein maskinlæringsmodell lærer berre ut frå data blir trena på, og du er ansvarleg for å tenkje gjennom og vurdera om data du serverar den faktisk representerar verda på ein god måte. Kan hende var kjønn og alder berre korrelert med ein eigentleg faktor som du ikkje har med i data? Og dersom du hadde inkludert denne så viser det seg at kjønn og alder ikkje spela noko rolle.

Eit sentralt prinsipp for oss er at resultatet av maskinlæringsalgoritmane ikkje går direkte i kundane sin disfavør. Det er inga etisk ok måte å bruka ei maskin for å avgjere at nokon ikkje skal få erstatning, så det vil vi ikkje gjere. Men ein kan bruke ei maskin til å raskare avgjere at nokon skal få erstatning og slik sett kan algoritmane hjelpe til med å få fleire saker til å bli heilautomatisert og styre dei få vanskelege sakene til manuell handsaming.

3 — Forstå kva som er målet

Om du har fått i oppdrag i å laga ein maskinlæringsmodell for å avgjere svik eller ikkje er det viktig å stile spørsmål om kvifor. Etter å ha forklara kvifor du ikkje kan eller vil (hugs punkt 1 og 2) ein modell for å avgjere om ein sak er svik eller ikkje, så må du freiste å finne ut av kva som er målet. Kva er det ein eigentleg håpar ein slik modell skal hjelpa ein å oppnå? Korleis er det tenkt at ein maskinlæringsmodell skal nyttast? Det er ikkje sikkert det er eitt eintydig svar.

Forsøk å få svar på spørsmål som:

• Blir det avdekka for lite svik i dag?
• Har utreiingsavdelinga kapasitet til å arbeida med fleire saker enn dei alt gjer?
• Er kvaliteten på dei sakene utreiingsavdelinga arbeidar med for dårleg?
• Skal modellen hjelpa til med å auka automatisering av sakshandsaming?
• Skal den på eit vis hindra svik?
• Skal den føre til betre kundehandsaming?
• For kven skal modellen vere eit verktøy?
• I kva prosessar skal modellen integrerast?

Svara du får kan vera førande for kva slags modell du vel å lage og ta i bruk (sjå punkt 4), og kan hende er dei og motstridande.

Eit naivt ynskje om å ha ein modell som finn all muffens er «enkelt» å få til ved å flagge alle saker. Men ei slik løysing vil ikkje fungera fordi det ikkje vil vere kapasitet til å manuelt handtera alle sakene. Det vil og gå verka direkte i mot eit ynskje om høgare grad av automatisering.

Målet vil ofte vere eit ynskje om å bli meir effektiv og utnytte dei ressursane ein har på best mogleg måte. Det er eit gode for alle om vanskelege saker raskast mogleg blir tatt hand om av sakshandsamarar, så ein modell som kan prioritera saker for manuell handtering kan vere eit mål. Ein kan og ha som mål at ein modell verkar preventivt, som ei form for avskrekking dersom det er kjent at vi nyttar AI for å detektera svik.

Når du i størst mogleg grad forstår kva som er målet, eller måla, og ser kor ein maskinlæringsmodell kan ha størst effekt er du klar for neste punkt, men hugs alltid dei fallgruvene du fann i punkt 2.

4 — Det er ikkje gull alt som glimrar

Det kan vere “lett” å samla inn data frå mange ulike kjelder og laga seg eit flott datasett til trening og testing av ein modell for å finne muffens. Men det er fleire moglege fallgruver du kan gå i og må vere merksam på.

For det første må du vurdera om det er lovleg å bruka dei data du vil. Det kan hende du har tilgang på mange opplysningar om kundar, men det er slett ikkje sikkert at det er lov til å bruka alle opplysningane til å laga ein modell for å finne muffens.

Det er viktig å vere klar over at dei data du har samla og satt saman til eit treningsdatasett, kanskje med tanke på å laga ein binær klassifikasjonsmodell («Denne saka er heilt OK», «Her er det noko muffens»), mest sannsynleg ikkje er ein faktisk fasit for korleis verda ser ut. Din «gulldata» med merkelappar for muffens eller ok basert på om ei sak har blitt sendt til utreiing eller ikkje. Du må då vere klar over at det i blant alle sakene som er merka som ok så gøymer det seg eit ukjent tal på saker som eigentleg burde vore merka muffens. Du kan faktisk rekna med at det er meir (ukjent) muffens blant sakene merka som ok, enn det er saker merka som (kjent) muffens (figur 1).

Figur 1 Treningsdata er som regel ikkje den eigentlege fasiten og difor ikkje berre gull.

I og med at forsikringssvindel heldigvis er noko dei færraste driv med, så er som nemnd tidlegare det store fleirtalet av forsikringssaker heilt normale og har ikkje noko muffens ved seg. Det fører naturleg nok til at ein får eit særs ubalansert datasett. Det er langt fleire 0-arar enn 1-arar om ein vil trene ein binær klassifikasjonsmodell for å finna «muffens».

Figur 2 Kva betyr ein AUC på 0.78 i praksis? Er det bra? Godt nok? Eller ikkje brukande?

Når du trenar modellen din er det viktig å tenkje over kva metrikk du vil optimalisera for. Som for alle maskinlæringsmodellar er valet av metrikk avhengig av kva ein vil oppnå og data du har. Med eit ubalansert datasett, og spesielt der det mest sannsynleg ikkje er nokon forklaringsvariablar som gjer det lett å skilje mellom 0 og 1, er til dømes accuracy ein veldig dårleg metrikk. Dersom 1 av hundre tilfeller er 1 og resten 0 oppnår du accuracy på 0.99 berre ved å alltid predikera 0, men du vil då sjølvsagt ha ein modell som ikkje finn muffens i det heile tatt. Balanced accuracy kan vere eit betre alternativ, men det er viktig å sjå på kostnaden av å ta feil (falsk negativ mot falsk positiv). Som regel vil ein måtte gjere ei avveging mellom precision (kor mange faktisk positive saker er det blant alle saker du merkar som positive) og recall (kor stor del av dei faktisk positive sakene flaggar du). Kva ein vel å vektleggje mest er avhengig av korleis modellen skal brukast, kva ein ynskjer å oppnå og kva slags kapasitet du har til å handsame saker som blir flagga.

Ser vi til dømes på ROC-kurve (figure 2) så kan den av og til vere misvisande, spesielt for ubalanserte data. Ein ROC-AUC-score på 0,78 er opplagt betre enn ingenting, men du må hugse på kva det faktisk betyr om du klassifiserar i 0 og 1. Frå leikeeksempelet i figuren så ser vi at vi kan oppnå ein true positive rate på ~0,65 ved ein false positive rate på «berre» ~0,17. Altså at du kan flagge 65 % av dei faktisk positive sakene ved å samstundes merke 17 % av dei negative sakene som (falske) positive. Men kva betyr det i praksis der du har særs ubalanserte data? Sei at du har eit datasett der 2 % av sakene faktisk er positive. Om du då har 1000 saker du skal handsame kan du forventa at 20 av dei er positive. Flaggar du 65 % av dei så er det 13 saker, men samstundes må du då forventa å flagga 167 saker som positive, men som eigentleg er negative. Er det noko organisasjonen og systema dine kan handtere?

Det er difor viktig å ikkje sjå seg blind på predikerte 0- og 1-verdiar, men hugse på at ein binær prediksjonsmodell leverar ein score, eit tal mellom 0 og 1, og du kan sjølv velje kva terskelverdi som kvalifiserar som muffens. Og det er ofte viktig å tenkje meir i retning rangering av saker og ikkje rein klassifikasjon. Ein kan for eksempel sjå for seg at ein sånn modell kan brukast slik at du automatisk sender dei mest muffensluktande sakene til meir erfarne sakshandsamarar.

Noko anna å vere klar over er mogleg uønskt bias i datasettet. Dei sakene som er merka som «muffens» har fått den merkelappen av nokon. Kanskje det var på bakgrunn av konkrete opplysningar, kan hende det var på bakgrunn av ei ullen magekjensle, eller det var fordi «sånne» kundar er det alltid noko muffens ved. Det er difor godt mogleg at det blant dei «ukjent muffens»-sakene skjuler seg eigenskapar som sakshandsamarane aldri eller sjeldan har flagga som muffens. Desse sakene vil då ikkje maskinlæringsmodellen læra seg å kjenne att.

Det kan og vere mykje data som potensielt kan gje ein betre modell for å finna muffens, men det er ikkje sikkert du har tilgang på tilsvarande data når du skal bruka modellen. Tilsvarande kan det vere data som har god forklaringskraft, men som det ikkje eksisterar historikk for. I og med at muffens er noko som opptrer sjeldan, kan det vere viktig og/eller nyttig å ta med data som spenner over eit relativt langt tidsrom. Du må då vere spesielt merksam på trendar og endringar over tid. Kanskje var det muffens med ein type oppførsel eller hending for lenge sidan, men grunna endra forutsetningar er ikkje det sikkert at det betyr noko i dag.

Når du tek modellen i bruk er viktig med oppfølging og kontinuerleg evaluering av den over tid. Gjennom periodisk revisjon av sakene som har blitt flagga og integrasjon av verktøy som til dømes SHAP og LIME inn i systemet/løysinga kan du og brukarane lettare få oversikt over kva som er avgjerande for dei resultata modellen gir. Og sjølv om «automatiserte» forklaringar av maskinlæringsmodellar ikkje gir alle svara, vil dei gjere det lettare å kartleggja og jobba med dei utfordringane som vi diskuterte i punkt 2.

Dersom du har lyst til å testa korleis ein kan gjere dette i praksis så kan du sjekka ut denne case-oppgåva som vi arrangerte for foreninga BRAIN NTNU i Trondheim: https://github.com/odaon/muffins-ai-motor