Toen we begonnen met het bouwen van Alex, Vera en Zia bij PrudAI, dachten we — net als de rest van de wereld — dat vector search de heilige graal was voor Retrieval-Augmented Generation (RAG). Je gooit je documenten in een vector database, berekent de cosine similarity tussen de query en de chunks, en klaar is Kees.
In de praktijk kwamen we er snel achter dat dit voor technische documentatie en specifieke klantvragen simpelweg niet volstaat. In deze post duik ik in de technische tekortkomingen van puur semantische zoekopdrachten en leg ik uit waarom we onze architectuur hebben omgegooid naar een combinatie van Hybrid Search (BM25 + Vector) en Cross-Encoder Reranking.
De 'Semantic Trap' van Vector Embeddings
Vector embeddings (zoals Google's gemini-embedding-001 of HuggingFace modellen) zijn fantastisch in het begrijpen van concepten. Als een gebruiker vraagt naar "problemen met inloggen", zal een vector search moeiteloos documenten vinden over "authenticatie fouten". Dat is de kracht van semantiek.
Maar zodra je werkt met technische data, faalt dit systeem op een voorspelbare manier. Stel dat een gebruiker zoekt op een specifiek serienummer, een foutcode zoals 0x8004210B, of een specifieke functienaam in een codebase. Voor een embedding model zijn deze unieke strings vaak 'out-of-vocabulary' of ze worden platgeslagen tot een vector die te dicht bij andere, niet-relevante technische termen ligt.
Het resultaat? De vector database geeft je de top-k resultaten die ongeveer hetzelfde voelen, maar mist de exacte chunk die de oplossing bevat. Voor onze agent Alex, die technische support automatiseert, is dat onacceptabel. Dichtbij is in engineering nog steeds fout.
BM25: De Terugkeer van Keyword Search
Om dit op te lossen, hebben we BM25 (Best Matching 25) opnieuw geïntroduceerd in onze pipeline. BM25 is een evolutie van TF-IDF en is een statistische methode die kijkt naar de frequentie van woorden in een document ten opzichte van de hele dataset.
In tegenstelling tot vector search, geeft BM25 prioriteit aan zeldzame tokens. Als de term ERR_CONNECTION_RESET maar in twee documenten voorkomt, zal BM25 deze direct naar boven halen. Het begrijpt de betekenis niet, maar het begrijpt de uniciteit. Door deze 'lexicale' zoekopdracht parallel aan onze vector search te draaien, vangen we de specifieke termen op die embeddings missen.
Hybrid Search en Reciprocal Rank Fusion (RRF)
Het hebben van twee zoekresultaten (één van de vector database en één van BM25) creëert een nieuw probleem: hoe combineer je ze? Je kunt niet simpelweg de scores optellen, want een cosine similarity score van 0.82 is niet vergelijkbaar met een BM25 score van 14.5.
Wij gebruiken hiervoor Reciprocal Rank Fusion (RRF). Dit is een algoritme dat resultaten rangschikt op basis van hun positie in de verschillende lijsten, in plaats van hun ruwe score. De formule is relatief simpel:
score = sum(1 / (k + rank))
Hierbij is k een constante (vaak 60). Dit zorgt ervoor dat documenten die in beide systemen hoog scoren, bovenaan komen te staan, terwijl uitschieters in één van de twee systemen nog steeds een eerlijke kans krijgen. Dit gaf ons een stabielere baseline, maar we waren er nog niet.
Waarom we Cohere Rerank nodig hadden
Zelfs met Hybrid Search is de context die je naar een LLM stuurt vaak nog vervuild. Je haalt misschien 20 documenten op, maar je hebt er maar 3 of 5 nodig voor een accuraat antwoord. Hoe bepaal je de absolute top?
Dit is waar we Cohere Rerank hebben geïntroduceerd. In de wereld van informatie-extractie maken we onderscheid tussen Bi-Encoders en Cross-Encoders.
- Bi-Encoders (Vector Search) berekenen de embedding van de query en het document onafhankelijk van elkaar. Dit is snel, maar verliest nuance.
- Cross-Encoders (Reranking) nemen de query en het document samen in het model. Het model kan hierdoor direct de interactie tussen de woorden in de vraag en de tekst in het document wegen.
Zoals beschreven in de documentatie van Cohere, fungeert de Reranker als een precisie-instrument. We sturen de top 25 resultaten van onze Hybrid Search naar het rerank-v3 model. Dit model geeft elk paar een relevantiescore tussen 0 en 1.
Het verschil is bizar. Waar een vector search soms een document teruggeeft omdat de 'vibe' klopt, ziet de Reranker dat de cruciale voorwaarde uit de vraag ontbreekt in de tekst. Hierdoor kunnen we met een veel kleiner context-window werken, wat niet alleen de kosten drukt, maar ook de kans op hallucinaties verkleint. De LLM hoeft namelijk niet meer door 10 pagina's aan 'ruis' te spitten.
De Impact op Alex en Vera
Sinds de implementatie van deze architectuur zien we een significante stijging in de 'Hit Rate' bij onze interne benchmarks. Voor complexe queries over API-specificaties steeg de nauwkeurigheid van de opgehaalde context van ~65% naar ruim 92%.
Bij PrudAI geloven we niet in de magie van AI; we geloven in robuuste systemen. De overstap van simpele vector search naar een multi-stage retrieval pipeline is voor ons het bewijs dat de basis van een goede AI-agent niet alleen in het model (GPT of Claude) zit, maar in de kwaliteit van de data die je het model voert.
Als je nu nog steeds alleen op vector_store.search() vertrouwt, laat je resultaten liggen. Het is tijd om je retrieval serieus te nemen.