Waarom geeft een AI-zoekbot het verkeerde antwoord?

Een AI-zoekbot geeft vaak het verkeerde antwoord omdat de zoekstap eronder een tekst ophaalt die op je vraag lijkt, maar over iets anders gaat. Die zoekstap heet vector search: het systeem vergelijkt de betekenis van je vraag met die van opgeslagen documenten, en pakt het document dat er wiskundig het dichtst bij ligt, ook als dat de verkeerde zaak is.

Een voorbeeld. Je vraagt de chatbot van een webwinkel “hoe annuleer ik mijn abonnement?” en krijgt keurig de stappen om je wachtwoord te veranderen. Je probeert het nog eens en krijgt hetzelfde antwoord. Het taalmodel dat het antwoord formuleert, doet daarbij vaak niets fout: het werkt met het verkeerde stuk tekst dat de zoekstap aanleverde.

Update 25 september 2026 Dit artikel is herschreven en gecorrigeerd. Een embedding bestaat uit honderden tot duizenden getallen (niet tientallen), trefwoordzoeken is juist snel en allerminst onfeilbaar, en de overdreven vergelijking “1 seconde tegen 1 uur” is geschrapt. Nieuw zijn bronnen over hybride zoeken van Anthropic en OpenAI.

Hoe vector search werkt

Stel je een AI-assistent een vraag waarvoor hij eerst in documenten moet zoeken (dat heet RAG, zie Wat is RAG?), dan wordt je vraag eerst omgezet in een lange rij getallen: een embedding. Bij moderne modellen zijn dat honderden tot duizenden getallen, die samen een punt vormen in een wiskundige ruimte. Teksten met een vergelijkbare betekenis komen in die ruimte dicht bij elkaar te liggen (Bron: Weaviate).

Alle documenten van het bedrijf zijn vooraf op dezelfde manier omgezet en opgeslagen in een vectordatabase. “Abonnement opzeggen”, “wachtwoord resetten” en “account verwijderen” zijn daar elk een eigen punt.

Vervolgens zoekt het systeem welke opgeslagen punten het dichtst bij het punt van jouw vraag liggen. Bij miljoenen documenten vergelijkt het niet alles één voor één. Het gebruikt een index die via vooraf gelegde verbindingen snel naar kansrijke kandidaten springt. Het bekendste algoritme daarvoor heet HNSW, voluit Hierarchical Navigable Small World (Bron: Pinecone).

Daar zit de kern van het probleem: “dichtst bij” betekent “lijkt het meest op”, en dat is iets anders dan “gaat over dezelfde zaak”.

Waarom de getallen je misleiden

“Hoe reset ik mijn wachtwoord?” en “Hoe annuleer ik mijn abonnement?” zijn op dezelfde manier gebouwd: een vraagwoord, een werkwoord, “ik”, “mijn” en een zelfstandig naamwoord. Ze gaan allebei over je account en staan in dezelfde klantenservicehoek. Een embedding-model, het systeem dat tekst in getallen omzet, kan ze daardoor dicht bij elkaar plaatsen.

Voor jou zijn het twee totaal verschillende dingen: bij het ene wil je blijven en je account herstellen, bij het andere wil je weg. Het model ziet vooral patronen en onderwerpen, en weegt dat verschil in bedoeling niet altijd zwaar genoeg mee. Dit heet een context-mismatch: twee teksten lijken inhoudelijk op elkaar, maar dienen een ander doel (Bron: VisionWrights).

Beginner-tip Een embedding is geen begrip. Zie het als een samengeperste vingerafdruk van taalpatronen. Het model redeneert niet over wat je bedoelt; het meet alleen hoe sterk teksten op elkaar lijken.

Drie dingen die fout kunnen gaan

Het embedding-model past niet bij de taak. Niet elk model vangt betekenis even goed, zeker niet in het Nederlands of in vakjargon. Openbare ranglijsten zoals het MTEB-leaderboard laten grote verschillen zien tussen modellen en talen (Bron: MTEB). Slechte embeddings geven slechte resultaten, hoe goed de rest ook is (Bron: Meilisearch).

De data is rommelig. Wie ruwe HTML, slecht omgezette PDF’s en halve tabellen in de database stopt, krijgt rommel terug. Ook de manier waarop documenten in stukjes worden geknipt telt mee: een stukje zonder context (“klik daarna op Bevestigen”) kan bij elke vraag passen (Bron: Anthropic).

De index is te grof afgesteld. HNSW zoekt bij benadering. Stel je hem in op snelheid, dan vindt hij sneller een antwoord dat in de buurt ligt, maar mist hij vaker het allerbeste.

HNSW: snel, maar bij benadering

HNSW werkt met lagen, een beetje zoals een kaart met snelwegen en straten. In de bovenste laag liggen weinig punten met lange verbindingen: daar maak je grote sprongen naar de goede regio. In de onderste lagen liggen alle punten met korte verbindingen: daar zoek je de buurt nauwkeurig af. Je vraag begint bovenaan en daalt zo af naar de dichtstbijzijnde kandidaten (Bron: Malkov en Yashunin, arXiv).

Dat maakt zoeken in miljoenen documenten razendsnel. De prijs: het algoritme garandeert niet dat het de echt dichtstbijzijnde tekst vindt, alleen een heel goede kandidaat.

Gevorderden De belangrijkste knoppen zijn het aantal verbindingen per punt (M), de zoekbreedte tijdens het bouwen van de index (efConstruction) en de zoekbreedte tijdens het zoeken (efSearch). Hogere waarden geven een hogere recall, maar kosten geheugen en snelheid. Let wel: ook een perfecte index haalt het verkeerde document op als de embeddings zelf het verschil in bedoeling niet vangen.

Hoe je dit merkt

Je merkt het als je dezelfde vraag anders formuleert en ineens wél het goede antwoord krijgt. Of als je meer context geeft (“ik wil mijn abonnement stopzetten, mijn wachtwoord werkt prima”) en het systeem opeens de juiste pagina vindt. Die extra woorden verschuiven je vraag in de ruimte, weg van de wachtwoordhoek.

Je merkt het ook als een assistent een antwoord geeft dat niet in het document staat dat je hebt geüpload. Dat kan komen doordat de zoekstap het verkeerde stuk ophaalde en het taalmodel daarop voortborduurde. Het kan ook een gewone hallucinatie zijn: het taalmodel vult dan zelf iets in. Van buitenaf zie je het verschil niet, en dat maakt dit soort fouten lastig.

Wat bedrijven eraan doen

Steeds meer systemen vertrouwen niet alleen op vector search, maar combineren meerdere technieken:

Trefwoordzoeken (lexicaal). Zoeken op exacte woorden, met klassieke methoden als BM25. Dat is snel en sterk bij namen, productcodes en foutmeldingen, precies waar embeddings nog weleens de mist in gaan. Anthropic liet in een eigen test zien dat het combineren van embeddings met BM25 het aantal mislukte zoekacties duidelijk verlaagt (Bron: Anthropic).

Vector search. Goed in betekenis en synoniemen, maar gevoelig voor de verwarring hierboven.

Filteren op kenmerken. Eerst de zoekruimte beperken met labels (“dit document hoort bij Abonnementen, niet bij Inloggen”), en pas daarbinnen op betekenis zoeken.

Ook de grote aanbieders werken zo: de bestandszoekfunctie van OpenAI zoekt volgens de eigen documentatie zowel op betekenis als op trefwoorden (Bron: OpenAI). Zo’n hybride aanpak kost iets meer rekenwerk, maar geeft betrouwbaardere resultaten.

Wat je zelf kunt doen

Werk je met een AI-assistent die in jouw documenten zoekt, dan helpt het volgende:

Geef context mee. “Dit is ons retourbeleid” werkt beter dan alleen de tekst uploaden. Duidelijke titels en labels helpen het systeem om documenten uit elkaar te houden.

Houd je bronnen schoon. Verwijder dubbele en verouderde versies en vul de metadata in. Een assistent is zo goed als de documenten die hij kan vinden.

Stel je vraag anders. Voelt een antwoord verkeerd, formuleer de vraag dan specifieker, met de woorden die in het document zelf staan.

Vraag om de bron. Laat de assistent aangeven uit welk document of welke passage een antwoord komt. Klopt die passage niet bij je vraag, dan weet je dat de zoekstap misging.

Vector search blijft de basis van de meeste AI-zoeksystemen, omdat het snel is en synoniemen begrijpt. Het is alleen geen scheidsrechter over wat je bedoelt. Wie dat weet, herkent een fout antwoord sneller en weet hoe je het systeem bijstuurt.

Stand van zaken — bijgewerkt 2026-09-25

De uitleg hierboven blijft staan, ongeacht welk model of welke database er draait. De productvoorbeelden hieronder zijn de bederfelijke laag.