Gevinster:
- Evne til å ta robust SQL og pandas kode og lese og verifisere den linje for linje ved å gi klart skjema og formål til kunstig intelligens
- Evne til å fange opp stille feil som radantall, tilpasningsfunksjon og gjennomstrømning etter sammenslåing/JOIN
- Evne til å løse problemet i feilsøking uten å dempe det og unngå å kjøre koden uten å teste den i produksjonsmiljøet
Datavitenskap har to primære språk: SQL (Structured Query Language - språket for å søke etter data fra databaser) og Python (spesifikt pandas-biblioteket - standardverktøyet for å manipulere tabeller programmatisk). I denne enheten vil vi lære å bruke AI som en kodepartner: få solid SQL- og pandaskode fra den med de riktige spørsmålene, lese og validere den koden, feilsøke den og aldri kjøre den blindt. AI skriver repeterende kode på sekunder i stedet for minutter; Men det er din jobb å sørge for at koden den produserer behandler riktig kolonne med riktig logikk. Arbeidskode betyr ikke riktig kode.
Hvorfor det er kraftig, men risikabelt å produsere kode med AI
AI gir tre store fordeler i kodegenerering: hastighet (skriver en 30-linjers gruppe-for-pivot-operasjon på sekunder), påminnelse (minner deg om en panda-funksjon du har glemt), og undervisning (forklarer koden linje for linje). Men det har tre risikoer: stille logikkfeil (kode som summerer feil kolonne kjører uten feil), tilpasset funksjon (antyder en metode som ikke eksisterer) og avkastningsfelle (kode som fungerer på små data, men krasjer ved 10 millioner rader). Så den gylne regelen: Les AI-koden som om du skrev den selv. Ikke kjør linjen du ikke forstår.
SQL: behandle data ved kilden
SQL lar deg hente data fra databasen og behandle dem der; Du kan oppsummere millioner av linjer uten å trekke dem inn i Python. Grunnleggende byggeklosser: SELECT (hvilke kolonner), HVOR (hvilke rader), GROUP BY (grupper og oppsummer), JOIN (sammenføye tabeller), HAVING (post-group filter). AI er veldig nyttig for å skrive komplekse JOINs og vindusfunksjoner, men sørg for å sjekke to ting: er JOIN via riktig nøkkel (feil nøkkel dupliserer rader) og er filterlogikken riktig (spesielt NULL-atferd og datoperioder).
Forsiktig: Ikke kjør en AI-generert SQL-spørring direkte mot produksjonsdatabasen. Test med en liten kopi eller LIMIT først. Kjør aldri en UPDATE/DELETE-spørring uten å validere WHERE-betingelsen; En feil WHERE kan slette hele tabellen.
Python/pandaer: fleksibel analyse
pandas er standardmåten for å manipulere tabeller (DataFrame) i Python. Den mest effektive bruken av AI er å gi den et klart opplegg og formål. Mest brukte operasjoner: filter, groupby, merge, pivot_table, bruk. AI skriver disse raskt; Det du vil sjekke er logikken: er grupperingen i riktig kolonne, har sammenslåingen endret antall rader uventet (sjekk alltid antall rader etter sammenslåingen), endrer kjedeoperasjonene originalen.
transaksjon
SQL
pandaer
sjekkpunkt
Filtrering
HVOR
df[df.x > 5]
NULL/NaN-adferd
gruppering
GRUPPE ETTER
df.groupby()
Er det høyre kolonne?
slå sammen
BLI MED
df.merge()
Endring av radantall
Sammendrag
AVG(), SUM()
.mean(), .sum()
Hvilken kolonne ble samlet inn
Sorter etter
BESTILL PÅ
.sort_values()
Retning (stigende/synkende)
deduplisering
DISTINKT
.drop_duplicates()
I hvilke kolonner?
Feilsøking: med AI
Når koden feiler, er AI en utmerket feilsøkingspartner. Gi den hele feilmeldingen og den relevante kodebiten. Men pass deg for to feller. For det første kan AI foreslå en løsning som "demper" feilen (f.eks. skjuler varsler) - dette fikser ikke feilen, det skjuler den. For det andre endrer AI noen ganger stille en annen atferd mens den "løser" et problem. Regel: forstå reparasjonen, løsne ikke demping, og kontroller at utdata fortsatt er riktig etter reparasjonen.
Ønsker tolkbar og vedlikeholdbar kode
Når du kjøper kode fra AI, be om kode som er lesbar og vedlikeholdbar, ikke bare kode som "fungerer". Når du eller en kollega åpner den koden måneder senere, bør den kunne forstå hva den gjør. For å gjøre dette, gjør det til en vane å la AI-en inkludere tre ting: meningsfulle variabelnavn (orders_temiz, ikke df2), korte kommentarlinjer ved kritiske trinn (forklarer hvorfor, ikke hva som blir gjort), og en navngitt konstant i stedet for et magisk tall (ACCEPT_ESIGI = 0,85 i stedet for 0,85 begravet i koden). Unngå også lange enkeltlinjekjeder (forbinder fem handlinger på en linje); disse gjør feilsøking vanskelig. Som standard produserer AI ofte kortfattet og "smart" kode; Hvis du tydelig sier "skriv lesbar, tolkbar, vedlikeholdbar", vil du få en mye mer vedlikeholdbar utgang. Dette er også grunnlaget for reproduserbarhet (enhet 10): kode som ikke blir forstått er kode som ikke kan kjøres på nytt trygt.
tre minisaker
Tilfelle 1 – JOIN-replikering. En analytiker kombinerte bestillingene med produkttabellen og fant at den totale omsetningen var 3 ganger høyere. Årsak: hvert produkt hadde flere rader (ulike farger) i produkttabellen; JOIN dupliserte hver bestilling. AI-koden "fungerte", men antall linjer hadde hoppet fra 240 tusen til 690 tusen. Leksjon: sjekk alltid antall linjer etter sammenslåing/JOIN.
Tilfelle 2 — Tilpasningsfunksjon. Han foreslo AI df.groupby('x').summarize() til en praktikant; Det er ingen slik metode i pandaer (det er .agg()). Koden fungerte ikke, praktikanten var tapt i 20 minutter. Leksjon: verifiser en funksjon du ikke kjenner igjen fra dokumentet; AI kan lage metoder.
Case 3 - Yield kollaps. En kode spurte databasen i applikasjon for hver rad; Den kjørte på 5000 linjer, tok 9 timer på 4 millioner linjer og stoppet. Da AI foreslo en vektorisert (batch) løsning, ble tiden redusert til 40 sekunder. Leksjon: kode som fungerer på små data kan krasje på store data; Vurder effektivitet.
Fire kopierbare maler
1) Be om SQL med skjema:
Din rolle: SQL-assistent (PostgreSQL). Tabeller:- orders(id, customer_id, date timestamp, number numeric)- customers(id, city text)Oppgave: Få total omsetning og antall ordre per by i 2024, sortert etter omsetning i synkende rekkefølge. Forklar hvordan du håndterer NULL-byer. Jeg vil teste spørringen med LIMIT først; OPPDATERING/SLETT generasjon.
2) pandaprosess med sjekkpunkt:
Jeg har DataFrames df (ordrer) og df_customers (kunder). Beregn gjennomsnittlig beløp per by. VIKTIG: skriv ut antall rader før og etter sammenslåing slik at jeg kan se om det er duplisering. Forklar i hvilken kolonne du slo sammen og hvorfor du valgte indre/venstre.
3) Kodeforklaring og verifisering:
Forklar følgende pandaer kode linje for linje: hva gjør hver linje, hvilke antakelser gjør den, i hvilke tilfeller kan den gi feil resultater? Gi meg beskjed hvis jeg brukte en fudge-funksjon. Kode: [lim inn]
4) Feilsøking:
Denne koden gir denne feilen. Full feilmelding: [lim inn]. Kode: [lim inn]. Forklar ROT-årsaken til feilen og fiks den. Løs det ved å faktisk løse problemet, ikke ved å dempe varselet. Angi også om rettelsen endret utgangen.
Svak forespørsel / Sterk forespørsel
Svak melding:
Skriv en forespørsel som gir meg salg per by.
Tabellnavn, kolonner, databasetype, NULL-atferd er uklare. AI er vanlig, det vil sannsynligvis produsere et søk som ikke passer bordet ditt.
Kraftig ledetekst:
Din rolle: SQL-assistent (MySQL 8). Tabell: salg(id, by varchar, beløp desimal, dato dato). Oppgave: Få det totale og gjennomsnittlige beløpet, antall bestillinger per by for året 2024; Sorter avtagende etter totalbeløp; Vis bare byer med mer enn 100 bestillinger (HAVING). NULL ekskluder by. Forklar spørringen; Jeg skal teste med LIMIT.
Her er database, skjema, filter, sortering og NULL-regel åpenbare.
Vanlige feil
- Kjøre koden uten å lese den. Arbeidskode er ikke riktig kode; Koden som manipulerer feil kolonne kjører også uten feil.
- Kontrollerer ikke antall rader etter sammenslåing/JOIN. Feil tast dupliserer rader stille og blåser opp totaler.
- Kontrollerer ikke tilpasningsfunksjonen. AI kan foreslå metoder som ikke eksisterer; Bekreft fra dokumentet at du ikke gjenkjenner det.
- Tenker ikke på effektivitet. bruk/sløyfe arbeider på små datakrasj på millioner av rader; vektorisere.
- Kjør direkte på produksjonsdatabase. Spesielt å kjøre UPDATE/DELETE uten WHERE eller testing er katastrofalt.
Tips: Ta for vane å legge til en "valideringslinje" til hver kode du mottar fra AI: et antall linjer før og etter behandling, noen få prøvelinjer og en kritisk total for hånd. Disse tre kontrollene fanger opp de fleste stille logiske feil.
Oppsummert
AI er en kraftig partner som raskt produserer SQL og pandas-kode, men den er ikke en blind autoritet. Gi ham ordningen og formålet tydelig; Les koden den produserer som om du skrev den selv; Sjekk antall rader, tilpasningsfunksjoner og gjennomstrømning etter sammenslåing/JOIN; Ikke kjør den uten å teste den i produksjonsdatabasen. Når du feilsøker, sikte på å løse problemet, ikke å stanse det. Koden som fungerer er ikke riktig kode; Bare du kan garantere nøyaktighet.
Søknadsoppgave
Velg et analysespørsmål (f.eks. "månedlig omsetning per kanal") og be om kode fra AI med både SQL og pandaer. Les begge kodene linje for linje, kontroller antall linjer etter sammenslåing/JOIN og kontroller manuelt minst én kritisk sum. Sammenlign om de to kodene gir samme resultat; Hvis annerledes, finn ut hvorfor.
sjekkliste
- [ ] Har jeg gitt tabellen/skjemaet og formålet tydelig til AI?
- [ ] Har jeg lest og forstått koden den produserte linje for linje?
- [ ] Sjekket jeg antall linjer etter sammenslåing/JOIN?
- [ ] Har jeg verifisert funksjonene jeg ikke kjenner igjen fra dokumentasjonen?
- [ ] Har jeg testet koden på sikre/små data først og ikke i produksjonsmiljøet?