Vector database

Hvad er en vector database?

En vector database er en database bygget til at gemme og søge i vektorer: lister af tal der repræsenterer betydning. Hvor en traditionel database er god til at finde rækker der matcher præcise kriterier (“find alle kunder i København”), er en vector database god til at finde ting der ligner noget (“find dokumenter der handler om det samme som dette spørgsmål”).

Når du bruger en AI-chatbot der kan søge i din virksomheds dokumenter, bruger den sandsynligvis en vector database i baggrunden. Dokumenterne er konverteret til embeddings (vektorer) og gemt i databasen. Når du stiller et spørgsmål, konverteres det også til en vektor, og databasen finder de dokumenter hvis vektorer ligner din mest. På millisekunder, selv blandt millioner af dokumenter.

Hvorfor ikke bare bruge en normal database?

Traditionelle databaser (PostgreSQL, MySQL, MongoDB) er designet til præcis matchning og filtrering. De er gode til “find alle ordrer fra marts” eller “find brugere med email X.” Men de er ikke bygget til lighedsøgning i højdimensionelle rum.

En embedding er typisk en vektor med 768-3.072 dimensioner. At finde de nærmeste naboer i et rum med tusindvis af dimensioner blandt millioner af vektorer kræver specialiserede algoritmer og datastrukturer. En brute-force sammenligning af alle vektorer ville tage sekunder eller minutter. En vector database gør det på millisekunder via smarte indekseringsmetoder.

Hvordan fungerer en vector database?

Indsættelse

1. Du konverterer dine data (dokumenter, produkter, billeder) til embeddings via en embedding-model.
2. Du indsætter embeddings i vector databasen sammen med metadata (titel, kilde, dato, kategori).
3. Databasen indekserer vektorerne for hurtig søgning.

Søgning (query)

1. Du konverterer din søgning til en embedding via den samme embedding-model.
2. Du sender embeddingens vektor til vector databasen.
3. Databasen finder de K nærmeste naboer: de vektorer der ligger tættest på din søgevektor.
4. Resultaterne returneres med afstandsscore og tilhørende metadata.

Indeksering

Det der gør vector databases hurtige er specialiserede indekseringsalgoritmer:

1. HNSW (Hierarchical Navigable Small World). Den mest populære metode. Bygger en grafstruktur der tillader hurtig navigation til de nærmeste naboer. Tænk på det som et netværk af genveje: i stedet for at tjekke alle vektorer, hopper algoritmen via genveje til det rigtige område.
2. IVF (Inverted File Index). Opdeler vektorrummet i klynger. Ved søgning tjekkes kun de nærmeste klynger, ikke alle vektorer.
3. PQ (Product Quantization). Komprimerer vektorer for at reducere hukommelsesforbrug. Hurtigere søgning med en lille præcisionsreduktion.
4. Flat index. Brute-force sammenligning af alle vektorer. 100% præcis men langsom ved mange vektorer. Bruges til små datasæt.

Vector databases i AI-økosystemet

RAG (Retrieval-Augmented Generation)

Den primære use case for vector databases i 2024-2026:

1. Virksomhedens dokumenter chunkes (opdeles i mindre stykker) og konverteres til embeddings.
2. Embeddings gemmes i en vector database.
3. Når en bruger stiller et spørgsmål, konverteres det til en embedding.
4. Vector databasen finder de mest relevante dokumentchunks.
5. Chunks sendes som kontekst til en sprogmodel (Claude, GPT-4) der genererer et svar baseret på dem.

RAG er det der gør det muligt for AI-assistenter at svare på spørgsmål om din virksomheds specifikke data. Uden at modellen er trænet på det.

Semantisk søgning

Søgning baseret på betydning i stedet for nøgleord:

1. En bruger søger “komfortabel stol til hjemmekontor.”
2. Vector databasen finder produkter med embeddings tæt på søge-embeddingens. Inklusiv “ergonomisk kontorstol med lændestøtte” selvom ordene er helt forskellige.

Anbefalingssystemer

1. Brugerens præferencer og adfærd repræsenteres som en vektor.
2. Produkter, artikler eller indhold repræsenteres som vektorer.
3. Vector databasen finder de vektorer der ligner brugerens præference-vektor mest.

Anomali-detektion

1. Normale datapunkter gemmes som vektorer.
2. Nye datapunkter sammenlignes med de eksisterende.
3. Hvis et nyt punkt er langt fra alle eksisterende punkter, er det en anomali: potentielt bedrageri, fejl eller usædvanlig adfærd.

Populære vector databases

Pinecone

1. Type. Fuldt managed cloud-tjeneste. Ingen infrastruktur at administrere.
2. Styrker. Nem at starte, automatisk skalering, lav latency, serverless-option.
3. Bedst til. Teams der vil undgå infrastruktur-overhead og hurtigt komme i gang.
4. Prissætning. Betaling per forbrug. Gratis tier tilgængelig.

Weaviate

1. Type. Open source med managed cloud-option.
2. Styrker. Hybrid søgning (vektor + nøgleord), indbygget embedding-generering, GraphQL API.
3. Bedst til. Teams der vil have fleksibilitet og hybrid søgning.
4. Kører. Self-hosted eller Weaviate Cloud.

Qdrant

1. Type. Open source med managed cloud-option.
2. Styrker. Høj ydeevne, Rust-baseret, avanceret filtrering, payload-indeksering.
3. Bedst til. Produktionssystemer der kræver høj ydeevne og avanceret filtrering.
4. Kører. Self-hosted eller Qdrant Cloud.

Chroma

1. Type. Open source, letvægts.
2. Styrker. Ekstremt nem at starte, kører in-process (ingen separat server), Python-native.
3. Bedst til. Prototyping, små projekter, lokal udvikling.
4. Begrænsning. Mindre egnet til store produktionssystemer.

Milvus

1. Type. Open source med managed option (Zilliz Cloud).
2. Styrker. Ekstrem skalerbarhed, distribueret arkitektur, håndterer milliarder af vektorer.
3. Bedst til. Store virksomheder med massive datamængder.

pgvector

1. Type. PostgreSQL-extension. Open source.
2. Styrker. Tilføjer vektorsøgning til eksisterende PostgreSQL. Ingen ny database at operere.
3. Bedst til. Teams der allerede bruger PostgreSQL og vil undgå endnu en database i stacken.
4. Begrænsning. Lavere ydeevne end dedikerede vector databases ved meget store datamængder.

Hybrid søgning

De bedste resultater opnås ofte ved at kombinere vektorsøgning med traditionel søgning:

1. Vektor-søgning. Finder dokumenter med lignende betydning. God til at forstå intent og kontekst.
2. Nøgleordssøgning (BM25). Finder dokumenter med præcise nøgleord. God til specifikke termer, navne og koder.
3. Hybrid. Kombiner begge og rank resultaterne. Fanger både semantisk relevans og nøgleords-matchning.

Eksempel: en bruger søger “GDPR artikel 17.” Vektorsøgning finder dokumenter om retten til sletning (semantisk match). Nøgleordssøgning finder dokumenter der nævner “artikel 17” eksplicit. Hybrid søgning returnerer begge. Det bedste fra begge verdener.

Chunking: at forberede data

Før data kan gemmes i en vector database, skal det opdeles i passende stykker (chunks):

1. For store chunks. Embeddingens betydning bliver udvandet. Den forsøger at repræsentere for mange koncepter i én vektor.
2. For små chunks. Mangler kontekst. En enkelt sætning uden omgivende tekst kan være meningsløs.
3. Sweet spot. Typisk 200-500 tokens per chunk. Nok kontekst til at være meningsfuldt, lille nok til at embeddingens vektor er fokuseret.
4. Overlap. Chunks bør overlappe lidt (f.eks. 50 tokens) for at sikre at information der spænder over to chunks ikke går tabt.

Vector databases i praksis

Kundesupport-chatbot

1. 5.000 FAQ-artikler og support-dokumenter chunkes og konverteres til embeddings.
2. Embeddings gemmes i Pinecone med metadata (kategori, dato, produkt).
3. Bruger stiller spørgsmål: “Kan jeg returnere en vare efter 30 dage?”
4. Vector databasen finder de 5 mest relevante chunks om returpolitik.
5. Chunks sendes til Claude sammen med brugerens spørgsmål.
6. Claude genererer et specifikt svar baseret på virksomhedens faktiske returpolitik.

Intern vidensbase

1. Virksomhedens interne dokumenter (wikis, policies, mødereferater) indekseres i Weaviate.
2. Medarbejdere søger: “Hvad er vores politik for hjemmearbejde?”
3. Vector databasen finder relevante dokumenter, uanset om de bruger “hjemmearbejde,” “remote work” eller “arbejde hjemmefra.”
4. Resultaterne vises direkte eller bruges som kontekst til en AI-assistent.

E-commerce produktsøgning

1. 100.000 produktbeskrivelser konverteres til embeddings og gemmes i Qdrant.
2. Kunde søger: “noget til at holde mine planter i live mens jeg er på ferie.”
3. Vector databasen finder automatiske vandingssystemer, selv-vandende urtepotter og plant sitters. Selvom ingen af disse produkter indeholder kundens søgeord.

Skalering og ydeevne

1. Millioner af vektorer. De fleste vector databases håndterer dette uden problemer. Søgetid: < 10ms.
2. Milliarder af vektorer. Kræver distribueret arkitektur (Milvus, Qdrant cluster). Søgetid: < 100ms.
3. Hukommelse vs. disk. Vektorer i RAM giver hurtigst søgning. Disk-baseret indeksering er billigere men langsommere.
4. Dimensioner. Flere dimensioner = mere hukommelse og langsommere søgning. 1.536 dimensioner er en god balance.