Vad är en vektordatabas?

En vektordatabas är en databas byggd för en särskild uppgift: att söka på likhet i betydelse i stället för på exakta ord. Det gör den till navet i de flesta RAG-lösningar, där en AI ska svara utifrån era egna dokument. Men det betyder inte att alla behöver skaffa en – ofta räcker det man redan har. Här är vad den gör och när den behövs.

Sökning på betydelse, inte exakta ord

För att förstå en vektordatabas hjälper det att först förstå vad den lagrar: embeddings. En embedding är en text omvandlad till en lista med siffror, en vektor, där texter med liknande betydelse får vektorer som ligger nära varandra. En vektordatabas är specialiserad på att lagra sådana vektorer och blixtsnabbt hitta de som ligger närmast en given fråga.

Resultatet är sökning på innebörd. Frågar ni efter något om “räkningar” kan databasen plocka fram ett dokument som handlar om “fakturor”, eftersom deras vektorer ligger nära varandra i betydelse. Sökningen handlar alltså om vad texten betyder, inte om vilka bokstäver den råkar innehålla.

Skillnaden mot en vanlig databassökning

Det tydligaste sättet att förstå värdet är att ställa det mot en vanlig databas. En traditionell databas är byggd för exakthet: du frågar efter ett kundnummer, ett datum eller ett exakt ord, och den returnerar raderna som matchar precis. Det är perfekt när du vet exakt vad du letar efter.

Men det brister när frågan handlar om betydelse. Ett konkret exempel: en användare söker “hur säger jag upp mitt abonnemang”. En vanlig sökning missar ett hjälpdokument med rubriken “avsluta ditt avtal”, eftersom inga ord matchar. En vektordatabas förstår att fraserna betyder samma sak och hittar rätt dokument ändå. Den ena svarar på “var finns exakt det här?”, den andra på “vad liknar det här?”.

Därför är den navet i RAG

RAG, retrieval-augmented generation, bygger på ett enkelt upplägg: innan språkmodellen svarar hämtas de dokument som är relevanta för frågan, så att svaret grundas i verklig text i stället för i modellens minne. Det avgörande steget är att hitta rätt dokument – och det är precis vad en vektordatabas gör.

Den håller embeddings för alla era dokument och plockar för varje fråga fram de mest relevanta styckena, snabbt, även när materialet är stort. Utan effektiv likhetssökning skulle det steget bli en flaskhals. Därför är vektordatabasen sällan huvudrollen man pratar om, men nästan alltid den som gör en RAG-lösning praktiskt användbar.

När den befintliga Postgres räcker

Här är en nyttig återhållsamhet: alla behöver inte en specialiserad vektordatabas. För mindre datamängder räcker det ofta gott att lägga till vektorstöd i en databas ni redan driver.

Det vanligaste exemplet är pgvector, ett tillägg som ger PostgreSQL förmågan att lagra och söka vektorer. Kör ni redan Postgres kan ni ofta börja där, utan ny infrastruktur att förvalta. Andra alternativ, som Pinecone eller Qdrant, är dedikerade lösningar som blir motiverade först när datamängden och kraven på söksnabbhet växer sig stora.

Rådet är att börja i det ni har och byta upp er när behovet faktiskt uppstår, inte innan. En extra databas är också något som ska driftas, övervakas och betalas för.

Vad valet egentligen beror på

När frågan om en dedikerad vektordatabas väl blir aktuell är det några saker som avgör. Datamängden är den tydligaste: en handfull dokument ställer inga krav, men miljontals textstycken gör att söksnabbheten börjar spela roll. Kraven på svarstid är en annan – ska sökningen kännas direkt för en användare i realtid ställs högre krav än om den körs i bakgrunden.

Slutligen väger er befintliga infrastruktur tungt. Kör ni redan Postgres är tröskeln för pgvector låg, medan en helt molnbaserad stack kanske passar bättre med en hanterad tjänst. Poängen är att låta behovet styra: välj efter datamängd, prestandakrav och vad ni redan driftar, snarare än att automatiskt nå efter den mest specialiserade lösningen. Vill ni ha hjälp att avgöra vad som räcker för just er lösning, läs mer om vårt arbete med AI eller hör av dig.