← terug

10 juni 2026

Embeddings en vector databases: de kopie van je bedrijfskennis waar niemand het over heeft

Vraag een organisatie waar hun documenten staan en je krijgt een redelijk antwoord. SharePoint, een DMS, een netwerkschijf, een dossiersysteem. Vraag vervolgens waar hun embeddings staan en het wordt meestal stil. Terwijl die embeddings, zodra je een AI-assistent op je eigen kennis hebt aangesloten, een tweede kopie van diezelfde kennis zijn. In een ander formaat, op een andere plek, vaak buiten elk bestaand beheerproces.

Ik heb eerder uitgelegd hoe RAG werkt: documenten knippen, omzetten naar embeddings, opslaan in een vector database, en bij elke vraag de relevante stukken ophalen. Dat stuk sla ik hier dus over. Deze blog gaat over de twee onderdelen die in elke architectuurtekening als een onschuldig blokje staan getekend: de embedding en de vector database. Wat zijn ze technisch, hoe werkt dat zoeken eigenlijk, en welke vragen moet je stellen voordat je ze in productie zet.

Wat een embedding technisch is

Een embedding is een lange rij getallen. Niet een paar, maar honderden tot duizenden. Een veelgebruikt open-source model als all-MiniLM produceert 384 getallen per stuk tekst, andere modellen zitten op 768, 1024 of 1536, en de grootste varianten gaan richting de drieduizend. Elk van die getallen heet een dimensie.

Het belangrijkste misverstand wil ik meteen wegnemen: een embedding is geen samenvatting. Er staat geen verkorte versie van je tekst in. Het is een plek op een betekeniskaart. Het embedding-model heeft tijdens zijn training geleerd om teksten die over hetzelfde gaan dicht bij elkaar te plaatsen, en teksten die nergens op elkaar lijken ver uit elkaar. "De medewerker wil vrij nemen" en "verlofaanvraag indienen" delen bijna geen woorden, maar landen op die kaart vlak naast elkaar. Dat is precies waarom zoeken op betekenis werkt waar zoeken op trefwoorden faalt.

Wat betekenen die dimensies dan? Eerlijk antwoord: dat weet niemand precies. Het zijn geen nette eigenschappen als "gaat over geld" of "is juridisch". Het zijn richtingen in een wiskundige ruimte die het model zelf heeft gekozen tijdens de training. Je kunt een embedding dus niet lezen zoals je een samenvatting leest. Maar, en dit wordt later belangrijk, dat betekent niet dat er geen informatie in zit. Er zit juist heel veel informatie in. Alleen in een vorm die voor mensen onleesbaar is en voor software prima bruikbaar.

Nog twee technische eigenschappen die in de praktijk veel uitmaken.

Ten eerste: embeddings zijn modelgebonden. De getallen van model A betekenen niets in de kaart van model B. Je vraag en je documenten moeten dus altijd door hetzelfde model. En wil je ooit overstappen op een ander of nieuwer embedding-model, dan moet je al je documenten opnieuw door de molen halen. Bij tien documenten is dat niks. Bij twee miljoen chunks is dat een serieus project met serieuze rekenkosten. Dit is een vorm van lock-in waar bijna niemand vooraf over nadenkt.

Ten tweede: het embedding-model ziet je tekst in platte vorm. Gebruik je een embedding-API van een externe partij, dan stuur je dus elke chunk van elk document in leesbare tekst naar die partij. Niet één keer een testdocumentje, maar je hele kennisbank, chunk voor chunk. Voor publieke handleidingen maakt dat weinig uit. Voor dossiers, contracten en personeelsdocumenten is dat een dataflow die je bewust moet kiezen, niet per ongeluk.

Hoe similarity search werkt

Zoeken in embeddings is afstand meten. Je vraag wordt een punt op de kaart, en het systeem zoekt de documentchunks waarvan de punten het dichtst bij dat vraagpunt liggen. De meest gebruikte maat daarvoor is cosine similarity: die kijkt of twee vectoren dezelfde kant op wijzen. Wijzen ze bijna dezelfde richting uit, dan gaan de teksten over hetzelfde. Score dicht bij 1 is verwant, score richting 0 is ongerelateerd.

Met een paar duizend chunks kun je dat gewoon brute force doen: vergelijk de vraag met alles, sorteer, klaar. Dat is exact en snel genoeg. Het wordt pas interessant bij miljoenen vectoren. Dan is alles vergelijken te traag, en stappen systemen over op approximate nearest neighbor search, kortweg ANN. Een veelgebruikte techniek heet HNSW, een soort gelaagd netwerk van snelkoppelingen door de kaart heen, waarmee je in een fractie van de tijd bij de buurt van het antwoord komt.

Let op dat woord: approximate. Bij benadering. Zo'n index vindt meestal de juiste buren, maar niet gegarandeerd altijd. Je ruilt een beetje volledigheid in voor heel veel snelheid, en die verhouding is instelbaar. Voor een muziekaanbeveling boeit dat niemand. Voor een assistent die antwoorden geeft over medicatiebeleid of contractvoorwaarden wil je weten hoe die afweging staat afgesteld, en wil je meten hoe vaak het juiste fragment daadwerkelijk bovenkomt. Een systeem dat 95 procent van de tijd het juiste stuk vindt klinkt goed, totdat je beseft dat één op de twintig vragen op het verkeerde fundament wordt beantwoord.

Wat een vector database eigenlijk doet

Een vector database is op het eerste gezicht een opslagplek voor embeddings met een zoekfunctie erbij. Maar het echte werk zit in alles eromheen.

Hij bouwt en onderhoudt de ANN-index, zodat zoeken snel blijft terwijl er data bijkomt en afgaat. Hij bewaart naast elke vector ook de metadata: uit welk document komt deze chunk, welke versie, wanneer toegevoegd, wie mag het zien. Hij kan filteren tijdens het zoeken: geef me de dichtstbijzijnde chunks, maar alleen uit documenten van afdeling X. En de betere systemen combineren betekeniszoeken met klassiek trefwoordzoeken, omdat geen van beide alleen genoeg is.

Qua smaken heb je grofweg drie opties. Je kunt vectorzoeken toevoegen aan een database die je al hebt, bijvoorbeeld met pgvector in PostgreSQL. Je kunt een gespecialiseerde open-source vector database zelf draaien, zoals Qdrant, Weaviate of Milvus. Of je neemt een volledig beheerde clouddienst af. Die laatste optie is het snelst live, en het is ook de optie waarbij je afgeleide bedrijfskennis bij een externe partij neerzet, vaak buiten Europa, onder andermans voorwaarden. Geen van de drie is fout. Maar het is een datalocatiebeslissing, geen techniekkeuze, en zo moet hij ook genomen worden.

Een voorbeeld: het advocatenkantoor

Stel, een advocatenkantoor bouwt een interne assistent op de eigen jurisprudentiedatabase en dossiers. Het team kiest pragmatisch: een Amerikaanse embedding-API, een beheerde vector database in de cloud, demo binnen twee weken, partners enthousiast.

Tel nu even mee waar de dossierkennis staat. Eén: in het dossiersysteem, waar hij hoort, met rechten per zaak. Twee: in leesbare vorm langs de embedding-API gegaan, chunk voor chunk. Drie: als vectoren plus metadata in een beheerde database bij een derde partij. Vier: in de backups en snapshots van die database, want die maakt netjes backups. De rechtenstructuur per zaak uit het dossiersysteem? Die is onderweg verdwenen, want de vector database kent standaard maar één toegangsniveau: wie de API-sleutel heeft, kan alles doorzoeken.

Niemand heeft hier iets fout gedaan in de klassieke zin. Er is geen hack, geen lek, geen kwade wil. Er is alleen een kopie van de meest vertrouwelijke kennis van het kantoor ontstaan op plekken die in geen enkel beleidsdocument staan.

De vier productievragen

Dit brengt me bij de vier vragen die ik elke organisatie zou willen meegeven die embeddings in productie heeft of gaat krijgen.

Waar staan de embeddings, inclusief de route ernaartoe? Niet alleen de eindbestemming telt. De embedding-API ziet je tekst leesbaar voorbijkomen, de vector database slaat de vectoren met metadata op, en backups vermenigvuldigen dat geheel. Teken die hele route uit. Als ergens op die route een partij zit waar je je brondocumenten nooit zou neerzetten, heb je een gesprek te voeren.

Wie kan ze doorzoeken? Veel vector databases werken in de praktijk met één API-sleutel voor de hele collectie. De fijnmazige rechten uit je bronsystemen reizen niet automatisch mee. En er is iets extra wrangs aan de hand: semantisch zoeken maakt gevoelige informatie juist beter vindbaar. Wie vroeger het exacte bestandsnaampje moest kennen, hoeft nu alleen te vragen "wat speelt er rond de reorganisatie". Toegang per gebruiker afdwingen op chunk-niveau, bij elke zoekopdracht, is dus geen luxe maar de kern van het ontwerp.

Wat gebeurt er als het brondocument verdwijnt? Een document verwijderen uit het DMS verwijdert niets uit de vector database. Zonder actieve koppeling blijven de afgeleide chunks gewoon vindbaar en blijft de assistent er antwoorden op baseren. Dat is vervelend bij verouderd beleid, en serieuzer wanneer een document weg moet vanwege een bewaartermijn of een verwijderverzoek onder de AVG. Dit is geen juridisch advies, maar wel een technische realiteit: wie embeddings van persoonsgegevens bewaart, moet ze ook gericht kunnen terugvinden en wissen, en dat geldt ook voor de backups en snapshots eromheen. Bouw die koppeling tussen bron en vectoren vanaf dag één, niet als project achteraf.

Kunnen embeddings zelf gevoelige informatie lekken? Lange tijd was het comfortabele antwoord: nee joh, het zijn maar getallen. Dat antwoord is achterhaald. Onderzoekers van Cornell lieten in 2023 zien dat je uit tekst-embeddings de oorspronkelijke tekst grotendeels kunt reconstrueren: voor korte stukken tekst lukte dat in hun experimenten in de meeste gevallen vrijwel woordelijk, inclusief namen. De methode heet embedding inversion. Je hoeft de details niet te kennen om de conclusie te snappen: behandel een embedding qua vertrouwelijkheid alsof het de brontekst zelf is. Een gestolen vector database is dan geen bak abstracte getallen, maar gewoon een datalek van je documenten.

Het denkmodel

Als je één ding uit deze blog onthoudt, laat het dit zijn: embeddings zijn een kopie van je bedrijfskennis in een ander formaat. Geen metadata, geen bijproduct, geen technische ruis. Een kopie.

Alles wat je voor je brondocumenten geregeld hebt, moet je dus ook voor die kopie regelen:

Niets hiervan is exotisch. Het is hetzelfde huiswerk dat organisaties voor elke database doen. Het wordt alleen vaak overgeslagen omdat de vector database als onderdeel van "de AI" wordt gezien in plaats van als wat hij is: een database met bedrijfsgegevens erin.

De demo is makkelijk. Productie is waar AI serieus wordt. En bij embeddings begint serieus met een simpele vraag aan je eigen team: waar staan ze, en wie kan erbij? Als daar geen vlot antwoord op komt, weet je waar je morgen begint. 

↘︎ ALLE ARTIKELEN