Fra problem til trenbart datasett

Start med beslutningen, ikke algoritmen

Tenk at et studenthus vil anslå neste døgns strømforbruk. Det er fristende å åpne et modellbibliotek med én gang, men først må vi formulere hva en prediksjon skal brukes til. Skal vi anslå et kontinuerlig antall kilowattimer, varsle om forbruket overstiger en grense, eller gruppere døgn med lignende mønster? Disse målene krever ulike labels, metrikker og evalueringsoppsett.

I veiledet læring har hvert treningseksempel et kjent mål. Historiske døgn kan ha temperatur, ukedag og antall beboere som input og målt energiforbruk som mål. I uveiledet læring mangler fasiten; da kan vi lete etter grupper av lignende forbruksmønstre eller uvanlige døgn. De to læringsformene svarer på forskjellige spørsmål. En klynge er ikke automatisk en «ekte» kundetype, og en label er ikke automatisk riktig bare fordi den finnes i en database.

En feature er en inputvariabel modellen får ved prediksjonstidspunktet. En label er verdien eller klassen en veiledet modell lærer å predikere. Tidspunktet er avgjørende. «Målt strømforbruk klokken 23» kan være en gyldig feature for å forutsi neste dag, men er lekkasje hvis oppgaven er å varsle samme dags topp klokken 08.

Før du samler data, skriv én presis setning: Gitt informasjon som er tilgjengelig ved tidspunkt T, prediker Y for enhet E og tidshorisont H. Den setningen avslører ofte uklare labels, ulovlige fremtidsfeatures og feil analyseenhet før de blir dyre.

Tre datasett, tre oppgaver

treningssettet brukes til å tilpasse modellparametere og alle preprocessing-transformasjoner. valideringssettet brukes til å sammenligne modeller, terskler og hyperparametere. testsettet skal ligge urørt til arbeidsflyten er låst. Med $n$ observasjoner og treningsandel $r$ gir ƒandel i treningssettet omtrent $\lfloor rn\rfloor$ treningseksempler.

En tilfeldig splitt passer når observasjonene kan behandles som uavhengige og likefordelte. Tidsserier krever vanligvis en tidsordnet splitt: tren på fortiden og evaluer på framtiden. Har samme pasient, maskin eller kunde flere rader, bør alle radene fra samme enhet havne på samme side av splitten. Ellers kan modellen kjenne igjen enheten i stedet for å lære et mønster som generaliserer.

1import numpy as np2 3rng = np.random.default_rng(4172)4X = rng.normal(size=(1_000, 3))5y = 2 * X[:, 0] - X[:, 1] + rng.normal(scale=0.4, size=1_000)6 7indeks = rng.permutation(len(X))8train, valid, test = np.split(indeks, [600, 800])9 10print(X[train].shape, X[valid].shape, X[test].shape)11print("Ingen overlapp:", len(set(train) & set(test)) == 0)

En fast seed gjør forsøket reproduserbart, men gjør ikke splitten faglig riktig. Seed bestemmer bare hvilket tilfeldig utfall vi kan gjenta. Vi må fortsatt begrunne om tilfeldig splitting samsvarer med situasjonen modellen skal brukes i.

Datalekkasje gir penere tall og dårligere kunnskap

datalekkasje betyr at informasjon som ikke ville vært tilgjengelig i ekte bruk, påvirker trening eller modellvalg. Den tydeligste varianten er en fremtidsfeature, som sluttstatus brukt til å predikere om en sak blir avsluttet. En mer subtil variant oppstår når vi beregner middelverdi, kategorier eller featureutvalg fra hele datasettet før splitten.

Figuren viser skillet mellom fit og transform. En transformasjon lærer parametere fra treningsdata i fit-steget. Deretter bruker den de låste parameterne på validering og test. Ved kryssvalidering gjentas dette i hver fold: middelverdi, imputering og featureutvalg tilpasses bare på treningsdelen av folden.

Testlekkasje kan også skje uten at en eneste testlabel går inn i treningen. Hvis vi prøver tjue modeller og velger den med best testscore, har testsettet påvirket modellvalget. Det er nå et valideringssett. Den rapporterte scoren er optimistisk fordi vi valgte blant tilfeldige variasjoner. Løsningen er å bruke validering under utvikling og test én gang til slutt.

Skalering er en lært transformasjon

To features kan beskrive samme observasjon med svært ulike tallområder: årlig inntekt i hundretusener og en andel mellom 0 og 1. For avstandsbaserte og gradientbaserte metoder kan den numerisk største skalaen dominere. ƒstandardisering trekker fra treningsmiddelet $\mu$ og deler på treningsstandardavviket $\sigma$. Resultatet uttrykker hvor mange standardavvik verdien ligger fra sentrum.

ƒmin–maks-skalering flytter treningssettets minste verdi til 0 og største til 1. Testverdier kan godt bli mindre enn 0 eller større enn 1. Det er ikke en feil; det forteller at de ligger utenfor treningsområdet. Å klippe dem automatisk kan skjule distribusjonsskift.

1import numpy as np2 3X_train = np.array([[40., 2.], [55., 3.], [70., 4.], [85., 5.]])4X_test = np.array([[100., 6.], [115., 7.]])5 6middel = X_train.mean(axis=0)7std = X_train.std(axis=0)8 9Z_train = (X_train - middel) / std10Z_test = (X_test - middel) / std11 12print("Treningsmiddel etter skalering:", Z_train.mean(axis=0))13print("Test transformert med treningsstatistikk:", Z_test)

Skalering er ikke nødvendig for alle modeller. Beslutningstrær sammenligner terskler innen én feature og er derfor lite følsomme for lineær reskalering. k-means, logistisk regresjon med gradienttrening og nevrale nettverk påvirkes langt mer. Preprocessing skal velges ut fra modellens geometri, ikke brukes som et ritual.

Kategorier og manglende verdier

En nominell kategori som postområde har ingen naturlig tallrekkefølge. Koder vi områdene som 1, 2 og 3, kan en lineær modell tolke avstanden mellom 1 og 3 som dobbelt av avstanden mellom 1 og 2. ƒone-hot-koding erstatter derfor kategori $k$ med en indikatorvektor som har én ener på posisjonen til kategorien.

Kategorier som bare finnes i validering eller produksjon må håndteres eksplisitt. En trygg encoder kan ignorere ukjente kategorier eller mappe dem til «annet». Hvis hele datasettet brukes til å oppdage alle kategorier på forhånd, får treningsflyten informasjon om framtidige data.

Manglende verdier krever også et lært valg. Medianimputering er robust mot ekstreme verdier, men medianen skal beregnes fra trening. En egen indikator for «manglet» kan være nyttig når fraværet i seg selv bærer informasjon. Samtidig må vi spørre hvorfor verdien mangler: tilfeldig sensorstøy er noe annet enn at en undersøkelse hoppes over for en bestemt gruppe.

Feature engineering uten framtidskunnskap

Feature engineering gjør rådata mer relevante for oppgaven. Et tidsstempel kan bli time på døgnet, ukedag og helg. Et forbrukstall kan deles på areal for å sammenligne byggstørrelser. Slike transformasjoner kan hjelpe en enkel modell, men må være tilgjengelige og stabile ved prediksjonstidspunktet.

Aggregeringer er en vanlig felle. «Gjennomsnittlig framtidig forbruk for kunden» er åpenbar lekkasje. «Gjennomsnitt siste sju fullførte døgn før prediksjonen» kan være gyldig hvis tidsvinduet beregnes separat for hver rad. I tidsdata bør hvert featureuttrykk kunne leses med ordene fram til, men ikke inkludert, prediksjonstidspunktet.

Mer er heller ikke alltid bedre. En unik rad-ID kan la en fleksibel modell memorere treningseksempler uten å hjelpe på nye data. En postkode kan være en nyttig geografisk feature, men også fungere som proxy for sensitive forhold. Datasettbygging er dermed både et statistisk og et ansvarlighetsmessig valg.

Pipeline som kontrakt

En pipeline binder preprocessing og modell sammen i riktig rekkefølge. Når pipeline-objektet tilpasses på trening, lærer hvert trinn bare fra samme treningsdata. Ved prediksjon brukes transformasjonene uendret. Det reduserer risikoen for at en notebook utfører litt andre steg i trening og produksjon.

Pipeline-kontrakten bør også bevare kolonnerekkefølge, datatyper og enheter. Hvis treningen mottok temperatur i grader Celsius og produksjon sender Fahrenheit, er formatet teknisk gyldig, men semantikken feil. Det samme gjelder kategorier med endret skrivemåte og heltall som plutselig inneholder desimaler. En enkel skjemakontroll før transformasjon kan stoppe slike feil tidlig.

Labels trenger en egen kvalitetskontroll. Et registrert utfall kan komme for sent, mangle for bestemte grupper eller være en proxy for det vi egentlig vil måle. To saksbehandlere kan også merke samme tilfelle forskjellig. Undersøk derfor labelandel, tidsforsinkelse og uenighet før du tolker modellfeil som bare et algoritmeproblem. Modellen kan ikke lære en mer presis definisjon enn dataarbeidet gir den.

Reproduserbarhet krever mer enn en tilfeldig seed. Versjoner rådatauttaket, splitteindeksene, transformasjonene og modellinnstillingene. Da kan en senere kjøring rekonstruere hva modellen faktisk så. Det gjør avvik mellom eksperiment og produksjon mulig å feilsøke og hindrer at «samme datasett» i praksis betyr et nytt uttrekk med andre rader.

Undersøk splittene med små tabeller før trening: antall rader, labelandel, tidsområde og mangler per kolonne. Store forskjeller kan være tilsiktet, særlig i en tidsordnet test, men de må være synlige. Da vet du om en svak score skyldes et realistisk vanskelig skift eller en tilfeldig feil i datakoden.

Den endelige evalueringen skal beskrive mer enn én score. Dokumenter analyseenhet, tidsperiode, splitstrategi, klasseandel, manglende verdier og hvilke transformasjoner som ble tilpasset. Hvis testdata skiller seg markant fra trening, er det viktig kunnskap om bruksområdet, ikke bare et tall modellen «fikk feil».

En trenbar datamatrise er derfor slutten på en argumentrekke: problemet bestemmer labelen, brukstidspunktet begrenser features, datagenereringen bestemmer splitten, og modellen bestemmer nødvendig preprocessing. Når denne kjeden er tydelig, blir algoritmevalget både enklere og mer ærlig.