Wat is een vector database?

Een vector database beantwoordt één vraag, heel snel

Geef het een lijst met getallen en het geeft de opgeslagen lijsten terug die daar het dichtst bij liggen. Dat is de hele interface.

De lijsten zijn embeddings. Een embeddingmodel zet een passage, een productomschrijving of een afbeelding om in enkele honderden tot enkele duizenden getallen, zo geplaatst dat vergelijkbare betekenissen dicht bij elkaar terechtkomen, en wat zijn embeddings in AI legt uit hoe dat werkt. Een vector database is waar die lijsten wonen zodra je er veel hebt. Het slaat elke lijst op met een ID en wat metadata, bouwt er een index over en beantwoordt nearest neighbour search: "hier is een queryvector, geef me de tien dichtstbijzijnde."

Het moeilijke deel is het woord snel. Een query vergelijken met een miljoen opgeslagen vectoren van elk 1.536 getallen is 1,5 miljard vermenigvuldigingen, en dat bij elke toetsaanslag doen schaalt niet. Daarom gebruiken vector databases approximate nearest neighbour indexen, waarvan HNSW de bekendste is, een graafstructuur uit een paper van Malkov en Yashunin uit 2016 die enkele honderden kandidaten bezoekt in plaats van het hele miljoen en bijna altijd het juiste antwoord teruggeeft. Dat "bijna" is de ruil: een beetje recall voor een duizendvoudige snelheidswinst.

Je bestaande database matcht woorden; een vector database matcht betekenis

Een relationele database vindt rijen waarvan de waarden matchen: WHERE customer_id = 4127. Een full-text index vindt documenten die woorden bevatten: terugbetaling AND beleid. Een vector database vindt items waarvan de betekenis dicht bij elkaar ligt: de vraag "hoe krijg ik mijn geld terug" geeft de passage getiteld "Retourneren en terugbetalingen" terug, ook al delen de twee geen enkel woord.

De laatste rij laat zien hoe vaag de categorie is. pgvector voegt vectorkolommen en een HNSW-index toe aan gewone Postgres, en Elasticsearch heeft al sinds versie 7.0 in 2019 een vectorveld en sinds 8.0 in 2022 HNSW-zoeken. Een "vector database" is vaak een mogelijkheid binnen een database die je al draait, in plaats van een nieuw product, en de losstaande producten concurreren op schaal en operationele afwerking, niet op iets doen wat Postgres niet kan.

Chatten met je documenten is vector search met een model aan het eind

Retrieval-augmented generation, waar wat is RAG doorheen loopt, heeft een zoekstap en een schrijfstap. De vector database is de zoekstap.

1. Splits elk document op in passages van enkele honderden tot duizend tokens.
2. Embed elke passage en sla de vectoren, samen met de passagetekst en de bron, op in de vector database.
3. Wanneer er een vraag binnenkomt, embed die en vraag de database om de dichtstbijzijnde passages.
4. Geef die passages samen met de vraag aan het taalmodel, en laat het het antwoord schrijven.

Stappen 1 en 2 gebeuren eenmalig, wanneer de documenten worden toegevoegd. Stappen 3 en 4 gebeuren bij elke vraag. Het taalmodel ziet nooit de hele collectie; het ziet de vijf of tien passages die de database heeft gekozen. Daarom is het antwoord alleen zo goed als de zoekopdracht: als de dichtstbijzijnde vector de verkeerde passage is, beantwoordt het model vol vertrouwen de verkeerde vraag, wat wat is een AI-hallucinatie archiveert als een gemiste zoekopdracht in plaats van een verzinsel.

Wanneer je er een nodig hebt, en wanneer het hele bestand versturen beter is

De keuze draait om omvang. Een model kan alleen zijn contextvenster tegelijk overzien, en elk token daarbinnen wordt bij elke beurt betaald. Een vector database bestaat om alleen het relevante stukje voor het model te leggen. Voor één document dat past, is retrieval een stap die je kunt overslaan; voor een collectie die niet past, is het de enige optie.

Prijs de twee ontwerpen door op een rapport van 300.000 tokens, enkele honderden pagina's, waarover tien vragen worden gesteld, met steeds vijf opgehaalde passages van 1.000 tokens per vraag. Het hele bestand elke keer versturen is 3 miljoen inputtokens. Vijf passages van 1.000 tokens per vraag ophalen is 50.000. Tegen de standaard inputtarieven in de AI model cost index, opgehaald bij OpenRouter op 2026-08-20, is het verschil 60x bij elk model. Prompt caching, waar de aanbieder dat aanbiedt, rekent een herlezing van hetzelfde bestand tegen een tiende tot de helft van de standaardprijs, wat het verschil verkleint tot ruwweg 6x tot 30x. Retrieval wint nog steeds, met minder verschil.

Het hele-bestand-ontwerp levert iets op voor dat geld wanneer het bestand binnen het budget past: een contract van 60 pagina's, ongeveer 40.000 tokens, laat het model vragen beantwoorden die het hele document tegelijk nodig hebben, zoals "is er hier iets dat clausule 14 tegenspreekt", wat retrieval niet kan vragen omdat het nooit clausule 14 en de tegenspraak in dezelfde batch ziet. De regel die daaruit volgt: één document, of een handjevol, gaat er heel in; een bibliotheek gaat door een vector database. Splits tussen de twee de upload op naar onderwerp, zodat het model de sectie krijgt die het nodig heeft.

Whizi stuurt de tekst zelf, tot een beurt van 40.000 tokens

Whizi draait geen vector database voor je chat. Wanneer je een bestand toevoegt, haalt het pad voor documenten uploaden de tekst eruit en stuurt die als prompttekst naar het model, tot een vast budget van 40.000 tokens per beurt; een langere upload wordt afgekapt, met een melding en een markering in het bericht die dat aangeeft. Projectbestanden werken op dezelfde manier: de functie projecten speldt tot 10 bestanden vast en bouwt hun tekst bij elk bericht opnieuw op in de prompt, met een maximum van 32.000 tekens per bestand en 120.000 voor het hele projectblok.

De limieten zijn de grens van het ontwerp. Een vastgespeld bestand voorbij 32.000 tekens wordt afgekapt, een bijlage voorbij het budget van 40.000 tokens per beurt wordt afgekapt, en een project is een map, geen doorzoekbare bibliotheek. De ruil is bewust: voor een contract of paper dat binnen het beurtbudget past, is de tekst aanwezig hebben beter dan hem doorzocht hebben, en de check die ertoe doet, het model vragen de passage te citeren die het gebruikte, werkt omdat de passage er is. Voor duizend documenten is een vector database het juiste gereedschap en een chatapp het verkeerde.

Twee gewoontes vloeien voort uit dit mechanisme. Noem het bestand in je vraag zodra er meerdere zijn toegevoegd, want anders kiest het model stilzwijgend. En vraag bij elk antwoord waarop je gaat handelen om het citaat. Een retrievalsysteem kan de verkeerde passage teruggeven; een hele-bestand-systeem kan uit het geheugen antwoorden in plaats van uit het bestand. Het citaat vangt beide op.