Vinster:
- Möjlighet att sätta upp en datapipeline (insamling, validering, rensning, transformering, delning, versionering) och placera schemavalidering i början av pipelinen
- Förmåga att fatta saknade värde och märkningsbeslut baserat på fältets betydelse och uppdelning för att förhindra dataläckage (grupp och tidsmässigt)
- Möjlighet att skapa en reproducerbar databas genom att fixa dataversionen och slumpmässighetsfröet
Den verkliga kraften i varje maskininlärningssystem ligger i data, inte i modellen. Erfarna ingenjörer vet: "skräp in, skräp ut" - även den mest avancerade modellen som matas med dålig data kommer att ge dåliga resultat. I den här enheten upprättar vi datapipeline (datapipeline: kedjan av steg som gör rådata redo för modellträning) från början till slut och lär oss vid vilket steg av denna linje vi säkert kan använda artificiell intelligens.
Steg av datalinje
En datalinje passerar vanligtvis genom dessa hållplatser:
- Insamling (intag): Hämta data från källor (databas, API, loggfiler, händelseströmmar).
- Validering: Kontrollera om data överensstämmer med det förväntade schemat, typerna och intervallen.
- Rengöring: Hanterar saknade värden, dubbletter av poster, extremvärden och inkonsekvenser.
- Transformation: Omvandla rådata till attribut — som att konvertera en kategorisk variabel till ett tal, producera en "veckodag" från ett datum.
- Uppdelning: Uppdelning i tränings-, validerings- och testset.
- Versionering: Registrerar vilken modell som tränats med vilken data.
Artificiell intelligens sparar tid genom att generera kodutkast och idéer, särskilt i steg 2, 3 och 4. Men beslut som vilken post som ska kasseras, vilket saknat värde som ska fyllas i och hur, tillhör ingenjören som kan data; eftersom felaktig rengöring kan injicera en dold förspänning i modellen.
Dataverifiering: tidigt försvar av linjen
De dyraste felen börjar inte i produktionen, utan där verifieringssteget hoppas över. Schemavalidering kontrollerar automatiskt om varje inkommande databatch överensstämmer med den förväntade strukturen. Är till exempel ålderskolumnen mellan 0-120, är e-postfältet tomt, har antalet kolumner ändrats?
Tips: Placera verifieringen i början av raden. Ju tidigare korrupta data fångas upp, desto billigare är det att fixa. Ett schemafel som fångas i produktionen är många gånger dyrare än ett som fångas i träningsfasen.
Skriv ett valideringsschema med pandera (eller Great Expectations) för följande dataschema. Kolumner och regler:- user_id: heltal, kan inte vara null, unikt- ålder: heltal, kan inte vara från 0-120- signup_date: date, kan inte vara i framtiden- land: kategorisk, från uppsättningen {TR, DE, US, UK}- saldo: decimal, kan inte vara negativ Skapa ett meningsfullt felmeddelande för varje regelöverträdelse. Visa testet med ett exempel på en streckad linje i slutet av koden.
Städning: det är människan som bestämmer
Saknade värden är en realitet för varje datamängd. Sätt att hantera:
- Borttagning: Kasta bort en rad/kolumn med en mycket hög felfrekvens. Men det finns en risk för informationsförlust och partiskhet.
- Imputation: Imputering med medelvärde, median, mest frekvent värde eller modellbaserad förutsägelse.
- Flagga: Lagring av "saknade" information i en separat flaggkolumn - ibland är den saknade själv signalen.
Vilken som är rätt beror på problemet. I en medicinsk datamängd bör informationen "blodvärde ej mätt" bevaras snarare än raderas; För även läkarens vägran att ta mätningar är en signal. AI kan ge dig alternativ och kod; Du väljer vilken som passar verkligheten på området.
Svag prompt / Stark prompt
Svag uppmaning: "Fyll i saknade värden."
Stark uppmaning: "Det saknas värden i följande kolumner: inkomst (12 % saknas, höger-sned fördelning), last_login (30 % saknas). Föreslå att fylla inkomsten med median, men förklara varför median och inte medelvärde. För last_login, anta att det saknade värdet kan vara signifikant (användaren kanske aldrig har loggat in); skriv endera av att generera en never_in-flagga för att ta bort. modellen."
Skillnad: stark prompt ger distributionsinformation och områdes betydelse; artificiell intelligens ger beslutsstöd istället för mekanisk fyllning.
Märkning: kvalitet mäts
Vid övervakat lärande (lärande där exempel ges med rätt svar) är det som modellen lär sig etiketter (etiketter: rätt svar för varje exempel). Etikettkvalitet sätter ett tak — om människor märker inkonsekvent lär sig modellen inkonsekvent.
Inter-annotator-avtal mäter den hastighet med vilken olika personer ger samma etikett till samma prov; Det uttrycks av en koefficient som Cohens Kappa. Låg efterlevnad indikerar antingen att uppgiften är otydlig eller så är instruktionen svag.
Artificiell intelligens hjälper till att märka på två sätt: (1) utarbetande av anteckningsriktlinjen, (2) förmärkning och att låta människan bara korrigera det. Men förmärkning med LLM har en fallgrop: systematiska fel i modellen kan läcka in i hela etikettuppsättningen. Det är därför människor alltid kontrollerar några av LLM-etiketterna.
Observera: Betrakta inte etiketter producerade av LLM som "grundsanning". Kontrollera ett prov med en människa och mät LLM-human passform. Om efterlevnaden är låg kommer förmärkning att göra mer skada än nytta.
Datapartition: förhindra läckage
Det farligaste misstaget när man delar upp data i träning/validering/testning är dataläckage: blandning av testinformation i träning. Exempel:
- Samma användares uppgifter faller inom både träning och testning (gruppläckage).
- Att använda framtiden i träning och det förflutna i testning i tidsserier (temporärt läckage).
- Beräkna skalningsparametrar (normalisering) från alla data och sedan dividera.
Temporal splitting är avgörande för problem som involverar tid: träna med det förflutna, testa i framtiden. Slumpmässig uppdelning ger en "framtida" fördel som aldrig kommer att hända i produktionen och blåser upp måtten.
Dataversionering och reproducerbarhet
"Vilka data tränade vi den här modellen med?" Att kunna svara på frågan månader senare är kännetecknet för seriös ML-teknik. Dataversionshantering lagrar varje dataögonblicksbild med ett ID (hash eller versionstagg). Verktyg som DVC (Data Version Control) versionsdata som kod.
För att reproducera resultatet av en modell måste tre saker fixas: dataversionen, kodversionen och slumpmässigt frö. Det går inte att säga "jag fick samma resultat" utan den här trion. Vi kommer att fördjupa reproducerbarheten i enhet 11; men fixering av fröet i datapipeline börjar härifrån.
tre minifodral
Fall 1 - Dagschemavalideringen sparad. När ett team konverterade ett uppströms systemprisfält från öre till lira sjönk alla priser 100 gånger. Schemavalidering avvisade batchen som "pris utanför intervallet" och modellen tränades inte med korrupta data. Utan verifiering skulle felet bara märkas i produktionen, med felaktiga förutsägelser.
Fall 2 - Bias av felaktig fyllning. I en kreditmodell fylldes uteblivna inkomstvärden med medelvärdet. Men uteblivna inkomster var övervägande i låginkomstgruppen; Genomsnittet artificiellt "berikade" denna grupp, och modellen erbjöd dem en orättvist hög gräns. Fixade problemet med median + missingness-flagga.
Fall 3 - Temporellt läckage. En modell för efterfrågeprognoser såg bra ut på testsetet (95 % noggrannhet) men kraschade i produktionen. Varför: på grund av slumpmässig uppdelning hade modellen sett framtiden. Att byta till temporal binning minskade testnoggrannheten till 78 % - men det var verklig prestanda och höll den i produktion.
Kopierbara mallar
Dela upp följande datauppsättning i tre uppsättningar: träning/validering/testning.Constraint: Detta är en tidsserie; Använd TEMPORAL splitting (träna i det förflutna, testa i framtiden). Förhindra batchläckage: ha samma `customer_id` endast i ett kluster. Beräkna skalningsparametrar ENDAST från träningsuppsättningen och tillämpa sedan på alla. Skriv ut hur många rader som finns kvar i koden vid varje steg och lägg till ett påstående som kontrollerar att det inte läcker.
Skriv ett utkast till anteckningsriktlinje för denna märkningsuppgift. Uppgift: [t.ex. Märk kundrecension positiv/negativ/neutral]Förtydliga gränsfall: sarkasm, blandade känslor, hur man märker recension som inte är relaterad till produkten? Ge 5 exempel och 3 svåra kantfall som kommer att öka konsekvensen mellan taggare.
Ta fram en checklista för reproducerbarhet för denna datapipeline:- Hur ska dataversionen fixas?- Vilka slumpmässiga frön ska sättas var?- Vilken metadata (datahash, radantal, datum) ska loggas? Min kodbas: [språk/bibliotek]
Kontrollera den här rensningskoden för dataläckage. Titta specifikt på detta: är skalnings-/kodningsparametrarna beräknade INNAN delning? Beräknas någon statistik från all data eller bara träning? Kod: [kod]
Beslutstabell: saknad värdestrategi
Status
Rekommenderat tillvägagångssätt
Varför
Numerisk, skev fördelning
fyll med median
Genomsnittet påverkas av extremvärden
Numerisk, symmetrisk
fyll med genomsnitt
Skyddar information
Bristen kan vara betydande
Flagga kolumn + fyll
Brist är en signal
Saknade andel > 60 %
Utvärdera/kassera kolumnen
Buller är för mycket
Kategoriskt
"Okänd" kategori
Skapar inte konstgjord majoritet
Vanliga misstag
- Hoppa över verifiering. Utan schemakontroll smyger korrupt data in tyst.
- Skalning före klyvning. Det läcker teststatistik till utbildningen.
- Använder slumpmässig uppdelning i tidsserier. Det producerar falska höga mätvärden.
- Blint litar på LLM-etiketter. Systematiska fel sprider sig över hela datan.
- Sparar inte dataversionen. Du kan inte återskapa resultatet.
- Mekanisk fyllning med medel. Det ignorerar fältets betydelse, lägger till partiskhet.
Sammanfattningsvis
Datapipelinen är grunden för ML-systemet och förtjänar mer ansträngning än modellen. Sätt verifiering överst; fatta beslut om städning och märkning med domänkunskap; förhindra läckage (grupp och temporal) i facket; fixa dataversionen och seed. AI genererar kod och idéer på den här linjen, men det är upp till dig att bestämma vilken data som ska bearbetas och hur – eftersom varje felaktigt beslut här övergår i modellen som en dold brist.
Applikationsuppgift
Skriv ett valideringsschema (pandera/Great Expectations) på din egen datauppsättning och lägg medvetet till en dålig rad och visa att den fastnade. Dela sedan upp data temporärt eller batchvis, beräkna skalningsparametrar endast från träning och verifiera att det inte finns något läckage med ett påstående. Skriv dataversionen och radräkningen till en metadatafil.
checklista
- [ ] Schemavalidering körs överst på raden.
- [ ] Jag valde strategin för missing value baserat på fältets betydelse, jag fyllde den inte mekaniskt.
- [ ] Jag mätte etikettens kvalitet (efterlevnad); Jag människokontrollerade LLM-taggar.
- [ ] Jag förhindrade grupp- och tidsläckage i rutan.
- [ ] Skalning/kodning beräknas endast från träningsuppsättningen.
- [ ] Dataversion, antal rader och seed registrerade.