Embeddingmodellen avgjør søkekvaliteten din

Når et team setter i gang med å bygge semantisk søk, starter samtalen nesten alltid på feil sted. Uker går til å velge vektordatabase — Qdrant eller pgvector, denne indeksen eller den, selvhostet eller administrert — og minutter til embeddingmodellen, som vanligvis faller til det populære eller det tutorialen brukte. Dette er nettopp baklengs. Databasen avgjør hvor raskt og billig du søker. Embeddingen avgjør om de riktige resultatene kommer i det hele tatt.

Returnerer søket ditt irrelevante resultater, er sjansen overveldende for at problemet er embeddingen, ikke databasen. Og ingen databasetuning fikser en dårlig embedding, for feilen ble gjort før databasen noensinne så dataene.

Hva embeddingen faktisk gjør

En embeddingmodell gjør hvert tekststykke til et punkt i et høydimensjonalt rom, plassert slik at like betydninger ligger nær hverandre. Søk finner så punktene nærmest spørringen din. Embeddingen definerer altså «nær». Plasserer modellen en spørring langt fra svaret, kan ingen rask database finne det.

Relevans bestemmes altså ved embedding-tid, ikke spørretid. Databasen finner raskt nære punkter; den har ingen mening om punktene ble plassert fornuftig. Det er helt embeddingmodellens jobb.

Beste modell avhenger av innholdet

Det finnes ingen enkelt beste embeddingmodell, for «beste» avhenger av hva du embedder. En modell som glimrer på juridisk tekst kan være middelmådig på korte produkttitler; en tunet for støttesaker kan feilvurdere tett teknisk dokumentasjon. Domene, lengde, vokabular og struktur endrer hvilken modell som presterer. En ledertavle-toppmodell kan slås på dine data av en mindre som passer bedre.

Derfor kan valget ikke tas abstrakt. Spørsmålet er aldri «hva er beste modell», men «hva er beste for dette innholdet og disse spørringene».

Språk endrer alt

Utover engelsk blir valget enda mer konsekvensrikt. En overveiende engelsk-trent modell underpresterer stille på finsk, norsk, svensk eller dansk — ikke med en åpenbar feil, men med subtilt dårligere plasseringer som viser seg som litt-gale resultater. For flerspråklig innhold er en genuint flerspråklig embedding ikke en nice-to-have; det er forskjellen mellom søk som virker og søk som nesten virker.

En vanlig, kostbar forglemmelse. Et team benchmarker på engelsk, alt ser bra ut, og degraderingen dukker først opp med ekte nordisk innhold — når arkitekturen er låst.

Hvorfor ledertavler villeder

Offentlige embedding-ledertavler er nyttige som startliste og farlige som beslutning. De rangerer modeller på standardiserte benchmark-data som nesten sikkert ikke er dine, i oppgaver som nesten sikkert ikke er din. En modell kan lede på generisk innhenting og likevel underprestere på ditt domene, dine lengder og språk. Å ta ledertavlen som stedfortreder er et veddemål om at dataene dine ligner benchmarken — vanligvis feil.

Ledertavlen sier hvilke modeller som er verdt å teste. Ikke hvilken du skal bruke. Bare dataene dine kan det.

Benchmark på egne data

Den pålitelige måten er uglamorøs: ta en håndfull kandidater, embed et representativt utsnitt av ekte innhold, kjør ekte spørringer mot hver og mål hvilken som returnerer de riktige resultatene. Dette tar ikke lang tid og erstatter gjetting med bevis. Vi gjør nettopp dette ved starten, for en time med benchmarking sparer uker med databasetuning for en embedding som aldri ville virket.

Målingen er poenget. Du leter ikke etter modellen med best rykte, men den som plasserer spørringene dine nærmest svarene — og det finnes bare ved å prøve dem på dine data.

Chunking er del av modellvalget

Hvordan du deler dokumenter i chunks samspiller direkte med embeddingen. For lange chunks fortynner betydningen til et vagt snitt; for korte mister konteksten som gjør dem finnbare. Riktig strategi avhenger av modell og innhold sammen, og feil gjort kan selv en god embedding gi dårlige resultater. Ikke en separat senere beslutning, men del av samme designproblem.

Få dette riktig, resten følger

Embeddingmodell og chunking er grunnlaget for semantisk søk. Få dem riktig, benchmarket på ekte data, og databasen blir det den bør være: en implementeringsdetalj om fart og kostnad. Få dem feil, og ingen database redder deg — du bruker tiden på å tune infrastruktur for å kompensere for et grunnlag som var feil fra start. Bruk innsatsen der den bestemmer utfallet, og resten av systemet blir mye lettere.