Hvad er en vektordatabase?
En vektordatabase er en database der søger på lighed i betydning i stedet for på præcise ord. Den lagrer embeddings, altså tekst omdannet til vektorer, og finder hurtigt dem der ligger tættest på et spørgsmål. Derfor er den omdrejningspunktet i RAG-løsninger. Nogle gange er en vektorudvidelse til den Postgres I allerede har, dog nok.
En vektordatabase er en database bygget til en bestemt opgave: at søge på lighed i betydning i stedet for på præcise ord. Det gør den til omdrejningspunktet i de fleste RAG-løsninger, hvor en AI skal svare ud fra jeres egne dokumenter. Men det betyder ikke at alle skal anskaffe en. Ofte er det man allerede har, nok. Her er hvad den gør og hvornår der er brug for den.
Søgning på betydning, ikke på præcise ord
For at forstå en vektordatabase hjælper det først at forstå hvad den lagrer: embeddings. En embedding er en tekst omdannet til en liste af tal, en vektor, hvor tekster med lignende betydning får vektorer der ligger tæt på hinanden. En vektordatabase er specialiseret i at lagre sådanne vektorer og lynhurtigt finde dem der ligger tættest på et givet spørgsmål.
Resultatet er søgning på indhold. Spørger I efter noget om “regninger”, kan databasen finde et dokument der handler om “fakturaer” fordi deres vektorer ligger tæt på hinanden i betydning. Søgningen handler altså om hvad teksten betyder, ikke om hvilke bogstaver den tilfældigvis indeholder.
Forskellen fra en almindelig databasesøgning
Den tydeligste måde at forstå værdien på er at holde den op mod en almindelig database. En traditionel database er bygget til præcision: Du spørger efter et kundenummer, en dato eller et præcist ord, og den returnerer de rækker der matcher nøjagtigt. Det er perfekt når du ved præcis hvad du leder efter.
Men det slår ikke til når spørgsmålet handler om betydning. Et konkret eksempel: En bruger søger på “hvordan opsiger jeg mit abonnement”. En almindelig søgning overser et hjælpedokument med overskriften “afslut din aftale” fordi ingen ord matcher. En vektordatabase forstår at formuleringerne betyder det samme og finder det rette dokument alligevel. Den ene svarer på “hvor står præcis det her?”, den anden på “hvad ligner det her?”.
Derfor er den omdrejningspunktet i RAG
RAG, retrieval-augmented generation, bygger på et enkelt princip: Før sprogmodellen svarer, hentes de dokumenter der er relevante for spørgsmålet, og svaret bygger dermed på rigtig tekst i stedet for på modellens hukommelse. Det afgørende trin er at finde de rette dokumenter, og det er netop hvad en vektordatabase gør.
Den rummer embeddings for alle jeres dokumenter og finder til hvert spørgsmål de mest relevante afsnit frem, hurtigt, også når materialet er stort. Uden effektiv lighedssøgning ville det trin blive en flaskehals. Derfor er vektordatabasen sjældent den hovedrolle man taler om, men næsten altid den der gør en RAG-løsning brugbar i praksis.
Når den eksisterende Postgres er nok
Her er det sundt at holde igen: Ikke alle har brug for en specialiseret vektordatabase. Til mindre datamængder er det ofte rigeligt at tilføje vektorunderstøttelse til en database I allerede har i drift.
Det mest almindelige eksempel er pgvector, en udvidelse der giver PostgreSQL evnen til at lagre og søge i vektorer. Kører I allerede Postgres, kan I ofte begynde der uden ny infrastruktur at drive og vedligeholde. Andre alternativer, som Pinecone eller Qdrant, er dedikerede løsninger som først bliver berettigede når datamængden og kravene til søgehastighed vokser sig store.
Rådet er at begynde med det I har og opgradere når behovet faktisk opstår, ikke før. En ekstra database er også noget der skal driftes, overvåges og betales for.
Hvad valget egentlig afhænger af
Når spørgsmålet om en dedikeret vektordatabase først bliver aktuelt, er der nogle ting der afgør det. Datamængden er den tydeligste: En håndfuld dokumenter stiller ingen krav, men millioner af tekststykker gør at søgehastigheden begynder at spille en rolle. Kravene til svartid er en anden. Skal søgningen føles øjeblikkelig for en bruger i realtid, stilles der højere krav end hvis den kører i baggrunden.
Endelig vejer jeres eksisterende infrastruktur tungt. Kører I allerede Postgres, er tærsklen for pgvector lav. En helt cloudbaseret stack passer måske bedre med en administreret tjeneste. Pointen er at lade behovet styre: Vælg efter datamængde, krav til ydeevne og hvad I allerede har i drift, i stedet for automatisk at gribe efter den mest specialiserede løsning. Vil I have hjælp til at afgøre hvad der er nok til netop jeres løsning, kan I læse mere om vores arbejde med AI eller kontakte os.
Ofte stillede spørgsmål
Hvad gør en vektordatabase, helt enkelt?
Den lagrer tekst der er omdannet til vektorer, embeddings, og leder derefter efter de vektorer der ligger tættest på et givet spørgsmål. I praksis betyder det at den søger på betydning: Den finder det der indholdsmæssigt ligner spørgsmålet, også når ordene ikke er præcis de samme. Det er et helt andet søgeprincip end i en almindelig database.
Hvordan adskiller den sig fra en almindelig database?
En almindelig database leder efter præcise værdier eller ordmatch, altså rækker der svarer nøjagtigt til det du spørger efter. En vektordatabase leder efter lighed i betydning og rangordner resultaterne efter hvor tæt de ligger på spørgsmålet. Den svarer altså på "hvad ligner det her?" i stedet for "hvor står præcis det her?".
Hvorfor er vektordatabasen omdrejningspunktet i RAG?
Fordi RAG bygger på at finde de rette dokumenter at give sprogmodellen før den svarer, og det er netop hvad en vektordatabase er bygget til. Den rummer embeddings for alle jeres dokumenter og finder hurtigt de mest relevante frem til hvert spørgsmål. Uden effektiv lighedssøgning ville RAG blive langsom og upålidelig.
Skal vi anskaffe en særskilt vektordatabase?
Ikke altid. Til mindre datamængder er det ofte nok at tilføje en vektorudvidelse til en database I allerede har, f.eks. pgvector i Postgres. Først når mængderne og kravene til søgehastighed vokser, bliver en dedikeret løsning berettiget. Begynd med det I har, og opgradér når behovet er bevist, ikke før.
Hvilke alternativer findes der?
Nogle almindelige navne er pgvector, der giver Postgres vektorsøgning, samt dedikerede tjenester som Pinecone og Qdrant. Hvad der passer, afhænger af datamængde, krav til ydeevne og hvordan jeres øvrige infrastruktur ser ud. Pointen er at vælge efter behov i stedet for automatisk at gribe efter den mest specialiserede løsning.