Vector Database

NoSQL

Specialiseret database til lagring og hurtig søgning i højdimensionelle vektorer — rygraden i moderne AI-applikationer med embeddings, semantisk søgning og RAG.

Beskrivelse

En vector database gemmer data som numeriske vektorer med hundreder eller tusinder af dimensioner. Vektorerne kommer typisk fra embedding-modeller som OpenAI's text-embedding-3, Cohere eller open source-modeller som sentence-transformers. To vektorer der ligger tæt på hinanden i det højdimensionelle rum, repræsenterer semantisk beslægtet indhold — det er præcis den egenskab der driver moderne AI-søgning. Den fundamentale operation er approximate nearest neighbor (ANN) søgning: givet en query-vektor, find de K nærmeste vektorer i databasen. Klassiske databaser kan ikke det effektivt — en brute force-scan af en million 1536-dimensionelle vektorer tager for lang tid. Vector databases bruger specialiserede indeks som HNSW (Hierarchical Navigable Small World), IVF (Inverted File Index) eller LSH (Locality-Sensitive Hashing) til at reducere søgetiden fra sekunder til millisekunder. HNSW er det mest udbredte indeks i moderne vector databases. Det bygger en graf af vektorer i lag, hvor øverste lag har få noder med lange forbindelser og nederste lag har alle vektorer med korte lokale links. En søgning starter i toppen, hopper hurtigt tæt på target-området og forfiner sig ned gennem lagene. Trade-off er hukommelse — HNSW-indekser bruger typisk 1,5-2x vektorernes rå størrelse. Kendte vector databases inkluderer Pinecone (managed), Weaviate, Qdrant, Milvus og Chroma. Derudover har PostgreSQL nu pgvector-udvidelsen der gør en almindelig relationel database til en brugbar vector store — ofte det rette valg til mindre projekter hvor man ikke vil drifte en ekstra database. Elasticsearch og Redis har også fået vector-support, men er ikke primært designet til det. De drives primært af RAG-arkitekturer (Retrieval-Augmented Generation), hvor en LLM får hentet relevante dokumenter ind i sin kontekst før den svarer. Uden vector search skulle modellen enten prompt-stuffe hele vidensbasen ind eller finetunes — begge dele dyrt og uskalerbart. Ud over RAG bruges vector databases også til anbefalinger, duplikat-detektion, billedsøgning og fraud detection hvor mønstre skal findes i højdimensionelle features. Valget af embedding-model er kritisk og ofte overset. En billig model som text-embedding-3-small giver 1536-dimensionelle vektorer og koster brøkdele af hvad de store modeller gør — men den lider ved domænespecifikt sprog. Til juridiske dokumenter, medicinsk fagsprog eller kode-search kan finetunede embeddings give markant bedre resultater end generic modeller. Et andet vigtigt hensyn er chunking-strategien: dokumenter opdeles i mindre passager før de embeddes, og valget af chunk-størrelse påvirker både relevans og token-omkostninger downstream i LLM-kaldet.

Features

-Approximate nearest neighbor-søgning med HNSW/IVF/LSH-indeks
-Metadata-filtering kombineret med vektor-søgning
-Hybrid search — kombinér vektor og keyword
-Understøttelse af flere distance-metrikker (cosine, euclidean, dot product)
-Batch-indeksering af millioner af vektorer
-Multi-tenancy og namespaces til isolerede datasæt
-Realtidsopdatering af embeddings uden fuld reindeksering

Query Eksempel

// Pinecone Python SDK — typisk RAG-flow
from pinecone import Pinecone
from openai import OpenAI

pc = Pinecone(api_key="your-key")
openai = OpenAI()
index = pc.Index("docs")

// 1. Indeksér dokumenter (kør én gang)
docs = [
    {"id": "doc1", "text": "PostgreSQL bruger MVCC til isolation."},
    {"id": "doc2", "text": "MongoDB gemmer JSON-lignende dokumenter."},
    {"id": "doc3", "text": "Redis er in-memory og bruges til caching."}
]

vectors = []
for doc in docs:
    emb = openai.embeddings.create(
        model="text-embedding-3-small",
        input=doc["text"]
    ).data[0].embedding
    vectors.append({
        "id": doc["id"],
        "values": emb,
        "metadata": {"text": doc["text"]}
    })

index.upsert(vectors=vectors)

// 2. Query — find de 3 mest relevante dokumenter
query = "Hvordan håndterer databaser samtidige transaktioner?"
query_emb = openai.embeddings.create(
    model="text-embedding-3-small",
    input=query
).data[0].embedding

results = index.query(
    vector=query_emb,
    top_k=3,
    include_metadata=True,
    filter={"category": {"$eq": "database"}}
)

for match in results["matches"]:
    print(f"score={match['score']:.3f}  text={match['metadata']['text']}")

// 3. Send konteksten til LLM'en
context = "\n".join([m["metadata"]["text"] for m in results["matches"]])
response = openai.chat.completions.create(
    model="gpt-4",
    messages=[
        {"role": "system", "content": f"Brug denne kontekst: {context}"},
        {"role": "user", "content": query}
    ]
)

// Alternativ: PostgreSQL med pgvector
CREATE EXTENSION vector;
CREATE TABLE docs (id serial, text text, embedding vector(1536));
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);

-- Nearest neighbor query
SELECT text, 1 - (embedding <=> $1) AS similarity
FROM docs
ORDER BY embedding <=> $1
LIMIT 3;

Anvendelsesområder

-RAG-systemer der giver LLM'er adgang til intern viden
-Semantisk søgning i dokumenter, kode eller support-tickets
-Anbefalingssystemer baseret på indholdslighed
-Duplikat- og lighedsdetektion (billeder, tekst, audio)
-Anomaly detection i højdimensionelle features

Fordele

+Millisekund-latenstid på millioner af vektorer
+Skalerer horisontalt til milliarder af embeddings
+Enkel API — de fleste operationer er upsert og query
+Naturlig fit til LLM-workflows
+Metadata-filtering giver præcis kontrol over resultater

Ulemper

-Indekseringsomkostningen er høj — HNSW-parametre skal tunes
-Approximate resultater betyder du kan miste den optimale match
-Højt hukommelsesforbrug fordi vektorer er dense
-Embedding-modellen låser dig fast — skift modellen, reindeksér alt
-Ikke egnet til klassiske relations- eller aggregeringsforespørgsler

Bedst til

→RAG-systemer der augmenterer LLM'er med privat data
→Semantisk søgning hvor keyword-match ikke er nok
→Multi-modal søgning (tekst, billeder, audio i samme rum)
→Anbefalinger baseret på lighed frem for kollaborativ filtrering
→Duplikatdetektion i store dokumentmængder

Ikke anbefalet til

!Klassisk keyword-søgning — brug Elasticsearch eller Meilisearch
!Små datasæt under 10.000 vektorer — brug FAISS in-memory eller pgvector
!Systemer der kræver eksakt match — ANN er per definition approximate
!Applikationer uden embedding-pipeline på plads
!Analytics-workloads med aggregations

Relaterede databaser

PineconeWeaviateQdrantMilvusChroma