Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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?