Embeddingmodellen afgør din søgekvalitet

Når et team går i gang med at bygge semantisk søgning, starter samtalen næsten altid på det forkerte sted. Uger går til at vælge vektordatabase — Qdrant eller pgvector, dette indeks eller det, selvhostet eller administreret — og minutter til embeddingmodellen, der som regel falder til det populære eller det, tutorialen brugte. Dette er præcis omvendt. Databasen afgør, hvor hurtigt og billigt du søger. Embeddingen afgør, om de rigtige resultater kommer overhovedet.

Returnerer din søgning irrelevante resultater, er oddsene overvældende for, at problemet er embeddingen, ikke databasen. Og ingen databasetuning fikser en dårlig embedding, for fejlen blev begået, før databasen nogensinde så dataene.

Hvad embeddingen faktisk gør

En embeddingmodel gør hvert tekststykke til et punkt i et højdimensionelt rum, placeret så ens betydninger ligger tæt på hinanden. Søgning finder så punkterne nærmest din forespørgsel. Embeddingen definerer altså "nær". Placerer modellen en forespørgsel langt fra svaret, kan ingen hurtig database finde det.

Relevans bestemmes altså ved embedding-tid, ikke forespørgselstid. Databasen finder hurtigt nære punkter; den har ingen mening om, hvorvidt punkterne blev placeret fornuftigt. Det er helt embeddingmodellens job.

Bedste model afhænger af indholdet

Der findes ingen enkelt bedste embeddingmodel, for "bedste" afhænger af, hvad du embedder. En model, der glimrer på juridisk tekst, kan være middelmådig på korte produkttitler; en tunet til supportsager kan fejlvurdere tæt teknisk dokumentation. Domæne, længde, ordforråd og struktur ændrer, hvilken model der præsterer. En topliste-topmodel kan slås på dine data af en mindre, der passer bedre.

Derfor kan valget ikke træffes abstrakt. Spørgsmålet er aldrig "hvad er bedste model", men "hvad er bedst til dette indhold og disse forespørgsler".

Sprog ændrer alt

Ud over engelsk bliver valget endnu mere konsekvensrigt. En overvejende engelsk-trænet model underpræsterer stille på finsk, norsk, svensk eller dansk — ikke med en åbenlys fejl, men med subtilt dårligere placeringer, der viser sig som lidt-forkerte resultater. For flersproget indhold er en genuint flersproget embedding ikke en nice-to-have; det er forskellen mellem søgning, der virker, og søgning, der næsten virker.

En almindelig, kostbar forglemmelse. Et team benchmarker på engelsk, alt ser fint ud, og degraderingen dukker først op med ægte nordisk indhold — når arkitekturen er låst.

Hvorfor toplister vildleder

Offentlige embedding-toplister er nyttige som startliste og farlige som beslutning. De rangerer modeller på standardiserede benchmark-data, der næsten sikkert ikke er dine, i opgaver, der næsten sikkert ikke er din. En model kan føre på generisk hentning og alligevel underpræstere på dit domæne, dine længder og sprog. At tage toplisten som stedfortræder er et væddemål om, at dine data ligner benchmarken — som regel forkert.

Toplisten siger, hvilke modeller der er værd at teste. Ikke hvilken du skal bruge. Kun dine data kan det.

Benchmark på egne data

Den pålidelige måde er uglamourøs: tag en håndfuld kandidater, embed et repræsentativt udsnit af ægte indhold, kør ægte forespørgsler mod hver og mål, hvilken der returnerer de rigtige resultater. Dette tager ikke lang tid og erstatter gætteri med bevis. Vi gør netop dette ved starten, for en time med benchmarking sparer uger med databasetuning for en embedding, der aldrig ville virke.

Målingen er pointen. Du leder ikke efter modellen med bedst ry, men den, der placerer dine forespørgsler nærmest dine svar — og det findes kun ved at prøve dem på dine data.

Chunking er del af modelvalget

Hvordan du deler dokumenter i chunks samspiller direkte med embeddingen. For lange chunks udvander betydningen til et vagt gennemsnit; for korte mister konteksten, der gør dem findbare. Den rigtige strategi afhænger af model og indhold sammen, og forkert gjort kan selv en god embedding give dårlige resultater. Ikke en separat senere beslutning, men del af samme designproblem.

Få dette rigtigt, resten følger

Embeddingmodel og chunking er grundlaget for semantisk søgning. Få dem rigtigt, benchmarket på ægte data, og databasen bliver, hvad den bør være: en implementeringsdetalje om fart og omkostning. Få dem forkert, og ingen database redder dig — du bruger tiden på at tune infrastruktur for at kompensere for et grundlag, der var forkert fra start. Brug indsatsen, hvor den bestemmer udfaldet, og resten af systemet bliver meget lettere.