Yunit 2 / 11

Pangongolekta ng Data at Pag-unawa sa Pinagmulan: Schema, Sampling, Quality at Leak Awareness

Mga nadagdag:

  • Kakayahang makilala ang iba't ibang mga mapagkukunan ng data (database, API, file, web scraping) at ang mga pitfalls ng bawat isa at maunawaan nang tama ang schema
  • Kakayahang magsagawa ng repeatable sampling sa pamamagitan ng pagsusuri kung ang sample ay kumakatawan sa populasyon at pagpili ng bias
  • Kakayahang alisin ang pagtagas ng data sa yugto ng pagkolekta at obserbahan ang mga legal/etikal na hangganan sa pamamagitan ng pagtatanong ng 'Makukuha ko ba ito sa oras ng hula' sa bawat column?

Ang bawat pagsusuri ay kasing ganda ng kalidad ng data na iyong kinokolekta. Maging ang pinaka-advanced na modelo sa mundo ay magbubunga ng hindi mapagkakatiwalaang mga resulta kung gumagana ito sa data na nakolekta nang hindi tama, naka-sample nang may bias, o naglalaman ng impormasyon tungkol sa hinaharap. Sa computer science, ang prinsipyong ito ay ibinubuod bilang "garbage in, garbage out" (garbage in, garbage out). Sa unit na ito, sasakupin namin ang yugto ng pangongolekta ng data: pag-unawa sa pinagmulan, pagsa-sample, pagtatanong ng mga tanong na may kalidad, at pagiging alerto sa panganib ng pagtagas ng data mula sa unang araw. Ang artificial intelligence ay isang malakas na tulong sa yugtong ito; Sumulat ng SQL query, nagbubuod ng dokumento ng API, nag-draft ng kontrata ng data. Ngunit ang tao ang magpapasya kung anong data ang iyong kinokolekta at kung ang data na iyon ay kumakatawan sa iyo.

Pagkilala sa mga pinagmumulan ng data

Ang data ay nagmula sa iba't ibang lugar, at ang bawat pinagmulan ay may sariling mga pitfalls. Ang database (nakabalangkas na data na nakaimbak sa mga talahanayan, kadalasang tinatanong gamit ang SQL) ay ang pinakakaraniwang mapagkukunan; Ito ay maaasahan, ngunit ito ay kinakailangan upang maunawaan nang mabuti ang pamamaraan nito. Ang API (Application Programming Interface) ay nagbibigay ng live na data ngunit nagdadala ng panganib ng mga limitasyon sa bilis at mga pagbabago sa format. Ang mga file (CSV, Excel, JSON) ay flexible ngunit madaling kapitan ng hindi pagkakapare-pareho ng format. Ang pag-scrape sa web ay makapangyarihan, ngunit mayroon itong mga legal at etikal na limitasyon; Hindi lahat ng site ay maaaring ma-scrap.

Pansin: Para sa web scraping at awtomatikong pangongolekta ng data, sumunod sa mga tuntunin ng paggamit ng site, robots.txt file at KVKK/GDPR. Ang hindi awtorisadong pangongolekta ng data ay lumilikha ng legal na pananagutan. Sa konteksto ng seguridad ng impormasyon, gumamit lamang ng mga tool sa pagkolekta ng data sa mga system kung saan ka awtorisado at para sa mga layunin ng pagtatanggol/pagsusuri; Ang hindi awtorisadong pag-access o pag-scrape ay ipinagbabawal.

Pag-unawa sa schema: pagiging pamilyar sa data

Bago mangolekta ng set ng data, dapat mong maunawaan ang schema nito (ang mga pangalan ng mga column, ang mga uri ng data nito, ang mga kahulugan nito, at ang mga ugnayan ng mga ito sa isa't isa). Ang AI ay lubhang kapaki-pakinabang dito sa paggawa ng "data dictionary" — isang talahanayan na nagpapaliwanag kung ano ang ibig sabihin ng bawat column. Ngunit ang mga paliwanag na ginawa ng AI ay mga hula; Kumpirmahin ang tunay na kahulugan ng bawat column sa pangkat na gumawa ng data. Halimbawa, ang isang column na pinangalanang "status" ay maaaring maglaman ng 0/1/2; Tanging ang pinagmulang team lang ang nakakaalam kung ang mga ito ay "nakabinbin/naaprubahan/nakansela" o iba pa.

Ang sumusunod na talahanayan ay nagbubuod sa mga pangunahing uri ng mapagkukunan at mga pag-iingat:

Pinagmulan

malakas na punto

bitag

Paano nakakatulong ang AI

SQL database

Structural, maaasahan

Mga kumplikadong JOIN

Sumulat ng draft ng query

API

live na data

Limitasyon ng bilis, pagbabago ng hugis

Mga buod ng dokumento, pull code

CSV/Excel

Flexible, mabilis

Hindi pagkakapare-pareho ng format

Basahin/i-parse ang code

web scraping

Malawak na abot

Legal/etikal na limitasyon

Pag-parse ng draft (sa loob ng awtoridad)

Data ng log/kaganapan

detalyado

malaking volume

Pag-filter ng query

Paglalarawan: ang bahagi ba ay kumakatawan sa kabuuan?

Kadalasan, nagtatrabaho ka gamit ang isang sample (isang subset na pinili mula sa populasyon) sa halip na ang buong data. Ang kritikal na tanong ay: kinakatawan ba ng sample na ito ang populasyon? Ang bias sa pagpili ay ang pinakakaraniwang bitag. Halimbawa, kung nagsa-sample ka lang ng mga user mula sa mobile app, hindi mo makikita ang mga web user at ang iyong mga resulta ay mapanlinlang. Ang random sampling (bawat record ay may pantay na pagkakataong mapili) ay pinakaligtas sa karamihan ng mga kaso; ngunit sa data ng time series, ang paghahati ay ginagawa ayon sa pagkakasunod-sunod sa halip na random (makikita natin ito sa Units 7 at 10).

Leak awareness mula sa unang araw

Ang pagtagas ng data ay ang pinagmumulan ng karamihan sa mga sakuna at kadalasang nangyayari sa yugto ng pagkolekta ng data. Halimbawa: kapag hinuhulaan ang "nakansela ba ito", kung idaragdag mo ang column na "petsa ng pagkansela" sa data, titingnan ng modelo ang hinaharap. Sa yugto ng pagtitipon, magtanong ng isang tanong para sa bawat column: "Makukuha ko ba talaga ang impormasyong ito sa oras na gumawa ako ng hula?" Kung hindi ang sagot, tumutulo ang column na iyon. Tatalakayin namin ang paksang ito nang malalim sa Yunit 10; Ngunit ang kamalayan ay dapat magsimula sa unang araw.

tatlong mini case

Kaso 1 — Ang problema ng representasyon. Isang bangko ang nangongolekta ng data lamang sa mga naaprubahang pautang para sa modelo ng panganib sa kredito nito (18,500 na tala). Ang mga pagtanggi ay wala sa data. Ang modelo ay mali sa totoong mundo dahil hindi nito nakita kung paano kumilos ang mga pagtanggi. Aralin: ang sample ay dapat na kinatawan ng buong populasyon kung saan ka nagdedesisyon.

Kaso 2 — Pagbabago ng tahimik na anyo. Isang team ang kumukuha ng data ng presyo mula sa isang API araw-araw. Isang araw, binago ng API provider ang currency mula USD patungong EUR, ngunit nanatiling pareho ang domain name. Nakolekta ang data sa maling unit sa loob ng 12 araw; 3,200 linya ang nasira. Aralin: Regular na suriin ang volume at pagkakapare-pareho ng format sa data ng API.

Kaso 3 — Maagang pagtagas. Isinama ng isang analyst ang column na "dahilan para sa pagsasara ng account" kapag nangongolekta ng data para sa pagtatantya ng "churn." Ang column na ito ay napunan lamang pagkatapos umalis ang customer. Ang modelo ay nagbunga ng 97% na katumpakan sa set ng pagsubok; Hindi ito gumana sa produksyon dahil walang laman ang column na iyon sa oras ng hula. Aralin: tanungin ang bawat hanay ng tanong na "mayroon ba ako nito sa oras ng hula?"

Apat na maaaring kopyahin na mga template

1) Pagkuha ng diksyunaryo ng data:

Ang iyong tungkulin: data scientist assistant. Nasa ibaba ang mga pangalan ng column at sample (anonymous) na mga value ng isang table. Para sa bawat column, ilista ang tinantyang kahulugan nito, uri ng data, at potensyal na panganib sa kalidad sa isang talahanayan. Markahan ang mga column na hindi ka sigurado bilang "kinakailangan ng kumpirmasyon"; paggawa ng kahulugan.Mga Hanay: [idikit dito]

2) Sampling code (random, repeatable):

Mayroon akong panda df. Sumulat ng code na kumukuha ng kinatawan ng 5% random na sample mula sa 200,000 row. Gumamit ng random_state=42 (para sa muling paggawa). Magdagdag ng code upang matiyak na ang pamamahagi ng klase ng sample ay katulad ng populasyon.

3) Tanong sa pag-scan ng leak:

Ibibigay ko sa iyo ang listahan ng mga column na ito. Ang layunin ko ay hulaan ang "kinansela ba ito" (0/1). Para sa bawat column, suriin kung talagang magkakaroon ako nito sa oras ng hula at markahan ito bilang "ligtas / kahina-hinala / tumagas". Isulat ang iyong katwiran sa isang pangungusap. Mga Hanay: [listahan]

4) SQL pull query draft:

Mayroon akong mga talahanayan ng "mga order" at "mga customer" sa PostgreSQL. Sumulat ng isang JOIN query na pinagsasama ang mga order ng huling 90 araw sa lungsod ng customer at ibinabalik ang kabuuang halaga at bilang ng mga order sa bawat lungsod. Ipaliwanag ang filter ng petsa at kung paano pinangangasiwaan ang NULL na mga lungsod. Tatakbuhin ko ang query at i-verify ito.

Mahinang prompt / Malakas na prompt

Mahinang prompt:

Hilahin ako ng magandang sample na data mula sa database na ito.

"Mabuti" ay hindi maliwanag; Aling pagpipinta, aling panahon, anong sukat, aling layunin ang hindi malinaw. Ang AI ay gagawa lamang ng generic, posibleng maling query.

Napakahusay na prompt:

Ang iyong tungkulin: SQL assistant. Mayroon akong talahanayan ng "mga transaksyon": columns id, customer_id, petsa (timestamp), halaga (numeric), channel (text: 'web'/'mobile'). Gawain: Sumulat ng paulit-ulit na (deterministic na may ORDER BY) na query na nagbabalik ng 10,000 representative row mula sa bawat channel para sa taong 2024. Layunin: channel comparative analysis. Ilista ang mga pagpapalagay ng iyong query.

Dito malinaw ang talahanayan, layunin, sukat at pag-uulit.

Mga karaniwang pagkakamali

  • Hindi kinukuwestiyon ang pagiging kinatawan ng sample. Ang madaling ma-access na data ay hindi tumpak na data; pinipiling ng bias ang resulta.
  • Pag-aangkop ng mga kahulugan ng column sa AI. Alam ng source team ang kahulugan; Huwag gamitin ang hula ng AI nang hindi kinukumpirma ito.
  • Hindi sinusubaybayan ang format ng API/pagbabago ng unit. Ang tahimik na pagbabago ay nangongolekta ng sirang data sa loob ng ilang araw.
  • Hindi pinapansin ang pagtagas sa yugto ng koleksyon. Kung ang tanong na "Mayroon ba ako nito sa oras ng hula" ay hindi tatanungin nang maaga, ang modelo ay magbibigay ng maling tagumpay.
  • Pagkolekta ng hindi awtorisado o ilegal na data. Ang paglabag sa robots.txt, mga tuntunin ng paggamit at KVKK ay isang malubhang panganib.
Tip: Panatilihin ang isang pahinang “data card” para sa bawat bagong data source: source, pull date, bilang ng mga row, alam na mga hangganan, at column na nasa panganib ng pagtagas. Ang card na ito ay nagse-save ng "ano ang data na ito" na tanong at reproducibility buwan mamaya.

Sa buod

Ang kalidad ng pagsusuri ay nalilimitahan ng kalidad ng data na nakolekta. Alamin nang mabuti ang pinagmulan (database, API, file, scrape) at schema; siguraduhin na ang sample ay kinatawan ng populasyon; Tanggalin ang pagtagas mula sa unang araw sa pamamagitan ng pagtatanong sa bawat column na "mayroon ba ako nito sa oras ng hula?" Ang AI ay isang mahusay na accelerator para sa query at paggawa ng dokumento, ngunit ang mga tao ang nagpapasya kung anong data ang kolektahin at ang pagiging kinatawan nito. Ang mga limitasyon ng awtoridad, batas at pagiging kumpidensyal ay palaging nauuna.

Gawain ng aplikasyon

Pumili ng data source (mula sa sarili mong negosyo o hypothetical). Kumuha ng draft ng diksyunaryo ng data mula sa AI gamit ang template na "pagkuha ng diksyunaryo ng data" sa itaas; Pagkatapos ay manu-manong suriin ang bawat column upang makita kung ito ay na-leak. Subukang maghanap ng kahit isang kahina-hinalang/leak na column at isulat sa isang pangungusap kung bakit ito mapanganib.

checklist

  • [ ] Nakumpirma ko ba ang data source at schema sa source team?
  • [ ] Nasuri ko ba na ang sample ay kinatawan ng populasyon?
  • [ ] Tinanong ko ba ang bawat column ng tanong na "makukuha ko ba ito sa oras ng pagtatantya?"
  • [ ] Ginawa ko bang paulit-ulit ang sampling (fixed seed)?
  • [ ] Nasuri ko na ba ang legal/etikal (awtoridad, robots.txt, KVKK) na mga limitasyon ng koleksyon?