RAG Query Rewriting: vervolgvragen voor AI-chatbots correct verwerken

Een enkele vraag zoals "En hoe lang is dat geldig?" is voor mensen vaak duidelijk. Ze herinneren zich het eerder besproken product, de locatie en de bedoelde termijn. Een zoekopdracht naar kennis ziet daarentegen aanvankelijk maar een paar woorden. Zonder de juiste gesprekscontext vindt deze misschien helemaal niets of zoekt op het verkeerde onderwerp. RAG Query Rewriting lost dit probleem op door een contextafhankelijke vervolgvraag vóór de zoekopdracht om te zetten in een zelfstandige zoekvraag.

Dat klinkt als een kleine tussenstap, maar het bepaalt vaak de kwaliteit van een meerstaps website-chat. Deze gids laat zien hoe teams vervolgvragen verwerken, wanneer ze beter verduidelijking kunnen vragen en hoe ze voorkomen dat een herschrijving nieuwe feiten, verkeerde rechten of verouderde context in de zoekopdracht injecteert.

Waarom vervolgvragen een kenniszoekopdracht overbelasten

De eerste gebruikersvraag is meestal concreet: "Welke garantie geldt voor model A?" Daarna volgen korte formuleringen zoals "En voor de grotere variant?", "Geldt dat ook in Nederland?" of "Wat heb ik daarvoor nodig?". Voornaamwoorden, weggelaten onderwerpen en verwijzingen naar eerdere antwoorden zijn natuurlijk in een gesprek. Als geïsoleerde zoekopdracht zijn ze echter zwak.

Een klassieke keyword-, vector- of hybrid search pipeline kan alleen beoordelen wat hij als zoekopdracht ontvangt. Reranking verbetert de volgorde van bestaande resultaten, maar vervangt niet de ontbrekende betekenis van "dat" of "daarvoor". Query Rewriting bevindt zich daarom vóór die stap: het vormt uit de huidige vraag en het relevante gesprek een doorzoekbare, zelfstandige vraag.

Wat een goede herschrijving moet opleveren

Een geslaagde rewrite-vraag is volledig genoeg voor retrieval, maar blijft dicht bij de intentie van de gebruiker. Van "En voor Nederland?" kan bijvoorbeeld "Welke garantievoorwaarden gelden voor model A in Nederland?" worden gemaakt, als model A en garantie in de direct voorafgaande dialoog duidelijk vaststaan. De herschrijving beantwoordt de vraag nog niet. Deze dient uitsluitend om passende bronnen te vinden.

De huidige Azure-architectuurrichtlijn voor Conversational RAG raadt aan relevante gespreksgeschiedenis op te nemen en de huidige vraag voor het retrieval als zelfstandige vraag met opgeloste verwijzingen te formuleren. Belangrijk is de scheiding die daar eveneens zichtbaar is: voor het latere antwoord blijft de oorspronkelijke gebruikersvraag behouden. Zo kan het systeem controleren of de gevonden bronnen daadwerkelijk passen bij de gestelde vraag.

Aanvullen, maar niet verzinnen

Een rewriter mag duidelijk aanwezige gegevens overnemen: product, versie, land, taal of de laatst genoemde handeling. Hij mag echter geen ontbrekend klantnummer aanvullen, geen vermoedelijke productvariant vastleggen en geen onzekere tijdsaanduiding omzetten in een concrete datum. Een nuttig klinkende, maar verzonnen verfijning stuurt de zoekopdracht gegarandeerd de verkeerde kant op.

Machtigingen blijven buiten het tekstmodel

Tenant, ingelogde gebruiker, vrijgegeven documentbereiken en rollen worden aan de serverzijde bepaald. Deze horen niet als vrij formuleerbare bewerering in de rewrite-vraag te staan. De backend stelt de bijbehorende metadatafilters afzonderlijk en onveranderbaar in. Noch een eerdere chatbijdrage noch een modelherschrijving mag een groter zoekgebied vrijgeven.

De context heeft een bewust budget nodig

Het ongefilterd verzenden van de volledige chatgeschiedenis naar de rewriter is zelden een goede oplossing. Oude onderwerpen kunnen de huidige vraag overschaduwen, persoonsgegevens kunnen onnodig worden doorgegeven en lange gesprekken verhogen de latentie en kosten. Als praktische richtlijn noemt de Microsoft-richtlijn twee tot vijf recente gespreksrondes en een samenvatting van oudere inhoud. Dit is geen universele limiet, maar een startpunt voor eigen tests.

Een compact contextpakket kan bestaan uit de volgende bouwstenen:

• de ongewijzigde huidige gebruikersvraag,
• een klein aantal direct relevante bijdragen van de gebruiker en de assistent,
• reeds bevestigde entiteiten zoals product, proces of locatie,
• locale en tijdzone als technische velden,
• een kortstondige, gecontroleerde samenvatting van oudere dialoogdelen, en
• de versie van de rewrite-regel, kennisindex en retrieval-configuratie.

De daadwerkelijke documentmachtigingen blijven hier van gescheiden. Evenzo moeten niet-benodigde e-mailadressen, bestelnummers of volledige antwoorden voorafgaand aan de rewrite worden verwijderd. Een datazuinige geschiedenis vergemakkelijkt bovendien het latere foutzoeken.

Een robuust proces in zes stappen

1. Zelfstandigheid controleren: Een duidelijke nieuwe vraag zoals "Hoe wijzig ik mijn wachtwoord?" kan direct naar de zoekfunctie. Niet elk bericht heeft een model-rewrite nodig.
2. Verwijzingen herkennen: Het systeem markeert voornaamwoorden, ellipsen, vergelijkingswoorden en verwijzingen zoals "daar", "beide" of "de tweede optie".
3. Relevante context selecteren: Alleen de bijdragen die deze verwijzingen aannemelijk oplossen, worden overgenomen. Een bewuste onderwerpsverandering beëindigt de oude context.
4. Beslissen tussen rewrite of verduidelijkingsvraag: Is er precies één aannemelijke interpretatie, dan ontstaat er een zelfstandige zoekopdracht. Zijn er meerdere aannemelijke betekenissen, dan stelt de chatbot een korte verduidelijkingsvraag.
5. Zoeken en eventueel opsplitsen: De vraag doorloopt keyword-, vector- of hybrid search. Meerdelige vragen kunnen worden opgesplitst in duidelijk benoemde subvragen.
6. Beantwoorden op basis van de originele vraag: Het antwoord wordt gegenereerd uit de gevonden bronnen, heeft betrekking op de oorspronkelijke formulering en vermeldt onzekerheid of ontbrekende bewijzen openlijk.

Microsofts overzicht van Agentic Retrieval beschrijft een vergelijkbaar proces: de vraag en gespreksgeschiedenis stromen in de planning, gefocuste subvragen worden parallel uitgevoerd en de resultaten worden vervolgens samengevoegd. Amazon Bedrock documenteert eveneens planning, iteratieve subvragen en de controle of de gevonden inhoud volstaat voor een antwoord. Dergelijke productfuncties kunnen delen van de pipeline overnemen; de kwaliteits- en veiligheidsgates van de eigen toepassing blijven desondanks noodzakelijk.

Rewrite, verduidelijkingsvraag of Query Decomposition?

Invoer	Passende reactie	Underbouwing
"En geldt dat ook in Nederland?" na een duidelijke garantievraag	Zelfstandige zoekopdracht formuleren	Onderwerp en referentie zijn duidelijk.
"Hoe zit het met de andere?" na drie genoemde varianten	Korte verduidelijkingsvraag stellen	Meerdere interpretaties zijn aannemelijk.
"Vergelijk prijs, levertijd en retournering voor beide modellen"	Opsplitsen in gefocuste subvragen	Meerdere onafhankelijke aspecten vereisen betrouwbare zoekresultaten.
"Nieuw onderwerp: Hoe bereik ik de klantenservice?"	Zoeken zonder oude productcontext	De gebruiker geeft een onderwerpsverandering aan.

Query Decomposition is dus niet hetzelfde als Query Rewriting. Rewriting maakt een afhankelijke vraag zelfstandig; Decomposition verdeelt een complexe vraag in meerdere zoektaken. De Bedrock-documentatie over Query Decomposition laat zien dat meerdere subvragen de dekking kunnen verbeteren. Elke extra zoekopdracht vereist echter een limiet, een gemeenschappelijk machtigingsmodel en een transparante samenvoeging.

Rewrite-output behandelen als code

Ook al is het resultaat alleen tekst, het moet een strikt contract hebben. Een gestructureerd object met velden zoals standaloneQuery, decision, resolvedReferences en reason is verstandig. Toegestane beslissingen zijn bijvoorbeeld SEARCH_AS_IS, REWRITE, CLARIFY en DECOMPOSE. De backend valideert lengte, taal en toegestane velden voordat een zoekopdracht start.

De rewriter ontvangt geen tools en antwoordt niet rechtstreeks aan de gebruiker. Systeeminstructies uit het gespreksverloop, ingevoegde documentteksten of opdrachten zoals "Negeer de regels" blijven data, geen besturingscommando's. Voor risicovolle zoekgebieden kan een deterministische regel bovendien afdwingen dat product-, locale- of tenantfilters nooit afkomstig zijn uit vrije tekst.

Testen met een eigen testset voor vervolgvragen

De kwaliteit kan niet worden aangetoond met enkele geslaagde demo's. Vul de bestaande Golden Set voor antwoordkwaliteit aan met echte meervoudige dialogen. Voor elk geval worden het oorspronkelijke verloop, de huidige vraag, de verwachte rewrite-beslissing, toegestane entiteiten, verboden aanvullingen en verwachte bronnen vastgelegd.

• Voornaamwoorden en weggelaten onderwerpen in korte vervolgvragen
• Correcties zoals "Nee, ik bedoelde model B"
• Onderwerpsveranderingen en terugkeer naar een eerder onderwerp
• Anderzins dubbelzinnige varianten die dwingend een verduidelijkingsvraag vereisen
• Locale-, datum- en tijdzonewijzigingen
• Ongeoorloofde pogingen om van zoekgebied of tenant te wisselen
• Lange gesprekken met irrelevante oudere details
• Meerdelige vragen die worden opgesplitst en weer samengevoegd

Meet afzonderlijk: Komt de herschrijving overeen met de intentie van de gebruiker? Vindt de retrieval de verwachte bronnen? Is er bij echte dubbelzinnigheid om verduidelijking gevraagd? Bleeven machtigingsfilters ongewijzigd? Hoeveel extra latentie veroorzaakt de stap? De NIST AI RMF Core plaatst herhaald testen, meten en documenteren binnen de gehele AI-levenscyclus. Voor websiteteams betekent dit: pas de rewrite-regel, het model of de contextselectie alleen aan met regressietests en een observeerbare uitrol.

Compacte checklist voor websiteteams

• Blijft de oorspronkelijke gebruikersvraag ongewijzigd behouden tot aan het antwoord?
• Worden alleen relevante en datazuinige onderdelen uit het verloop meegenomen?
• Kan de rewriter duidelijk kiezen tussen herschrijven, verduidelijken en opsplitsen?
• Vult hij uitsluitend confirmed entiteiten aan en geen vermoedens?
• Stelt de backend locale, tenant en machtigingen onafhankelijk van de rewrite in?
• Heeft elke subvraag vaste limieten voor aantal, tijd en kosten?
• Worden retrieval-resultaten geëvalueerd ten opzichte van de oorspronkelijke vraag?
• Dekt een testset met meervoudige dialogen verwijzingen, correcties en onderwerpsveranderingen af?

Conclusie: Eerst de zoekvraag verhelderen, dan antwoorden

RAG Query Rewriting maakt van natuurlijke, korte gespreksuitingen een betrouwbare zoekopdracht. Het grootste nut ontstaat niet door zo creatief mogelijke herschrijvingen, maar door duidelijke grenzen: bevestigde context overnemen, onzekerheid oplossen via een verduidelijkingsvraag, machtigingen aan de serverzijde houden en het antwoord blijven controleren aan de hand van de originele vraag. Begin met twintig typische vervolgvragen uit uw support, markeer de verwachte beslissing en test elke wijziging aan de hand van dezelfde gevallen. Zo wordt een meerstaps chat begrijpelijker, zonder dat de zoekfunctie stilzwijgend een andere vraag beantwoordt.

Bronnen

• Microsoft Azure Architecture Center: Prompt Engineering voor RAG
• Microsoft Learn: Agentic Retrieval in Azure AI Search
• Amazon Bedrock: Zoekopdrachten en antwoordgeneratie configureren
• Amazon Bedrock: Agentic Retrieval voor kennisbanken
• NIST AI Risk Management Framework Core