Je zoekt naar “hoe annuleer ik mijn abonnement” en AI-assistent Claude geeft je netjes stappen om je wachtwoord te veranderen. Je probeert het opnieuw. Dezelfde antwoord. Dan begin je te twijfelen: zit het aan mij, of aan hem?
Het zit aan de technologie onder de motorkap. Niet aan Claude zelf, maar aan hoe het zoeksysteem dat hem voert met documenten omgaat. Dat heet vector search. En vector search—het snelste zoekmechanisme voor AI-assistenten — is goed in veel dingen, maar heel slecht in dit éne: het onderscheid tussen twee concepten die klinken als dezelfde zaak, maar niet zijn.
Hoe vector search eigenlijk werkt
Als je ChatGPT of Claude een vraag stelt waarvoor het eerst in je bedrijfsdocumenten moet graven, dan gebeurt dit: je vraag wordt omgezet in getallen. Tientallen getallen. Die getallen vormen samen een “vector”—een pijl in een digitale ruimte die jouw vraag betekenis-getrouw weergeeft (Bron: Weaviate).
Tegelijk liggen al je bedrijfsdocumenten ook als getallen-rijen opgeslagen in dezelfde digitale ruimte. “Annulering-procedures”, “wachtwoord-reset”, “account-verwijdering”—allemaal kleine pijltjes, allemaal op een andere plaats.
Nu zoekt het systeem: “Welke opgeslagen document-pijl ligt het dichtst bij mijn vraag-pijl?” Het algoritme checkt niet elk document één voor één. In plaats daarvan gebruikt het slimme routering—het springt via vooraf gemaakte verbindingen naar waarschijnlijke kandidaten. Dit algoritme heet HNSW: Hierarchical Navigable Small World (Bron: Pinecone).
Het probleem zit hierin: “dichtst bij” betekent hier “gelijkaardige getallen”, niet “dezelfde zaak”.
Waarom de getallen liegen
Twee concepten kunnen dezelfde structuur hebben zonder dezelfde zaak te zijn. “Hoe reset ik mijn wachtwoord” en “Hoe annuleer ik mijn abonnement” gebruiken beide hetzelfde taal-patroon: hulpwerkwoord + onderwerp + bezitsspronomen + selfstandige naamwoord. Ze delen trefwoorden: “reset”, “mijn”, “account”.
Een embedding-model—het systeem dat woorden en zinnen in getallen omzet—ziet deze structuur en denkt: “Dit zijn gelijkaardige dingen.” Ze eindigen dicht bij elkaar in de digitale ruimte.
Maar ze zijn niet gelijkaardige dingen. Annulering is het tegengestelde van accountbeheer; wachtwoord-reset is onderhoud. Het model kent het verschil niet, omdat het alleen op semantische gelijkenissen let, niet op samenhang.
Dit heet context mismatch (Bron: VisionWrights). Het systeem vindt twee dokumhenten die oppervlakkig gelijkaardige betekenis hebben, maar in totaal verschillende doelen dienen.
Beginner-tip:Embeddings zijn niet hetzelfde als intelligentie. Een embedding is een gecomprimeerde foto van taalpatronen. Het model heeft geen denkproces, geen logica—alleen wiskundige gelijkenissen.
Drie dingen die fout kunnen gaan
Het model zelf is middelmatig. Niet alle embedding-modellen zijn even goed. Sommige vatten betekenis goed samen; anderen missen nuances of maken vreemde verbanden. OpenAI’s embedding-model is goed; minder bekende modellen kunnen slordig zijn. (Bron: Meilisearch)
De data is rommelig. Als je ruwe HTML, ongeformatteerde PDF’s of mengselmatten van formaten in het systeem stopt, krijgt het model rommel in en spuwt rommel uit. Veel bedrijven stoppen gewoon alles in hun vector-database zonder schoonmaak.
Het indexing-algoritme is verkeerd afgesteld. HNSW is snel, maar het kan ook hoeken snijden. Als je het algoritme niet goed aanstelt (te veel “snelle routes”, te weinig “herhaald zoeken”), vind het eerder een snel antwoord dan het goede antwoord.
Bij elkaar: een slecht model, slechte data en slechte indexing = slechte zoekresultaten.
Het HNSW-algoritme: slim, maar niet altijd goed
HNSW is geen magie. Stel je een berg voor met miljoenen paadjes die erover heen gaan. HNSW zegt: “In plaats van elke route te proberen, pak ik de ‘snelle paden’ die naar waarschijnlijke pieken leiden.”
Het algoritme werkt in lagen. Bovenin: een kleine berg met weinig paadjes, maar lange sprongen. Onderaan: een dichtbegroeid woud met korte stappen tussen veel palen. Je vraag start bovenin, hopst via lange paden naar waarschijnlijke regio’s, en dan zoeken in het woud er gedetailleerd.
Dit is snel. Voor miljoen-document-databases kan dit het verschil zijn tussen 1 seconde en 1 uur.
Maar snelheid heeft een prijs: het garanteert niet dat je de juiste piek bereikt. Je bereikt misschien een dichtbijzijnde piek—maar niet de juiste.
Gevorderden:HNSW-parameters (number-of-neighbours, ef-construction, ef-search) beïnvloeden de balans tussen snelheid en nauwkeurigheid. Meer neighbours = nauwkeuriger, maar trager. Dit is de klassieke precision-recall tradeoff.
Hoe jij dit merkt
Je merkt dit op wanneer je hetzelfde vraagt, net anders gesteld, en ineens het juiste antwoord krijgt. Of wanneer je meer context geeft (“ik wil mijn account permanent deleten, niet alleen inactief maken”) en het werkt.
Waarom? Extra context helpt het model de semantische afstand tussen “annulering” en “wachtwoord-reset” groter te maken. Het verschil wordt voelbaar.
Je merkt het ook op wanneer je met ChatGPT een document uploadt en het antwoorden geeft die nergens in het document staan. Dan heeft vector search het verkeerde stuk gepakt, en ChatGPT heeft dat stuk als waar aangenomen en creatief uitgebreid. Dit heet “hallucination”, maar de eerste fout is de vector-search-fout.
Wat bedrijven eraan doen
Grote bedrijven stoppen nu niet langer alleen op vector search. Ze combineren drie soorten zoeken:
Lexicaal zoeken — zoeken op exacte termen, zoals Google. Traag voor miljoen-datasets, maar onfeillbaar: als de query “annulering” bevat en het document ook “annulering” bevat, dan is het waarschijnlijk relevant.
Vector search — snel, semantisch, maar rommelig.
Attribute-filteren — voor publiceren je antwoorden eerst op attributen (“dit document hoort bij kategorie Abonnementen, niet Beveiligingsfaq”). Dan pas vector search erbinnen.
OpenAI, voor example, adviseerde in hun RAG-best-practices om lexicaal + vector te combineren. Google doet gelijkaardige hybride technieken voor hun Search generative experience.
Het resultaat: langzamer dan puur vector search, maar beter resultaten.
Wat je zelf kunt doen
Als je ChatGPT of Claude met je eigen documenten voert (via plugins, API of RAG-systemen):
Geef meer context. “Dit is mijn refund-policy” helpt beter dan gewoon de tekst uploaden. Extra labels helpen het model kategoriseren.
Controleer indexering. Zijn je documenten schoon? Is de metadata gevuld? Veel AI-assistenten halen slimmere antwoorden uit goed-schone data.
Probeer opnieuw, anders gesteld. Als het antwoord voelt fout, herschrijf je vraag. Het helpt echt.
Combineer bronnen. Als je werkt met ChatGPT/Claude: vraag niet alleen “wat staat in mijn document”, maar “is dit logisch gegeven [extra context]”. Laat het model kritisch denken, niet alleen zoeken.
Vector search is hier om te blijven—het is veel sneller dan alternatieven. Maar het is net een sterke koppelaars: ongelooflijk nuttig, maar niet buiten toezicht te gebruiken.