Gevinster:
- Evne til at genkende forskellige datakilder (database, API, fil, web-skrabning) og faldgruberne ved hver og forstå skemaet korrekt
- Evne til at udføre gentagelig prøvetagning ved at evaluere, om prøven repræsenterer populations- og selektionsbias
- Evne til at eliminere datalækage på indsamlingsstadiet og overholde juridiske/etiske grænser ved at stille spørgsmålet 'Vil jeg have det på forudsigelsestidspunktet' i hver kolonne?
Hver analyse er lige så god som kvaliteten af de data, du indsamler. Selv den mest avancerede model i verden vil producere upålidelige resultater, hvis den arbejder med data, der er indsamlet forkert, samplet skævt eller indeholder information om fremtiden. I datalogi er dette princip opsummeret som "skrald ind, skrald ud" (skrald ind, skrald ud). I denne enhed vil vi dække dataindsamlingsfasen: forstå kilden, prøveudtagning, stille kvalitetsspørgsmål og være opmærksom på risikoen for datalækage fra dag ét. Kunstig intelligens er et stærkt hjælpemiddel på dette stadium; Skriver SQL-forespørgsel, opsummerer API-dokument, udarbejder datakontrakt. Men det er mennesket, der bestemmer, hvilke data du indsamler, og om disse data repræsenterer dig.
Lær datakilder at kende
Data kommer fra forskellige steder, og hver kilde har sine egne faldgruber. Database (strukturerede data gemt i tabeller, normalt forespørges med SQL) er den mest almindelige kilde; Det er pålideligt, men det er nødvendigt at forstå dets skema godt. API (Application Programming Interface) leverer live data, men medfører risiko for hastighedsbegrænsninger og formatændringer. Filer (CSV, Excel, JSON) er fleksible, men tilbøjelige til formatinkonsekvens. Webskrabning er kraftfuldt, men det har juridiske og etiske grænser; Ikke alle websteder kan skrabes.
OBS: For web-skrabning og automatisk dataindsamling skal du overholde webstedets vilkår for brug, robots.txt-fil og KVKK/GDPR. Uautoriseret dataindsamling skaber juridisk ansvar. I forbindelse med informationssikkerhed, brug kun dataindsamlingsværktøjer på systemer, som du er autoriseret til, og til forsvars-/analyseformål; Uautoriseret adgang eller skrabning er forbudt.
Forståelse af skemaet: sætte sig ind i dataene
Før du indsamler et datasæt, skal du forstå dets skema (navnene på kolonnerne, deres datatyper, deres betydninger og deres relationer til hinanden). AI er meget nyttig her til at skabe en "dataordbog" - en tabel, der forklarer, hvad hver kolonne betyder. Men de forklaringer, AI producerer, er forudsigelser; Bekræft den sande betydning af hver kolonne med det team, der producerede dataene. For eksempel kan en kolonne med navnet "status" indeholde 0/1/2; Kun det oprindelige team ved, om disse er "afventer/godkendt/annulleret" eller noget andet.
Følgende tabel opsummerer de grundlæggende ressourcetyper og advarsler:
Kilde
stærke side
fælde
Hvordan AI hjælper
SQL database
Strukturel, pålidelig
Komplekse JOINs
Skriver et forespørgselsudkast
API
live data
Hastighedsbegrænsning, formændring
Dokumentresuméer, pull-kode
CSV/Excel
Fleksibel, hurtig
Formatinkonsistens
Læs/parse kode
web skrabning
Bred rækkevidde
Lovlig/etisk grænse
Parsing af udkast (inden for myndighed)
Log/hændelsesdata
detaljeret
kæmpe volumen
Filtreringsforespørgsel
Illustration: repræsenterer delen helheden?
Det meste af tiden arbejder du med en stikprøve (en delmængde valgt fra populationen) i stedet for hele data. Det kritiske spørgsmål er: repræsenterer denne stikprøve befolkningen? Udvælgelsesbias er den mest almindelige fælde. For eksempel, hvis du kun prøver brugere fra mobilappen, vil du ikke se webbrugere, og dine resultater vil være vildledende. Stikprøver (hver post har lige stor chance for at blive udvalgt) er sikrest i de fleste tilfælde; men i tidsseriedata sker opdelingen kronologisk snarere end tilfældigt (vi vil se dette i enhed 7 og 10).
Lækbevidsthed fra dag ét
Datalækage er kilden til de fleste katastrofer og opstår normalt i dataindsamlingsfasen. Eksempel: når du forudsiger "blev det annulleret", hvis du tilføjer kolonnen "annulleringsdato" til dataene, ser modellen ind i fremtiden. Under indsamlingsfasen skal du stille et spørgsmål for hver kolonne: "Vil jeg faktisk have disse oplysninger på det tidspunkt, jeg laver forudsigelsen?" Hvis svaret er nej, er den kolonne utæt. Vi vil dække dette emne i dybden i enhed 10; Men bevidstheden bør starte fra dag ét.
tre minisager
Sag 1 — Problemet med repræsentation. En bank indsamlede kun data om godkendte lån til sin kreditrisikomodel (18.500 poster). Afvisninger var ikke i dataene. Modellen var forkert i den virkelige verden, fordi den aldrig så, hvordan afviste ville opføre sig. Lektion: stikprøven skal være repræsentativ for hele den population, som du træffer din beslutning ud fra.
Sag 2 — Tavs formændring. Et team hentede prisdata fra en API hver dag. En dag ændrede API-udbyderen valuta fra USD til EUR, men domænenavnet forblev det samme. Data blev indsamlet i den forkerte enhed i 12 dage; 3.200 linjer blev beskadiget. Lektion: Kontroller regelmæssigt volumen og formatkonsistens i API-data.
Tilfælde 3 — Tidlig lækage. En analytiker inkluderede kolonnen "årsag til kontolukning" ved indsamling af data til et "churn"-estimat. Denne kolonne blev først udfyldt, efter at kunden var gået. Modellen gav 97% nøjagtighed på testsættet; Det fungerede ikke i produktionen, fordi den kolonne var tom på forudsigelsestidspunktet. Lektion: Stil hver kolonne spørgsmålet "har jeg det på tidspunktet for forudsigelsen?"
Fire kopierbare skabeloner
1) Udtræk af dataordbog:
Din rolle: Data scientist assistent. Nedenfor er kolonnenavne og eksempel (anonyme) værdier for en tabel. For hver kolonne skal du angive dens anslåede betydning, datatype og potentielle kvalitetsrisici i en tabel. Marker de kolonner, du ikke er sikker på, som "bekræftelse påkrævet"; betyder at lave. Kolonner: [indsæt her]
2) Samplingkode (tilfældig, gentagelig):
Jeg har pandaer df. Skriv kode, der udtrækker en repræsentativ 5 % tilfældig stikprøve fra 200.000 rækker. Brug random_state=42 (for reproducerbarhed). Tilføj kode for at kontrollere, at prøvens klassefordeling svarer til populationen.
3) Spørgsmål om lækagescanning:
Jeg giver dig denne liste over kolonner. Mit mål er at forudsige "er det annulleret" (0/1). For hver kolonne skal du vurdere, om jeg faktisk vil have det på tidspunktet for forudsigelsen, og markere det som "sikkert / mistænkeligt / læk". Skriv din begrundelse i én sætning. Kolonner: [liste]
4) SQL pull-forespørgselsudkast:
Jeg har "ordrer" og "kunder" tabeller i PostgreSQL. Skriv en JOIN-forespørgsel, der kombinerer ordrerne fra de sidste 90 dage med kundebyen og returnerer det samlede beløb og antallet af ordrer pr. by. Forklar datofilteret og hvordan NULL-byer håndteres. Jeg vil køre forespørgslen og bekræfte den.
Svag prompt / Stærk prompt
Svag prompt:
Træk mig et godt eksempel på data fra denne database.
"God" er tvetydig; Hvilket maleri, hvilken periode, hvilken størrelse, hvilket formål er ikke klart. AI vil kun producere en generisk, muligvis forkert forespørgsel.
Kraftig prompt:
Din rolle: SQL assistent. Jeg har en "transaktions"-tabel: kolonne-id, kunde_id, dato (tidsstempel), beløb (numerisk), kanal (tekst: 'web'/'mobil'). Opgave: Skriv en gentagelig (deterministisk med ORDER BY) forespørgsel, der returnerer 10.000 repræsentative rækker fra hver kanal for år 2024. Formål: kanalkomparativ analyse. Angiv antagelserne for din forespørgsel.
Her er tabellen, formålet, størrelsen og repeterbarheden klar.
Almindelige fejl
- Uden at sætte spørgsmålstegn ved stikprøvens repræsentativitet. Let tilgængelige data er ikke nøjagtige data; selektionsbias forvrænger resultatet.
- Tilpasning af kolonnebetydninger til AI. Kildeholdet kender betydningen; Brug ikke AI-forudsigelsen uden at bekræfte den.
- Sporer ikke API-format/enhedsændring. Den tavse ændring indsamler korrupte data i dagevis.
- Ignorerer lækagen på indsamlingsstadiet. Hvis spørgsmålet "Har jeg det på forudsigelsestidspunktet" ikke stilles tidligt, vil modellen give falsk succes.
- Indsamling af uautoriserede eller ulovlige data. Overtrædelse af robots.txt, brugerbetingelser og KVKK er en alvorlig risiko.
Tip: Behold et "datakort" på én side for hver ny datakilde: kilde, pull-dato, antal rækker, kendte grænser og kolonner med risiko for lækage. Dette kort gemmer spørgsmålet "hvad var disse data" og reproducerbarhed måneder senere.
Sammenfattende
Kvaliteten af analysen er begrænset af kvaliteten af de indsamlede data. Kend kilden (database, API, fil, scrape) og skemaet godt; sørg for, at stikprøven er repræsentativ for populationen; Eliminer lækage fra dag ét ved at spørge hver kolonne "har jeg den på forudsigelsestidspunktet?" AI er en fantastisk accelerator til forespørgsels- og dokumentarbejde, men mennesker bestemmer, hvilke data der skal indsamles og deres repræsentativitet. Grænser for myndighed, lov og fortrolighed kommer altid først.
Ansøgningsopgave
Vælg en datakilde (fra din egen virksomhed eller hypotetisk). Få et udkast til en dataordbog fra AI med skabelonen "dataordbogsudtrækning" ovenfor; Evaluer derefter hver kolonne manuelt for at se, om den er blevet lækket. Prøv at finde mindst én mistænkelig/lækage kolonne og skriv i én sætning, hvorfor det er risikabelt.
tjekliste
- [ ] Har jeg bekræftet datakilden og skemaet med kildeteamet?
- [ ] Har jeg kontrolleret, at stikprøven er repræsentativ for populationen?
- [ ] Har jeg stillet hver kolonne spørgsmålet "vil jeg have det på tidspunktet for skønnet?"
- [ ] Har jeg gjort prøvetagningen gentagelig (fast frø)?
- [ ] Har jeg tjekket de juridiske/etiske (autoritet, robots.txt, KVKK) grænser for indsamling?