Laurits Søgaard Nielsen

Kontorchef, Dataanalyse

SKAT

Arkitektur og opmærksomheds-

punkter ved udviklingen og

produktionssættelsen af

analytiske modeller.

24-04-2018 2

Agenda

1

2

3

4

5

Kort om mig

Tidslinje for Kontoret Dataanalyse

Introduktion

Udfordringer og tanker ift. Data Science metode og proces

Data Science i fremtiden

• SKAT siden juni 2016 – kontorchef for

35 medarbejdere i CoE.

• Cand. Merc. EMF fra CBS

• Har ud over det læst en række fag på

både ITU, DTU, Coursera mv.

• Før ansættelsen i SKAT ca. 6 år som

selvstændig konsulent og har bl.a.

været med til at bygge Statens

Business Case model, arbejdet med

vindmølledata (SCADA) i DONG

Energy (nu Ørsted) samt været

drivkraften i at at digitalisere to større

virksomheder (oms. ~500. mio).

24-04-2018 3

Laurits Søgaard Nielsen Kontorchef – Skatteforvaltningens Center of Excellence (CoE) for Avanceret Analyse og Machine Learning

Laurits Søgaard Nielsen

24-04-2018 4

Tidslinje

3 modeller i production

Fokus på standardiserede

skabeloner og artefakter

Status CoE

2017.Q1

CoE etableres for at skabe

strategisk kapabilitet.

Advanced Analytics CoE

2014.Q3 Opstart på agil udvikling,

DevOps og continuous

delivery processer.

Agile Start

2016.Q3

35 FTE (27 Data Scientists)

3 modeller i produktion

6-8 modeller under udvikling

Current status

17 Data Scientists

1 model i produktion

Advanced Analytics CoE

2016.Q2 2 modeller i produktion

2016.Q4

• Data Science er et nyt felt som kombinerer fagdisciplinerne matematik / statistik, computer science og faglig viden.

• Data Scientist kommer fra mange forskellige uddannelsesmæssige baggrunde – og har derfor sjældent en fælles metode / tilgang til arkitektur.

• Der er ofte en meget ”hackish” tilgang til problemløsningen, som gør at de løsninger som laves er ustrukturerede, ikke reproducerbare og ej egnede til at sætte i produktion.

• Time to market er høj, og det gør det svært at integrere data science løsninger som realtids beslutningsstøtte og reducerer værdien af at have et data science team.

24-04-2018 5

Introduktion

• Hvordan sikres lovlighed, hurtig

time to market og realtids-

integration mod organisationens

beslutningsprocesser?

24-04-2018 6

Introduktion

Sådan bliver Data Science en success

Hvis en Data Science afdeling skal blive

en succes og adskille sig fra mere

traditionel analytics, så skal der i højere

grad - ud over værdi i de løsninger som

laves - fokuseres på:

• Transparente og definerede processer som

sikrer høj kvalitet i udviklingsarbejdet.

• Automatisering af trivielle opgaver såsom

modeldiagnostik, træning, data- og

modelkvalitet, produktionssætning som

sikrer høj udviklingshastighed.

• Real-time beslutningsunderstøttelse – dvs.

produktionssættelsen af analytiske modeller

som API’er / Microservices, som sikrer at

brugen af modellerne ikke involverer

analytikerne (ad-hoc batch).

24-04-2018 7

Transparente og definerede processer

• Data Scientists kommer fra mange

forskellige fagområder, og derfor har

der ofte ikke været en fælles tilgang til

udviklingen af modeller.

• Fokus har også ofte været på at

levere en visualisering eller en

”skrivebordsanalyse” – men for at

skabe endnu større værdi skal

processerne tilpasses ift. at der skal

leveres realtids beslutningsstøtte.

• Der er derfor behov for at definere den

proces som der skal følges under

modeludviklingen – og at gøre det ret

detaljeret.

24-04-2018 8

GDPR

• Den nye persondataforordning gør at

transparente og definerede processer

i modeludvikling og –afvikling er blevet

et lovkrav – herunder også for-

klaringen af hvordan en model virker.

• Her kan vi skelne mellem globale

forklaringer og lokale forklaringer af

machine learning modeller.

• Den globale forklaring er hvordan en

machine learning model fungerer på

overordnet niveau - eks. kan deep

learning modeller være svære at

foklare, hvorimod en lineær regression

til højre er mere enkel.

24-04-2018 9

GDPR

• En lokal forklaring kan fortælle hvilke

input i den analytiske model som

bidrog til modelles outout.

• Her kan eks. bruges frameworks som

LIME eller aLIME til at ”forklare” hvad

der influerer på den analytiske models

beslutning.

• Her til højre er vist et eksempel på en

deep learning model, som kan forklare

hvad der er på billedet. LIME forklarer

hvad der gør at den analytiske model

tror at det er en en kat.

24-04-2018 10

GDPR

• Derudover er det vigtigt at kunne

forklare den process, som data flyder

igennem.

• Data Scientists skal derfor kunne

beskrive modeludviklingsprocessen,

og dermed hvordan en model er

fremkommet.

• Det kræver at modeludviklingsarbejdet

er reproducerbart og følger en fast

proces.

24-04-2018 11

Træningsproces

(modeludvikling)

Træningsprocessen tager typisk tid – og køres

afhængig af hvornår der er nok data til at

gentræne modellen.

24-04-2018 12

Opsplittede Data Science processer Der er to hovedprocesser – træning og prædiktion.

Data & domæne-

viden

Træn

Model

Model definition

+ Markdown diagnostik

Prædiktionsproces

(modelafvikling)

Prædiktionsprocessen er typisk kort (da

modellen allerede er estimeret – sædvanligvis er

det blot at applikere vægte). Processen starter

med model definitionen og applikation af data til

at prædiktere på. Output er prædikterede

værdier.

Input Modellering Output

Data Model-

prædiktion

Præ-dikterede værdier

Input Prædiktion Output

Den overordnede udviklingsproces

ASUS DM 2.0 (CRISP DM 2.0) er et godt

udgangspunkt for produktionssættelsen

af modeller.

Den indeholder to hovedprocesser.

• Development Cycle (Modeludvikling)

• Deployment Cycle (Model

produktionssættelse)

24-04-2018 13

Automatisering

• Et af de største problemer for Data

Scientists er mængden af ad-hoc

arbejde samt at deres arbejde ofte

ikke genbruges på tværs af data

science projekter.

• Derudover er der ofte en hel del

manuelt arbejde forbundet med

produktionssættelse og drift

(modelkørsler).

• Dette arbejde kan automatiseres med

continuous delivery, skabeloner og

standardprocesser.

24-04-2018 14

Brug af continuous delivery og agil udvikling (Kanban)

Data Science kan låne mange gode

processer og metoder fra software-

udviklere.

• Versionskontrol

• Præ testede commits

• Statisk kodeanalyse

• Unit-, funktions- og accepttest

• Continuous Delivery

• En udviklingsproces som ex. Kanban

eller Scrum.

24-04-2018 15

Check

Skanner projektfiler

for kendte mønstre

som indikerer ikke

færdigt arbejde. Ex.

@todo, lintr,

cyklomatisk

kompleksitet etc.

24-04-2018 16

Pipeline til R modeller – Continuos Delivery Løsning indtil videre

Unit test

Afvikler unit test og

benytter covr til at

vise code coverage.

Fokus på input- og

outputlag.

Test deploy

Installerer modellen

på en test server.

Accept, smoke og

batch test

Parallel eksekvering

af forskellige test.

Smoke test til at se

deployment fungerer

(API). Accepttest for

at sikre at binaries og

pakker regner korrekt

ift. tidligere

pakkeversioner.

Dokumentation

Sikrer at der

genereres

dokumentation og

der findes

dokumentation i

pakken.

Check Unit test Test deploy Accept, smoke,

batch test

Dokumen-tation

Release Kandidat

Release kandidat

Der promoveres en

release kandidat som

kan releases af driften.

Analytikere kan ikke

release til prod.

Ved release gentages

alle steps fra ”Test

deploy” i prod miljøet.

Continuos Analytics Delivery?

• Tillader at vi kører flere hurtige runder i den agile ASUS-DM proces for modeludvikling og deploye hver model hurtigt i produktions-sættelsesprocessen. Dette undersøtter agil analytics og lader os undgå den analytiske dødsspiral.

• Sikrer en proces for hvornår en model er done done – og CD maskinens regler overvåger kvaliteten i modellernes kode.

• Sporbarhed i alle ændringer i hver model. Alle modeller sættes automatisk i produktion og sikrer at modelkode i produktion altid matcher mod modellen i versionskontrol.

• Låst produktionsmiljø – ingen analytikere kan tilgå produktionen – roller og ansvar er på plads.

• Automatics tilbagerulning til en ældre model såfremt der går noget galt i produktions-sættelsesprocessen.

Statistiske modeller er software og Data Scientist laver softwareudvikling.

24-04-2018 17

• Kræver at den analytiske model kan

produktionssættes og har en høj

kvalitet.

• Kræver også at der er en

standardiseret og struktureret måde at

udvikle modeller på.

• Kræver også at der er en

standardiseret arkitektur omkring det

at bygge og afvikle modellerne.

24-04-2018 18

Analytiske modeller i realtid

Microservices og API’er

• Microservice / API tilgangen er god ift.

at produktionslægge machine learning

modeller, da udviklingscyklus er

anderledes end traditionel

softwareudvikling. Det tillader data

scientist at adskille udvikling og

afvikling af de analytiske modeller.

• API tilgangen sikrer også at

analytikerne ikke skal afvikle

analytiske batch jobs i deres kode. Det

er bedre at flytte afviklingen og

overvågningen af batch til ETL

folkene.

24-04-2018 19

24-04-2018 20

Machine Learning modeller i produktion

On Premise Machine Learning Microservice 1.00.000

On Premise Machine Learning Microservice 1.00.001

• Data Scientist skal i langt højere grad

end nu arbejde semi-struktureret eller

struktureret i stedet for ustruktureret.

• Data Scientists bør benytte flere

standard byggeklodser, sådan at den

dybe tallerken ikke genopfindes gang

på gang. Dvs. vidensdele og bygge

analytiske aktiver.

• Data Scientists bør ikke afvikle deres

modeller – men i stedet udvikle

standardmetoder til at udstille realtids

API’er til beslutningstagerne (evt. incl.

GUI).

24-04-2018 21

Data Science i fremtiden Hvordan sikres lovlighed, hurtig time to market og realtids-integration mod organisationens beslutningsprocesser?