Gevinster:
- Evne til å sette opp en datapipeline (innsamling, validering, rensing, transformering, splitting, versjonering) og plassere skjemavalidering i begynnelsen av pipelinen
- Evne til å ta manglende verdi og merkebeslutninger basert på feltbetydning og inndeling for å forhindre datalekkasje (gruppe og tidsmessig)
- Evne til å lage en reproduserbar database ved å fikse dataversjonen og tilfeldighetsfrøet
Den virkelige kraften til hvert maskinlæringssystem ligger i dataene, ikke modellen. Erfarne ingeniører vet: "søppel inn, søppel ut" - selv den mest avanserte modellen matet med dårlige data vil gi dårlige resultater. I denne enheten etablerer vi datapipeline (datapipeline: kjeden av trinn som gjør rådataene klare for modelltrening) ende til ende og lærer på hvilket trinn av denne linjen vi trygt kan bruke kunstig intelligens.
Trinn av datalinje
En datalinje går vanligvis gjennom disse holdeplassene:
- Innsamling (inntak): Henting av data fra kilder (database, API, loggfiler, hendelsesstrømmer).
- Validering: Kontrollerer om dataene samsvarer med forventet skjema, typer og områder.
- Rengjøring: Håndtering av manglende verdier, dupliserte poster, uteliggere og inkonsekvenser.
- Transformasjon: Gjøre rådata til attributter - for eksempel å konvertere en kategorisk variabel til et tall, produsere en "ukedag" fra en dato.
- Splitting: Separering i trenings-, validerings- og testsett.
- Versjonskontroll: Registrering av hvilken modell som ble trent med hvilke data.
Kunstig intelligens sparer tid ved å generere kodeutkast og ideer, spesielt i trinn 2, 3 og 4. Men avgjørelser som hvilken post som skal forkastes, hvilken manglende verdi som skal fylles ut og hvordan, tilhører ingeniøren som kjenner dataene; fordi feil rengjøring kan injisere en skjult skjevhet i modellen.
Dataverifisering: tidlig forsvar av linjen
De dyreste feilene begynner ikke i produksjonen, men hvor verifikasjonstrinnet hoppes over. Skjemavalidering sjekker automatisk om hver innkommende batch med data samsvarer med den forventede strukturen. Er for eksempel alderskolonnen mellom 0-120, er e-postfeltet tomt, har antall kolonner endret seg?
Tips: Sett bekreftelsen på begynnelsen av linjen. Jo før korrupte data fanges opp, jo billigere er det å fikse. En skjemafeil fanget i produksjon er mange ganger dyrere enn en fanget i treningsfasen.
Skriv et valideringsskjema med pandera (eller Great Expectations) for følgende dataskjema. Kolonner og regler:- user_id: heltall, kan ikke være null, unik- alder: heltall, kan ikke være fra 0-120- signup_date: dato, kan ikke være i fremtiden- land: kategorisk, fra settet {TR, DE, US, UK}- saldo: desimal, kan ikke være negativ Lag en meningsfull feilmelding for hvert regelbrudd. Vis testen med et eksempel med stiplet linje på slutten av koden.
Rengjøring: det er mennesket som bestemmer
Manglende verdier er en realitet for hvert datasett. Måter å håndtere:
- Sletting: Forkaster en rad/kolonne med en svært høy manglende rate. Men det er en risiko for tap av informasjon og skjevhet.
- Imputering: Imputasjon med gjennomsnitt, median, hyppigste verdi eller modellbasert prediksjon.
- Flagg: Lagring av "manglet" informasjon i en egen flaggkolonne - noen ganger er selve manglende signalet.
Hvilken som er riktig avhenger av problemet. I et medisinsk datasett bør informasjonen "blodverdi ikke målt" bevares i stedet for å slettes; For selv legens avslag på å ta mål er et signal. AI kan gi deg alternativer og kode; Du velger hvilken som passer til feltets virkelighet.
Svak forespørsel / Sterk forespørsel
Svak melding: "Fyll inn manglende verdier."
Sterk melding: "Det mangler verdier i følgende kolonner: inntekt (12 % mangler, høyreskjev fordeling), last_login (30 % mangler). Foreslå å fylle inntekten med median, men forklar hvorfor median og ikke middelverdi. For last_login, anta at den manglende verdien kan være betydelig (brukeren har kanskje aldri logget på); vurderer_å generere en never_-flagget i stedet for å enten_logge ned. modellen."
Forskjell: sterk melding gir distribusjonsinformasjon og områdebetydning; kunstig intelligens produserer beslutningsstøtte i stedet for mekanisk fylling.
Merking: kvalitet måles
I veiledet læring (læring hvor det gis eksempler med de riktige svarene), er det modellen lærer merkelapper (etiketter: riktig svar for hvert eksempel). Etikettkvalitet setter et tak – hvis folk merker inkonsekvent, lærer modellen inkonsekvent.
Inter-annotator-avtale måler hastigheten som forskjellige personer gir samme etikett til samme prøve; Det uttrykkes med en koeffisient som Cohens Kappa. Lav etterlevelse indikerer enten at oppgaven er uklar eller instruksjonen er svak.
Kunstig intelligens hjelper til med merking på to måter: (1) utforming av annoteringsretningslinjen, (2) forhåndsmerking og få bare mennesket til å korrigere det. Men forhåndsmerking med LLM har en fallgruve: systematisk feil i modellen kan lekke inn i hele etikettsettet. Det er derfor mennesker alltid sjekker noen av LLM-etikettene.
OBS: Ikke betrakt etiketter produsert av LLM som "grunnsannhet". Sjekk en prøve med et menneske og mål LLM-menneskelig passform. Hvis etterlevelsen er lav, vil forhåndsmerking gjøre mer skade enn nytte.
Datapartisjon: forhindre lekkasje
Den farligste feilen når du deler opp data i trening/validering/testing er datalekkasje: blanding av testinformasjon i trening. Eksempler:
- Den samme brukerens registreringer faller inn i både trening og testing (gruppelekkasje).
- Bruke fremtiden i trening og fortiden i testing i tidsserier (temporal lekkasje).
- Beregner skalerings (normalisering) parametere fra alle data og deretter dele.
Tidsmessig splittelse er avgjørende for problemer som involverer tid: tren med fortiden, test i fremtiden. Tilfeldig splitting gir en "fremtidig" fordel som aldri vil skje i produksjon og blåser opp beregningene.
Dataversjon og reproduserbarhet
"Hvilke data trente vi denne modellen med?" Å kunne svare på spørsmålet måneder senere er kjennetegnet på seriøs ML-ingeniør. Dataversjonsstyring lagrer hvert dataøyeblikksbilde med en ID (hash eller versjonstag). Verktøy som DVC (Data Version Control) versjonsdata som kode.
For å reprodusere resultatet av en modell, må tre ting fikses: dataversjonen, kodeversjonen og det tilfeldige frøet. Det er ikke mulig å si «jeg fikk samme resultat» uten denne trioen. Vi vil utdype reproduserbarheten i enhet 11; men fiksering av frøet i datarørledningen starter herfra.
tre minisaker
Tilfelle 1 - Dagskjemavalideringen er lagret. Når et team konverterte et oppstrøms systemprisfelt fra pennies til lire, falt alle prisene 100 ganger. Skjemavalidering avviste partiet som "pris utenfor området", og modellen ble ikke trent med korrupte data. Uten verifisering vil feilen bare bli lagt merke til i produksjonen, med feil spådommer.
Tilfelle 2 - Bias av feil fylling. I en kredittmodell ble manglende inntektsverdier fylt med gjennomsnittet. Men manglende inntekt var overveiende i lavinntektsgruppen; gjennomsnittlig "beriket" denne gruppen kunstig, og modellen ga dem en urettferdig høy grense. Løste problemet med median + missingness flagg.
Tilfelle 3 - Temporell lekkasje. En etterspørselsprognosemodell så bra ut på testsettet (95 % nøyaktighet), men krasjet i produksjonen. Hvorfor: på grunn av tilfeldig splitting hadde modellen sett fremtiden. Bytte til temporal binning reduserte testnøyaktigheten til 78 % - men det var ekte ytelse og holdt den i produksjon.
Kopierbare maler
Del følgende datasett i tre sett: trening/validering/testing.Begrensning: Dette er en tidsserie; Bruk TEMPORAL splitting (tren i fortiden, test i fremtiden). Forhindre batchlekkasje: ha samme `customer_id` bare i én klynge. Beregn skaleringsparametere KUN fra treningssettet, og bruk deretter for alle. Skriv ut hvor mange linjer som er igjen i koden ved hvert trinn, og legg til en påstand som sjekker for lekkasjer.
Skriv et utkast til kommentarretningslinje for denne merkeoppgaven. Oppgave: [f.eks. Merk kundeanmeldelse positiv/negativ/nøytral]Tydeliggjør grensetilfeller: sarkasme, blandede følelser, hvordan merke anmeldelser som ikke er relatert til produktet? Gi 5 eksempler og 3 vanskelige kantsaker som vil øke konsistensen på tvers av taggere.
Lag en reproduserbarhetssjekkliste for denne datapipelinen:- Hvordan skal dataversjonen fikses?- Hvilke tilfeldighetsfrø skal settes hvor?- Hvilke metadata (datahash, radantall, dato) skal logges? Min kodebase: [språk/bibliotek]
Sjekk denne oppryddingskoden for datalekkasje. Se spesielt på dette: er skalerings-/kodingsparametrene beregnet FØR deling? Er noen statistikk beregnet fra alle data eller bare trening? Kode: [kode]
Beslutningstabell: manglende verdistrategi
Status
Anbefalt tilnærming
Hvorfor
Numerisk, skjev fordeling
fyll med median
Gjennomsnittet påvirkes av uteliggere
Numerisk, symmetrisk
fyll med gjennomsnitt
Beskytter informasjon
Mangelen kan være betydelig
Flagg kolonne + fyll
Mangel er et signal
Manglende andel > 60 %
Evaluer/kasser kolonne
Støy er for mye
Kategorisk
"Ukjent" kategori
Skaper ikke kunstig flertall
Vanlige feil
- Hopp over verifisering. Uten skjemakontroll sniker korrupte data seg lydløst inn.
- Skalering før klyving. Det lekker teststatistikk inn i utdanningen.
- Bruker tilfeldig deling i tidsserier. Det produserer falske høye beregninger.
- Stoler blindt på LLM-etiketter. Systematiske feil sprer seg gjennom dataene.
- Lagrer ikke dataversjonen. Du kan ikke reprodusere resultatet.
- Mekanisk fylling med middels. Den ignorerer feltbetydning, legger til skjevhet.
Oppsummert
Datapipelinen er grunnlaget for ML-systemet og fortjener mer innsats enn modellen. Sett verifisering øverst; ta beslutninger om rengjøring og merking med domenekunnskap; forhindre lekkasje (gruppe og tidsmessig) i rommet; fikse dataversjonen og frøet. AI genererer kode og ideer på denne linjen, men det er opp til deg å bestemme hvilke data som skal behandles og hvordan – fordi hver feil beslutning her går inn i modellen som en skjult feil.
Søknadsoppgave
Skriv et valideringsskjema (pandera/Great Expectations) på ditt eget datasett og legg bevisst til en dårlig rad og vis at den ble fanget. Del deretter dataene midlertidig eller batchvis, beregn skaleringsparametere kun fra trening, og kontroller at det ikke er noen lekkasje med en påstand. Skriv dataversjonen og radtellingen til en metadatafil.
sjekkliste
- [ ] Skjemavalidering kjører på toppen av linjen.
- [ ] Jeg valgte strategien for manglende verdi basert på feltbetydning, jeg fylte den ikke ut mekanisk.
- [ ] Jeg målte etikettkvalitet (compliance); Jeg menneskesjekket LLM-tagger.
- [ ] Jeg forhindret gruppe- og tidslekkasje i ruten.
- [ ] Skalering/koding beregnet kun fra treningssettet.
- [ ] Dataversjon, antall rader og frø registrert.