Wat is reranking en wanneer heb je het nodig?

Reranking is een tweede selectiestap in een RAG-pipeline waarbij de documenten die een zoekmechanisme heeft opgehaald opnieuw worden beoordeeld op relevantie voor de exacte gebruikersvraag. Vector search of hybride retrieval haalt eerst relatief snel een groep kandidaatdocumenten op; een reranker vergelijkt daarna de vraag veel nauwkeuriger met elk kandidaatdocument en zet de beste resultaten bovenaan voordat ze naar het taalmodel gaan.

Je hebt reranking vooral nodig wanneer de eerste retrievalronde regelmatig documenten vindt die semantisch ongeveer kloppen, maar niet precies genoeg zijn om betrouwbare antwoorden te genereren. Bij kleine, overzichtelijke kennisbanken met duidelijke documenten en eenvoudige vragen is reranking vaak overkill. Bij grotere RAG-systemen, sterk gelijkende documenten, juridische of technische kennis en vragen waarbij kleine betekenisverschillen belangrijk zijn, kan reranking juist een belangrijk onderdeel van de retrievallaag zijn.

Wat reranking precies doet

Een standaard RAG-systeem begint meestal met retrieval. Documenten worden opgesplitst in chunks en omgezet naar embeddings: numerieke representaties van hun betekenis. Een gebruikersvraag wordt eveneens naar een embedding vertaald. Vervolgens zoekt een vectordatabase naar chunks waarvan de vectoren dicht bij de vector van de vraag liggen.

Dit wordt doorgaans gedaan met een bi-encoder. De vraag en de documenten worden afzonderlijk gecodeerd. Daardoor kun je documentembeddings vooraf berekenen en miljoenen vectoren relatief efficiënt doorzoeken. Dat is snel, maar heeft een beperking: het model beoordeelt de vraag en het document niet gezamenlijk.

Een reranker gebruikt vaak een cross-encoder. In plaats van twee losse embeddings te vergelijken, krijgt het model de combinatie vraag + kandidaatdocument als één input, en beoordeelt vervolgens rechtstreeks hoe relevant dat document voor die specifieke vraag is. Dat kost meer rekenwerk, maar levert doorgaans een fijnmaziger relevantiesignaal op. Daarom gebruik je een cross-encoder niet om een volledige documentcollectie te doorzoeken — de eerste retrievalronde maakt eerst een beperkte kandidatenlijst; de reranker sorteert alleen die kandidaten opnieuw.

Conceptueel: vraag → vector/hybride retrieval → kandidaat-chunks → reranker → beste chunks → LLM. Reranking vervangt retrieval dus niet. Het verfijnt de resultaten ervan, zoals ook beschreven in hybride retrieval in productie.

Waarom eerste-ronde retrieval niet altijd genoeg is

Embeddingmodellen zijn goed in semantische overeenkomst, maar semantische overeenkomst is niet hetzelfde als relevantie. Stel dat een kennisbank verschillende documenten bevat over:

opzegging van arbeidsovereenkomsten;
opzegging van dienstverleningsovereenkomsten;
opzegtermijnen;
ontbinding van overeenkomsten;
voorwaarden voor tussentijdse beëindiging.

Een vraag over de opzegtermijn van één specifiek contracttype ligt semantisch dicht bij meerdere van deze documenten. Een vectordatabase kan ze daarom allemaal hoog waarderen. Voor een RAG-systeem is dat een probleem: het taalmodel ziet niet alleen het juiste document, maar mogelijk ook meerdere stukken die inhoudelijk verwant maar juridisch of praktisch niet van toepassing zijn.

De eerste retrievalronde optimaliseert vooral voor recall: zorgen dat het relevante materiaal überhaupt in de kandidatenlijst terechtkomt. De reranker kan vervolgens sterker optimaliseren voor precision: bepalen welke kandidaten daadwerkelijk het meest geschikt zijn om aan het taalmodel te geven. Een goede reranker kan geen document terughalen dat tijdens de eerste retrieval helemaal niet is gevonden — als de juiste bron ontbreekt in de kandidatenlijst, moet je eerst de retrieval verbeteren.

Wanneer heb je reranking wel nodig?

Een duidelijk signaal is dat je bij tests ziet dat het juiste document meestal wel wordt gevonden, maar regelmatig pas onder minder relevante resultaten staat. Dat is precies het soort fout dat een reranker kan corrigeren. Ook bij collecties met sterk gelijkende documenten is reranking nuttig — denk aan verschillende versies van beleidsstukken, contracten, technische handleidingen of procedures, waar de globale semantiek vrijwel identiek kan zijn terwijl enkele bepalende passages verschillen.

Reranking is daarnaast relevant wanneer queries complexer worden, bijvoorbeeld: "Welke procedure geldt wanneer leverancier X na beëindiging nog toegang heeft tot persoonsgegevens?" Daarin zitten meerdere concepten tegelijk — leverancier, beëindiging, toegang en persoonsgegevens — en een cross-encoder kan de relatie daartussen beoordelen omdat hij vraag en passage tegelijk ziet. Ook voor systemen waarbij retrievalfouten relatief kostbaar zijn is reranking sneller te rechtvaardigen: bij interne zoekfuncties is een net iets minder relevant resultaat vooral irritant, bij juridische analyse of compliance kan dezelfde fout de basis vormen voor een verkeerd antwoord.

Wanneer is reranking overkill?

Niet iedere RAG-pipeline heeft een reranker nodig. Bij een kleine kennisbank met goed gestructureerde, duidelijk verschillende documenten kan standaard vector retrieval al voldoende zijn — als tests aantonen dat de juiste passages vrijwel altijd bovenaan verschijnen, voegt reranking vooral extra infrastructuur en latency toe. Hetzelfde geldt voor brede vragen: voor "wat zijn onze belangrijkste IT-beveiligingsrichtlijnen?" kunnen meerdere algemene passages relevant zijn, en voegt een extreem precieze rangschikking minder toe dan bij een vraag naar één specifieke uitzondering in een procedure.

Reranking lost bovendien slechte chunking niet automatisch op, en slechte oorspronkelijke retrieval blijft slechte retrieval — als het relevante document niet bij de kandidaten zit, heeft een reranker niets om opnieuw te rangschikken. De juiste volgorde is daarom meestal: retrieval meten → retrieval verbeteren → pas daarna bepalen of reranking nodig is.

Latency en andere praktische afwegingen

De belangrijkste technische kosten van reranking zijn latency en compute. Bij vector search zijn documentembeddings vooraf berekend, waardoor een query efficiënt met veel documenten kan worden vergeleken. Een cross-encoder moet daarentegen tijdens iedere zoekopdracht meerdere vraag-documentcombinaties verwerken: hoe meer kandidaten je laat reranken, hoe meer inference nodig is. De eerste retriever moet dus voldoende kandidaten leveren om een hoge kans te hebben dat het juiste document ertussen zit, zonder onnodig een enorme lijst door een zwaarder model te sturen.

Reranking hoeft geen externe dienst te zijn. Cross-encoder-modellen kunnen ook lokaal of op eigen infrastructuur worden uitgevoerd — in ecosystemen zoals Sentence Transformers zijn modellen beschikbaar die expliciet bedoeld zijn voor pairwise relevantiebeoordeling. Dat kan interessant zijn wanneer documenten de eigen infrastructuur niet mogen verlaten of wanneer een RAG-systeem volledig on-premises moet draaien. Self-hosting betekent uiteraard dat je zelf verantwoordelijk bent voor modeldeployment, hardwarecapaciteit, monitoring, updates en schaalbaarheid — de afweging is dus niet simpelweg "API versus gratis lokaal model", maar architectuur versus operationele verantwoordelijkheid.

Reranking is geen vervanging voor goede retrieval

Een veelgemaakte fout is reranking behandelen als oplossing voor ieder retrievalprobleem. Een goede RAG-pipeline bestaat uit meerdere lagen die elkaar beïnvloeden: document parsing → chunking → metadata → embeddings → retrieval → filtering → reranking → contextselectie → generatie. Wanneer de documentextractie slecht is, kan een reranker weinig herstellen. Wanneer chunks te groot of te klein zijn, beoordeelt hij mogelijk de verkeerde context. Reranking werkt vooral goed wanneer de eerste retrieval al redelijk functioneert — zie het als de laatste precisielaag van retrieval, niet als reparatiemiddel voor een slechte zoekarchitectuur.

Vuistregel: wanneer reranking toevoegen?

Gebruik deze korte checklist voordat je een reranker in je RAG-stack zet:

Komt het juiste document meestal wel in de eerste zoekresultaten terecht?
Staat het juiste document regelmatig niet hoog genoeg?
Bevat de kennisbank veel inhoudelijk vergelijkbare documenten of passages?
Zijn kleine betekenisverschillen belangrijk voor het uiteindelijke antwoord?
Is nauwkeurigheid belangrijker dan minimale latency?
Kun je de extra inference-stap operationeel dragen?
Heb je retrievalkwaliteit gemeten in plaats van alleen losse voorbeelden bekeken?

Is het antwoord op de eerste vraag nee, verbeter dan eerst retrieval. Is het antwoord op de eerste vraag ja, en op meerdere volgende vragen eveneens, dan is reranking een logische volgende stap. De eenvoudigste vuistregel: retrieval zorgt dat het juiste document in de kandidatenlijst komt, reranking zorgt dat het juiste document bovenaan komt. Voeg reranking pas toe wanneer die tweede stap aantoonbaar een probleem is.