Vinster:
- Förmåga att känna igen olika datakällor (databas, API, fil, webbskrapning) och fallgroparna för var och en och förstå schemat korrekt
- Förmåga att utföra repeterbar provtagning genom att utvärdera om provet representerar populations- och urvalsbias
- Förmåga att eliminera dataläckage vid insamlingsstadiet och observera juridiska/etiska gränser genom att ställa frågan "Kommer jag att ha det vid tidpunkten för förutsägelse" i varje kolumn?
Varje analys är lika bra som kvaliteten på den data du samlar in. Även den mest avancerade modellen i världen kommer att ge otillförlitliga resultat om den fungerar med data som samlas in felaktigt, provas partiskt eller innehåller information om framtiden. Inom datavetenskap sammanfattas denna princip som "skräp in, skräp ut" (skräp in, skräp ut). I den här enheten kommer vi att täcka datainsamlingsfasen: förstå källan, provtagning, ställa kvalitetsfrågor och vara uppmärksam på risken för dataläckage från dag ett. Artificiell intelligens är ett kraftfullt hjälpmedel i detta skede; Skriver SQL-fråga, sammanfattar API-dokument, utarbetar datakontrakt. Men det är människan som bestämmer vilken data du samlar in och om den data representerar dig.
Lär känna datakällor
Data kommer från olika platser, och varje källa har sina egna fallgropar. Databas (strukturerad data lagrad i tabeller, vanligtvis efterfrågad med SQL) är den vanligaste källan; Det är pålitligt, men det är nödvändigt att förstå dess schema väl. API (Application Programming Interface) tillhandahåller livedata men medför risk för hastighetsbegränsningar och formatändringar. Filer (CSV, Excel, JSON) är flexibla men benägna att formatera inkonsekvens. Webbskrapning är kraftfullt, men det har juridiska och etiska gränser; Inte varje webbplats kan skrapas.
Observera: För webbskrapning och automatisk datainsamling, följ webbplatsens användarvillkor, robots.txt-fil och KVKK/GDPR. Otillåten datainsamling skapar juridiskt ansvar. I samband med informationssäkerhet, använd datainsamlingsverktyg endast på system som du är auktoriserad för och för försvars-/analysändamål; Obehörig åtkomst eller skrapning är förbjuden.
Förstå schemat: bekanta dig med data
Innan du samlar in en datamängd måste du förstå dess schema (namnen på kolumnerna, deras datatyper, deras betydelser och deras relationer med varandra). AI är mycket användbar här för att skapa en "dataordbok" - en tabell som förklarar vad varje kolumn betyder. Men förklaringarna som AI producerar är förutsägelser; Bekräfta den sanna innebörden av varje kolumn med teamet som producerade data. Till exempel kan en kolumn med namnet "status" innehålla 0/1/2; Endast det ursprungliga teamet vet om dessa är "väntande/godkända/avbrutna" eller något annat.
Följande tabell sammanfattar de grundläggande resurstyperna och varningarna:
Källa
starka sida
fälla
Hur AI hjälper
SQL-databas
Strukturell, pålitlig
Komplexa JOINs
Skriver ett frågeutkast
API
livedata
Hastighetsbegränsning, formförändring
Dokumentsammanfattningar, pull-kod
CSV/Excel
Flexibel, snabb
Formatinkonsekvens
Läs/parsera kod
webbskrapning
Bred räckvidd
Laglig/etisk gräns
Analysera utkast (inom behörighet)
Logg-/händelsedata
detaljerad
enorm volym
Filtreringsfråga
Illustration: representerar delen helheten?
För det mesta arbetar du med ett urval (en delmängd vald från populationen) snarare än hela data. Den kritiska frågan är: representerar detta urval befolkningen? Urvalsbias är den vanligaste fällan. Om du till exempel bara provar användare från mobilappen kommer du inte att se webbanvändare och dina resultat kommer att vara vilseledande. Slumpmässigt urval (varje post har lika stor chans att väljas ut) är säkrast i de flesta fall; men i tidsseriedata sker uppdelningen kronologiskt snarare än slumpmässigt (vi kommer att se detta i enheterna 7 och 10).
Läcka medvetenhet från dag ett
Dataläckage är källan till de flesta katastrofer och uppstår vanligtvis under datainsamlingsfasen. Exempel: när du förutsäger "blev den avbruten", om du lägger till kolumnen "avbokningsdatum" i data, ser modellen in i framtiden. Under insamlingsfasen, ställ en fråga för varje kolumn: "Kommer jag verkligen att ha den här informationen när jag gör förutsägelsen?" Om svaret är nej, läcker den kolumnen. Vi kommer att täcka detta ämne på djupet i enhet 10; Men medvetenheten bör börja från dag ett.
tre minifodral
Fall 1 — Problemet med representation. En bank samlade endast in data om godkända lån för sin kreditriskmodell (18 500 poster). Avslag fanns inte i uppgifterna. Modellen hade fel i den verkliga världen eftersom den aldrig såg hur avvisade skulle bete sig. Lärdom: urvalet bör vara representativt för hela populationen från vilken du fattar ditt beslut.
Fall 2 — Tyst formändring. Ett team hämtade prisdata från ett API varje dag. En dag ändrade API-leverantören valuta från USD till EUR, men domännamnet förblev detsamma. Data samlades in i fel enhet under 12 dagar; 3 200 linjer skadades. Lektion: Kontrollera regelbundet volym och formatkonsistens i API-data.
Fall 3 — Tidigt läckage. En analytiker inkluderade kolumnen "orsak till kontostängning" när han samlade in data för en "churn"-uppskattning. Denna kolumn fylldes i först efter att kunden lämnat. Modellen gav 97 % noggrannhet på testsetet; Det fungerade inte i produktionen eftersom den kolumnen var tom vid prediktionstiden. Lektion: ställ varje kolumn frågan "har jag den vid tidpunkten för förutsägelsen?"
Fyra kopierbara mallar
1) Dataordboksextraktion:
Din roll: assistent för datavetare. Nedan finns kolumnnamn och exempel (anonyma) värden för en tabell. För varje kolumn, lista dess uppskattade betydelse, datatyp och potentiella kvalitetsrisker i en tabell. Markera de kolumner du inte är säker på som "bekräftelse krävs"; vilket betyder att göra. Kolumner: [klistra in här]
2) Samplingskod (slumpmässig, repeterbar):
Jag har pandor df. Skriv kod som extraherar ett representativt slumpmässigt urval på 5 % från 200 000 rader. Använd random_state=42 (för reproducerbarhet). Lägg till kod för att kontrollera att urvalets klassfördelning liknar populationen.
3) Fråga om läckageskanning:
Jag ska ge dig den här listan med kolumner. Mitt mål är att förutsäga "är det inställt" (0/1). För varje kolumn, utvärdera om jag faktiskt kommer att ha den vid tidpunkten för förutsägelsen och markera den som "säker / misstänkt / läcka". Skriv din motivering i en mening. Kolumner: [lista]
4) SQL pull-fråga utkast:
Jag har "order" och "kunder" tabeller i PostgreSQL. Skriv en JOIN-förfrågan som kombinerar de senaste 90 dagarnas beställningar med kundens stad och returnerar det totala beloppet och antalet beställningar per stad. Förklara datumfiltret och hur NULL-städer hanteras. Jag kör frågan och verifierar den.
Svag prompt / Stark prompt
Svag uppmaning:
Ta fram ett bra exempeldata från denna databas.
"Bra" är tvetydigt; Vilken målning, vilken period, vilken storlek, vilket syfte är inte klart. AI kommer bara att producera en generisk, möjligen felaktig fråga.
Kraftfull uppmaning:
Din roll: SQL-assistent. Jag har en "transaktionstabell": kolumner id, kund_id, datum (tidsstämpel), belopp (numeriskt), kanal (text: 'webb'/'mobil'). Uppgift: Skriv en repeterbar (deterministisk med ORDER BY) fråga som returnerar 10 000 representativa rader från varje kanal för år 2024. Syfte: kanaljämförande analys. Lista antagandena i din fråga.
Här är tabell, syfte, storlek och repeterbarhet tydliga.
Vanliga misstag
- Ifrågasätter inte provets representativitet. Lätttillgänglig data är inte korrekt data; urvalsbias förvränger resultatet.
- Anpassa kolumns betydelser till AI. Källteamet vet innebörden; Använd inte AI-förutsägelsen utan att bekräfta den.
- Spårar inte API-format/enhetsändring. Den tysta förändringen samlar in korrupta data i dagar.
- Att ignorera läckan vid insamlingsstadiet. Om frågan "Har jag det vid tidpunkten för förutsägelse" inte ställs tidigt kommer modellen att ge falsk framgång.
- Samla in obehörig eller olaglig data. Brott mot robots.txt, användarvillkor och KVKK är en allvarlig risk.
Tips: Behåll ett ensidigt "datakort" för varje ny datakälla: källa, dragdatum, antal rader, kända gränser och kolumner med risk för läckage. Detta kort sparar frågan "vad var denna data" och reproducerbarhet månader senare.
Sammanfattningsvis
Kvaliteten på analysen begränsas av kvaliteten på de insamlade uppgifterna. Känn till källan (databas, API, fil, scrape) och schemat väl; se till att urvalet är representativt för populationen; Eliminera läckage från dag ett genom att fråga varje kolumn "har jag det vid tidpunkten för förutsägelse?" AI är en bra accelerator för fråge- och dokumentarbete, men människor bestämmer vilken data som ska samlas in och dess representativitet. Befogenheter, lag och sekretess kommer alltid först.
Applikationsuppgift
Välj en datakälla (från ditt eget företag eller hypotetisk). Skaffa ett utkast till en dataordbok från AI med mallen "dataordboksextraktion" ovan; Utvärdera sedan varje kolumn manuellt för att se om den har läckt. Försök att hitta minst en misstänkt/läckande kolumn och skriv i en mening varför det är riskabelt.
checklista
- [ ] Har jag bekräftat datakällan och schemat med källteamet?
- [ ] Har jag kontrollerat att urvalet är representativt för populationen?
- [ ] Har jag ställt varje kolumn frågan "kommer jag att ha den vid tidpunkten för uppskattningen?"
- [ ] Har jag gjort provtagningen repeterbar (fast utsäde)?
- [ ] Har jag kontrollerat de juridiska/etiska (myndighet, robots.txt, KVKK) gränserna för insamling?