Vad är en vektordatabas?

En vektordatabas svarar på en fråga, väldigt snabbt

Ge den en lista med siffror och den returnerar de lagrade listor som ligger närmast. Det är hela gränssnittet.

Listorna är embeddings. En embeddingmodell omvandlar ett textavsnitt, en produktbeskrivning eller en bild till några hundra till några tusen siffror, placerade så att liknande betydelser hamnar nära varandra, och vad är embeddings inom AI går igenom hur. En vektordatabas är där de listorna lever när du har många av dem. Den lagrar varje lista med ett ID och lite metadata, bygger ett index över dem och svarar på sökning efter närmaste granne: "här är en frågevektor, ge mig de tio närmaste."

Den svåra delen är ordet snabbt. Att jämföra en fråga mot en miljon lagrade vektorer med 1 536 siffror var är 1,5 miljarder multiplikationer, och att göra det vid varje tangenttryckning skalar inte. Därför använder vektordatabaser approximativa index för närmaste granne, där HNSW är vanligast, en grafstruktur från en artikel från 2016 av Malkov och Yashunin som besöker några hundra kandidater istället för alla en miljon och nästan alltid ger rätt svar. Det "nästan" är avvägningen: lite träffsäkerhet mot en tusenfaldig hastighetsökning.

Din befintliga databas matchar ord; en vektordatabas matchar betydelse

En relationsdatabas hittar rader vars värden matchar: WHERE customer_id = 4127. Ett fulltextindex hittar dokument som innehåller ord: återbetalning AND policy. En vektordatabas hittar objekt vars betydelse ligger nära: frågan "hur får jag tillbaka mina pengar" returnerar avsnittet med titeln "Returer och återbetalningar" trots att de två inte delar ett enda ord.

Den sista raden visar hur suddig kategorin är. pgvector lägger till vektorkolumner och ett HNSW-index i vanliga Postgres, och Elasticsearch har haft ett vektorfält sedan version 7.0 år 2019 och HNSW-sökning sedan 8.0 år 2022. En "vektordatabas" är ofta en förmåga inuti en databas du redan kör, snarare än en ny produkt, och de fristående produkterna konkurrerar om skala och operativ finess, inte om att göra något Postgres inte klarar.

Chatt med dina dokument är en vektorsökning med en modell i slutet

Retrieval-augmented generation, som vad är RAG går igenom, har ett söksteg och ett skrivsteg. Vektordatabasen är sökssteget.

1. Dela upp varje dokument i avsnitt på några hundra till tusen tokens.
2. Embedda varje avsnitt och lagra vektorerna, tillsammans med textavsnittet och dess källa, i vektordatabasen.
3. När en fråga kommer in embeddas den och databasen ombeds hitta de närmaste avsnitten.
4. Ge de avsnitten till språkmodellen tillsammans med frågan och låt den skriva svaret.

Steg 1 och 2 sker en gång, när dokumenten läggs till. Steg 3 och 4 sker vid varje fråga. Språkmodellen ser aldrig hela samlingen, den ser bara de fem eller tio avsnitt som databasen valde ut. Det är därför svaret bara är så bra som sökningen: om den närmaste vektorn är fel avsnitt svarar modellen självsäkert på fel fråga, vilket vad är en AI-hallucination klassar som en missad sökning snarare än ett påhitt.

När du behöver en, och när det är bättre att skicka hela filen

Beslutet handlar om storlek. En modell kan bara ta hänsyn till sitt kontextfönster åt gången, och varje token inuti det betalas för vid varje tur. En vektordatabas finns för att bara lägga fram den relevanta delen framför modellen. För ett enskilt dokument som får plats är sökning ett steg du kan hoppa över; för en samling som inte gör det är det det enda alternativet.

Prissätt de två upplägget på en rapport med 300 000 tokens, flera hundra sidor, som ställs tio frågor, där fem avsnitt på 1 000 tokens hämtas per fråga. Att skicka hela filen varje gång är 3 miljoner indatatokens. Att hämta fem avsnitt på 1 000 tokens per fråga är 50 000. Med listpriserna i AI-modellernas kostnadsindex, hämtade från OpenRouter den 2026-08-20, är skillnaden 60 gånger på varje modell. Promptcachning, där leverantören erbjuder det, fakturerar en omläsning av samma fil till en tiondel till hälften av listpriset, vilket minskar skillnaden till ungefär 6 till 30 gånger. Sökning vinner fortfarande, fast med mindre marginal.

Upplägget med hela filen ger något för pengarna när filen ryms i budgeten: ett kontrakt på 60 sidor, cirka 40 000 tokens, låter modellen svara på frågor som kräver hela dokumentet samtidigt, som "strider något här mot klausul 14", vilket sökning inte kan svara på eftersom den aldrig ser klausul 14 och motsägelsen i samma omgång. Regeln som faller ut: ett dokument, eller en handfull, går in i sin helhet; ett bibliotek går genom en vektordatabas. Mellan de två, dela upp uppladdningen per ämne så att modellen får det avsnitt den behöver.

Whizi skickar texten själv, upp till en tur på 40 000 tokens

Whizi kör ingen vektordatabas för din chatt. När du bifogar en fil extraherar dokumentuppladdning texten och skickar den till modellen som promptext, upp till en fast budget på 40 000 tokens per tur; en längre uppladdning klipps av, med en toast och en markering i meddelandet som säger det. Projektfiler fungerar likadant: projekt låter dig fästa upp till 10 filer och bygger om deras text till prompten vid varje meddelande, med tak på 32 000 tecken per fil och 120 000 för hela projektblocket.

Taken är designens gräns. En fäst fil över 32 000 tecken trunkeras, en bilaga över turens budget på 40 000 tokens klipps av, och ett projekt är en mapp, inte ett sökbart bibliotek. Avvägningen är medveten: för ett kontrakt eller en artikel som får plats i turens budget slår att ha texten närvarande att ha den sökt igenom, och kontrollen som spelar roll, att be modellen citera avsnittet den använde, fungerar eftersom avsnittet finns där. För tusen dokument är en vektordatabas rätt verktyg och en chattapp fel verktyg.

Två vanor följer med från mekanismen. Namnge filen i din fråga när flera är bifogade, för annars väljer modellen tyst själv. Och vid vilket svar du än tänker agera på, be om citatet. Ett sökbaserat system kan returnera fel avsnitt; ett system med hela filen kan svara ur minnet istället för från filen. Citatet fångar båda.