Winst:
- Vermogen om verschillende gegevensbronnen (database, API, bestand, webscraping) en de valkuilen van elke gegevensbron te herkennen en het schema correct te begrijpen
- Mogelijkheid om herhaalbare steekproeven uit te voeren door te evalueren of de steekproef de populatie en selectiebias vertegenwoordigt
- Mogelijkheid om datalekken in de verzamelfase te elimineren en juridische/ethische grenzen te observeren door in elke kolom de vraag te stellen: 'Zal ik het hebben op het moment van de voorspelling'?
Elke analyse is zo goed als de kwaliteit van de gegevens die u verzamelt. Zelfs het meest geavanceerde model ter wereld zal onbetrouwbare resultaten opleveren als het werkt met gegevens die onjuist zijn verzameld, op een vertekende manier zijn bemonsterd of informatie over de toekomst bevatten. In de computerwetenschappen wordt dit principe samengevat als "garbage in, garbage out" (garbage in, garbage out). In dit onderdeel behandelen we de fase van het verzamelen van gegevens: het begrijpen van de bron, het nemen van steekproeven, het stellen van kwaliteitsvragen en het vanaf dag één alert zijn op het risico op gegevenslekken. Kunstmatige intelligentie is in dit stadium een krachtig hulpmiddel; Schrijft SQL-query, vat het API-document samen, stelt een datacontract op. Maar het is de mens die bepaalt welke gegevens je verzamelt en of die gegevens jou vertegenwoordigen.
Gegevensbronnen leren kennen
Gegevens komen van verschillende plaatsen en elke bron heeft zijn eigen valkuilen. Database (gestructureerde gegevens opgeslagen in tabellen, meestal opgevraagd met SQL) is de meest voorkomende bron; Het is betrouwbaar, maar het is noodzakelijk om het schema goed te begrijpen. API (Application Programming Interface) biedt live gegevens, maar brengt het risico met zich mee van snelheidslimieten en formaatwijzigingen. Bestanden (CSV, Excel, JSON) zijn flexibel, maar gevoelig voor inconsistentie in de indeling. Webscrapen is krachtig, maar kent juridische en ethische grenzen; Niet elke site kan worden geschraapt.
Let op: voor webscraping en automatische gegevensverzameling dient u zich te houden aan de gebruiksvoorwaarden van de site, het robots.txt-bestand en de KVKK/GDPR. Ongeautoriseerde gegevensverzameling creëert wettelijke aansprakelijkheid. Gebruik in het kader van informatiebeveiliging de tools voor gegevensverzameling alleen op systemen waarvoor u geautoriseerd bent en voor verdedigings-/analysedoeleinden; Ongeoorloofde toegang of schrapen is verboden.
Het schema begrijpen: kennis maken met de gegevens
Voordat u een dataset verzamelt, moet u het schema ervan begrijpen (de namen van de kolommen, hun gegevenstypen, hun betekenis en hun relaties met elkaar). AI is hier erg handig bij het maken van een ‘data dictionary’: een tabel waarin wordt uitgelegd wat elke kolom betekent. Maar de verklaringen die AI produceert zijn voorspellingen; Bevestig de ware betekenis van elke kolom met het team dat de gegevens heeft geproduceerd. Een kolom met de naam 'status' kan bijvoorbeeld 0/1/2 bevatten; Alleen het oorspronkelijke team weet of deze 'in behandeling/goedgekeurd/geannuleerd' zijn of iets anders.
De volgende tabel geeft een overzicht van de basisresourcetypen en waarschuwingen:
Bron
sterk punt
val
Hoe AI helpt
SQL-database
Structureel, betrouwbaar
Complexe JOIN's
Schrijft een queryconcept
API
live gegevens
Snelheidslimiet, vormverandering
Documentsamenvattingen, pull-code
CSV/Excel
Flexibel, snel
Inconsistentie van het formaat
Code lezen/parseren
webschrapen
Groot bereik
Juridische/ethische limiet
Concept ontleden (binnen autoriteit)
Log-/gebeurtenisgegevens
gedetailleerd
enorm volume
Zoekopdracht filteren
Illustratie: vertegenwoordigt het deel het geheel?
Meestal werk je met een steekproef (een subset geselecteerd uit de populatie) in plaats van met de hele gegevens. De kritische vraag is: representeert deze steekproef de populatie? Selectiebias is de meest voorkomende valkuil. Als u bijvoorbeeld alleen gebruikers uit de mobiele app test, ziet u geen webgebruikers en zijn uw resultaten misleidend. Willekeurige steekproeven (elke record heeft een gelijke kans om geselecteerd te worden) is in de meeste gevallen het veiligst; maar bij tijdreeksgegevens gebeurt het splitsen chronologisch in plaats van willekeurig (we zullen dit zien in de eenheden 7 en 10).
Lekbewustzijn vanaf dag één
Gegevenslekken zijn de bron van de meeste rampen en ontstaan meestal tijdens de fase van gegevensverzameling. Voorbeeld: als u bij het voorspellen van "was het geannuleerd" de kolom "annuleringsdatum" aan de gegevens toevoegt, kijkt het model naar de toekomst. Stel tijdens de verzamelfase één vraag voor elke kolom: “Zal ik daadwerkelijk over deze informatie beschikken op het moment dat ik de voorspelling doe?” Als het antwoord nee is, lekt die kolom. We zullen dit onderwerp diepgaand behandelen in Unit 10; Maar bewustwording moet vanaf dag één beginnen.
drie minikoffers
Geval 1 — Het probleem van vertegenwoordiging. Eén bank verzamelde alleen gegevens over goedgekeurde leningen voor haar kredietrisicomodel (18.500 records). Afwijzingen stonden niet in de data. Het model klopte niet in de echte wereld, omdat het nooit zag hoe afwijzingen zich zouden gedragen. Les: de steekproef moet representatief zijn voor de gehele populatie waaruit u uw beslissing neemt.
Geval 2 — Stille vormverandering. Een team haalde elke dag prijsgegevens uit een API. Op een dag veranderde de API-provider de valuta van USD naar EUR, maar de domeinnaam bleef hetzelfde. Gedurende 12 dagen zijn gegevens in de verkeerde eenheid verzameld; 3.200 lijnen waren beschadigd. Les: Controleer regelmatig de volume- en formaatconsistentie in API-gegevens.
Geval 3 — Vroege lekkage. Een analist heeft de kolom 'Reden voor sluiting van account' opgenomen bij het verzamelen van gegevens voor een schatting van 'churn'. Deze kolom werd pas gevuld nadat de klant was vertrokken. Het model leverde een nauwkeurigheid van 97% op op de testset; Het werkte niet in de productie omdat die kolom leeg was op het moment van de voorspelling. Les: stel elke kolom de vraag "heb ik deze op het moment van de voorspelling?"
Vier kopieerbare sjablonen
1) Extractie van gegevenswoordenboek:
Jouw rol: datawetenschapper-assistent. Hieronder staan de kolomnamen en voorbeeld (anonieme) waarden van een tabel. Vermeld voor elke kolom de geschatte betekenis, het gegevenstype en de potentiële kwaliteitsrisico's in een tabel. Markeer de kolommen waarvan u niet zeker bent als "bevestiging vereist"; betekenis maken.Kolommen: [plak hier]
2) Bemonsteringscode (willekeurig, herhaalbaar):
Ik heb panda's df. Schrijf code die een representatieve willekeurige steekproef van 5% uit 200.000 rijen haalt. Gebruik random_state=42 (voor reproduceerbaarheid). Voeg code toe om te controleren of de klassenverdeling van de steekproef vergelijkbaar is met de populatie.
3) Vraag over het scannen van lekken:
Ik geef je deze lijst met kolommen. Mijn doel is om te voorspellen "is het geannuleerd" (0/1). Evalueer voor elke kolom of ik deze daadwerkelijk zal hebben op het moment van de voorspelling en markeer deze als "veilig / verdacht / lek". Schrijf je motivatie in één zin. Kolommen: [lijst]
4) SQL-pullqueryconcept:
Ik heb tabellen "bestellingen" en "klanten" in PostgreSQL. Schrijf een JOIN-query die de bestellingen van de afgelopen 90 dagen combineert met de stad van de klant en het totale bedrag en aantal bestellingen per stad retourneert. Leg het datumfilter uit en hoe met NULL-steden wordt omgegaan. Ik zal de query uitvoeren en verifiëren.
Zwakke prompt/sterke prompt
Zwakke prompt:
Haal mij een goed voorbeeld van gegevens uit deze database.
"Goed" is dubbelzinnig; Welk schilderij, welke periode, welk formaat, welk doel is niet duidelijk. AI zal alleen een generieke, mogelijk verkeerde vraag produceren.
Krachtige prompt:
Jouw rol: SQL-assistent. Ik heb een tabel "transacties": kolommen id, klant_id, datum (tijdstempel), bedrag (numeriek), kanaal (tekst: 'web'/'mobiel'). Taak: Schrijf een herhaalbare (deterministische met ORDER BY) query die 10.000 representatieve rijen van elk kanaal retourneert voor het jaar 2024. Doel: vergelijkende analyse van kanalen. Maak een lijst van de aannames van uw vraag.
Hier zijn de tabel, het doel, de omvang en de herhaalbaarheid duidelijk.
Veel voorkomende fouten
- De representativiteit van de steekproef wordt niet in twijfel getrokken. Gemakkelijk toegankelijke gegevens zijn geen nauwkeurige gegevens; selectiebias vertekent het resultaat.
- Kolombetekenissen aanpassen aan AI. Het bronteam kent de betekenis; Gebruik de AI-voorspelling niet zonder deze te bevestigen.
- Wijziging van API-formaat/eenheid wordt niet bijgehouden. De stille verandering verzamelt dagenlang corrupte gegevens.
- Het lek negeren tijdens de verzamelfase. Als de vraag "Heb ik het op het moment van de voorspelling" niet vroeg wordt gesteld, zal het model vals succes opleveren.
- Het verzamelen van ongeautoriseerde of illegale gegevens. Schending van robots.txt, gebruiksvoorwaarden en KVKK vormt een ernstig risico.
Tip: Bewaar een ‘gegevenskaart’ van één pagina voor elke nieuwe gegevensbron: bron, ophaaldatum, aantal rijen, bekende grenzen en kolommen die het risico lopen te lekken. Deze kaart bewaart de vraag "wat waren deze gegevens" en de reproduceerbaarheid maanden later.
Samengevat
De kwaliteit van de analyse wordt beperkt door de kwaliteit van de verzamelde gegevens. Ken de bron (database, API, bestand, scrape) en schema goed; zorg ervoor dat de steekproef representatief is voor de populatie; Elimineer lekkage vanaf de eerste dag door elke kolom te vragen: 'Heb ik deze op het moment van de voorspelling?' AI is een geweldige versneller voor query- en documentwerk, maar mensen beslissen welke gegevens ze verzamelen en de representativiteit ervan. Grenzen van autoriteit, recht en vertrouwelijkheid komen altijd op de eerste plaats.
Applicatie taak
Kies een gegevensbron (van uw eigen bedrijf of hypothetisch). Ontvang een concept van een datadictionary van AI met de bovenstaande sjabloon voor ‘data dictionary-extractie’; Evalueer vervolgens elke kolom handmatig om te zien of deze is gelekt. Probeer minimaal één verdachte/lekkolom te vinden en schrijf in één zin op waarom dit riskant is.
controlelijst
- [ ] Heb ik de gegevensbron en het schema bevestigd bij het bronteam?
- [ ] Heb ik gecontroleerd of de steekproef representatief is voor de populatie?
- [ ] Heb ik aan elke kolom de vraag gesteld: "Zal ik deze hebben op het moment van de schatting?"
- [ ] Heb ik de bemonstering herhaalbaar gemaakt (vast zaad)?
- [ ] Heb ik de wettelijke/ethische (autoriteit, robots.txt, KVKK) limieten voor het verzamelen gecontroleerd?