Winst:
- Mogelijkheid om een datapijplijn op te zetten (verzameling, validatie, opschoning, transformatie, splitsen, versiebeheer) en schemavalidatie aan het begin van de pijplijn te plaatsen
- Mogelijkheid om ontbrekende waarde- en labelbeslissingen te nemen op basis van veldbetekenis en -verdeling om gegevenslekken te voorkomen (groep en temporeel)
- Mogelijkheid om een reproduceerbare database te creëren door de gegevensversie en het willekeurszaad vast te stellen
De echte kracht van elk machine learning-systeem ligt in de data, niet in het model. Ervaren ingenieurs weten: “garbage in, garbage out” – zelfs het meest geavanceerde model dat slechte data gebruikt, zal slechte resultaten opleveren. In deze unit brengen we de datapijplijn (datapijplijn: de keten van stappen die de ruwe data gereed maken voor modeltraining) end-to-end in kaart en leren we bij welke stap van deze lijn we veilig kunstmatige intelligentie kunnen gebruiken.
Stappen van de datalijn
Een datalijn passeert doorgaans deze haltes:
- Verzameling (opname): gegevens ophalen uit bronnen (database, API, logbestanden, gebeurtenisstromen).
- Validatie: controleren of de gegevens voldoen aan het verwachte schema, typen en bereiken.
- Opschonen: omgaan met ontbrekende waarden, dubbele records, uitschieters en inconsistenties.
- Transformatie: het omzetten van ruwe gegevens in attributen – zoals het converteren van een categorische variabele naar een getal, het produceren van een ‘dag van de week’ uit een datum.
- Splitsen: Opsplitsen in trainings-, validatie- en testsets.
- Versiebeheer: Vastleggen welk model met welke gegevens is getraind.
Kunstmatige intelligentie bespaart tijd door codeconcepten en ideeën te genereren, vooral in de stappen 2, 3 en 4. Maar beslissingen zoals welk record moet worden weggegooid, welke ontbrekende waarde moet worden ingevuld en hoe, behoren toe aan de ingenieur die de gegevens kent; omdat onjuist schoonmaken een verborgen bias in het model kan injecteren.
Gegevensverificatie: vroege verdediging van de linie
De duurste fouten beginnen niet in de productie, maar daar waar de verificatiestap wordt overgeslagen. Schemavalidatie controleert automatisch of elke binnenkomende batch gegevens voldoet aan de verwachte structuur. Ligt de leeftijdskolom bijvoorbeeld tussen 0-120, is het e-mailveld leeg, is het aantal kolommen gewijzigd?
Tip: Zet de verificatie aan het begin van de regel. Hoe eerder corrupte gegevens worden ontdekt, hoe goedkoper het is om deze te repareren. Een schemafout die tijdens de productie wordt ontdekt, is vele malen duurder dan een fout die tijdens de trainingsfase wordt ontdekt.
Schrijf een validatieschema met pandera (of Great Expectations) voor het volgende gegevensschema. Kolommen en regels: - user_id: geheel getal, kan niet nul zijn, uniek - leeftijd: geheel getal, kan niet tussen 0 en 120 liggen - signup_date: datum, kan niet in de toekomst liggen - land: categorisch, uit de set {TR, DE, US, UK} - saldo: decimaal, kan niet negatief zijn Produceer een betekenisvol foutbericht voor elke regelovertreding. Toon de test met een voorbeeld van een onderbroken lijn aan het einde van de code.
Schoonmaken: het is de mens die beslist
Ontbrekende waarden zijn een realiteit in elke dataset. Manieren om te verwerken:
- Verwijdering: het weggooien van een rij/kolom met een zeer hoog percentage ontbrekende gegevens. Maar er bestaat een risico op informatieverlies en vooringenomenheid.
- Imputatie: Imputatie met gemiddelde, mediaan, meest voorkomende waarde of op modellen gebaseerde voorspelling.
- Vlag: Het opslaan van “ontbrekende” informatie in een aparte vlagkolom – soms is het ontbreken zelf het signaal.
Welke juist is, hangt af van het probleem. In een medische gegevensset moet de informatie "Bloedwaarde niet gemeten" worden bewaard in plaats van verwijderd; Want zelfs de weigering van de dokter om te meten is een signaal. AI kan je opties en code geven; Jij kiest welke past bij de realiteit van het vakgebied.
Zwakke prompt/sterke prompt
Zwakke prompt: "Vul ontbrekende waarden in."
Sterke prompt: "Er ontbreken waarden in de volgende kolommen: inkomen (12% ontbreekt, rechtsscheve verdeling), last_login (30% ontbreekt). Stel voor om inkomen in te vullen met mediaan, maar leg uit waarom mediaan en niet gemiddeld. Neem voor last_login aan dat de ontbrekende waarde aanzienlijk kan zijn (de gebruiker heeft mogelijk nooit ingelogd); overweeg om een 'never_logged_in'-vlag te genereren in plaats van deze te verwijderen. Schrijf de bias op die beide benaderingen aan het model zouden toevoegen."
Verschil: sterke prompt geeft distributie-informatie en gebiedsbetekenis; kunstmatige intelligentie produceert beslissingsondersteuning in plaats van mechanische vulling.
Etikettering: kwaliteit wordt gemeten
Bij begeleid leren (leren waarbij voorbeelden worden gegeven met de juiste antwoorden) leert het model labels (labels: het juiste antwoord voor elk voorbeeld). De kwaliteit van labels stelt een plafond: als mensen inconsistent labelen, leert het model inconsistent.
Inter-annotatorovereenkomst meet de snelheid waarmee verschillende mensen hetzelfde label aan dezelfde steekproef geven; Het wordt uitgedrukt door een coëfficiënt zoals Cohen's Kappa. Lage naleving geeft aan dat de taak onduidelijk is of dat de instructie zwak is.
Kunstmatige intelligentie helpt op twee manieren bij het labelen: (1) het opstellen van de annotatierichtlijn, (2) het vooraf labelen en het alleen door de mens laten corrigeren. Maar pre-labeling met LLM heeft een valkuil: systematische fouten in het model kunnen in de hele labelset terechtkomen. Dat is de reden waarom mensen altijd enkele LLM-labels controleren.
Let op: Beschouw labels geproduceerd door LLM niet als "grondwaarheid". Controleer een monster met een mens en meet de LLM-menselijke fit. Als de naleving laag is, zal pre-etikettering meer kwaad dan goed doen.
Datapartitie: voorkom lekkage
De gevaarlijkste fout bij het opsplitsen van data in training/validatie/testen is datalekken: het vermengen van testinformatie in training. Voorbeelden:
- De gegevens van dezelfde gebruiker vallen onder zowel training als testen (groepslek).
- De toekomst gebruiken bij training en het verleden bij testen in tijdreeksen (temporele lekkage).
- Berekening van schaalparameters (normalisatie) uit alle gegevens en vervolgens delen.
Tijdelijke splitsing is essentieel voor problemen met tijd: trainen met het verleden, testen in de toekomst. Willekeurige splitsing levert een ‘toekomstig’ voordeel op dat nooit zal gebeuren in de productie, en vergroot de statistieken.
Versiebeheer en reproduceerbaarheid van gegevens
“Met welke gegevens hebben we dit model getraind?” Het maanden later kunnen beantwoorden van de vraag is het kenmerk van serieuze ML-engineering. Met gegevensversiebeheer wordt elke momentopname van gegevens opgeslagen met een ID (hash of versietag). Tools zoals DVC-versiegegevens (Data Version Control), zoals code.
Om het resultaat van een model te reproduceren, moeten drie dingen worden opgelost: de dataversie, de codeversie en het willekeurige zaad. Zonder dit trio is het niet mogelijk om te zeggen "Ik heb hetzelfde resultaat". We zullen de reproduceerbaarheid verdiepen in unit 11; maar het repareren van het zaad in de datapijplijn begint vanaf hier.
drie minikoffers
Geval 1 - De opgeslagen dagschemavalidatie. Toen een team een stroomopwaarts systeemprijsveld omzet van centen naar lira's, daalden alle prijzen honderd keer. Schemavalidatie heeft de batch afgewezen als 'prijs buiten bereik' en het model is niet getraind met beschadigde gegevens. Zonder verificatie zou de fout alleen in de productie worden opgemerkt, met onjuiste voorspellingen.
Geval 2 - Vooroordeel door onjuiste vulling. In een kredietmodel werden ontbrekende inkomenswaarden gevuld met het gemiddelde. Maar de ontbrekende inkomens bevonden zich vooral in de lage-inkomensgroep; het gemiddelde heeft deze groep kunstmatig "verrijkt", en het model bood hen een oneerlijk hoge limiet. Het probleem met de mediaan + ontbrekende vlag opgelost.
Geval 3 - Tijdelijke lekkage. Een vraagvoorspellingsmodel zag er geweldig uit op de testset (95% nauwkeurigheid), maar crashte tijdens de productie. Waarom: door willekeurige splitsing had het model de toekomst gezien. Door over te schakelen naar tijdelijke binning daalde de testnauwkeurigheid tot 78%, maar dat waren echte prestaties en deze bleven in productie.
Kopieerbare sjablonen
Splits de volgende dataset in drie sets: training/validatie/testen. Beperking: dit is een tijdreeks; Gebruik TIJDELIJKE splitsing (train in het verleden, test in de toekomst). Voorkom batchlekken: zorg ervoor dat u dezelfde `customer_id` slechts in één cluster heeft. Bereken ALLEEN schaalparameters uit de trainingsset en pas deze vervolgens op alle toe. Druk af hoeveel regels er bij elke stap nog in de code zitten en voeg een bewering toe die controleert of er geen lekken zijn.
Schrijf een concept-annotatierichtlijn voor deze etiketteringstaak. Taak: [bijv. Label klantrecensie positief/negatief/neutraal]Verduidelijk grensgevallen: sarcasme, gemengde emoties, hoe label je een recensie die geen verband houdt met het product? Geef vijf voorbeelden en drie moeilijke randgevallen die de consistentie tussen taggers zullen vergroten.
Maak een reproduceerbaarheidchecklist voor deze gegevenspijplijn: - Hoe moet de gegevensversie worden hersteld? - Welke willekeurzaden moeten waar worden ingesteld? - Welke metagegevens (gegevenshash, aantal rijen, datum) moeten worden vastgelegd? Mijn codebase: [taal/bibliotheek]
Controleer deze opschooncode op gegevenslekken. Kijk hier specifiek naar: worden de schaal-/coderingsparameters berekend VOORDAT er wordt gesplitst? Worden er statistieken berekend op basis van alle gegevens of alleen uit training? Code: [code]
Beslissingstabel: strategie voor ontbrekende waarden
Status
Aanbevolen aanpak
Waarom
Numerieke, scheve verdeling
vullen met mediaan
Het gemiddelde wordt beïnvloed door uitschieters
Numeriek, symmetrisch
vullen met gemiddeld
Beschermt informatie
Het tekort kan aanzienlijk zijn
Vlagkolom + vulling
Gebrek is een signaal
Ontbrekend percentage > 60%
Kolom evalueren/weggooien
Lawaai is te veel
Categorisch
Categorie 'Onbekend'
Creëert geen kunstmatige meerderheid
Veel voorkomende fouten
- Verificatie overslaan. Zonder schemacontrole sluipen beschadigde gegevens geruisloos binnen.
- Schalen vóór het splitsen. Het lekt teststatistieken naar het onderwijs.
- Het gebruik van willekeurige splitsing in tijdreeksen. Het produceert valse hoge statistieken.
- Blindelings vertrouwend op LLM-labels. Systematische fouten verspreiden zich door de gegevens.
- De gegevensversie wordt niet opgeslagen. U kunt het resultaat niet reproduceren.
- Mechanische vulling met gemiddeld. Het negeert de betekenis van het veld en voegt bias toe.
Samengevat
De datapijplijn vormt de basis van het ML-systeem en verdient meer inspanning dan het model. Zet verificatie bovenaan; maak schoonmaak- en etiketteringsbeslissingen met domeinkennis; lekkage (groeps- en tijdelijk) in het compartiment voorkomen; repareer de gegevensversie en het zaad. AI genereert op deze lijn code en ideeën, maar het is aan jou om te beslissen welke gegevens je wilt verwerken en hoe – omdat elke verkeerde beslissing hier als een verborgen fout in het model terechtkomt.
Applicatie taak
Schrijf een validatieschema (pandera/Great Expectations) op uw eigen dataset en voeg opzettelijk een slechte rij toe en laat zien dat deze is opgevangen. Splits vervolgens de gegevens tijdelijk of batchgewijs, bereken de schaalparameters alleen op basis van training en controleer met een bewering of er geen lekkage is. Schrijf de gegevensversie en het aantal rijen naar een metadatabestand.
controlelijst
- [ ] Schemavalidatie wordt bovenaan de regel uitgevoerd.
- [ ] Ik heb de strategie voor ontbrekende waarden gekozen op basis van de betekenis van het veld, ik heb deze niet mechanisch ingevuld.
- [ ] Ik heb de labelkwaliteit (compliance) gemeten; Ik heb de LLM-tags door mensen gecontroleerd.
- [ ] Ik voorkwam groeps- en tijdlekkage in de ruit.
- [ ] Schalen/codering wordt alleen berekend op basis van de trainingsset.
- [ ] Gegevensversie, aantal rijen en geregistreerd zaad.