Hvad er en vektordatabase?

En vektordatabase er en database, der gemmer embeddings og finder data ud fra matematisk lighed mellem vektorer. Den bruges især, når tekst, billeder, dokumenter eller produkter skal søges efter betydning, mønstre eller relevans i stedet for kun eksakte søgeord.

Hvordan adskiller en vektordatabase sig fra en almindelig database?

En almindelig database er stærk, når du kender et felt, en nøgle, en dato, en kategori eller en præcis værdi. En vektordatabase er bygget til en anden type spørgsmål: Hvilke poster minder mest om dette input? Den arbejder med talrepræsentationer af indhold, så lignende tekster, billeder eller andre datatyper kan placeres tæt på hinanden i et vektorrum.

Det betyder ikke, at en vektordatabase erstatter relationelle databaser, dokumentdatabaser eller søgeindekser. Den løser især den del af problemet, hvor betydning, kontekst eller mønstre skal sammenlignes. I praksis ligger den ofte ved siden af eksisterende systemer, hvor den gemmer embeddings, id’er, metadata og reference til det oprindelige indhold.

Hvad gemmer en vektordatabase egentlig?

Den centrale datadel er en embedding: en liste af tal, typisk decimaltal, der repræsenterer et stykke indhold. OpenAI beskriver for eksempel en embedding som en vektor, hvor afstanden mellem to vektorer kan bruges som mål for, hvor relaterede to tekststrenge er. Det samme princip bruges bredere med embeddings fra forskellige modeller og datatyper.

En vektordatabase gemmer normalt ikke kun selve vektoren. Den gemmer også et id, metadata og en reference til kilden. Hvis en tekst er delt op i mindre bidder, kan hver bid have sin egen embedding, men stadig pege tilbage på dokumentet, afsnittet, siden eller produktet, som den stammer fra.

Metadata er en praktisk nøgle. Uden metadata kan databasen finde semantisk lignende indhold, men den kan have svært ved at begrænse søgeresultatet til den rigtige kunde, afdeling, sprogversion, dato, dokumenttype eller adgangsgruppe. Derfor er en god vektordatabase sjældent kun et lager af tal; den er også en struktur for relationen mellem embeddings og det oprindelige datagrundlag.

Hvordan fungerer søgning med embeddings?

Først omsættes input til en embedding med en embedding-model. Det kan være en søgeforespørgsel, et dokumentafsnit, en produktbeskrivelse, en supportbesked eller et billede, afhængigt af modellen. Derefter sammenligner vektordatabasen den nye vektor med de vektorer, der allerede er gemt.

Sammenligningen sker med et afstandsmål eller en similarity-funktion. I praktiske systemer møder du især cosine similarity, L2-afstand og inner product. Valget afhænger af embedding-modellen, datatypen og den database eller søgemotor, der bruges. Hvis modellen producerer normaliserede vektorer, kan flere afstandsmål give samme rangering, men det må ikke antages for alle modeller.

Resultatet er typisk en rangeret liste over de nærmeste poster. Listen kan derefter kombineres med metadatafiltre, adgangskontrol eller en efterrangering, før den vises til en bruger eller sendes videre til en sprogmodel. Det er denne kæde, der gør vector search nyttig i semantisk søgning, anbefalinger og systemer med retrieval augmented generation.

Hvorfor er nearest neighbor-search centralt?

Nearest neighbor-search handler om at finde de nærmeste punkter i et vektorrum. Hvis du kun har få tusinde vektorer, kan et system i nogle tilfælde sammenligne forespørgslen med alle vektorer direkte. Når samlingen vokser til millioner eller milliarder af vektorer, bliver fuld sammenligning dyrere i både tid, hukommelse og regnekraft.

Derfor bruger mange vektordatabaser approximate nearest neighbor-search. I stedet for at garantere det absolut nærmeste resultat hver gang forsøger systemet at finde meget relevante naboer hurtigt. Den praktiske afvejning kaldes ofte speed-recall tradeoff: højere hastighed kan koste noget recall, mens højere recall kan kræve mere tid, større indeks eller mere hukommelse.

Forskning i HNSW beskriver en grafbaseret metode, hvor vektorer forbindes i lag, så søgningen kan navigere hurtigt mod relevante områder. FAISS-paperet viser, hvordan similarity search i højdimensionelle vektorer kan skaleres med blandt andet GPU’er, approximate search og komprimerede repræsentationer. Pointen for en organisation er ikke at vælge algoritme efter navn alene, men at teste kvalitet, responstid og driftskrav på egne data.

Hvornår giver en vektordatabase mening?

En vektordatabase giver mest mening, når brugeren ikke nødvendigvis kender de præcise ord, som findes i data. Det gælder for eksempel vidensbaser, interne dokumenter, produktkataloger, supporthistorik, billedsamlinger, semantisk dubletkontrol og anbefalinger. Her kan to tekster være relevante for hinanden, selv om de bruger forskellige formuleringer.

Den giver mindre mening som eneste løsning, hvis opgaven primært er klassisk opslag, bogføring, lagerstatus, brugerrettigheder eller andre transaktioner, hvor korrekthed afhænger af nøjagtige værdier. I de situationer bør vektorsøgning supplere de eksisterende databaser i stedet for at overtage deres rolle.

• Brug vektorsøgning, når betydning, semantisk lighed eller mønstergenkendelse er vigtigere end eksakt ordmatch.
• Brug almindelige databasefiltre, når resultatet skal begrænses efter kunde, rolle, dato, status eller dokumenttype.
• Brug traditionel søgning eller hybrid søgning, når nøgleord, fagtermer og præcise navne stadig har høj betydning.

Hvad betyder chunking for kvaliteten?

Chunking er processen, hvor større dokumenter deles op i mindre tekststykker, før de embeddes. Hvis stykkerne er for lange, kan en embedding blande flere emner sammen. Hvis de er for korte, kan de miste den kontekst, der gør resultatet brugbart. Derfor påvirker chunking ofte retrieval-kvaliteten lige så meget som selve vektordatabasen.

En praktisk tilgang er at dele efter naturlige enheder: afsnit, sektioner, spørgsmål, produktsider eller sagsnotater. Overlap mellem tekststykker kan bevare kontekst, men for meget overlap giver flere næsten ens resultater. Det kan forringe rangering og øge lagerforbrug.

Hvis du arbejder med AI-embeddings, bør du derfor måle, om de fundne chunks faktisk svarer på brugerens spørgsmål. En teknisk høj similarity-score er ikke nok, hvis tekststykket mangler den konkrete oplysning, systemet skal bruge.

Hvordan spiller metadata og filtre sammen med vektorsøgning?

Metadata gør vektorsøgning styrbar. Et semantisk søgeresultat kan være matematisk tæt på forespørgslen, men stadig irrelevant, hvis det kommer fra forkert produktlinje, forkert sprog, forkert adgangsniveau eller for gammel version. Derfor kombinerer moderne vector search ofte nearest neighbor-søgning med filtrering.

pgvector-dokumentationen viser et praktisk mønster, hvor nearest neighbor-søgning kan kombineres med almindelige felter i Postgres, for eksempel kategori. Det samme princip findes i mange dedikerede vektordatabaser: først afgrænses eller efterfiltreres kandidaterne, derefter vurderes deres vektorlighed.

Rækkefølgen betyder noget. Filtrerer du for hårdt før vektorsøgning, kan systemet overse relevante kandidater. Filtrerer du for sent, kan irrelevante eller utilgængelige resultater nå for langt i processen. I systemer med adgangsstyring bør rettigheder ikke kun være en visuel begrænsning i brugerfladen, men indgå i selve retrieval-flowet.

Hvilke data- og sikkerhedsspørgsmål følger med?

Embeddings er afledte data, men de bør ikke behandles som ufarlige restprodukter. De kan være koblet til dokument-id’er, bruger-id’er, kundesager, interne beskrivelser eller andet følsomt materiale. Risikoen ligger både i selve vektoren, metadataene og i muligheden for at hente oprindeligt indhold via referencer.

Et praktisk kontrolpunkt er at spørge, hvem der må søge i hvilke embeddings, og om samme database blander data fra flere kunder, afdelinger eller adgangsniveauer. Hvis en sprogmodel får adgang til retrieval-resultater, bør systemet også kontrollere, om modellen får mere kontekst end nødvendigt.

Sletning og opdatering kræver særlig disciplin. Hvis et dokument ændres, skal den tilhørende embedding normalt genskabes. Hvis et dokument slettes, skal både kildetekst, embedding, metadata og eventuelle cachede retrieval-resultater håndteres. Ellers kan forældede eller uønskede oplysninger blive ved med at dukke op i svar eller anbefalinger.

Hvordan bruges vektordatabaser i RAG-systemer?

I et RAG-system bruges vektordatabasen som hukommelses- og genfindingslag. Når en bruger stiller et spørgsmål, bliver spørgsmålet embeded, og databasen finder relevante tekststykker. Disse tekststykker sendes videre som kontekst til en sprogmodel, der kan formulere et svar på baggrund af det fundne materiale.

Vektordatabasen gør ikke svaret korrekt af sig selv. Den kan kun hente kandidater, der findes i datagrundlaget, og rangeringen afhænger af embeddings, chunking, filtre og indeksindstillinger. Hvis relevante dokumenter mangler, er for gamle eller er dårligt opdelt, kan RAG-systemet give et svagt svar, selv om den underliggende sprogmodel er stærk.

Derfor bør RAG evalueres som en samlet kæde: datakilder, opdeling, embeddings, vektordatabase, promptkontekst, adgangskontrol og svarvurdering. Et teknisk hurtigt opslag er først værdifuldt, når det også henter de tekststykker, som faktisk hjælper brugeren.

Hvad er forskellen på vektorsøgning og traditionel søgning?

Traditionel søgning er stærk til ord, navne, produktnumre, præcise fraser og dokumenter, hvor det vigtigste begreb faktisk står i teksten. Vektorsøgning er stærkere, når ordvalget varierer, eller når spørgsmålet beskriver et behov i stedet for et bestemt søgeord.

Et eksempel kan være en medarbejder, der søger efter “hvordan får jeg adgang efter barsel?”. Et traditionelt søgeindeks leder efter de konkrete ord. Vektorsøgning kan finde et dokument om genåbning af brugerkonto efter orlov, hvis embedding-modellen placerer de to formuleringer tæt på hinanden.

Den bedste løsning er ofte hybrid. Nøgleord kan sikre præcise hits på fagtermer, navne og lovbestemte udtryk, mens vektorsøgning kan finde semantisk beslægtet indhold. Det samme gælder i datamining, hvor både strukturerede signaler og mønstre i ustruktureret data kan have værdi.

Hvordan vælger du mellem exact og approximate search?

Exact search sammenligner forespørgslen med alle relevante vektorer og giver den mest direkte rangering efter det valgte afstandsmål. Det kan være enkelt og præcist på mindre datamængder, men bliver dyrere, når antallet af vektorer og dimensioner vokser.

Approximate search bruger et indeks, der begrænser søgeområdet. HNSW og IVFFlat er eksempler på sådanne indeks i pgvector. Ifølge pgvector kan et approximate indeks give andre resultater end exact search, fordi det bytter noget recall for hastighed. HNSW beskrives samme sted som hurtigt i speed-recall-afvejningen, men med langsommere byggetid og højere hukommelsesforbrug end IVFFlat.

Valget bør bygge på målinger. For en intern vidensbase kan lidt lavere recall være acceptabelt, hvis svaret stadig indeholder gode kilder og kommer hurtigt. For et system, der skal finde næsten ens dokumenter før en kritisk beslutning, kan recall veje tungere end responstid.

• Mål recall ved at sammenligne systemets topresultater med en kendt testmængde.
• Mål latency ved realistiske forespørgsler, ikke kun ved tomme testkald.
• Mål filterkvalitet, så brugere kun får resultater fra data, de må se.
• Mål friskhed, især hvis dokumenter ofte ændres, slettes eller versioneres.

Hvilke fejl går igen i projekter med vektordatabaser?

En almindelig fejl er at behandle vektordatabasen som selve AI-løsningen. Databasen kan gemme og finde embeddings, men den vurderer ikke automatisk, om en kilde er sand, aktuel, tilstrækkelig eller tilladt at bruge. Den tekniske retrieval-kvalitet afhænger af dataarbejdet rundt om databasen.

En anden fejl er at teste med få pæne eksempler. Semantisk søgning kan se imponerende ud i en demo, men produktion kræver test med stavefejl, blandede sprog, korte spørgsmål, tvetydige ord, forældede dokumenter, adgangsbegrænsninger og brugere, der ikke formulerer sig som testteamet.

En tredje fejl er at ignorere opdateringsflowet. Hvis nye dokumenter først embeddes efter flere timer, eller slettede dokumenter bliver i indekset, kan systemet levere forældet indhold. Det er især relevant for organisationer, der bruger vector search sammen med API’er, dokumentarkiver og interne videnssystemer.

Hvordan bør en organisation evaluere en vektordatabase?

Evalueringen bør begynde med brugeropgaven. Skal systemet finde de fem mest relevante supportartikler, foreslå lignende produkter, opdage dubletter, hente dokumentgrundlag til en sprogmodel eller gruppere store tekstmængder? Hver opgave kræver forskellige testdata og succesmål.

Tekniske målinger bør kombineres med kvalitative vurderinger. Recall, latency, indeksstørrelse, pris og oppetid er vigtige, men de siger ikke alene, om resultaterne hjælper brugeren. En god test samler realistiske spørgsmål, forventede kilder og vurdering af, om svaret kunne bruges uden at vildlede.

Drift bør også indgå tidligt. Spørg hvordan systemet håndterer genindeksering, backup, eksport, adgangslogning, versionsskift af embedding-model og skift mellem databaser. Hvis embedding-modellen udskiftes, kan gamle og nye embeddings ikke altid sammenlignes direkte. Det kan kræve fuld re-embedding eller separat håndtering af versioner.

Hvilke kilder ligger til grund?

Definitionen af embeddings og brugen af vektordatabaser til hurtig genfinding er kontrolleret mod OpenAIs dokumentation om embeddings. Afvejningen mellem exact og approximate search, afstandsmål, HNSW, IVFFlat og filtrering er kontrolleret mod pgvector-dokumentationen.

Den tekniske forklaring af HNSW bygger på Malkov og Yashunins paper om Hierarchical Navigable Small World graphs. Perspektivet på similarity search i store vektorsamlinger bygger også på Johnson, Douze og Jégous FAISS-paper om billion-scale similarity search.