Câștiguri:
- Abilitatea de a recunoaște diferite surse de date (bază de date, API, fișier, web scraping) și capcanele fiecăreia și de a înțelege schema corect
- Capacitatea de a efectua eșantionare repetabilă prin evaluarea dacă eșantionul reprezintă populația și prejudecata de selecție
- Capacitatea de a elimina scurgerile de date în etapa de colectare și de a respecta limitele legale/etice punând întrebarea „Voi avea la momentul predicției” în fiecare coloană?
Fiecare analiză este la fel de bună ca și calitatea datelor pe care le colectați. Chiar și cel mai avansat model din lume va produce rezultate nesigure dacă funcționează cu date care sunt colectate incorect, eșantionate în mod părtinitor sau care conține informații despre viitor. În informatică, acest principiu este rezumat ca „gunoi în, gunoi afară” (gunoi în, gunoi afară). În această unitate, vom acoperi faza de colectare a datelor: înțelegerea sursei, eșantionarea, adresarea întrebărilor de calitate și atenția la riscul scurgerii de date din prima zi. Inteligența artificială este un ajutor puternic în această etapă; Scrie interogarea SQL, rezumă documentul API, redactează contractul de date. Dar ființa umană este cea care decide ce date colectezi și dacă acele date te reprezintă.
Cunoașterea surselor de date
Datele provin din locuri diferite și fiecare sursă are propriile capcane. Baza de date (date structurate stocate în tabele, de obicei interogate cu SQL) este cea mai comună sursă; Este de încredere, dar este necesar să-i înțelegeți bine schema. API (Application Programming Interface) furnizează date live, dar prezintă riscul limitărilor de viteză și modificărilor de format. Fișierele (CSV, Excel, JSON) sunt flexibile, dar predispuse la inconsecvență de format. Web scraping este puternic, dar are limite legale și etice; Nu orice site poate fi răzuit.
Atenție: Pentru web scraping și colectarea automată a datelor, respectați termenii de utilizare ai site-ului, fișierul robots.txt și KVKK/GDPR. Colectarea neautorizată a datelor creează răspundere legală. În contextul securității informațiilor, utilizați instrumente de colectare a datelor numai pe sistemele pentru care sunteți autorizat și în scop de apărare/analiza; Accesul neautorizat sau răzuirea este interzisă.
Înțelegerea schemei: familiarizarea cu datele
Înainte de a colecta un set de date, trebuie să înțelegeți schema acestuia (numele coloanelor, tipurile lor de date, semnificațiile și relațiile dintre ele). AI este foarte utilă aici în crearea unui „dicționar de date” - un tabel care explică ce înseamnă fiecare coloană. Dar explicațiile pe care AI le produce sunt predicții; Confirmați adevărata semnificație a fiecărei coloane cu echipa care a produs datele. De exemplu, o coloană numită „stare” poate conține 0/1/2; Doar echipa de origine știe dacă acestea sunt „în așteptare/aprobate/anulate” sau altceva.
Următorul tabel rezumă tipurile de resurse de bază și precauțiile:
Sursa
punct forte
capcană
Cum ajută AI
baza de date SQL
Structural, de încredere
JOIN-uri complexe
Scrie o schiță de interogare
API
date live
Limită de viteză, schimbare de formă
Rezumatele documentelor, codul de extragere
CSV/Excel
Flexibil, rapid
Incoerență de format
Citiți/analizați codul
răzuire web
Aria largă
Limită legală/etică
Analiză schiță (în limita autorității)
Date de jurnal/eveniment
detaliat
volum mare
Interogare de filtrare
Ilustrație: partea reprezintă întregul?
De cele mai multe ori, lucrați cu un eșantion (un subset selectat din populație) și nu cu datele întregi. Întrebarea critică este: acest eșantion reprezintă populația? Prejudecățile de selecție este cea mai comună capcană. De exemplu, dacă eșantionați numai utilizatori din aplicația mobilă, nu veți vedea utilizatori de web, iar rezultatele dvs. vor fi înșelătoare. Eșantionarea aleatorie (fiecare înregistrare are șanse egale de a fi selectată) este cea mai sigură în majoritatea cazurilor; dar în datele din seria temporală, împărțirea se face mai degrabă cronologic decât aleatoriu (vom vedea acest lucru în Unitățile 7 și 10).
Scurgeri de conștientizare din prima zi
Scurgerea datelor este sursa majorității dezastrelor și apare de obicei în timpul fazei de colectare a datelor. Exemplu: atunci când preziceți „a fost anulat”, dacă adăugați coloana „data anulării” la date, modelul privește în viitor. În timpul fazei de colectare, puneți o întrebare pentru fiecare coloană: „Voi avea efectiv aceste informații în momentul în care fac predicția?” Dacă răspunsul este nu, coloana respectivă curge. Vom acoperi acest subiect în profunzime în Unitatea 10; Dar conștientizarea ar trebui să înceapă din prima zi.
trei mini cutii
Cazul 1 — Problema reprezentării. O bancă a colectat date doar despre împrumuturile aprobate pentru modelul său de risc de credit (18.500 de înregistrări). Respingeri nu erau în date. Modelul a greșit în lumea reală, deoarece nu a văzut niciodată cum se vor comporta respingerii. Lecție: eșantionul ar trebui să fie reprezentativ pentru întreaga populație din care iei decizia.
Cazul 2 — Schimbare silențioasă a formei. O echipă extragea date despre preț dintr-un API în fiecare zi. Într-o zi, furnizorul API a schimbat moneda din USD în EUR, dar numele domeniului a rămas același. Datele au fost colectate într-o unitate greșită timp de 12 zile; 3.200 de linii au fost corupte. Lecție: verificați în mod regulat volumul și consistența formatului în datele API.
Cazul 3 – Scurgere timpurie. Un analist a inclus coloana „motivul închiderii contului” atunci când a colectat date pentru o estimare de „renunțare”. Această coloană a fost completată numai după ce clientul a plecat. Modelul a oferit o precizie de 97% pe setul de testare; Nu a funcționat în producție, deoarece acea coloană era goală la momentul predicției. Lecție: puneți fiecărei coloane întrebarea „o am în momentul predicției?”
Patru șabloane copiabile
1) Extragerea dicționarului de date:
Rolul dvs.: asistent de date. Mai jos sunt numele coloanelor și valorile eșantionului (anonim) ale unui tabel. Pentru fiecare coloană, enumerați semnificația estimată, tipul de date și riscurile potențiale de calitate într-un tabel. Marcați coloanele de care nu sunteți sigur drept „confirmare necesară”; însemnând a face.Coloane: [lipește aici]
2) Cod de eșantionare (aleatoriu, repetabil):
Am panda df. Scrieți cod care extrage un eșantion aleatoriu reprezentativ de 5% din 200.000 de rânduri. Folosiți random_state=42 (pentru reproductibilitate). Adăugați cod pentru a verifica dacă distribuția de clasă a eșantionului este similară cu populația.
3) Întrebare de scanare a scurgerilor:
Vă voi da această listă de coloane. Scopul meu este să prezic „este anulat” (0/1). Pentru fiecare coloană, evaluați dacă o voi avea de fapt la momentul predicției și marcați-o ca „sigur/suspect/scurgere”. Scrieți rațiunea dvs. într-o singură propoziție. Coloane: [listă]
4) Schiță de interogare de extragere SQL:
Am tabele „comenzi” și „clienți” în PostgreSQL. Scrieți o interogare JOIN care combină comenzile din ultimele 90 de zile cu orașul clientului și returnează suma totală și numărul de comenzi per oraș. Explicați filtrul de dată și cum sunt gestionate orașele NULL. Voi rula interogarea și o voi verifica.
Prompt slab / Prompt puternic
Prompt slab:
Aduceți-mi o mostră bună de date din această bază de date.
„Bine” este ambiguu; Ce pictură, ce perioadă, ce dimensiune, ce scop nu este clar. AI va produce doar o interogare generică, posibil greșită.
Solicitare puternică:
Rolul dvs.: asistent SQL. Am un tabel cu „tranzacții”: id-ul coloanelor, id-ul clientului, data (marca temporală), cantitatea (numeric), canalul (text: „web”/„mobil”). Sarcină: Scrieți o interogare repetabilă (deterministă cu ORDER BY) care returnează 10.000 de rânduri reprezentative din fiecare canal pentru anul 2024. Scop: analiză comparativă a canalului. Enumerați ipotezele interogării dvs.
Aici tabelul, scopul, dimensiunea și repetabilitatea sunt clare.
Greșeli comune
- Nu pune sub semnul întrebării reprezentativitatea eșantionului. Datele ușor accesibile nu sunt date exacte; prejudecata de selecție denaturează rezultatul.
- Adaptarea semnificațiilor coloanei la AI. Echipa sursă cunoaște semnificația; Nu utilizați predicția AI fără a o confirma.
- Nu urmărește modificarea formatului/unității API. Schimbarea silențioasă colectează date corupte zile întregi.
- Ignorarea scurgerii în etapa de colectare. Dacă întrebarea „O am la momentul predicției” nu este pusă devreme, modelul va da un succes fals.
- Colectarea datelor neautorizate sau ilegale. Încălcarea robots.txt, a condițiilor de utilizare și a KVKK reprezintă un risc serios.
Sfat: păstrați un „card de date” de o pagină pentru fiecare nouă sursă de date: sursă, data extragerii, număr de rânduri, limite cunoscute și coloane cu risc de scurgere. Acest card salvează întrebarea „ce au fost aceste date” și reproductibilitatea luni mai târziu.
Pe scurt
Calitatea analizei este limitată de calitatea datelor colectate. Cunoașteți bine sursa (bază de date, API, fișier, scrape) și schema; asigurați-vă că eșantionul este reprezentativ pentru populație; Eliminați scurgerea din prima zi, întrebând fiecare coloană „o am în momentul predicției?” AI este un accelerator excelent pentru interogări și documente, dar oamenii decid ce date să colecteze și reprezentativitatea acestora. Limitele de autoritate, de lege și de confidențialitate sunt întotdeauna pe primul loc.
Sarcina de aplicare
Alegeți o sursă de date (de la propria afacere sau ipotetică). Obțineți o schiță a unui dicționar de date de la AI cu șablonul „extracție dicționar de date” de mai sus; Apoi evaluați manual fiecare coloană pentru a vedea dacă a fost scursă. Încercați să găsiți cel puțin o coloană suspectă/scurgere și scrieți într-o singură propoziție de ce este riscant.
lista de verificare
- [ ] Am confirmat sursa de date și schema cu echipa sursă?
- [ ] Am verificat dacă eșantionul este reprezentativ pentru populație?
- [ ] Am pus fiecare coloană întrebarea „o voi avea la momentul devizării?”
- [ ] Am făcut ca eșantionarea să fie repetabilă (sămânță fixă)?
- [ ] Am verificat limitele legale/etice (autoritate, robots.txt, KVKK) de colectare?