Min rolle
#- Mitt arbeid
- I fase I utformet jeg repositoriet og den samlede arkitekturen, bygde orkestreringen som kobler data, variabler, modeller, evaluering og utdata, og utviklet automatiseringen rundt. Jeg la til GAM-modellering og rullerende validering, implementerte SARIMAX og bidro vesentlig til XGBoost-modellen. Jeg utfordret også måldefinisjoner og valideringsvalg.
- Kollegaens arbeid
- En kollega utviklet den opprinnelige XGBoost-modellen, mange av variablene og vesentlige deler av datavalidering, rensing og filtrering, og samarbeidet med dataleverandøren.
- Fase II: omleggingen
- Jeg ledet og gjennomførte arkitekturomleggingen selvstendig over én måned. Kodeagenter gjorde avgrensede deler av implementeringen, mens jeg hadde ansvar for retning, integrasjon og vurdering av endringene.
Omleggingen er fullført. Prognoseløsningen er under utvikling, ikke i produksjon.
Mer om status
- Effekt
- Omleggingen skulle bevare modellatferden. Den er ikke et mål på prognosenøyaktighet.
Flere kjøreveier måtte fungere sammen
#Arkitekturen skulle endres rundt et eksisterende samarbeid og en eksisterende modellflyt. Konfigurert atferd måtte beholde sin betydning, samtidig som klargjøring, kjøring og utdata fikk et tydeligere samlet ansvar.
Pasientvolum og kapasitetsbehov krever presise måldefinisjoner. Tidspunktet prognosen lages, informasjonen som er kjent da, og tidspunktet resultatet gjelder for, må holdes fra hverandre. Ellers kan en beregning som lar seg kjøre, svare på et annet spørsmål enn planleggeren trenger.
Implementeringen hadde flere opphav: kollegaens modell- og dataarbeid, mitt arkitektur- og modellarbeid og kodeagentenes bidrag. Repositoriet er på om lag 40 000 linjer R og Python, skrevet av oss begge og av kodeagenter. Alt måtte samles i én arkitektur.
En vellykket modellkjøring, en sammenlignbar migrasjon og en god prognose er forskjellige resultater. Jeg krevde tidsbevisst validering, sammenligning mot enkle referansemodeller og akseptansekriterier.
Klargjøre data med eksplisitt mål og tid.
Avklare utvalg, modellforløp og forutsetninger.
Hver modell gjør sitt eget arbeid innenfor planen.
Sammenligne like observasjoner og vise grensene.
Kjøreansvar, omfang, tidsgrenser og samsvar
#Samle kjøreansvaret
#Flere innganger og ulike utførelsesmønstre gjorde det krevende å holde modellkjøring og videreutvikling samlet.
Jeg samlet klargjøring, kjøreplanlegging og modulær utførelse i den nye arkitekturen, med tydelige grenser mot modellberegningene.
Felles klargjøring og kjøreplanlegging samler ansvar som ellers måtte koordineres for hver inngang. Modellberegningene beholder sine egne forutsetninger.
Felles logikk måtte håndtere reelle forskjeller mellom modellforløpene.
Forenkle planen underveis
#Omleggingen med kodeagenter startet fra en altfor omfattende plan. Den ville gitt en god kjernearkitektur for en stor aktør som selger prognoser som tjeneste, med mye infrastruktur kodebasen vår ikke trengte.
Jeg oppdaget det forholdsvis tidlig og stoppet implementeringen. Med den delvis implementerte koden som utgangspunkt planla jeg på nytt, utformet en strengt avgrenset minimumsversjon (MVP) og implementerte den fullt ut.
Mye av arbeidet som allerede var gjort, var godt og kunne brukes videre. Arkitekturen skulle passe prosjektets faktiske behov.
Gjøre tid og mål til faglige valg
#Et prognosegrunnlag kan inneholde opplysninger som først blir kjent etter tidspunktet prognosen skulle vært laget.
Jeg undersøkte måldefinisjon, overlappende intervaller, duplikater, liggetid, tidslekkasje og samsvar mellom variabler og mål, og la til rullerende validering.
En holdout-test, altså data som holdes utenfor modelltilpasningen, må etterligne situasjonen prognosen skal brukes i. Definisjonen av observasjon og tidsgrense er derfor en del av modellvurderingen. En tilfeldig oppdeling kan overse at modellen bruker informasjon den ikke ville hatt.
Sammenligne det omleggingen skulle bevare
#En stor arkitekturendring kan endre atferd selv om de nye delene hver for seg lar seg kjøre.
Jeg sammenlignet konfigurert atferd før og etter omleggingen på et eksplisitt grunnlag, i stedet for å regne en vellykket kjøring som bevis på at løsningen var bevart.
Verdier må gjelde de samme observasjonene før de kan sammenlignes. Manglende og dupliserte rader er egne avvik, også når en total ser lik ut. Å sammenligne bare totalsummer eller standardinnstillinger kunne skjult slike forskjeller.
En avgrenset sammenligning uttaler seg bare om sitt eget grunnlag.
Kilder og grenser
#Kode, konfigurasjon og testutdata fra prosjektet er ikke publisert.
Den rekonstruerte endringsflaten i omleggingen er 267 filer og 71 108 linjeoperasjoner. Tallet beskriver hvor mye som ble endret, ikke hvem som skrev linjene.
I den rekonstruerte sammenligningen av konfigurert modellatferd før og etter omleggingen var det rapporterte restavviket opptil om lag 0,000005 pasient, fra flyttallsforskjeller. Resultatet er ikke uavhengig reprodusert.
- Den fiktive sammenligningen på siden viser kontrollprinsippet. Den kjører verken den gamle eller den nye løsningen.
Teknisk grunnlag
#Informasjonstidspunkt og tidspunkt for resultatet
For en prognose må det være klart når beregningen lages og når utfallet gjelder. En opplysning som er registrert senere, kan ikke uten videre brukes til å beskrive hva modellen ville visst tidligere.
Det er også forskjell på en kjent nullobservasjon og et utfall som ennå ikke er kjent. Hvis de blandes, kan både treningsgrunnlag og feilmål få en annen betydning enn målbeskrivelsen.
Dette var spørsmål jeg tok opp i måldefinisjon og validering.
Sammenligne samme observasjon
En observasjon trenger en identitet som gjør det mulig å vite at gammel og ny verdi gjelder samme størrelse. Før tallene undersøkes, må nøkkelsettet være entydig og sammenlignbart.
I det fiktive eksemplet skilles duplikater, rader som bare finnes på én side, og ulike manglende verdier fra numerisk forskjell. To manglende verdier gir ingen numerisk sammenligning, og et slikt tilfelle skal ikke bli en vellykket tallkontroll.
Et fullstendig nøkkelsett er bare begynnelsen. En virkelig sammenligning må også avklare utvalg, konfigurasjon, datagrunnlag og hvilken beregning verdiene kommer fra.
Hva som gjenstår før operativ bruk
Arkitektur gjør utvikling og sammenligning mulig, men avgjør ikke alene om en prognose bør tas i bruk. Operativ bruk krever et vurdert datagrunnlag, relevante referanser, egnede feilmål og avklarte forventninger til oppfølging.
Arkitekturen gjør det også lettere å legge til og sammenligne modellfamilier. SARIMAX testes og evalueres fortsatt som et alternativ til de eksisterende modellene.
Kontroller dekning før du sammenligner
Dette viser hvorfor en tallkontroll først må sjekke at begge sider har de samme nøklene.
Syntetisk illustrasjon. Kjører ikke originalsystemet.
Uten fungerende JavaScript vises det faste eksemplet. Valg i lenken beregnes ikke.
Sammenligning av et testpar
Samsvar i testparet. 3 tallpar sammenlignet.
Sammenlignet uten normalisering.
| Nøkkel | Referanse (rå) | Kandidat (rå) | Forskjell |
|---|---|---|---|
| SYN-1 | 12,50000000 | 12,50000000 | 0,00000000 |
| SYN-2 | 20,00000000 | 20,00000000 | 0,00000000 |
| SYN-3 | 7,25000000 | 7,25000000 | 0,00000000 |