Kasu:
- Võimalus ära tunda erinevaid andmeallikaid (andmebaas, API, fail, veebikraapimine) ja nende lõkse ning mõista õigesti skeemi
- Võimalus teostada korduvat valimit, hinnates, kas valim esindab populatsiooni ja valiku kallutatust
- Võimalus kõrvaldada andmete lekkimine kogumisetapis ja järgida õiguslikke/eetilisi piire, esitades igas veerus küsimuse „Kas see on prognoosimise ajal olemas”?
Iga analüüs on sama hea kui teie kogutud andmete kvaliteet. Isegi maailma kõige arenenum mudel annab ebausaldusväärseid tulemusi, kui see töötab andmetega, mis on kogutud valesti, võetud kallutatud või sisaldavad teavet tuleviku kohta. Arvutiteaduses on see põhimõte kokku võetud sõnadega "prügi sisse, prügi välja" (prügi sisse, prügi välja). Selles üksuses käsitleme andmete kogumise etappi: allika mõistmist, proovide võtmist, kvaliteediküsimuste esitamist ja andmete lekke ohu suhtes valvsust alates esimesest päevast. Tehisintellekt on selles etapis võimas abivahend; Kirjutab SQL päringu, teeb API dokumendi kokkuvõtte, koostab andmelepingu projekti. Kuid inimene on see, kes otsustab, milliseid andmeid te kogute ja kas need andmed esindavad teid.
Andmeallikatega tutvumine
Andmed pärinevad erinevatest kohtadest ja igal allikal on oma lõksud. Andmebaas (tabelitesse salvestatud struktureeritud andmed, millele tavaliselt päritakse SQL-iga) on kõige levinum allikas; See on usaldusväärne, kuid selle skeemi on vaja hästi mõista. API (Application Programming Interface) pakub reaalajas andmeid, kuid sellega kaasneb kiiruspiirangute ja vormingu muutmise oht. Failid (CSV, Excel, JSON) on paindlikud, kuid võivad põhjustada vormingu ebaühtlust. Veebi kraapimine on võimas, kuid sellel on juriidilised ja eetilised piirangud; Iga saiti ei saa kraapida.
Tähelepanu: veebi kraapimiseks ja automaatseks andmete kogumiseks järgige saidi kasutustingimusi, faili robots.txt ja KVKK/GDPR. Volitamata andmete kogumine toob kaasa juriidilise vastutuse. Infoturbe kontekstis kasutage andmete kogumise tööriistu ainult süsteemides, mille jaoks olete volitatud, ja kaitse/analüüsi eesmärgil; Volitamata juurdepääs või kraapimine on keelatud.
Skeemi mõistmine: andmetega tutvumine
Enne andmekogumi kogumist peate mõistma selle skeemi (veergude nimed, andmetüübid, tähendused ja seosed üksteisega). AI on siin väga kasulik "andmesõnastiku" loomisel - tabel, mis selgitab iga veeru tähendust. Kuid AI selgitused on ennustused; Kinnitage iga veeru tegelik tähendus andmed koostanud meeskonnaga. Näiteks veerg nimega "status" võib sisaldada 0/1/2; Ainult loov meeskond teab, kas need on "ootel/kinnitatud/tühistatud" või midagi muud.
Järgmine tabel võtab kokku peamised ressursitüübid ja hoiatused.
Allikas
tugev külg
lõks
Kuidas AI aitab
SQL andmebaas
Struktuurne, töökindel
Komplekssed JOIN-id
Kirjutab päringu mustandi
API
reaalajas andmed
Kiirusepiirang, kuju muutmine
Dokumendi kokkuvõtted, tõmba kood
CSV/Excel
Paindlik, kiire
Vormingu ebakõla
Koodi lugemine/parsimine
veebikraapimine
Lai haare
Seaduslik/eetiline piir
Mustandi sõelumine (volituse piires)
Logi/sündmuse andmed
üksikasjalik
tohutu maht
Filtreerimispäring
Illustratsioon: kas osa esindab tervikut?
Enamiku ajast töötate pigem valimiga (populatsioonist valitud alamhulgaga), mitte kogu andmetega. Kriitiline küsimus on: kas see valim esindab populatsiooni? Valiku kallutatus on kõige levinum lõks. Näiteks kui kasutate mobiilirakenduses ainult näidiskasutajaid, ei näe te veebikasutajaid ja teie tulemused on eksitavad. Juhuslik valim (igal kirjel on võrdne võimalus valituks osutuda) on enamikul juhtudel kõige turvalisem; kuid aegridade andmetes toimub poolitamine pigem kronoloogiliselt kui juhuslikult (seda näeme 7. ja 10. ühikutes).
Lekketeadlikkus alates esimesest päevast
Andmete lekkimine on enamiku katastroofide allikas ja tekib tavaliselt andmete kogumise etapis. Näide: "kas see tühistati" ennustamisel, kui lisate andmetele veeru "tühistamiskuupäev", vaatab mudel tulevikku. Küsige kogumisfaasis iga veeru kohta üks küsimus: "Kas mul on see teave ennustuse tegemise ajal?" Kui vastus on eitav, lekib see veerg. Seda teemat käsitleme põhjalikult 10. peatükis; Kuid teadlikkus peaks algama esimesest päevast.
kolm minikarpi
1. juhtum – esindatuse probleem. Üks pank kogus oma krediidiriski mudeli jaoks andmeid ainult heakskiidetud laenude kohta (18 500 kirjet). Tagasilükkamisi andmetes ei olnud. Mudel oli reaalses maailmas vale, sest ta ei näinud kunagi, kuidas tõrjutud käituvad. Õppetund: valim peaks esindama kogu populatsiooni, mille põhjal oma otsuse teete.
Juhtum 2 – vaikse vormi muutmine. Meeskond tõmbas iga päev API-st hinnaandmeid. Ühel päeval muutis API pakkuja valuuta USD-lt EUR-ks, kuid domeeninimi jäi samaks. Andmeid koguti vales ühikus 12 päeva; 3200 rida oli rikutud. Õppetund: Kontrollige regulaarselt API andmete mahu ja vormingu järjepidevust.
Juhtum 3 – varajane leke. Analüütik lisas veergu "Konto sulgemise põhjus", kui kogus "Curn" hinnangu jaoks andmeid. See veerg täideti alles pärast kliendi lahkumist. Mudel andis katsekomplektis 97% täpsuse; Tootmises see ei töötanud, kuna see veerg oli ennustusajal tühi. Õppetund: esitage igale veerule küsimus "kas mul on see ennustuse ajal?"
Neli kopeeritavat malli
1) Andmesõnastiku väljavõte:
Teie roll: andmeteadlase assistent. Allpool on tabeli veergude nimed ja näidisväärtused (anonüümsed). Loetlege iga veeru hinnanguline tähendus, andmetüüp ja võimalikud kvaliteediriskid tabelis. Märkige veerud, milles te pole kindel, kui "vajalik kinnitus"; tähendab tegemine.Veerud: [kleebi siia]
2) Valimikood (juhuslik, korratav):
Mul on pandad df. Kirjutage kood, mis eraldab 200 000 reast tüüpilise 5% juhusliku valimi. Kasutage random_state=42 (reprodutseeritavuse huvides). Lisage kood, et kontrollida, kas valimi klassijaotus on üldkogumiga sarnane.
3) Lekke skaneerimise küsimus:
Ma annan teile selle veergude loendi. Minu eesmärk on ennustada "kas see on tühistatud" (0/1). Hinnake iga veeru puhul, kas see on mul ennustuse ajal ka tegelikult olemas, ja märkige see kui "ohutu / kahtlane / lekib". Kirjutage oma põhjendus ühe lausega. Veerud: [loend]
4) SQL-i tõmbepäringu mustand:
Mul on PostgreSQL-is "tellimuste" ja "klientide" tabelid. Kirjutage JOIN päring, mis ühendab viimase 90 päeva tellimused kliendi linnaga ja tagastab tellimuste kogusumma ja arvu linna kohta. Selgitage kuupäevafiltrit ja seda, kuidas NULL-linnu käsitletakse. Käivitan päringu ja kontrollin seda.
Nõrk viip / Tugev viip
Nõrk viip:
Tooge mulle sellest andmebaasist hea näidisandmed.
"Hea" on mitmetähenduslik; Milline maal, mis ajastu, mis suurus, mis eesmärk pole selge. AI loob ainult üldise, võib-olla vale päringu.
Võimas viip:
Teie roll: SQL-i assistent. Mul on "tehingute" tabel: veergude id, kliendi_id, kuupäev (ajatempel), summa (numbriline), kanal (tekst: 'veeb'/'mobiil'). Ülesanne: Kirjutage korratav (deterministlik koos ORDER BY-ga) päring, mis tagastab 2024. aasta kohta igast kanalist 10 000 tüüpilist rida. Eesmärk: kanalite võrdlev analüüs. Loetlege oma päringu eeldused.
Siin on selged tabel, eesmärk, suurus ja korratavus.
Levinud vead
- Ei sea kahtluse alla valimi esinduslikkust. Kergesti juurdepääsetavad andmed ei ole täpsed andmed; valiku kallutatus moonutab tulemust.
- Veergude tähenduste kohandamine AI-ga. Allikameeskond teab tähendust; Ärge kasutage AI ennustust ilma seda kinnitamata.
- Ei jälgi API vormingu/ühiku muutust. Vaikne muutus kogub rikutud andmeid päevade kaupa.
- Lekke ignoreerimine kogumisetapis. Kui küsimust "Kas mul on see ennustamise ajal" varakult ei esitata, annab mudel vale edu.
- Volitamata või ebaseaduslike andmete kogumine. Robots.txt, kasutustingimuste ja KVKK rikkumine on tõsine oht.
Näpunäide. Hoidke iga uue andmeallika jaoks alles üheleheküljeline andmekaart: allikas, tõmbamiskuupäev, ridade arv, teadaolevad piirid ja lekkeohuga veerud. See kaart salvestab mitu kuud hiljem küsimuse "mis need andmed olid" ja reprodutseeritavuse.
Kokkuvõttes
Analüüsi kvaliteeti piirab kogutud andmete kvaliteet. Tunne hästi allikat (andmebaas, API, fail, scrape) ja skeemi; veenduge, et valim esindab üldkogumit; Likvideerige leke alates esimesest päevast, küsides iga veeru kohta "kas mul on see ennustuse ajal?" AI on suurepärane kiirendi päringu- ja dokumenteerimistööks, kuid inimesed otsustavad, milliseid andmeid koguda ja nende esinduslikkust. Volituste piirid, seadus ja konfidentsiaalsus on alati esikohal.
Rakenduse ülesanne
Valige andmeallikas (oma ettevõttest või hüpoteetiline). Hankige tehisintellektilt andmesõnastiku mustand ülaltoodud malliga „Andmesõnastiku väljavõte”; Seejärel hinnake käsitsi iga veergu, et näha, kas see on lekkinud. Proovi leida vähemalt üks kahtlane/lekkiv veerg ja kirjuta ühe lausega, miks see on riskantne.
kontrollnimekiri
- [ ] Kas olen andmeallika ja skeemi allikameeskonnaga kinnitanud?
- [ ] Kas ma olen kontrollinud, et valim esindaks üldkogumit?
- [ ] Kas olen esitanud igale veerule küsimuse "kas mul on see hinnangu tegemise ajal?"
- [ ] Kas olen muutnud proovivõtu korratavaks (fikseeritud seeme)?
- [ ] Kas olen kontrollinud kogumise seaduslikke/eetilisi (volitus, robots.txt, KVKK) piire?