En vektordatabase besvarer ét spørgsmål, meget hurtigt
Giv den en talrække, og den returnerer de gemte talrækker, der ligger tættest på. Det er hele grænsefladen.
Talrækkerne kaldes embeddings. En embedding-model omdanner et afsnit, en produktbeskrivelse eller et billede til et par hundrede til et par tusind tal, placeret så beslægtede betydninger havner tæt på hinanden, og hvad er embeddings i AI gennemgår hvordan. En vektordatabase er der, hvor disse talrækker ligger, når du har mange af dem. Den gemmer hver enkelt med et ID og noget metadata, bygger et indeks over dem og besvarer nærmeste nabo-søgning: "her er en forespørgselsvektor, giv mig de ti tætteste."
Det svære er ordet hurtigt. At sammenligne en forespørgsel med en million gemte vektorer på 1.536 tal hver er 1,5 milliarder multiplikationer, og at gøre det ved hvert tastetryk skalerer ikke. Derfor bruger vektordatabaser tilnærmede nærmeste nabo-indekser, hvor det mest almindelige er HNSW, en grafstruktur fra en artikel fra 2016 af Malkov og Yashunin, der besøger et par hundrede kandidater i stedet for hele millionen og næsten altid returnerer det rigtige svar. Det "næsten" er byttehandlen: lidt recall for en tusindfold hastighedsforøgelse.
Din eksisterende database matcher ord; en vektordatabase matcher betydning
En relationel database finder rækker, hvis værdier matcher: WHERE customer_id = 4127. Et fuldtekstindeks finder dokumenter, der indeholder ord: refund AND policy. En vektordatabase finder elementer, hvis betydning ligger tæt på: forespørgslen "hvordan får jeg mine penge tilbage" returnerer afsnittet med titlen "Retur og refundering", selvom de to ikke deler et eneste ord.
| Relationel database | Fuldtekstsøgning | Vektordatabase | |
|---|---|---|---|
| Spørger | Hvilke rækker matcher denne værdi? | Hvilke dokumenter indeholder disse ord? | Hvilke elementer betyder noget tæt på dette? |
| Indeks | B-tree på kolonner | Omvendt indeks på termer | Graf eller klyngedannelse over vektorer (HNSW, IVF) |
| Præcist? | Ja | Ja | Som regel tilnærmet |
| God til | ID'er, datoer, beløb, joins | Navne, koder, præcise sætninger | Synonymer, omskrivning, sprog på tværs, billeder |
| Dårlig til | Betydning | Betydning | Præcise strenge, optælling, filtrering efter værdi |
| Eksempler | Postgres, MySQL, SQLite | Elasticsearch, Lucene | Pinecone, Weaviate, Qdrant, Milvus, Chroma, pgvector |
Den sidste række viser, hvor udvisket kategorien er. pgvector tilføjer vektorkolonner og et HNSW-indeks til almindelig Postgres, og Elasticsearch har haft et vektorfelt siden version 7.0 i 2019 og HNSW-søgning siden 8.0 i 2022. En "vektordatabase" er ofte en egenskab inde i en database, du allerede kører, snarere end et nyt produkt, og de selvstændige produkter konkurrerer på skala og driftsmæssig finish, ikke på at kunne noget, Postgres ikke kan.
Chat med dine dokumenter er en vektorsøgning med en model i den anden ende
Retrieval-augmented generation, som hvad er RAG gennemgår, har et søgetrin og et skrivetrin. Vektordatabasen er søgetrinnet.
- Del hvert dokument op i afsnit på et par hundrede til tusind tokens.
- Lav embeddings af hvert afsnit, og gem vektorerne sammen med afsnittets tekst og kilde i vektordatabasen.
- Når et spørgsmål kommer ind, laves der en embedding af det, og databasen bliver bedt om de nærmeste afsnit.
- Giv disse afsnit til sprogmodellen sammen med spørgsmålet, og lad den skrive svaret.
Trin 1 og 2 sker én gang, når dokumenterne tilføjes. Trin 3 og 4 sker ved hvert spørgsmål. Sprogmodellen ser aldrig hele samlingen, den ser kun de fem eller ti afsnit, databasen har udvalgt. Derfor er svaret kun så godt som søgningen: hvis den nærmeste vektor er det forkerte afsnit, svarer modellen selvsikkert på det forkerte spørgsmål, hvilket hvad er en AI-hallucination registrerer som en søgefejl snarere end en opfindelse.
Hvornår du har brug for en, og hvornår det er bedre at sende hele filen
Beslutningen handler om størrelse. En model kan kun tage sit context window i betragtning ad gangen, og hver eneste token i det betales for hver runde. En vektordatabase findes for kun at lægge det relevante udsnit foran modellen. For ét dokument, der kan være der, er retrieval et trin, du kan springe over; for en samling, der ikke kan, er det den eneste mulighed.
Prissæt de to design på en rapport på 300.000 tokens, flere hundrede sider, med ti spørgsmål, hvor der hentes fem afsnit på 1.000 tokens pr. spørgsmål. At sende hele filen hver gang er 3 millioner input-tokens. At hente fem afsnit på 1.000 tokens pr. spørgsmål er 50.000. Ved listepriserne for input i AI-modelprisindekset, hentet fra OpenRouter den 2026-08-20, er forskellen 60x på alle modeller. Prompt caching, hvor udbyderen tilbyder det, afregner en genlæsning af den samme fil til en tiendedel til det halve af listeprisen, hvilket indsnævrer forskellen til cirka 6x til 30x. Retrieval vinder stadig, men med mindre margin.
Design med hele filen giver noget for pengene, når filen passer inden for budgettet: en kontrakt på 60 sider, cirka 40.000 tokens, lader modellen besvare spørgsmål, der kræver hele dokumentet på én gang, som "strider noget her mod klausul 14", hvilket retrieval ikke kan spørge om, fordi det aldrig ser klausul 14 og modsigelsen i samme omgang. Reglen, der falder ud af det: ét dokument, eller en håndfuld, går ind i sin helhed; et bibliotek går gennem en vektordatabase. Mellem de to, del uploaden op efter emne, så modellen får det afsnit, den har brug for.
Whizi sender selve teksten, op til 40.000 tokens pr. runde
Whizi kører ikke en vektordatabase til din chat. Når du vedhæfter en fil, udtrækker dokumentupload-forløbet teksten og sender den til modellen som prompt-tekst, op til et fast budget på 40.000 tokens pr. runde; en længere upload bliver klippet af, med en notifikation og en markering i beskeden, der fortæller det. Projektfiler fungerer på samme måde: funktionen projekter fastgør op til 10 filer og genopbygger deres tekst i prompten ved hver besked, med et loft på 32.000 tegn pr. fil og 120.000 for hele projektblokken.
Grænserne er designets yderkant. En fastgjort fil på over 32.000 tegn bliver afkortet, en vedhæftning ud over budgettet på 40.000 tokens pr. runde bliver klippet, og et projekt er en mappe, ikke et søgbart bibliotek. Kompromiset er bevidst: for en kontrakt eller et papir, der passer inden for rundebudgettet, er det bedre at have teksten til stede end at få den søgt, og det tjek, der betyder noget, at bede modellen om at citere det afsnit, den brugte, virker, fordi afsnittet rent faktisk er der. For tusind dokumenter er en vektordatabase det rigtige værktøj, og en chatapp er det forkerte.
To vaner følger af mekanismen. Nævn filens navn i dit spørgsmål, når flere er vedhæftet, for ellers vælger modellen tavst selv. Og ved ethvert svar, du vil handle på, bed om citatet. Et retrieval-system kan returnere det forkerte afsnit; et system med hele filen kan svare fra hukommelsen i stedet for filen. Citatet fanger begge dele.
- Send ét dokument i sin helhed; læg en samling bag en vektordatabase
- Del en lang upload op efter emne, så modellen får det afsnit, spørgsmålet kræver
- Bed modellen om at citere det afsnit, den brugte, før du stoler på svaret
- Brug almindelig tekstsøgning til ID'er, koder og præcise sætninger; vektorsøgning matcher betydning, ikke tegn
- Betragt en søgefejl som et søgeproblem: lav embeddings igen med en bedre model eller mindre afsnit, før du bebrejder skrivemodellen
Ofte stillede spørgsmål
Hvad er en vektordatabase i enkle termer?
Et lager til de talrækker, en AI-model bruger til at repræsentere betydning, bygget til hurtigt at finde de tætteste match. Du giver den embeddingen for et spørgsmål, og den returnerer de embeddings, og teksten bag dem, der betyder noget lignende. Det er søgehalvdelen af chat med dine dokumenter, når samlingen er for stor til at sende i sin helhed.
Har jeg brug for en vektordatabase for at bruge AI med mine dokumenter?
Kun hvis dokumenterne ikke kan være i modellens context window. En enkelt rapport eller kontrakt kan sendes til modellen i sin helhed, hvilket er, hvad Whizi gør med vedhæftninger og fastgjorte projektfiler. Et bibliotek med tusindvis af dokumenter kræver retrieval, og retrieval kræver et vektorindeks, uanset om det er i et dedikeret produkt eller en Postgres-udvidelse som pgvector.
Hvad er forskellen på en vektordatabase og en almindelig database?
En almindelig database matcher værdier: dette ID, denne dato, dette præcise ord. En vektordatabase matcher betydning og returnerer de gemte elementer, hvis embeddings ligger tættest på forespørgslens. Den er som regel tilnærmet og bruger et indeks som HNSW, der tjekker et par hundrede kandidater i stedet for alle elementer, og den er dårlig til den præcise matchning, en almindelig database er god til.
Hvilke vektordatabaser bruges mest?
Pinecone, Weaviate, Qdrant, Milvus og Chroma er de mest almindelige selvstændige produkter, og pgvector tilføjer den samme egenskab til Postgres. Elasticsearch og OpenSearch leveres også med vektorsøgning. Valget er som regel driftsmæssigt, om skala og hosting, fordi de alle sammen implementerer den samme idé om tilnærmet nærmeste nabo.
Hvor meget sparer retrieval sammenlignet med at sende hele filen?
Ti spørgsmål om en rapport på 300.000 tokens koster $6.00 med Claude Sonnet 5, hvis filen sendes ved hver runde, og $0.10, hvis fem afsnit på 1.000 tokens hentes i stedet, ved OpenRouters listepriser hentet 2026-08-20. Med GPT-5.6 Luna er det samme par $0.60 mod $0.01. Forholdet er 60x på alle modeller, fordi begge design betaler den samme pris pr. token.
