Gevinster:
- Evne til å gjenkjenne forskjellige datakilder (database, API, fil, nettskraping) og fallgruvene til hver og forstå skjemaet riktig
- Evne til å utføre repeterbar prøvetaking ved å evaluere om utvalget representerer populasjons- og seleksjonsskjevheten
- Evne til å eliminere datalekkasje på innsamlingsstadiet og observere juridiske/etiske grenser ved å stille spørsmålet 'Vil jeg ha det på prediksjonstidspunktet' i hver kolonne?
Hver analyse er like god som kvaliteten på dataene du samler inn. Selv den mest avanserte modellen i verden vil gi upålitelige resultater hvis den fungerer med data som er samlet inn feil, samplet skjevt eller inneholder informasjon om fremtiden. I informatikk er dette prinsippet oppsummert som «søppel inn, søppel ut» (søppel inn, søppel ut). I denne enheten vil vi dekke datainnsamlingsfasen: forstå kilden, prøvetaking, stille kvalitetsspørsmål og være oppmerksom på risikoen for datalekkasje fra dag én. Kunstig intelligens er et kraftig hjelpemiddel på dette stadiet; Skriver SQL-spørring, oppsummerer API-dokument, utarbeider datakontrakt. Men det er mennesket som bestemmer hvilke data du samler inn og om disse dataene representerer deg.
Bli kjent med datakilder
Data kommer fra forskjellige steder, og hver kilde har sine egne fallgruver. Database (strukturerte data lagret i tabeller, vanligvis spørres med SQL) er den vanligste kilden; Det er pålitelig, men det er nødvendig å forstå ordningen godt. API (Application Programming Interface) gir live data, men medfører risiko for fartsgrenser og formatendringer. Filer (CSV, Excel, JSON) er fleksible, men utsatt for formatinkonsekvens. Nettskraping er kraftig, men det har juridiske og etiske grenser; Ikke alle nettsteder kan skrapes.
OBS: For nettskraping og automatisk datainnsamling, følg nettstedets brukervilkår, robots.txt-fil og KVKK/GDPR. Uautorisert datainnsamling skaper juridisk ansvar. I forbindelse med informasjonssikkerhet, bruk datainnsamlingsverktøy kun på systemer som du er autorisert for og for forsvars-/analyseformål; Uautorisert tilgang eller skraping er forbudt.
Forstå skjemaet: bli kjent med dataene
Før du samler inn et datasett, må du forstå skjemaet (navnene på kolonnene, deres datatyper, deres betydninger og deres forhold til hverandre). AI er veldig nyttig her for å lage en "dataordbok" - en tabell som forklarer hva hver kolonne betyr. Men forklaringene AI produserer er spådommer; Bekreft den sanne betydningen av hver kolonne med teamet som produserte dataene. For eksempel kan en kolonne kalt "status" inneholde 0/1/2; Det er kun det opprinnelige teamet som vet om disse er "venter/godkjent/kansellert" eller noe annet.
Følgende tabell oppsummerer de grunnleggende ressurstypene og advarslene:
Kilde
sterke poeng
felle
Hvordan AI hjelper
SQL database
Strukturell, pålitelig
Komplekse JOINs
Skriver et spørringsutkast
API
live data
Fartsgrense, formendring
Dokumentsammendrag, pull-kode
CSV/Excel
Fleksibel, rask
Formatinkonsekvens
Les/parse kode
nettskraping
Bred rekkevidde
Juridisk/etisk grense
Parsing av utkast (innenfor myndighet)
Logg-/hendelsesdata
detaljert
stort volum
Filtreringsspørring
Illustrasjon: representerer delen helheten?
Mesteparten av tiden jobber du med et utvalg (en delmengde valgt fra populasjonen) i stedet for hele dataene. Det kritiske spørsmålet er: representerer dette utvalget populasjonen? Seleksjonsskjevhet er den vanligste fellen. Hvis du for eksempel bare prøver brukere fra mobilappen, vil du ikke se nettbrukere og resultatene vil være villedende. Tilfeldig prøvetaking (hver post har like stor sjanse for å bli valgt) er tryggest i de fleste tilfeller; men i tidsseriedata gjøres deling kronologisk i stedet for tilfeldig (vi vil se dette i enhet 7 og 10).
Lekkasjebevissthet fra dag én
Datalekkasje er kilden til de fleste katastrofer og oppstår vanligvis i datainnsamlingsfasen. Eksempel: når du forutsier "var det kansellert", hvis du legger til kolonnen "kanselleringsdato" i dataene, ser modellen inn i fremtiden. Under innsamlingsfasen, still ett spørsmål for hver kolonne: "Vil jeg faktisk ha denne informasjonen når jeg gjør spådommen?" Hvis svaret er nei, lekker den kolonnen. Vi vil dekke dette emnet i dybden i enhet 10; Men bevisstheten bør starte fra dag én.
tre minisaker
Sak 1 – Representasjonsproblemet. En bank samlet inn kun data om godkjente lån for sin kredittrisikomodell (18 500 poster). Avslag var ikke i dataene. Modellen tok feil i den virkelige verden fordi den aldri så hvordan avviste ville oppføre seg. Leksjon: utvalget skal være representativt for hele populasjonen du tar avgjørelsen fra.
Sak 2 — Stille formendring. Et team hentet prisdata fra et API hver dag. En dag endret API-leverandøren valuta fra USD til EUR, men domenenavnet forble det samme. Data ble samlet inn i feil enhet i 12 dager; 3200 linjer ble ødelagt. Leksjon: Kontroller regelmessig volum og formatkonsistens i API-data.
Tilfelle 3 — Tidlig lekkasje. En analytiker inkluderte kolonnen "grunn til kontoavslutning" når han samlet inn data for et "churn"-estimat. Denne kolonnen ble fylt ut først etter at kunden forlot. Modellen ga 97 % nøyaktighet på testsettet; Det fungerte ikke i produksjonen fordi den kolonnen var tom på prediksjonstidspunktet. Leksjon: still hver kolonne spørsmålet "har jeg det på tidspunktet for spådommen?"
Fire kopierbare maler
1) Dataordbokutvinning:
Din rolle: assistent for dataforsker. Nedenfor er kolonnenavnene og eksempelverdiene (anonyme) for en tabell. For hver kolonne, oppgi dens estimerte betydning, datatype og potensielle kvalitetsrisikoer i en tabell. Merk kolonnene du ikke er sikker på som "bekreftelse nødvendig"; betyr å lage. Kolonner: [lim inn her]
2) Samplingskode (tilfeldig, repeterbar):
Jeg har pandaer df. Skriv kode som trekker ut et representativt tilfeldig utvalg på 5 % fra 200 000 rader. Bruk random_state=42 (for reproduserbarhet). Legg til kode for å kontrollere at klassefordelingen til utvalget er lik populasjonen.
3) Spørsmål om lekkasjeskanning:
Jeg skal gi deg denne listen over kolonner. Målet mitt er å forutsi "er det kansellert" (0/1). For hver kolonne, evaluer om jeg faktisk vil ha den på tidspunktet for spådommen og merk den som "sikker / mistenkelig / lekkasje". Skriv begrunnelsen din i én setning. Kolonner: [liste]
4) SQL pull-spørringsutkast:
Jeg har "ordre" og "kunder" tabeller i PostgreSQL. Skriv et JOIN-spørsmål som kombinerer bestillingene de siste 90 dagene med kundebyen og returnerer totalbeløpet og antall bestillinger per by. Forklar datofilteret og hvordan NULL-byer håndteres. Jeg kjører spørringen og bekrefter den.
Svak forespørsel / Sterk forespørsel
Svak melding:
Ta en god prøvedata fra denne databasen.
"Bra" er tvetydig; Hvilket maleri, hvilken periode, hvilken størrelse, hvilket formål er ikke klart. AI vil bare produsere en generisk, muligens feil spørring.
Kraftig ledetekst:
Din rolle: SQL-assistent. Jeg har en "transaksjonstabell": kolonne-id, kunde_id, dato (tidsstempel), beløp (numerisk), kanal (tekst: 'web'/'mobil'). Oppgave: Skriv en repeterbar (deterministisk med ORDER BY) spørring som returnerer 10 000 representative rader fra hver kanal for året 2024. Formål: kanalkomparativ analyse. List opp forutsetningene for søket ditt.
Her er tabellen, formålet, størrelsen og repeterbarheten tydelig.
Vanlige feil
- Stiller ikke spørsmål ved representativiteten til utvalget. Lett tilgjengelige data er ikke nøyaktige data; seleksjonsskjevhet forvrenger resultatet.
- Tilpasning av kolonnebetydninger til AI. Kildelaget vet betydningen; Ikke bruk AI-prediksjonen uten å bekrefte den.
- Sporer ikke API-format/enhetsendring. Den stille endringen samler inn korrupte data i flere dager.
- Ignorerer lekkasjen på innsamlingsstadiet. Hvis spørsmålet «Har jeg det på prediksjonstidspunktet» ikke stilles tidlig, vil modellen gi falsk suksess.
- Innsamling av uautoriserte eller ulovlige data. Brudd på robots.txt, brukervilkår og KVKK er en alvorlig risiko.
Tips: Behold et "datakort" på én side for hver nye datakilde: kilde, trekkdato, antall rader, kjente grenser og kolonner med risiko for lekkasje. Dette kortet lagrer spørsmålet "hva var disse dataene" og reproduserbarhet måneder senere.
Oppsummert
Kvaliteten på analysen begrenses av kvaliteten på dataene som samles inn. Kjenn kilden (database, API, fil, scrape) og skjemaet godt; sørge for at utvalget er representativt for populasjonen; Eliminer lekkasje fra dag én ved å spørre hver kolonne "har jeg den på prediksjonstidspunktet?" AI er en flott akselerator for spørre- og dokumentarbeid, men mennesker bestemmer hvilke data som skal samles inn og deres representativitet. Begrensninger for myndighet, lov og konfidensialitet kommer alltid først.
Søknadsoppgave
Velg en datakilde (fra din egen virksomhet eller hypotetisk). Få et utkast til en dataordbok fra AI med malen "dataordbokutvinning" ovenfor; Evaluer deretter hver kolonne manuelt for å se om den har blitt lekket. Prøv å finne minst én mistenkelig/lekkasjekolonne og skriv i én setning hvorfor det er risikabelt.
sjekkliste
- [ ] Har jeg bekreftet datakilden og skjemaet med kildeteamet?
- [ ] Har jeg sjekket at utvalget er representativt for populasjonen?
- [ ] Har jeg stilt hver kolonne spørsmålet "vil jeg ha det på tidspunktet for estimatet?"
- [ ] Har jeg gjort prøvetakingen repeterbar (fast frø)?
- [ ] Har jeg sjekket de juridiske/etiske (autoritet, robots.txt, KVKK) grensene for innsamling?