Hvorfor vi flyttet søk, tagging og anbefalinger ut av skyen

De fleste «AI-drevne» nettleserutvidelser sender alt til en server – også de delene som overhodet ikke har noe med AI å gjøre. Søk, tag-opprydding og «finn lignende elementer» er flere tiår gamle, velprøvde teknikker. De trenger ingen språkmodell, og de trenger definitivt ingen tur innom nettverket. Vi gikk gjennom AI Summary Helper funksjon for funksjon og spurte: Trenger dette egentlig skyen, eller velger vi det bare fordi det er den enkleste arkitekturen?

De aller fleste trengte det ikke.

Dette flyttet vi lokalt til enheten

Søk. Opprinnelig søkte utvidelsen kun i artikkeltitler og emneknagger – raskt, men blindt for innholdet i selve teksten. I stedet for å råsjekke hele teksten for hvert tastetrykk eller sende alle søk til en server, bygde vi en liten TF-IDF-indeks fra ditt eget lagrede arkiv. Enkle felter – som tittel og tags – sjekkes først og lynraskt, akkurat som før. Lengre søk utvides mot indeksen, som bygges én gang per økt og oppdateres fortløpende, uten å skannes på nytt for hvert tastetrykk.

Duplikatgjenkjenning. Før en lagring fullføres, kjøres en trinnvis sjekk: først eksakt normalisert URL-treff (enkelt, O(1)), deretter tittellikhet på kandidatene som passerer det filteret, og først til slutt – for de få gjenværende kandidatene – en full TF-IDF cosinus-likhetssammenligning. De fleste lagringer når aldri det tunge trinnet, fordi de enkle trinnene allerede har løst oppgaven.

Tag-normalisering. Tags sklir gjerne ut over tid – «ML», «Machine Learning» og «machine-learning» betyr det samme for et menneske, men er helt ulike for et filter. En liten alias-tabell fanger opp de åpenbare tilfellene. En fleksibel avstandssammenligning (fuzzy edit-distance) på tvers av hele tag-vokabularet tar resten, og velger skrivemåten du faktisk har brukt oftest som standard, i stedet for å tvinge en «fasit» på deg.

Lesbarhet og tone. Lesbarhetsindekser som Flesch–Kincaid er ren matematikk basert på antall setninger og stavelser – ingen modell kreves. Stemningsanalyse gjøres med en integrert AFINN-ordliste og en enkel sjekk for negasjoner i de to foregående ordene. Ingen av delene trengte noen gang å forlate nettleseren.

«Lignende artikler» og Digest. Begge gjenbruker nøyaktig de samme TF-IDF-vektorene som søket allerede har bygget. Det hadde vært lett å bygge tre separate likhetssystemer for tre ulike funksjoner. Ved å bygge én felles indeks som både søk, anbefalinger og sammendragskuratering leser fra, holdt vi hele systemet lettere – og en forbedring av indeksen forbedret automatisk alle tre funksjoner samtidig.

Dette lot vi bevisst bli værende i skyen

Selve oppsummeringstrinnet – delen som faktisk krever en språkmodell – krever fortsatt et nettverkskall. Det kommer man ikke unna med dagens lokale modellstørrelser hvis man vil ha kvaliteten til en skybasert toppmodell. Du tar med din egen API key for dette trinnet (OpenAI, Gemini, Mistral, DeepSeek), eller kobler utvidelsen til en lokal Ollama-instans for å droppe nettverket helt. Dette er det eneste stedet hvor lokal prosessering ikke er standard – det er et aktivt valg, fordi avveiningen er reell: en lokal modell er tregere og har lavere kvalitet enn en skybasert modell, og vi ønsker ikke å late som noe annet.

Hvorfor dette handler om mer enn bare personvern

Personvernaspektet er reelt – en utvidelse med vide tilganger som sender sideinnhold til en server for ting som ikke trenger det, er et legitimt tillitsspørsmål, ikke bare pynt. Men den mer jordnære grunnen er at det som regel bare er bedre håndverk. Et TF-IDF-søk trenger ikke 200 ms nettverksforsinkelse. Tag-opprydding trenger ikke en API-faktura. Når du velger riktig verktøy for selve jobben, i stedet for å rute alt gjennom skyen som standard, ender du opp med noe som er raskere, billigere i drift og mer robust når du er frakoblet – og personverngevinsten følger med på kjøpet.