Gevinster:
- Evne til å gjenkjenne typer datalekkasje (mål, tid, forbehandling, gruppert rad) og spørre om "for godt til å være sant" som en alarm
- Evne til å forhindre lekkasje med tidlig separasjon av testsett, rørledning og korrekt inndeling (kronologisk/gruppert)
- Evne til å gjøre analyser reproduserbare med faste frø, versjonskontroll og fjerning av manuelle trinn
Det er to feil som kaster bort mest innsats innen datavitenskap, og de er begge lumske fordi de fører til katastrofe akkurat når alt "ser ut til å være bra." Den første er datalekkasje: modellen fungerer utmerket på testsettet, men krasjer i produksjonen. Det andre er irreproduserbarhet: du kjører en analyse seks måneder senere og får et helt annet resultat. Denne enheten er dedikert til å kjenne og unngå disse to fallgruvene i dybden. AI kan øke begge risikoene (genererer raskt, foreslår skjulte lekkasjer, gjør det lettere for deg å ta manuelle trinn), men kan også redusere dem hvis de brukes riktig. Forskjellen ligger i disiplin.
Datalekkasje: klarsynt modell
Datalekkasje er når modellen ser informasjon under trening som den ikke vil ha på tidspunktet for faktisk prediksjon. Modellen "jukser" med denne informasjonen, ser bra ut på testsettet, men krasjer i produksjon uten den informasjonen. Symptomet på en lekkasje er nesten alltid det samme: for godt til å være sant. Før du gleder deg når du ser 99% nøyaktighet, bør du se etter lekkasjer.
De viktigste typene lekkasje er:
1. Mållekkasje: En funksjon er et resultat av målet. I "ble cancelled"-prognosen er "kanselleringsdato" eller "refusjonsbeløp"-kolonnene resultatet av målet; De vil først fylles ut når resultatet er klart.
2. Tidslekkasje: Å bringe fremtidig informasjon til fortiden. Når du beregner "gjennomsnittet for siste 30 dager", inkluderer dagene etter prognosedagen, eller del tidsserien tilfeldig.
3. Forbehandlingslekkasje: Læretransformasjoner som skalering, fylling, koding fra alle data før trenings-/testpartisjonen. Gjennomsnittet av testdata forstyrrer treningen.
4. Duplikat/gruppert radlekkasje: Rekker som tilhører samme person er tilstede i både trening og testing (to besøk av samme pasient i ulike sett). Modellen memorerer personen.
Lekkasjetype
Hvordan er født
Hvordan forebygge
mållekkasje
Kolonne som er resultatet av målet
"Har jeg det på tidspunktet for prediksjon" test
tidslekkasje
Å bringe fremtiden til fortiden
Kronologisk inndeling, vinduskontroll
Forbehandlingslekkasje
Forhåndsdelt konvertering
Pipeline, passe bare fra trening
Gruppert radlekkasje
Samme enhet i to sett
Delt etter gruppe (GroupKFold)
Den eneste disiplinen for å forhindre lekkasje
Den vanlige løsningen for alle typer lekkasjer koker ned til én setning: Isoler testsettet så tidlig som mulig for å etterligne den virkelige fremtiden, og ikke "lær" det noe. I praksis betyr dette: først dele opp, deretter lære alle transformasjonene kun fra opplæringen og bruke dem i en pipeline (en struktur som samler alle trinnene i en enkelt kjede). For hver funksjon, still spørsmålet "har jeg denne informasjonen på tidspunktet for spådommen?" Hvis det er tid, del den kronologisk; Hvis den samme enheten er repeterende, del etter gruppe.
Forsiktig: Det farligste aspektet ved en lekkasje er at den fremstår som en suksess. En dårlig modell vil åpenbart gi dårlige resultater og vil bli lagt merke til; En lekket modell fungerer utmerket, gleder alle og settes i produksjon — det er der kollapsen begynner. Det er derfor et "veldig godt" resultat er grunn til alarm, ikke feiring.
Reproduserbarhet: får samme resultat to ganger
Reproduserbarhet er muligheten til å få samme resultat når du kjører en analyse på nytt på et annet tidspunkt, på en annen maskin. Uten dette er analysen din tilfeldig, ikke vitenskapelig. Hovedårsaker og løsninger som svekker reproduserbarheten:
Manuelle trinn: Manuelt endre en celle i Excel, manuelt redigere et diagram. Løsning: ha hvert trinn i kode.
Ufiksert tilfeldighet: Modelltrening, prøvetaking, splitting involverer tilfeldighet. Løsning: fiks det tilfeldige frøet (startverdien til tilfeldig generator) (tilfeldig_tilstand=42).
Versjonsskifter: Resultatet kan endres når bibliotekversjonen endres. Løsning: fiks avhengigheter (requirements.txt, miljøfil).
Ingen journalføring: Det er ikke klart hvilke data, hvilken kode, hvilken parameter som ble brukt. Løsning: versjonskontroll (Git — systemet som lagrer alle versjoner av koden) og dataversjon.
"Det fungerer bare på min maskin": Løsning: dokumenter miljøet, bruk beholdere (Docker) hvis mulig.
tre minisaker
Tilfelle 1 — Mållekkasje. En helseanalyse inneholdt kolonnen "medisinering etter utskrivning" for å forutsi "om pasienten vil bli innlagt på nytt." Denne kolonnen ble fylt først etter at pasienten ble skrevet ut. Modellen ga 96 %, i produksjon 61 %. 8 ukers prosjektet var søppel. Leksjon: spør hver funksjon "er den til stede på prediksjonstidspunktet?"
Tilfelle 2 — Forbehandlingslekkasje. Ett team skalerte alle dataene og delte dem deretter. Gjennomsnittet av testdataene var involvert i skalering. CV-score 89 %, faktisk produksjon 76 %. Den falske suksessen forsvant da jeg flyttet til Pipeline og lærte om transformasjoner kun fra trening. Leksjon: del først, transformer senere.
Tilfelle 3 — Manglende reprodusering. En analytiker ønsket å oppdatere diagrammet han presenterte for ledelsen tre måneder senere, men kunne ikke huske hvordan han produserte det; mange trinn ble gjort manuelt i Excel. Resultatet gikk ikke og tilliten ble rokket. Leksjon: ingen manuelle trinn, alt er i kode og Git.
Fire kopierbare maler
1) Lekkasjeinspeksjon:
Din rolle: lekkasjeinspektør. Mål: "churn" (0/1), prognosereferansedato: record_date. Jeg vil gi deg denne listen over funksjoner. For HVER funksjon: (a) er det en konsekvens av målet, (b) er det tilgjengelig for meg på prediksjonstidspunktet, (c) inkluderer tidsvinduet fremtiden? Merk det som «utrygt/mistenkelig/lekkasje» og skriv en årsak. Funksjoner: [liste]
2) Lekkasjefri rørledning:
Sett opp sklearn Pipeline: først delt tog/test (stratifisert, frø=42), SÅ monter all forbehandling (imputere, skalere, kode) inn i rørledningen KUN fra trening. Forklar hvorfor koden er lekkasjefri, hvilket trinn ble lært hvor.
3) Kode for sjekkliste for reproduserbarhet:
Jeg ønsker å gjøre analysen min reproduserbar. Foreslå kode/struktur som legger til: (1) hardt frø for all tilfeldighet, (2) utskriftsbibliotekversjoner som brukes, (3) dato/versjonskode for data og utdata. Gi meg også en sjekkliste for å sikre at det ikke er noen manuelle trinn.
4) Gruppert partisjon (samme enhetslekkasje):
I dataene finnes den samme customer_id i flere rader. Lag en splitt (GroupKFold ellerGroupShuffleSplit, gruppe = kunde_id) som HINDER at samme kunde er i både opplæring og testing. Ta med kode for å bekrefte at ingen kunder er i begge settene etter oppdeling.
Svak forespørsel / Sterk forespørsel
Svak melding:
Modellen min ga 98 % nøyaktighet, er ikke det bra? Optimaliser koden.
Å feire 98 % skjuler lekkasjen. Før du optimaliserer, bør det stilles spørsmål ved om denne poengsummen er ekte eller ikke.
Kraftig ledetekst:
Din rolle: lekkasjeinspektør. Modellen min gir 98 % nøyaktighet på testsettet, noe som høres "for godt ut til å være sant" for meg. Sjekk: (1) er noen funksjoner resultatet av målet, (2) er konverteringene gjort før splitting, (3) er den samme enheten i to sett, (4) er det noen tidslekkasjer. List opp eventuelle mistenkelige punkter; Fokuser på å finne lekkasjen, ikke å fikse poengsummen.
Her behandles en høy poengsum som et tegn som skal stilles spørsmålstegn ved, ikke feires.
Vanlige feil
- Vi feirer det "veldig gode" resultatet. En score som er for god til å være sann er et lekkasjevarsel, ikke en prestasjon.
- Lære transformasjonen fra alle data før deling. Den vanligste lekkasjen; Del først med rørledning.
- Deler tidsserien tilfeldig. Modellen ser fremtiden; Kronologisk inndeling er et must.
- Forlater samme enhet i to sett. Modellen memorerer personen; Del etter gruppe.
- Ikke gå inn manuelt og skrive inn i koden. Analysen blir irreproduserbar; alt skal være i kode og Git.
Tips: Skriv et "æresløfte" med to setninger i begynnelsen av prosjektet ditt: "Jeg har ikke rørt testsettet på noen måte før jeg ser det i produksjon. Hvert trinn er i koden og frøet er fikset." Hvis du ikke kan signere disse to setningene ærlig, er resultatet ikke pålitelig ennå.
Oppsummert
Datalekkasje og ikke-reproduserbarhet er de to dyreste stille feilene innen datavitenskap. Lekkasje er modellens fremtidsvisjon og presenterer seg som falsk suksess; Løsningen er å dele testsettet tidlig, lære transformasjonene kun fra trening (pipeline), stille hver funksjon spørsmålet "Har jeg det på prediksjonstidspunktet" og gjøre korrekt splitting (kronologisk/gruppert). Reproduserbarhet er å kunne få samme resultat to ganger; løsningen hans er å fjerne trinn manuelt, feste frøet, fryse versjonene og beholde alt i Git. AI kan enten øke eller redusere disse risikoene; Det er din disiplin som avgjør.
Søknadsoppgave
Ta funksjonslisten til en modell du har bygget (eller en hypotetisk) og still hver funksjon spørsmålet "har jeg denne informasjonen på prediksjonstidspunktet?" skriftlig; Finn minst én lekkasjekandidat. Fyll deretter ut en sjekkliste for å gjøre analysen reproduserbar: er frøet fikset, er det manuelle trinn, er versjonene registrert, er de i Git. Rett opp manglene.
sjekkliste
- [ ] Spurte jeg "for godt til å være sant"-poengsum som et lekkasjevarsel?
- [ ] Lærte jeg alle transformasjonene etter splitt, bare fra trening?
- [ ] Har jeg delt i henhold til tids-/gruppestrukturen (kronologisk/GroupKFold)?
- [ ] Har jeg gjort all tilfeldighet repeterbar med fast frø?
- [ ] Har jeg fjernet de manuelle trinnene og holdt alt i kode og versjonskontroll?