Rot i webdata koster deg mer enn du tror: Derfor er content extraction kritisk
Den skjulte kostnaden av støyende webdata: Hvorfor innholdsutvinning aldri har vært viktigere
Hver språkmodell leser nettet to ganger. Først under trening, der den lærer mønstrene i menneskelig kunnskap. Deretter ved inferenstidspunktet, når den henter relevant kontekst for å svare på spørsmålene dine. Begge stadier deler en skitten hemmelighet: størsteparten av inputen er fullstendig ubrukelig støy.
Forskning viser at rundt 70% av HTML-koden på en typisk nettside består av standardinnhold—navigasjonsmenyer, annonser, sidelinjer, informasjonskapselsamtykker og bunntekster. Det faktiske innholdet du bryr deg om? Det utgjør bare 30% av siden. Og her kommer poenget: det 30% avgjør alt.
Hvorfor datakvalitet er den virkelige fordelen
Maskinlæringsmiljøet har vært opptatt av modelarkitektur, antall parametre og treningsregimer. Men en voksende mengde forskning tyder på at det kjedelige arbeidet med dataprepparering kan være den sanne differensiatoren.
En studie fra 2025 av Ma et al. (AICC) kjørte et avslørende eksperiment. Teamet opprettet to treningskorpus fra identiske Common Crawl-øyeblikksbilder. Den eneste variabelen som ble endret var utvinningsmetoden—én brukte tradisjonelle heuristikker, den andre brukte en modellbasert tilnærming. Alt annet var likt.
Modellen trent på renere, modellutvunnet data overgikk motparten med 1,08 prosentpoeng på tvers av 13 benchmarks. Enda mer imponerende: denne ene endringen lot dem slå modeller trent på FineWeb og RefinedWeb—datasett kjent for sine omfattende filtreringspipelines.
Dette funnet bør få enhver ML-avdeling til å stoppe opp. Mens alle stresser med å trene større modeller eller eksperimentere med nye arkitekturer, kan de største gevinstene komme fra rett og slett å fjerne søpla.
Problemet ved inferenstid
Datakvalitet betyr noe utover trening. Forskning fra Shi et al. (ICML 2023) viste at en enkelt irrelevant passasje fullstendig kan forvrenge en modells svar. Når systemet ditt henter inn støyete kontekst, kaster du ikke bare bort datakraft—you aktivt forringer svarkvaliteten.
Dette skaper et problematisk scenario for produksjonssystemer. RAG-pipelines (Retrieval-Augmented Generation) lover å forankre svar i relevant informasjon, men hvis denne hentingen inkluderer sidelinjeannonser og informasjonskapselsamtykker, injiserer du gift i kontekstvinduet ditt.
Tallene er slående når du ser på hvordan ulike utvinnere bevarer strukturert innhold. Heuristikkbaserte metoder som Trafilatura viser likhetsscorer på bare 0,13 for kodeblokker og 0,61 for matematiske formler sammenlignet med modellbaserte tilnærminger som scorer 0,91 og 0,94. Når dokumentasjonen din inneholder kodeeksempler eller teknisk notasjon, blir disse utvinningsfeilene til treningskorrupsjon.
Arkitekturvalget: Encoder mot Decoder
Dagens utvinningsmetoder faller i to kategorier: strukturbaserte og innholdsbaserte.
Strukturbaserte utvinnere (Trafilatura, Readability, Boilerpipe) analyserer HTML gjennom overfladiske signaler—DOM-posisjon, tag-typer, tekstdensitet. De er raske og krever ingen ML-overhead, men de forvirrer elementer som ligner. En navigasjonstabell og en datatabell har identiske strukturelle signaturer, så disse metodene klassifiserer uunngåelig feil.
Lesingsbaserte utvinnere mater faktisk innhold til transformermodeller. Dripper, den nåværende lederen, bruker en decoder-arkitektur som genererer etiketter token for token. Denne tilnærmingen oppnår utmerket nøyaktighet, men har et fundamentalt effektivitetsproblem: hvert token krever at hele modellen leses fra minnet. Hastigheten blir bundet av minnebandbredde heller enn datakraft.
Dette er der en ny tilnærming kalt Pulpie tar en interessant arkitektonisk satsing. I stedet for en decoder som genererer etiketter sekvensielt, bruker Pulpie en encoder som merker hver HTML-blokk i én fremoverkjøring. Dette flytter flaskehalsen fra minnebandbredde til ren datakraft—et langt mer skalerbart problem.
Resultatene er overbevisende. På en NVIDIA L4 GPU prosesserer den lille Pulpie-modellen 13,7 sider per sekund mot Drippers 0,68 sider per sekund. Det er en 20x throughput-forbedring. Oversatt til reelle kostnader: rensing av én milliard sider koster omtrent 7 900 dollar med Pulpie mot 159 000 dollar med Dripper.
Hva dette betyr for din AI-stack
For startups og utviklere som bygger AI-applikasjoner, har denne forskningen praktiske implikasjoner:
Først: revider din utvinningspipeline. Hvis du fremdeles bruker heuristikkbaserte utvinnere for trening eller RAG-pipelines, etterlater du målbar ytelse på bordet. Marginalkostnaden for bedre utvinning er nå en brøkdel av hva den var for bare et år siden.
Deretter: tenk over hvor utvinning passer inn i arkitekturen din. Mange team behandler webinnhold som et løst problem—hent siden, stripp HTML-en, ferdig. Men etter hvert som modellene blir mer sofistikerte, betyr kvaliteten på inputen mer. Systemet ditt er bare så godt som utvinningslaget.
Tredje: vurder åpen kildekode-alternativer. Pulpie blir med i et voksende økosystem av åpen kildekode-utvinningsmodeller. Dagene med å trenge dyre proprietære API-er for kvalitetsutvinning er i ferd med å ebbe ut.
Det større bildet
Vi vitner om en stille endring i hvordan ML-miljøet tenker om datakvalitet. I år har antakelsen vært at mer data overgår renere data. Skaler korpuset, bruk grunnleggende filtrering, tren lenger—til slutt overvelder signalet støyen.
Men etter hvert som modellene når høyere ferdighetsnivåer, bryter denne antakelsen sammen. Når du trener på hundrevis av milliarder av tokens, kompounderer selv små korrupsjonsrater til meningsfull skade. Og når inferenskontekster er bundne, er hvert støyete token ett mindre nyttig token.
Ironien er at webutvinning—det kjedelige arbeidet med å identifisere hovedinnhold fra HTML—kan være en av de høyest leverage intervensjonene i hele ML-pipelinen din. Det neste gjennombruddet i modellens ytelse kommer kanskje ikke fra en ny arkitektur. Det kan komme fra rett og slett å lese nettet mer nøye.
Rene data er ikke glamourøst. Men det er det som skiller en god modell fra en flott en.