Wat is een vector-database? Opslag die tekst als getallenreeksen bewaart zodat je op betekenis kunt zoeken. De basis onder RAG en semantisch zoeken.
Een vector-database bewaart tekst in de vorm van getallenreeksen die de betekenis ervan vastleggen, en kan daardoor zoeken op gelijkenis in plaats van op letterlijke woorden. Vraag naar 'opzeggen' en hij vindt ook de alinea over 'beëindiging van het contract'. Zo'n zoeklaag is de basis onder RAG-toepassingen: zonder opzoeken op betekenis blijft een taalmodel aangewezen op zijn eigen geheugen.
In een gewone database zoek je op waarde: een klantnummer, een datum, een woord dat exact voorkomt. Een vector-database doet iets anders. Elk stuk tekst wordt bij opslag omgezet in een lange reeks getallen (een embedding) die het onderwerp en de betekenis codeert. Tekst over hetzelfde onderwerp levert reeksen op die dicht bij elkaar liggen, ook als de woorden verschillen. Zoeken betekent dan: de reeksen vinden die het dichtst bij de vraag staan.
Dat gaat niet zonder voorwerk. Documenten moeten eerst zinvol geknipt worden in stukken, elk stuk krijgt zijn vector, en bij elke wijziging moet dat opnieuw. De opslag bewaart daarom meestal twee dingen naast elkaar: de vector voor het zoeken en het originele tekststuk, zodat wat er teruggegeven wordt leesbaar en citeerbaar is. Zonder die originele stukken heeft een gevonden 'gelijkende tekst' weinig waarde voor het model dat ermee moet antwoorden.
Belangrijk om te weten: een vector-database is een techniek, geen product dat je per se hoeft te kopen. Voor kleinere verzamelingen documenten volstaat vaak een kolom met vectoren in de database die je al hebt. De echte keuze is niet merk maar schaal: hoeveel tekst, hoe vaak wijzigt die, en hoe snel moeten zoekresultaten erbij zijn.
De moeite waard is hij zodra je zoekt op betekenis in een verzameling die te groot is om steeds volledig mee te sturen: een kennisbank met honderden documenten, een archief aan tickets, productinformatie in meerdere talen. Ook als gebruikers hun vraag niet in de exacte woorden van het document stellen, wint hij van letterlijk zoeken. Dat is precies het verschil dat het nodig maakt.
Niet nodig is hij bij gestructureerde gegevens die al netjes in kolommen staan: een factuuroverzicht zoek je met een gewone query, niet op gelijkenis. En voor een handjevol documenten is het bouwwerk overbodig. Die stuur je gewoon mee. De valkuil is om technologie te kiezen voor de schaal die je zou kúnnen krijgen; begin bij de verzameling die er nu is.
We bepalen eerst welke documenten mee mogen doen en hoe ze geknipt worden. Dat bepaalt meer dan de keuze van de opslag zelf. Dan volgt de zoeklaag, vaak gewoon in de bestaande database van het project, met de originele stukken ernaast zodat elk antwoord een bron kan noemen. Rechten reizen mee: wie geen toegang heeft tot een dossier, ziet ook geen stukken ervan terug in antwoorden. Bij oplevering hoort een uitleg bij de knip- en zoekkeuzes, zodat je die later kunt bijstellen.
Vaak volstaat je huidige systeem. Moderne relationele databases kunnen vectoren als kolom opslaan en zoeken op gelijkenis, en voor een verzameling van enkele duizenden stukken is dat meestal ruim voldoende. Een aparte gespecialiseerde opslag wordt interessant bij veel data, hoge snelheidseisen of frequente updates. We kiezen die bewust pas in de discovery, als de omvang en het zoekgedrag bekend zijn. Niet omdat een merk opduikt in een presentatie.
Kunnen, ja: een vector is een getallenweergave van tekst die een naam of adres bevat, en die tekst blijft er doorgaans naast staan. Behandel de zoeklaag daarom precies zo als het origineel: dezelfde rechten, dezelfde bewaartermijnen, dezelfde opschoning. Een vector-omzetting is geen anonimisering. Wat er in welke laag staat en wie erbij kan, leggen we per project vast voordat er één document wordt ingeladen.
Een wijziging in een document verandert niets aan de reeds opgeslagen stukken. Die staan er nog in de oude vorm. Daarom hoort bij elke zoeklaag een proces dat aanpassingen verwerkt: het document opnieuw knippen, nieuwe vectoren maken en de oude vervangen. Zonder dat proces antwoordt een toepassing trouw op verouderde tekst, en dat is het gevaarlijkste soort fout omdat het plausibel blijft. Dit is onderhoudswerk, geen eenmalige opzet.
De opslag zelf is bijna nooit de duurste post; het voorwerk is dat. Welke documenten mogen mee, hoe worden ze geknipt, wie mag ze zien en hoe blijven ze actueel. Dat bepaalt de omvang van de bouw. We maken zo'n schatting per situatie en offreren op nacalculatie, met een heldere offerte vóór de bouw. Meestal beginnen we met één bron, zodat je eerst ziet of het zoeken beter wordt voordat het hele archief eraan gaat.
EIGHTY8