Hva er AI-forbehandling? [Video og quiz]

Kort svar: AI-forbehandling er et sett med repeterbare trinn som omdanner rå data med høy varians til konsistente modellinndata, inkludert rensing, koding, skalering, tokenisering og bildetransformasjoner. Dette er viktig fordi modeller kan feile stille hvis treningsinndata og produksjonsinndata er forskjellige. Hvis et trinn «lærer» parametere, må det bare tilpasses treningsdata for å unngå lekkasje.

AI-forbehandling er alt du gjør med rådata før (og noen ganger under) trening eller inferens, slik at en modell faktisk kan lære av dem. Ikke bare «rensing». Det handler om å rense, forme, skalere, kode, utvide og pakke data til en konsistent representasjon som ikke stille og rolig vil sette modellen i gang senere. [1]

Viktige konklusjoner:

Definisjon: Forbehandling konverterer råtabeller, tekst, bilder og logger til modellklare funksjoner.

Konsistens: Bruk de samme transformasjonene under trening og inferens for å forhindre feil på grunn av avvik.

Lekkasje: Tilpass skalerere, kodere og tokeniserere kun på treningsdata.

Reproduserbarhet: Bygg pipelines med inspiserbar statistikk, ikke ad hoc-cellesekvenser i notatboken.

Produksjonsovervåking: Spor skjevhet og avvik slik at inndataene ikke gradvis forringer ytelsen.

Artikler du kanskje vil lese etter denne:

🔗 Slik tester du AI-modeller for ytelse i den virkelige verden
Praktiske metoder for raskt å evaluere nøyaktighet, robusthet og skjevhet.

🔗 Er tekst-til-tale kunstig intelligens, og hvordan fungerer det?
Forklarer det grunnleggende om TTS, viktige bruksområder og vanlige begrensninger i dag.

🔗 Kan AI lese kursiv håndskrift nøyaktig i dag
Dekker gjenkjenningsutfordringer, beste verktøy og tips for nøyaktighet.

🔗 Hvor nøyaktig er AI på tvers av vanlige oppgaver
Bryter ned nøyaktighetsfaktorer, referansepunkter og pålitelighet i den virkelige verden.

AI-forbehandling i enkelt språk (og hva det ikke er) 🤝

AI-forbehandling er transformasjonen av rå input (tabeller, tekst, bilder, logger) til modellklare funksjoner. Hvis rådata er et rotete verksted, er forbehandling at du merker esker, kaster ødelagt skrot og stabler ting slik at du faktisk kan gå gjennom uten å bli skadet.

Det er ikke selve modellen. Det er tingene som gjør modellen mulig:

• å gjøre kategorier om til tall (enkelttall, ordinaltall osv.) [1]

• skalering av store numeriske områder til fornuftige områder (standardisering, min-maks, osv.) [1]

• tokenisering av tekst til input-ID-er (og vanligvis en oppmerksomhetsmaske) [3]

• endring av størrelse/beskjæring av bilder og bruk av deterministiske kontra tilfeldige transformasjoner på riktig måte [4]

• bygge repeterbare pipelines slik at opplæring og «virkelige» input ikke avviker på subtile måter [2]

En liten praktisk merknad: «forbehandling» inkluderer alt som skjer konsekvent før modellen ser inputen. Noen team deler dette inn i «funksjonsteknikk» kontra «datarensing», men i virkeligheten blir disse linjene uklare. 

Hvorfor AI-forbehandling er viktigere enn folk innrømmer 😬

En modell er en mønstermatcher, ikke en tankeleser. Hvis innspillene dine er inkonsekvente, lærer modellen inkonsekvente regler. Det er ikke filosofisk, det er smertelig bokstavelig.

Forbehandling hjelper deg med å:

• Forbedre læringsstabiliteten ved å legge inn funksjoner i representasjoner som estimatorer kan bruke pålitelig (spesielt når skalering/koding er involvert). [1]

• Reduser støy ved å få rotete virkelighet til å se ut som noe en modell kan generalisere fra (i stedet for å memorere rare artefakter).

• Forhindre stille feilmoduser som lekkasje og tog/serve-avvik (den typen som ser «fantastisk» ut i validering og deretter faceplantes i produksjon). [2]

• Få fart på iterasjonen fordi repeterbare transformasjoner slår spaghetti i en bærbar PC hver dag i uken.

Det er også der mye av «modellprestasjonen» faktisk kommer fra. Som ... overraskende mye. Noen ganger føles det urettferdig, men det er virkeligheten 🙃

Hva kjennetegner en god AI-forbehandlingspipeline ✅

En «god versjon» av forbehandling har vanligvis disse egenskapene:

• Reproduserbar: samme input → samme output (ingen mystisk tilfeldighet med mindre det er forsettlig forstørrelse).

• Konsistens i togservering: alt du gjør under trening, brukes på samme måte under inferens (samme tilpassede parametere, samme kategorikart, samme tokenizer-konfigurasjon osv.). [2]

• Lekkasjesikker: ingenting i evalueringen/testen påvirker noen tilpasningstrinn . (Mer om denne fellen senere.) [2]

• Observerbar: du kan inspisere hva som har endret seg (funksjonsstatistikk, manglende funksjoner, antall kategorier), slik at feilsøking ikke er vibrasjonsbasert ingeniørarbeid.

Hvis forbehandlingen din er en haug med notatblokkceller kalt final_v7_really_final_ok… vet du hvordan det er. Det fungerer helt til det ikke lenger gjør det 😬

Kjernebyggesteiner i AI-forbehandling 🧱

Tenk på forprosessering som et sett med byggeklosser du kombinerer til en pipeline.

1) Rengjøring og validering 🧼

Typiske oppgaver:

• fjern duplikater

• håndtere manglende verdier (fjerne, imputere eller representere manglende verdier eksplisitt)

• håndheve typer, enheter og områder

• oppdage feilformede innganger

• standardisere tekstformater (mellomrom, store og små bokstaver, Unicode-eiendommer)

Denne delen er ikke glamorøs, men den forhindrer ekstremt dumme feil. Jeg sier det med kjærlighet.

2) Koding av kategoriske data 🔤

De fleste modeller kan ikke bruke rå strenger som «red» eller «premium_user».

Vanlige tilnærminger:

• En-hot-koding (kategori → binære kolonner) [1]

• Ordinal koding (kategori → heltalls-ID) [1]

Det viktigste er ikke hvilken koder du velger – det er at kartleggingen forblir konsistent og ikke «endrer form» mellom trening og inferens. Det er slik du ender opp med en modell som ser fin ut offline og oppfører seg hjemsøkt online. [2]

3) Funksjonsskalering og normalisering 📏

Skalering er viktig når funksjoner befinner seg på vidt forskjellige områder.

To klassikere:

• Standardisering: fjern gjennomsnitt og skaler til enhetsvarians [1]

• Min-maks skalering: skaler hver funksjon til et spesifisert område [1]

Selv når du bruker modeller som «for det meste klarer seg», gjør skalering ofte rørledninger enklere å resonnere rundt – og vanskeligere å ødelegge ved et uhell.

4) Funksjonsutvikling (også kjent som nyttig juks) 🧪

Det er her du gjør modellens jobb enklere ved å skape bedre signaler:

• forholdstall (klikk / visninger)

• rullevinduer (siste N dager)

• antall (hendelser per bruker)

• logtransformasjoner for tunghalede fordelinger

Det er en kunst her. Noen ganger lager du en reportasje, føler deg stolt ... og den gjør ingenting. Eller enda verre, den gjør vondt. Det er normalt. Ikke bli følelsesmessig knyttet til reportasjer – de elsker deg ikke tilbake 😅

5) Dele data på riktig måte ✂️

Dette høres opplagt ut helt til det ikke er det:

• tilfeldige splittelser for IID-data

• tidsbaserte oppdelinger for tidsserier

• grupperte oppdelinger når enheter gjentar seg (brukere, enheter, pasienter)

Og viktigst av alt: splitt før tilpasning av forbehandling som lærer fra data. Hvis forbehandlingstrinnet ditt «lærer» parametere (som middelverdier, vokabularer, kategorikart), må det bare lære dem gjennom trening. [2]

AI-forbehandling etter datatype: tabell, tekst, bilder 🎛️

Forbehandling endrer form avhengig av hva du mater modellen.

Tabelldata (regneark, logger, databaser) 📊

Vanlige trinn:

• strategi for manglende verdi

• kategorisk koding [1]

• skalering av numeriske kolonner [1]

• håndtering av outliers (domeneregler slår "tilfeldig klipping" mesteparten av tiden)

• avledede funksjoner (aggregeringer, forsinkelser, rullerende statistikk)

Praktiske råd: definer kolonnegrupper eksplisitt (numeriske vs. kategoriske vs. identifikatorer). Ditt fremtidige jeg vil takke deg.

Tekstdata (NLP) 📝

Tekstforbehandling inkluderer ofte:

• tokenisering til tokener/underord

• konvertering til inndata-ID-er

• utfylling/avkorting

• bygge oppmerksomhetsmasker for batching [3]

Liten regel som sparer deg for bryderi: for transformerbaserte oppsett, følg modellens forventede tokenizer-innstillinger og ikke freestyle med mindre du har en grunn. Freestyle er hvordan du ender opp med at «det trener, men det er rart»

Bilder (datamaskinvisjon) 🖼️

Typisk forbehandling:

• endre størrelse/beskjær til konsistente former

• deterministiske transformasjoner for evaluering

• tilfeldige transformasjoner for treningsutvidelse (f.eks. tilfeldig beskjæring) [4]

En detalj folk overser: «tilfeldige transformasjoner» er ikke bare en vibrasjon – de sampler bokstavelig talt parametere hver gang de kalles. Flott for å trene mangfold, forferdelig for evaluering hvis du glemmer å slå av tilfeldigheten. [4]

Fellen alle går i: datalekkasje 🕳️🐍

Lekkasje er når informasjon fra evalueringsdata sniker seg inn i treningen – ofte gjennom forbehandling. Det kan få modellen din til å se magisk ut under validering, og deretter skuffe deg i den virkelige verden.

Vanlige lekkasjemønstre:

• skalering ved bruk av statistikk for hele datasettet (i stedet for kun trening) [2]

• bygge kategorikart ved å bruke tog+test sammen [2]

• ethvert fit()- eller fit_transform()- trinn som «ser» testsettet [2]

Tommelfingerregel (enkel, brutal, effektiv):

• Alt med et fit steg bør kun være fit på trening.

• Så transformerer validering/testing ved å bruke den tilpassede transformatoren. [2]

Og hvis du vil ha en magefølelse på «hvor ille kan det være?»: scikit-learns egne dokumenter viser et eksempel på en lekkasje der en feil forbehandlingsrekkefølge gir en nøyaktighet på rundt 0,76 på tilfeldige mål – og deretter faller tilbake til ~0,5 når lekkasjen er fikset. Det er så overbevisende feil lekkasje kan se ut. [2]

Få forprosessering inn i produksjon uten kaos 🏗️

Mange modeller mislykkes i produksjon, ikke fordi modellen er «dårlig», men fordi input-virkeligheten endres – eller fordi pipelinen din gjør det.

Produksjonsrettet forbehandling inkluderer vanligvis:

• Lagrede artefakter (kodertilordninger, skaleringsparametere, tokenizer-konfigurasjon) slik at inferensen bruker nøyaktig de samme lærte transformasjonene [2]

• Strenge inputkontrakter (forventede kolonner/typer/områder)

• Overvåking av skjevhet og avdrift, fordi produksjonsdata vil avvike [5]

Hvis du ønsker konkrete definisjoner: Googles Vertex AI Model Monitoring skiller mellom trenings- og serveringsfordeling (produksjonsfordeling avviker fra trening) og inferensdrift (produksjonsfordeling endres over tid), og støtter overvåking av både kategoriske og numeriske funksjoner. [5]

Fordi overraskelser er dyre. Og ikke av den morsomme typen.

Sammenligningstabell: vanlige verktøy for forbehandling + overvåking (og hvem de er for) 🧰

(Ja, tabellen har fortsatt meninger. Men i det minste er det ærlige meninger 😅)

En praktisk sjekkliste for forbehandling du faktisk kan bruke 📌

Før trening

• Definer et inputskjema (typer, enheter, tillatte områder)

• Revider manglende verdier og duplikater

• Del data på riktig måte (tilfeldig / tidsbasert / gruppert)

• Forbehandling av tilpasning kun under trening (fit / fit_transform forblir på toget) [2]

• Lagre forbehandlingsartefakter slik at inferensen kan gjenbruke dem [2]

Under trening

• Bruk kun tilfeldig augmentasjon der det er passende (vanligvis kun treningssplitt) [4]

• Hold evalueringsforbehandlingen deterministisk [4]

• Spor endringer i forbehandling som modellendringer (fordi de er det)

Før utplassering

• Sørg for at inferensen bruker identisk forbehandlingsbane og artefakter [2]

• Sett opp drift-/skjevhetsovervåking (selv grunnleggende kontroller av funksjonsfordeling er svært nyttige) [5]

Dyptgående: vanlige feil i forbehandling (og hvordan du unngår dem) 🧯

Feil 1: «Jeg skal bare normalisere alt raskt» 😵

Hvis du beregner skaleringsparametere på hele datasettet, lekker du evalueringsinformasjon. Tilpass på tog, transformer resten. [2]

Feil 2: kategorier som driver inn i kaos 🧩

Hvis kategoritilordningen din skifter mellom trening og inferens, kan modellen din feillese verden i stillhet. Hold tilordningene fikset via lagrede artefakter. [2]

Feil 3: tilfeldig augmentasjon sniker seg inn i evalueringen 🎲

Tilfeldige transformasjoner er fantastiske i trening, men de bør ikke være «i hemmelighet på» når du prøver å måle ytelse. (Tilfeldig betyr tilfeldig.) [4]

Avsluttende bemerkninger 🧠✨

AI-forbehandling er den disiplinerte kunsten å gjøre rotete virkelighet om til konsistente modellinndata. Det dekker rensing, koding, skalering, tokenisering, bildetransformasjoner og – viktigst av alt – repeterbare pipelines og artefakter.

• Gjør forbehandling bevisst, ikke tilfeldig. [2]

• Splitt først, tilpass transformasjoner kun under trening, unngå lekkasje. [2]

• Bruk modalitetstilpasset forbehandling (tokeniserere for tekst, transformasjoner for bilder). [3][4]

• Overvåk produksjonsskjevhet/drift slik at modellen din ikke sakte, men sikkert driver inn i tull. [5]

Og hvis du noen gang står fast, spør deg selv:
«Ville dette forbehandlingstrinnet fortsatt gi mening hvis jeg kjørte det i morgen på helt nye data?»
Hvis svaret er «ehh ... kanskje?», er det ledetråden din 😬

Eksempel fra den virkelige verden: Bygge en lekkasjesikker forbehandlingsrørledning for churn-prediksjon

Scenario

Tenk deg et lite SaaS-team som prøver å forutsi hvilke kunder som sannsynligvis vil kansellere i løpet av de neste 30 dagene. Rådataene deres finnes på tre steder: faktureringseksporter, produktbrukslogger og supportforespørsler.

Den første versjonen av modellen ser utmerket ut i validering, men yter dårlig når den testes på en fersk måned med kunder. Problemet er ikke modellarkitekturen. Det er forprosesseringen.

Teamet skalerte ved et uhell numeriske funksjoner ved hjelp av hele datasettet, bygde kategorikartlegginger fra tog- og testdata sammen, og inkluderte tagger for supportticket som først ble lagt til etter kansellering. Klassisk lekkasje. Smertefullt, men fiksbart. [2]

Hva rørledningen trenger

Et praktisk oppsett ville inkludere:

• Et fast inndataskjema: kunde_id, plan_type, konto_alder_dager, innlogginger_30d, billetter_30d, siste_betalingsstatus, region

• En tidsbasert fordeling, for eksempel opplæring i januar–september og testing i oktober

• Numerisk skalering kun montert på treningsdelingen

• Kategoriske kodere montert kun på treningsdelingen

• En lagret forbehandlingspipeline slik at produksjonen bruker de samme tilordningene og skaleringsverdiene

• Grunnleggende overvåking av manglende kolonner, usynlige kategorier og distribusjonsendringer etter distribusjon

Kjerneregelen er enkel: del først, tilpass forprosessering deretter. Alt som lærer fra dataene, bør bare lære fra treningsperioden. [2]

Eksempelinstruksjon

Bruk dette som arbeidsbeskrivelse for forbehandlingstrinnet:

Bygg en forbehandlingspipeline for en churn-prediksjonsmodell ved hjelp av data om kundefakturering, bruk og support. Del dataene etter tid før du tilpasser noen transformatorer. Tilpass numeriske skalerere og kategoriske kodere kun på treningsdataene, og bruk deretter disse tilpassede transformasjonene på validerings- og testdata. Lagre alle forbehandlingsartefakter slik at produksjonsmodellen bruker samme skjema, kategoritilordninger og skaleringsparametere. Flagg manglende kolonner, uventede datatyper, usete kategorier og store distribusjonsendringer før prediksjon.

Hvordan teste det

Før du stoler på modellen, test forbehandlingsrørledningen med noen bevisst vanskelige poster:

• En kunde på en plantype som ikke var til stede i opplæringen

• En rad med manglende region eller siste_betalingsstatus

• En kunde med uvanlig høy bruk, for eksempel 10 000 pålogginger på 30 dager

• En produksjonsfil med kolonner i feil rekkefølge

• Et testsett for fremtidige måneder som aldri ble brukt under tilpasning

Sjekk deretter tre ting:

• Kjører pipelinen uten å endre funksjonsrekkefølgen?

• Blir ukjente kategorier håndtert konsekvent?

• Synker valideringsytelsen til et mer troverdig nivå etter at lekkasjen er fjernet?

Det siste punktet er viktig. En mistenkelig høy valideringsscore er ofte en lukt fra førbehandling, ikke et mirakel.

Resultat

Illustrativt resultat, basert på tidsberegning av fem eksempelforbehandlingskjøringer før og etter konvertering av notatboktrinn til en lagret pipeline:

• Manuell forbehandlingstid ble redusert fra 55 minutter per datasettoppdatering til 8 minutter.

• Feil i funksjonsrekkefølgen falt fra 3 feil i 5 testoppdateringer til 0 feil i 5 oppdateringer.

• Valideringsnøyaktigheten falt fra 91 % til 74 % etter at lekkasjen ble fjernet, men testnøyaktigheten fra den siste måneden ble forbedret fra 62 % til 71 %.

• Teamet la til seks automatiserte kontroller: manglende kolonner, ugyldige typer, usynlige kategorier, endring av nullrate, endring av numerisk område og avvik mellom tog-serveringsskjemaer.

Disse tallene er ikke en universell referanse. De er den typen enkle før-og-etter-målinger et team kan reprodusere ved å taste inn oppdateringer, telle mislykkede kjøringer og sammenligne valideringsresultater med en utsatt fremtidig måned.

Hva kan gå galt

Den største risikoen er å få pipelinen til å se ren ut samtidig som lekkasjen i det stille bevares. For eksempel kan «dager siden siste e-post med kanselleringsvarsel» virke verdifullt, men hvis e-posten bare sendes etter en intern gjennomgang av kundeavgang, kan den lekke fremtidig kunnskap.

Andre vanlige feller:

• Tilpasse kodere i produksjon i stedet for å laste inn lagrede tilordninger

• La nye kategorier stille endre funksjonsposisjoner

• Testing på en tilfeldig deling når den virkelige oppgaven er tidsbasert

• Slipper rader med manglende verdier i trening, men håndterer dem ikke ved inferens

• Overvåking av modellens nøyaktighet mens man ignorerer avvik i inngangsdata

Praktisk takeaway

En god forbehandlingspipeline gjør mer enn å rydde opp i rådata. Den beskytter modellen mot dårlig evaluering, ødelagte produksjonsinndata og langsom, stille drift. For en churn-modell kommer forskjellen mellom smart forbehandling og pålitelig forbehandling ofte ned til om de samme tilpassede transformasjonene brukes på nytt hver gang, spesielt når dataene kommer fra en måned modellen aldri har sett maken til.

Vanlige spørsmål

Hva er AI-forbehandling, enkelt sagt?

AI-forbehandling er et repeterbart sett med trinn som omdanner støyende rådata med høy varians til konsistente input som en modell kan lære av. Det kan inkludere rensing, validering, koding av kategorier, skalering av numeriske verdier, tokenisering av tekst og bruk av bildetransformasjoner. Målet er å sikre at trening og produksjonsinferens ser «samme type» input, slik at modellen ikke glider inn i uforutsigbar oppførsel senere.

Hvorfor er AI-forbehandling så viktig i produksjon?

Forbehandling er viktig fordi modeller er følsomme for representasjon av input. Hvis treningsdata skaleres, kodes, tokeniseres eller transformeres annerledes enn produksjonsdata, kan du få feil i tog/servering-avvik som ser fine ut offline, men feiler stille online. Sterke forbehandlingsrørledninger reduserer også støy, forbedrer læringsstabiliteten og fremskynder iterasjonen fordi du ikke løser opp i spaghetti i notatboken.

Hvordan unngår jeg datalekkasje under forbehandling?

En enkel regel fungerer: alt med et tilpasningstrinn må kun tilpasses treningsdata. Dette inkluderer skalerere, kodere og tokeniserere som lærer parametere som gjennomsnitt, kategorikart eller vokabularer. Du deler først, tilpasser på treningsdelingen, og transformerer deretter validering/testing ved hjelp av den tilpassede transformatoren. Lekkasje kan få validering til å se "magisk" bra ut og deretter kollapse i produksjonsbruk.

Hva er de vanligste forbehandlingstrinnene for tabelldata?

For tabelldata inkluderer den vanlige pipelinen rensing og validering (typer, områder, manglende verdier), kategorisk koding (en-hot eller ordinal) og numerisk skalering (standardisering eller min-max). Mange pipelines legger til domenedrevet funksjonsteknikk som forholdstall, rullerende vinduer eller antall. En praktisk vane er å definere kolonnegrupper eksplisitt (numerisk vs. kategorisk vs. identifikatorer) slik at transformasjonene dine forblir konsistente.

Hvordan fungerer forbehandling for tekstmodeller?

Tekstforbehandling betyr vanligvis tokenisering til tokener/underord, konvertering av dem til input-ID-er og håndtering av utfylling/avkorting for batching. Mange transformer-arbeidsflyter oppretter også en oppmerksomhetsmaske ved siden av ID-ene. En vanlig tilnærming er å bruke modellens forventede tokenizer-konfigurasjon i stedet for å improvisere, fordi små forskjeller i tokenizer-innstillinger kan føre til utfall av typen «den trener, men den oppfører seg uforutsigbart».

Hva er annerledes med forbehandling av bilder for maskinlæring?

Bildeforbehandling sikrer vanligvis konsistente former og pikselhåndtering: endring av størrelse/beskjæring, normalisering og en klar splittelse mellom deterministiske og tilfeldige transformasjoner. For evaluering bør transformasjoner være deterministiske slik at beregningene er sammenlignbare. For trening kan tilfeldig forstørrelse (som tilfeldige beskjæringer) forbedre robustheten, men tilfeldigheten må bevisst være knyttet til treningsdelingen, ikke ved et uhell la den være på under evalueringen.

Hva gjør en forbehandlingsrørledning «god» i stedet for skjør?

En god AI-forbehandlingspipeline er reproduserbar, lekkasjesikker og observerbar. Reproduserbar betyr at samme input produserer samme output med mindre tilfeldighet er bevisst forsterket. Lekkasjesikker betyr at tilpasningstrinn aldri berører validering/testing. Observerbar betyr at du kan inspisere statistikk som manglende antall, antall kategorier og funksjonsfordelinger, slik at feilsøking er basert på bevis, ikke magefølelse. Pipelines slår ad hoc-notatboksekvenser hver gang.

Hvordan sørger jeg for at trening og forbehandling av slutninger er konsistent?

Nøkkelen er å gjenbruke nøyaktig de samme lærte artefaktene ved inferens: skaleringsparametere, kodertilordninger og tokeniseringskonfigurasjoner. Du ønsker også en inputkontrakt (forventede kolonner, typer og områder) slik at produksjonsdata ikke stille kan drive inn i ugyldige former. Konsistens handler ikke bare om å «gjøre de samme trinnene» – det handler om å «gjøre de samme trinnene med de samme tilpassede parameterne og tilordningene»

Hvordan kan jeg overvåke problemer med forhåndsbehandling som avdrift og skjevhet over tid?

Selv med en solid pipeline endres produksjonsdata. En vanlig tilnærming er å overvåke endringer i funksjonsfordelingen og varsle om treningsvisningsskjevhet (produksjon avviker fra trening) og inferensdrift (produksjonsendringer over tid). Overvåking kan være lett (grunnleggende distribusjonskontroller) eller administrert (som Vertex AI Model Monitoring). Målet er å fange opp endringer i input tidlig – før de sakte eroderer modellens ytelse.

Referanser

[1] scikit-learn API: sklearn.preprocessing (kodere, skalerere, normalisering)
[2] scikit-learn: Vanlige fallgruver - datalekkasje og hvordan unngå det
[3] Hugging Face Transformers-dokumentasjon: Tokenizere (inndata-ID-er, oppmerksomhetsmasker)
[4] PyTorch Torchvision-dokumentasjon: Transformasjoner (endre størrelse/normaliser + tilfeldige transformasjoner)
[5] Google Cloud Vertex AI-dokumentasjon: Oversikt over modellovervåking (funksjonsskjevhet og -drift)

Finn den nyeste AI-en i den offisielle AI-assistentbutikken

Om oss