Gevinster:
- Mulighed for at opsætte en datapipeline (indsamling, validering, rensning, transformation, opdeling, versionering) og placere skemavalidering i begyndelsen af pipelinen
- Evne til at træffe manglende værdi og mærkningsbeslutninger baseret på feltbetydning og opdeling for at forhindre datalækage (gruppe og tidsmæssig)
- Evne til at skabe en reproducerbar database ved at rette dataversionen og tilfældighedsfrøet
Den virkelige kraft af ethvert maskinlæringssystem ligger i dataene, ikke modellen. Erfarne ingeniører ved: "skrald ind, skrald ud" - selv den mest avancerede model med dårlige data vil give dårlige resultater. I denne enhed etablerer vi datapipeline (datapipeline: kæden af trin, der gør rådataene klar til modeltræning) fra ende til anden og lærer, på hvilket trin af denne linje, vi sikkert kan bruge kunstig intelligens.
Trin af datalinje
En datalinje passerer typisk gennem disse stop:
- Indsamling (indtagelse): Træk data fra kilder (database, API, logfiler, hændelsesstrømme).
- Validering: Kontrol af, om dataene er i overensstemmelse med det forventede skema, typer og intervaller.
- Rengøring: Håndtering af manglende værdier, duplikerede poster, afvigelser og uoverensstemmelser.
- Transformation: At omdanne rådata til attributter - såsom at konvertere en kategorisk variabel til et tal, producere en "ugedag" fra en dato.
- Opdeling: Adskillelse i trænings-, validerings- og testsæt.
- Versionering: Registrering af hvilken model der blev trænet med hvilke data.
Kunstig intelligens sparer tid ved at generere kodeudkast og ideer, især i trin 2, 3 og 4. Men beslutninger som hvilken post der skal kasseres, hvilken manglende værdi der skal udfyldes og hvordan, tilhører ingeniøren, der kender dataene; fordi forkert rengøring kan injicere en skjult skævhed i modellen.
Dataverifikation: tidligt forsvar af linjen
De dyreste fejl begynder ikke i produktionen, men hvor verifikationstrinnet springes over. Skemavalidering kontrollerer automatisk, om hver indgående batch af data er i overensstemmelse med den forventede struktur. Er alderskolonnen for eksempel mellem 0-120, er e-mail-feltet tomt, er antallet af kolonner ændret?
Tip: Sæt bekræftelsen i begyndelsen af linjen. Jo hurtigere korrupte data fanges, jo billigere er det at rette. En skemafejl fanget i produktionen er mange gange dyrere end en fanget i træningsfasen.
Skriv et valideringsskema med pandera (eller Great Expectations) for følgende dataskema. Kolonner og regler:- user_id: heltal, kan ikke være null, unikt- alder: heltal, kan ikke være fra 0-120- signup_date: dato, kan ikke være i fremtiden- land: kategorisk, fra sættet {TR, DE, US, UK}- balance: decimal, kan ikke være negativ Fremstil en meningsfuld fejlmeddelelse for hver regelovertrædelse. Vis testen med et eksempel på en stiplet linje i slutningen af koden.
Rengøring: det er mennesket, der bestemmer
Manglende værdier er en realitet for alle datasæt. Måder at håndtere:
- Sletning: Kassering af en række/kolonne med en meget høj manglende rate. Men der er risiko for tab af information og bias.
- Imputation: Imputation med middelværdi, median, hyppigste værdi eller modelbaseret forudsigelse.
- Flag: Lagring af "manglede" information i en separat flagkolonne - nogle gange er selve det manglende signalet.
Hvilken der er korrekt afhænger af problemet. I et medicinsk datasæt bør informationen "blodværdi ikke målt" bevares i stedet for at slettes; For selv lægens afvisning af at tage mål er et signal. AI kan give dig muligheder og kode; Du vælger, hvilken der passer til feltets virkelighed.
Svag prompt / Stærk prompt
Svag prompt: "Fyld manglende værdier."
Stærk prompt: "Der mangler værdier i følgende kolonner: indkomst (12 % mangler, højreskæv fordeling), last_login (30 % mangler). Foreslå at udfylde indkomst med median, men forklar hvorfor median og ikke middelværdi. For last_login, antag, at den manglende værdi kan være signifikant (brugeren har måske aldrig logget ind); skriv_tilføj nedadgående tilgang i stedet for enten at tilføje en aldrig_logging. modellen."
Forskel: stærk prompt giver distributionsinformation og områdebetydning; kunstig intelligens producerer beslutningsstøtte i stedet for mekanisk fyldning.
Mærkning: Kvalitet måles
I superviseret læring (læring, hvor der gives eksempler med de rigtige svar), er det, som modellen lærer, etiketter (etiketter: det rigtige svar for hvert eksempel). Etiketkvalitet sætter et loft - hvis folk mærker inkonsekvent, lærer modellen inkonsekvent.
Inter-annotator-aftale måler den hastighed, hvormed forskellige personer giver den samme etiket til den samme prøve; Det er udtrykt ved en koefficient som Cohens Kappa. Lav compliance indikerer enten at opgaven er uklar, eller instruktionen er svag.
Kunstig intelligens hjælper med at mærke på to måder: (1) udarbejdelse af annoteringsvejledningen, (2) præ-mærkning og kun at få mennesket til at rette det. Men præ-mærkning med LLM har en faldgrube: systematisk fejl i modellen kan lække ind i hele etiketsættet. Det er derfor, mennesker altid tjekker nogle af LLM-etiketterne.
Bemærk: Betragt ikke etiketter produceret af LLM som "grundsandhed". Tjek en prøve med et menneske og mål LLM-human fit. Hvis overensstemmelsen er lav, vil præ-mærkning gøre mere skade end gavn.
Datapartition: forhindre lækage
Den farligste fejl ved opdeling af data i træning/validering/testning er datalækage: sammenblanding af testinformation i træning. Eksempler:
- Den samme brugers registreringer falder ind under både træning og test (gruppelækage).
- Brug af fremtiden i træning og fortiden i test i tidsserier (temporal lækage).
- Beregning af skalering (normalisering) parametre fra alle data og derefter division.
Tidsmæssig opdeling er afgørende for problemer, der involverer tid: Træn med fortiden, test i fremtiden. Tilfældig opsplitning giver en "fremtidig" fordel, der aldrig vil ske i produktionen og puster metrikken op.
Dataversionering og reproducerbarhed
"Hvilke data trænede vi denne model med?" At kunne besvare spørgsmålet måneder senere er kendetegnende for seriøs ML-ingeniør. Dataversionering gemmer hvert datasnapshot med et ID (hash eller versionstag). Værktøjer såsom DVC (Data Version Control) versionsdata som kode.
For at gengive resultatet af en model, skal tre ting rettes: dataversionen, kodeversionen og den tilfældige frø. Det er ikke muligt at sige "Jeg fik samme resultat" uden denne trio. Vi vil uddybe reproducerbarheden i enhed 11; men fiksering af frøet i datapipelinen starter herfra.
tre minisager
Case 1 - Dagskemavalideringen er gemt. Da et hold konverterede et opstrøms systemprisfelt fra pennies til lire, faldt alle priser 100 gange. Skemavalidering afviste batchen som "pris uden for intervallet", og modellen blev ikke trænet med korrupte data. Uden verifikation ville fejlen kun blive bemærket i produktionen med forkerte forudsigelser.
Tilfælde 2 - Bias af forkert fyldning. I en kreditmodel blev manglende indkomstværdier udfyldt med middelværdien. Men manglende indkomst var overvejende i lavindkomstgruppen; gennemsnittet kunstigt "berigede" denne gruppe, og modellen tilbød dem en uretfærdig høj grænse. Rettede problemet med median + missingness flag.
Case 3 - Temporal lækage. En efterspørgselsprognosemodel så godt ud på testsættet (95 % nøjagtighed), men styrtede ned i produktionen. Hvorfor: På grund af tilfældig opdeling havde modellen set fremtiden. Skift til temporal binning faldt testnøjagtigheden til 78 % - men det var reel ydeevne og holdt den i produktion.
Kopierbare skabeloner
Opdel følgende datasæt i tre sæt: træning/validering/testning.Constraint: Dette er en tidsserie; Brug TEMPORAL opdeling (træn i fortiden, test i fremtiden). Forebyg batchlækage: have det samme `customer_id` kun i én klynge. Beregn KUN skaleringsparametre fra træningssættet, og gælder derefter for alle. Udskriv, hvor mange linjer der er tilbage i koden ved hvert trin, og tilføj en påstand, der kontrollerer, om der ikke er lækager.
Skriv et udkast til annoteringsvejledning til denne mærkningsopgave. Opgave: [f.eks. Mærk kundeanmeldelse positiv/negativ/neutral]Tydeliggør grænsetilfælde: sarkasme, blandede følelser, hvordan mærker man anmeldelse, der ikke er relateret til produktet? Giv 5 eksempler og 3 svære kantsager, der vil øge sammenhængen på tværs af taggere.
Lav en reproducerbarhedstjekliste for denne datapipeline:- Hvordan skal dataversionen rettes?- Hvilke tilfældighedsfrø skal sættes hvor?- Hvilke metadata (datahash, rækkeantal, dato) skal logges? Min kodebase: [sprog/bibliotek]
Tjek denne oprydningskode for datalækage. Se specifikt på dette: er skalerings-/kodningsparametrene beregnet FØR opdeling? Er nogen statistik beregnet ud fra alle data eller blot træning? Kode: [kode]
Beslutningstabel: manglende værdistrategi
Status
Anbefalet tilgang
Hvorfor
Numerisk, skæv fordeling
fyld med median
Gennemsnittet er påvirket af outliers
Numerisk, symmetrisk
fyld med gennemsnit
Beskytter information
Manglen kan være betydelig
Flag kolonne + fyld
Mangel er et signal
Manglende sats > 60 %
Evaluer/kasser kolonne
Støj er for meget
Kategorisk
"Ukendt" kategori
Skaber ikke kunstigt flertal
Almindelige fejl
- Springer verifikation over. Uden skemakontrol sniger korrupte data sig lydløst ind.
- Skalering før opdeling. Det lækker teststatistik til uddannelse.
- Brug af tilfældig opdeling i tidsserier. Det producerer falske høje metrics.
- Blinde tillid til LLM-etiketter. Systematiske fejl spreder sig gennem dataene.
- Dataversionen gemmes ikke. Du kan ikke gengive resultatet.
- Mekanisk fyldning med gennemsnit. Det ignorerer feltbetydning, tilføjer bias.
Sammenfattende
Datapipelinen er grundlaget for ML-systemet og fortjener en større indsats end modellen. Sæt verifikation øverst; træffe beslutninger om rengøring og mærkning med domæneviden; forhindre lækage (gruppe og tidsmæssig) i rummet; reparere dataversionen og seed. AI genererer kode og ideer på denne linje, men det er op til dig at beslutte, hvilke data der skal behandles og hvordan - fordi enhver forkert beslutning her går ind i modellen som en skjult fejl.
Ansøgningsopgave
Skriv et valideringsskema (pandera/Great Expectations) på dit eget datasæt og tilføj bevidst en dårlig række og vis, at den blev fanget. Opdel derefter dataene midlertidigt eller batchvis, beregn skaleringsparametre kun fra træning, og bekræft, at der ikke er nogen lækage med en påstand. Skriv dataversionen og rækkeantallet til en metadatafil.
tjekliste
- [ ] Skemavalidering kører øverst på linjen.
- [ ] Jeg valgte strategien for manglende værdi baseret på feltbetydning, jeg udfyldte den ikke mekanisk.
- [ ] Jeg målte etiketkvalitet (compliance); Jeg mennesketjekkede LLM-tags.
- [ ] Jeg forhindrede gruppe- og tidslækage i ruden.
- [ ] Skalering/kodning beregnes kun ud fra træningssættet.
- [ ] Dataversion, antal rækker og seed registreret.