Hva er en vektordatabase?

En vektordatabase svarer på ett spørsmål, veldig raskt

Gi den en tallrekke, og den returnerer de lagrede rekkene som ligger nærmest den. Det er hele grensesnittet.

Tallrekkene er embeddings. En embedding-modell gjør om et avsnitt, en produktbeskrivelse eller et bilde til noen hundre til noen tusen tall, plassert slik at lignende betydninger havner nær hverandre, og hva er embeddings i AI forklarer hvordan. En vektordatabase er der disse rekkene lever når du har mange av dem. Den lagrer hver med en ID og noe metadata, bygger en indeks over dem, og svarer på nærmeste nabo-søk: "her er en spørrevektor, gi meg de ti nærmeste."

Den vanskelige delen er ordet raskt. Å sammenligne et spørsmål mot en million lagrede vektorer på 1536 tall hver er 1,5 milliarder multiplikasjoner, og å gjøre det på hvert tastetrykk skalerer ikke. Derfor bruker vektordatabaser tilnærmede nærmeste nabo-indekser, der den vanligste er HNSW, en grafstruktur fra en artikkel fra 2016 av Malkov og Yashunin som besøker noen hundre kandidater i stedet for hele millionen og gir riktig svar nesten hver gang. Det "nesten" er byttehandelen: litt tapt presisjon mot en tusenfoldig hastighetsøkning.

Den eksisterende databasen din matcher ord, en vektordatabase matcher mening

En relasjonsdatabase finner rader hvis verdier matcher: WHERE customer_id = 4127. En fulltekstindeks finner dokumenter som inneholder ord: refund AND policy. En vektordatabase finner elementer hvis mening ligger nær: spørsmålet "hvordan får jeg pengene tilbake" returnerer avsnittet med tittelen "Retur og refusjon", selv om de to ikke deler et eneste ord.

Den siste raden viser hvor uklar kategorien er. pgvector legger til vektorkolonner og en HNSW-indeks i vanlig Postgres, og Elasticsearch har hatt et vektorfelt siden versjon 7.0 i 2019 og HNSW-søk siden 8.0 i 2022. En "vektordatabase" er ofte en funksjon inni en database du allerede kjører, snarere enn et nytt produkt, og de frittstående produktene konkurrerer på skala og driftsmodenhet, ikke på å gjøre noe Postgres ikke kan.

Chat-med-dine-dokumenter er et vektorsøk med en modell på enden

Retrieval-augmented generation, som hva er RAG går gjennom, har et søkesteg og et skrivesteg. Vektordatabasen er søkesteget.

1. Del hvert dokument inn i avsnitt på noen hundre til tusen tokens.
2. Embed hvert avsnitt og lagre vektorene, sammen med avsnittsteksten og kilden, i vektordatabasen.
3. Når et spørsmål kommer inn, embed det og be databasen om de nærmeste avsnittene.
4. Gi disse avsnittene til språkmodellen sammen med spørsmålet, og la den skrive svaret.

Steg 1 og 2 skjer én gang, når dokumentene legges til. Steg 3 og 4 skjer for hvert spørsmål. Språkmodellen ser aldri hele samlingen; den ser de fem eller ti avsnittene databasen valgte. Derfor er svaret bare så godt som søket: hvis nærmeste vektor er feil avsnitt, svarer modellen selvsikkert på feil spørsmål, noe hva er en AI-hallusinasjon klassifiserer som en søkefeil snarere enn en oppdiktning.

Når du trenger en, og når det er bedre å sende hele filen

Avgjørelsen handler om størrelse. En modell kan bare vurdere sitt kontekstvindu om gangen, og hvert token inni det betales for på hver runde. En vektordatabase finnes for å legge kun den relevante biten foran modellen. For ett dokument som får plass, er henting et steg du kan hoppe over; for en samling som ikke gjør det, er det eneste alternativet.

Prissett de to designene på en rapport på 300 000 tokens, flere hundre sider, med ti spørsmål, som henter fem avsnitt på 1000 tokens per spørsmål. Å sende hele filen hver gang er 3 millioner input-tokens. Å hente fem avsnitt på 1000 tokens per spørsmål er 50 000. Med listeprisene for input i AI-modellkostnadsindeksen, hentet fra OpenRouter 2026-08-20, er forskjellen 60x på alle modeller. Prompt-caching, der leverandøren tilbyr det, fakturerer en gjenlesning av samme fil til en tidel til en halvpart av listeprisen, som snevrer inn forskjellen til rundt 6x til 30x. Henting vinner fortsatt, med mindre margin.

Design med hele filen gir noe for de pengene når filen får plass innenfor budsjettet: en kontrakt på 60 sider, om lag 40 000 tokens, lar modellen svare på spørsmål som krever hele dokumentet samtidig, som "strider noe her mot klausul 14", noe henting ikke kan spørre om fordi den aldri ser klausul 14 og motsigelsen i samme batch. Regelen som følger av dette: ett dokument, eller en håndfull, går inn i sin helhet; et bibliotek går gjennom en vektordatabase. Mellom de to, del opp opplastingen etter tema slik at modellen får den delen den trenger.

Whizi sender selve teksten, opptil en 40 000-token runde

Whizi kjører ikke en vektordatabase for chatten din. Når du legger ved en fil, trekker dokumentopplasting ut teksten og sender den til modellen som prompt-tekst, opptil et flatt budsjett på 40 000 tokens per runde; en lengre opplasting kuttes, med en varsling og en markør i meldingen som sier det. Prosjektfiler fungerer på samme måte: prosjekter-funksjonen fester opptil 10 filer og bygger teksten deres inn i prompten på hver melding, med et tak på 32 000 tegn per fil og 120 000 for hele prosjektblokken.

Takene er grensen for designet. En festet fil over 32 000 tegn blir avkortet, et vedlegg over budsjettet på 40 000 tokens per runde blir kuttet, og et prosjekt er en mappe, ikke et søkbart bibliotek. Byttehandelen er bevisst: for en kontrakt eller et papir som får plass innenfor rundebudsjettet, er det bedre å ha teksten til stede enn å ha den søkt gjennom, og testen som betyr noe, å be modellen sitere avsnittet den brukte, fungerer fordi avsnittet er der. For tusen dokumenter er en vektordatabase riktig verktøy, og en chat-app er feil.

To vaner følger av mekanismen. Nevn filnavnet i spørsmålet ditt når flere er lagt ved, fordi modellen ellers velger stille selv. Og på et hvilket som helst svar du vil handle etter, be om sitatet. Et hentesystem kan returnere feil avsnitt; et system med hele filen kan svare fra hukommelsen i stedet for filen. Sitatet fanger opp begge.