Vectorieel ophalen is in 2026 de de facto standaard voor RAG-deployments. De meeste teams stellen een embedding-model in, vullen Qdrant of pgvector en gaan live. Het werkt — totdat er een zoekopdracht binnenkomt als "§ 271 lid 2 Arbeidsrecht" of "HMI model 7NF-420-C". Een dense embedding weet daar geen raad mee: het comprimeert een document tot één vector en de exacte string gaat verloren in de semantische ruimte. Precies hier komt hybrid search in beeld — een combinatie van keyword retrieval (BM25) en vectorieel zoeken, met een reranker als afsluitende laag.
Dit artikel gaat dieper dan het onderwerp RAG-pipeline — 3 instellingen die de kwaliteit bepalen, waar we de reranker alleen in de context van de pipeline noemden. Hier richten we ons uitsluitend op de zoeklaag: waarom vectoren alleen niet volstaan, hoe hybrid mechanisch werkt, wat RRF-fusie inhoudt, wanneer een reranker echt helpt en hoe je dit alles in de praktijk instelt.
Waarom vectoren alleen niet volstaan
Een dense embedding-model (bijv. BGE-M3 of text-embedding-3-large) zet tekst om in een vector in een ruimte van honderden of duizenden dimensies. Vectoren die dicht bij elkaar liggen, hebben een vergelijkbare semantische inhoud. Uitstekend voor vragen als "wat zijn de voorwaarden voor ontslag", waarbij het de betekenis is die telt.
Het probleem doet zich voor bij lexicaal specifieke zoekopdrachten:
- Normnummers en wetsartikelen:
§ 63,EN ISO 12100,EU-verordening 2016/679 - Product- en onderdeelcodes:
SKF-6204-2RS,Siemens SIMATIC S7-1500 - Namen, afkortingen, acroniemen:
ARBO,DNB,FFT-analyse - Exacte waarden:
230 V AC,IP67,UL 508A
In deze gevallen faalt embedding om één reden: het model is niet getraind op het gegeven dat "SKF-6204-2RS" en "SKF-6205-2RS" fundamenteel verschillende items zijn. Vectoren kunnen dicht bij elkaar liggen omdat ze hetzelfde voorvoegsel delen. De exacte overeenkomst gaat verloren.
BM25 (Best Matching 25) heeft dit probleem niet. Het is een klassieke statistische methode op basis van TF-IDF uit 1994, die het voorkomen van elk token in een document expliciet afweegt ten opzichte van het corpus. Voor exacte strings is BM25 nog altijd beter dan welk embedding-model ook — en dat geldt in 2026 net zo goed als in 2014.
Uit indicatieve benchmarktests op synthetische corpora:
- BM25 alleen: ~58 % precisie
- Dense vectoren alleen: ~79 %
- Hybrid (BM25 + dense): ~85–88 %
- Hybrid + cross-encoder reranker: ~88–91 %
De werkelijke verbetering hangt af van de dataset, de taal en het type zoekopdrachten. Voor industriële documentatie met codes en normen zien we in de praktijk een verschil van 8–12 procentpunten precision@5 tussen hybrid en dense.
Hoe BM25 werkt
BM25 is een statistisch model. Voor elk document en elke zoekopdracht berekent het een score als gewogen som van TF-IDF (term frequency — inverse document frequency) voor elk token in de query. Parameters:
k1— regelt de saturatie van de termfrequentie (doorgaans 1,2–2,0). Hoger = lineairder verband tussen frequentie en score.b— normalisatie van de documentlengte (0 = geen, 1 = volledig). Default 0,75.
BM25 vereist geen GPU of speciale hardware — het is deterministisch, snel en draait op CPU. Bibliotheek: rank_bm25 in Python, of native ondersteuning in Weaviate, OpenSearch, Elasticsearch en Qdrant (via sparse vectors).
Beperking: BM25 begrijpt geen synoniemen of parafrasen. De zoekopdracht "beëindiging arbeidsovereenkomst" vindt geen document dat alleen spreekt over "ontslag op staande voet". Daar zijn vectoren juist voor.
Reciprocal Rank Fusion — twee resultatenlijsten samenvoegen
Als we twee afzonderlijke rankings hebben (BM25 en dense vectoren), moeten we die samenvoegen tot één. De meest gebruikte aanpak in 2026 is RRF (Reciprocal Rank Fusion).
De mechanica is eenvoudig. Voor elk document berekenen we:
RRF_score(d) = sum( 1 / (k + rank_i(d)) )waarbij rank_i(d) de positie van het document in de i-de ranking is en k een afvlakkingsparameter (doorgaans 60). Documenten die in beide rankings hoog staan, krijgen de hoogste score. Een document dat het ene systeem niet kent maar dat het andere systeem op positie 1 zet, krijgt toch een behoorlijke score.
Waarom geen gewogen gemiddelde van de scores? BM25-scores en embedding cosine similarity liggen op verschillende schalen — een directe weging zou één van de systemen bevoordelen. RRF werkt uitsluitend met rangorde, zodat de schaal er niet toe doet.
Alternatief voor RRF: DBSF (Distribution-Based Score Fusion) — normaliseert scores vóór de fusie, geschikt wanneer beide systemen gekalibreerd zijn. In de praktijk beginnen de meeste implementaties met RRF en proberen DBSF pas wanneer er distributieproblemen optreden.
De parameter alpha in sommige frameworks (bijv. Weaviate) regelt eenvoudig de verhouding BM25 vs. dense — alpha=0 = puur BM25, alpha=1 = puur dense, alpha=0.5 = gelijke bijdrage van beide. Default 0,5 is een goed startpunt, maar voor inhoud met een hoge dichtheid aan codes en normen kunt u alpha=0,3–0,4 proberen (grotere bijdrage van BM25).
Reranker — waarom retrieval niet volstaat
Hybrid search verbetert de recall aanzienlijk — de kans dat het juiste document bij de top-K kandidaten zit. Maar precision@5 (hoeveel van de eerste 5 echt relevant zijn) hangt af van hoe goed de kandidaten gerangschikt zijn.
Hier komt de reranker om de hoek kijken (een cross-encoder model). De werking:
- 1.Hybrid retrieval retourneert top-K documenten (doorgaans K = 20–50). Snel.
- 2.De reranker ontvangt elk van de K documenten samen met de zoekopdracht, verwerkt ze gezamenlijk en kent een nauwkeurige relevantiesccore toe. Trager, maar preciezer.
- 3.De top-N (doorgaans N = 5) met de hoogste reranker-score gaat naar de LLM-context.
Waarom is een reranker preciezer dan embedding? Een bi-encoder comprimeert document en zoekopdracht elk afzonderlijk tot een vector — de interactie daartussen wordt alleen via cosinus-afstand beoordeeld. Een cross-encoder ziet zoekopdracht en document tegelijk, waardoor het subtiele token-level interacties kan opvangen die een bi-encoder mist.
Typische stijging van precision@5 na toevoeging van een reranker: 7–12 procentpunten. Extra latentie: 50–200 ms voor top-20 reranking.
Actuele best-in-class:
- Cohere Rerank 3.5 — managed API, uitstekend voor meertalige inhoud inclusief Centraal-Europa, eenvoudige integratie
- BGE-reranker-v2-m3 — open-weight, self-hosted, meertalig, uitstekende prijs-kwaliteitverhouding
- ms-marco-MiniLM-L-6-v2 — klein, snel, Engelstalig prototype
Voor de keuze van een embedding-model geldt hetzelfde principe: meertalige EU-inhoud verdient een meertalige reranker.
Wanneer hybrid echt helpt (en wanneer niet)
Hybrid search helpt sterk wanneer:
- De inhoud codes, cijfers, afkortingen, normen of productaanduidingen bevat
- De gebruiker exacte zoekopdrachten stelt (copy-paste uit een document, onderdeelcode uit een bestelling)
- De taal niet uitsluitend Engels is — BM25 heeft geen taalmodel nodig en werkt voor het Nederlands net zo goed
- Recall een knelpunt is — "het relevante document werd niet gevonden" is een veelgehoorde klacht
- Het corpus thematisch zeer gelijksoortige documenten bevat (bijv. 5 000 vergelijkbaar opgebouwde technische datasheets)
Hybrid search helpt minder wanneer:
- Zoekopdrachten volledig conversationeel en op parafrasen gebaseerd zijn (FAQ-chatbot, HR-antwoorden)
- Het corpus klein is (minder dan 500 documenten) — de extra latentie en complexiteit wegen niet op
- Latentie kritisch is — elke laag voegt BM25-scoring toe (doorgaans +10–30 ms) en eventueel een reranker (+50–200 ms)
- De inhoud voornamelijk Engelstalig is en de embeddings kwalitatief hoogwaardig zijn — dense vectoren benaderen dan de resultaten van hybrid retrieval
Bij een klant uit de reserveonderdelenbranche hebben we dit in de praktijk gezien: een corpus van 18 000 technische datasheets met SKF-, NSK- en FAG-codes. Puur dense retrieval, precision@5 = 0,63. Na overstap op hybrid met alpha=0,35 en BGE-reranker-v2-m3: precision@5 = 0,84. Hoofdreden — exacte overeenkomst op de onderdeelcode uit de zoekopdracht van de klant.
Praktische instelling — stack 2026
Qdrant (aanbevolen voor B2B industriële deployments)
Qdrant ondersteunt native hybrid search via sparse + dense vectoren in één collectie. Sparse vectoren voor BM25 genereren we via BM25Encoder uit de fastembed-bibliotheek.
# initialisatie sparse encoder
from fastembed import SparseTextEmbedding
sparse_model = SparseTextEmbedding("Qdrant/bm25")
# bij indexering
sparse_vec = sparse_model.embed(text)
dense_vec = embedding_model.embed(text)
# query: hybrid search met RRF-fusie
results = client.query_points(
collection_name="documents",
prefetch=[
Prefetch(query=sparse_vec, using="sparse", limit=20),
Prefetch(query=dense_vec, using="dense", limit=20),
],
query=FusionQuery(fusion=Fusion.RRF),
limit=5
)Collectieconfiguratie: twee vectorindexen — dense (dimensie afhankelijk van het embedding-model, cosine) en sparse (sparse index, dot). Qdrant verwerkt beide in één doorgang.
Weaviate
Weaviate heeft hybrid search als eersteklas functie — BM25 + dense vectoren + RRF-fusie in één API-aanroep. De parameter alpha direct in de query:
results = collection.query.hybrid(
query="§ 63 Arbeidsrecht ontslag",
alpha=0.4, # grotere bijdrage van BM25
limit=20
)Vervolgens reranking via Cohere of een lokale cross-encoder op de top-20 resultaten.
Reranking-laag
Ongeacht de vectordatabase is de reranker een aparte stap. Aanbevolen instelling:
- K = 20–30 kandidaten uit hybrid retrieval
- Reranker op K kandidaten → N = 5 resultaten voor de LLM
- Voor self-hosted:
BGE-reranker-v2-m3op GPU; op CPU haalt het ~500 ms/query voor top-20 - Voor cloud: Cohere Rerank 3.5 API, EU-endpoint
Een reranker toevoegen aan bestaande hybrid retrieval is doorgaans 20–40 regels code. Wanneer we het hebben over evaluatie van de RAG-pipeline via RAGAS, is dit precies de stap die een eigen precision@5-meting vóór en na verdient.
Latentie: wat elke laag toevoegt
Indicatieve latenties bij 10 M vectoren, RTX 4090 GPU:
- BM25-scoring op CPU: 10–30 ms
- Dense vector search (Qdrant): 5–15 ms
- RRF-fusie: onder 5 ms
- Reranker cross-encoder top-20 (GPU): 80–150 ms
- Reranker cross-encoder top-20 (CPU): 400–800 ms
- Cohere Rerank 3.5 API (netwerk): 100–200 ms
Totale pipeline: hybrid retrieval + GPU-reranker = doorgaans 200–400 ms end-to-end voor de zoeklaag. Voor interactieve chatbots is dat doorgaans acceptabel. Voor systemen met een vereiste onder 150 ms: overweeg de reranker alleen bij lage netwerklatentie of vervang hem door een eenvoudigere bi-encoder resorting.
Een uitgebreidere vergelijking van vectordatabases en hun QPS-parameters vindt u in het artikel Vectordatabases — Qdrant, Weaviate, pgvector, Milvus.
Veelgestelde vragen
Moet ik het systeem vanaf het begin ontwerpen met hybrid retrieval, of kan ik BM25 later toevoegen?
Een BM25-index is onafhankelijk van de embedding-index en kan op elk moment aan een bestaand corpus worden toegevoegd. In Qdrant volstaat het om een sparse vector-index aan de collectie toe te voegen en de documenten opnieuw te indexeren — de dense indexen blijven onaangetast. Weaviate, Milvus en pgvector hanteren een vergelijkbare werkwijze. De reïndexatietijd hangt af van de corpusgrootte, maar voor een typische B2B-kennisbank (tot 1 M documenten) gaat het om uren, niet om dagen.
Wat werkt beter voor Nederlandstalige inhoud: BM25 of dense embedding?
Dat hangt af van het karakter van de zoekopdrachten. BM25 werkt voor het Nederlands net zo goed als voor het Engels — het is een statistisch model zonder taalafhankelijkheid. Voor semantische vragen (parafrasen, synoniemen) is een meertalige dense embedding zoals BGE-M3 of Qwen3-Embedding-8B beter. In de praktijk voor Nederlandstalige B2B-corpora: hybrid met alpha=0,4–0,5 levert het beste resultaat.
Wanneer helpt een reranker niet?
Een reranker herordent alleen de documenten die retrieval heeft teruggegeven. Als het juiste document niet bij de top-K kandidaten zit, redt de reranker het niet. Dit betekent: herstel eerst de recall (hybrid retrieval, groter K) en voeg daarna pas een reranker toe. Als precision@5 ook na reranking stagneert, zit het probleem meestal in recall — het juiste document zit simpelweg niet bij de kandidaten.
Wat is het verschil tussen hybrid search en agentic RAG?
Hybrid search is een techniek op het niveau van de retrieval-laag — het verbetert welke documenten in de LLM-context terechtkomen. Agentic RAG is een architectuurpatroon waarbij een agent actief beslist wat en hoe er gezocht wordt — iteratief bevragen, verschillende bronnen, sub-queries. Hybrid search en agentic RAG sluiten elkaar niet uit: een goede agent gebruikt hybrid retrieval onder de motorkap.
Is hybrid search on-prem te deployen zonder cloudafhankelijkheden?
Ja. Zowel Qdrant als Weaviate zijn open-source en draaien self-hosted. BGE-reranker-v2-m3 is een open-weight model dat lokaal op GPU draait. BM25 vereist geen externe dienst. De volledige stack — hybrid retrieval + reranker — kan volledig on-prem draaien, wat essentieel is voor gereguleerde sectoren. Meer over dit onderwerp in on-prem LLM voor gereguleerde sectoren.
---
*Als uw RAG-systeem er tegenaan loopt dat exacte codes, normen of productaanduidingen niet betrouwbaar worden gevonden, ligt het probleem vrijwel altijd in een ontbrekende keyword-laag. Wij helpen bedrijven bij het ontwerpen en deployen van een hybrid retrieval-stack — van de keuze van database en embedding-model tot de instelling van de reranker en het meten van de verbetering.*