Vektordatabase

En vektordatabase kombinerer fire komponenter: varig lagring af vektorer med et ID og en payload af metadata (kildetekst eller reference, ejer, dato, adgangsmærkater), et eller flere indeks til approksimativ nærmeste-nabo-søgning (oftest HNSW, nogle gange IVF-varianter eller diskbaserede grafer som DiskANN), en filtreringsmotor til metadatabetingelser og det sædvanlige databasemaskineri med write-ahead-log, segmenter, replikering og backup. Afstandsfunktionen (cosinus, indre produkt eller euklidisk) ligger fast pr. samling eller indeks og skal passe til, hvordan embedding-modellen er trænet. Vektorkvantisering, hvad enten det er int8-skalar-, produkt- eller binær kvantisering, sænker hukommelsesforbruget, som regel med en genberegning af de øverste kandidater på vektorer i fuld præcision. Dimensioneringen er simpel regning: En million float32-vektorer med 1.024 dimensioner fylder omkring 4,1 GB før indeksoverhead, og en HNSW-graf lægger nabolister oveni.

Markedet spænder fra specialbyggede systemer (Milvus, Qdrant, Weaviate, Pinecone, Chroma og andre) over vektorfunktioner tilføjet generelle motorer (udvidelsen pgvector til PostgreSQL, der fik et HNSW-indeks i version 0.5.0 i august 2023, og k-NN-søgning i Elasticsearch og OpenSearch) til biblioteker som FAISS og hnswlib. Et bibliotek leverer indekset, men ikke persistens, opdateringer, filtrering eller adgangsstyring, og er derfor ikke en database i sig selv. Pan, Wang og Li's oversigt fra 2024 i The VLDB Journal beskriver designrummet. For mange organisationer er det enklere at sikre, tage backup af og styre vektorer i en eksisterende PostgreSQL- eller søgeklynge end at indføre et nyt datalager, mod en vis pris i skala og funktioner.

Filtrering og aktualitet er de svære ingeniørdele. At kombinere en nærmeste-nabo-søgning med selektive betingelser som "dokumenter, denne bruger må læse" risikerer at give for få resultater eller springe relevante over, afhængigt af om filtrene anvendes før, under eller efter gennemløbet af indekset, og motorerne adskiller sig markant på det punkt. Nyskrevne vektorer bliver måske først synlige efter en opdatering af indekset, og sletninger er ofte tombstones, der først fjernes fysisk ved komprimering.

Sikkerhed og databeskyttelse følger af, at lageret rummer en kopi, eller en tæt afledning, af kildeindholdet. OWASP Top 10 for LLM Applications 2025 har LLM08 Vector and Embedding Weaknesses, der dækker uautoriseret adgang og læk mellem lejere, embedding-inversion og forgiftning af de indekserede data. Embeddings er ikke anonyme: Vec2Text (Morris m.fl., 2023) genskabte 92 % af input på 32 tokens præcist. Kontrollerne omfatter at spejle kildesystemernes rettigheder som metadata og håndhæve dem i forespørgselsfilteret med slutbrugerens identitet, aldrig kun i prompten; separate samlinger eller namespaces for lejere med forskelligt tillidsniveau; kryptering og adgangslogning; og efter databeskyttelsesforordningen at tage lageret med i fortegnelsen over behandlingsaktiviteter (art. 30) og sikre, at sletning efter art. 17 når vektorer, payloads, replikaer og backups og ikke kun det oprindelige dokument.