Query rewriting (RAG)

Wat is query rewriting?

Query rewriting is de stap in een RAG-pijplijn tussen de vraag die iemand intypt en de zoekopdracht die naar je index gaat. Een model leest de vraag eerst en maakt er iets van dat de zoekmachine kan matchen: het verbetert tikfouten, schrijft afkortingen voluit, haalt context uit eerdere beurten van het gesprek erbij, knipt een dubbele vraag in twee, of maakt van "facturen van maart" een datumfilter. Pas daarna wordt er gezocht.

De stap bestaat door een kloof die elk zoeksysteem heeft. Mensen stellen hun vraag in hun eigen woorden, midden in een gesprek, met de helft van de context in hun hoofd. Documenten zijn geschreven in de woorden van de leverancier, door iemand die de vraag niet kende. Dat was het punt van het werk rond rewrite-retrieve-read van onderzoekers bij Microsoft Research Asia en de Shanghai Jiao Tong University in 2023: de vraag aanpassen is goedkoper dan de zoekmachine of het model aanpassen.

Vergelijk het met een bibliothecaris. Jij vraagt "heb je dat boek over de stakingen in de Antwerpse haven" en zij zoekt in de catalogus op "havenarbeiders Antwerpen jaren zeventig". De herschrijving is haar vertaling van hoe jij het vraagt naar hoe de rekken gelabeld zijn.

Welke herschrijvingen kom je het vaakst tegen?

Uitbreiden en verbeteren. De eenvoudigste herschrijving voegt synoniemen en volle vormen toe en corrigeert de spelling, zodat "dso" wordt tot "days sales outstanding, DSO, klantenkrediettermijn". Azure AI Search doet dit binnen zijn semantic ranker: je vraag gaat naar een generatief model, er komen tot tien varianten terug, en de zoekopdracht loopt op het origineel en de varianten samen.

Het gesprek oplossen. Bij een helpdesk-assistent is de tweede vraag zelden volledig. Een klant vraagt "heeft de X200 automatisch ontkalken", krijgt een antwoord, en typt dan "en de X300, doet die dat ook". Zoek je daarop alleen, dan vind je niets. Een herschrijving die de vorige beurt meeleest, maakt er "heeft de X300 automatisch ontkalken" van, en daar kunnen je handleidingen op antwoorden.

Een samengestelde vraag opsplitsen. "Wat is de garantie op de X300 en kan ik die verlengen" zijn twee zoekopdrachten. Een herschrijving die twee deelvragen maakt, voor allebei zoekt en de fragmenten samenvoegt, beantwoordt beide helften. Als het model daarbovenop zelf de deelvragen plant en blijft zoeken tot het tevreden is, zit je bij agentic RAG, dat een eigen lemma heeft.

Meerdere formuleringen tegelijk (multi-query). Het model schrijft een paar versies van de vraag vanuit een andere hoek, op elke versie wordt gezocht, en de resultaten worden samengevoegd zonder dubbels. De MultiQueryRetriever van LangChain doet dat, met een standaardprompt die om drie versies vraagt. Je betaalt meerdere zoekopdrachten in plaats van een, en het antwoord hangt minder af van hoe de vraag toevallig geformuleerd was.

Zoeken met een hypothetisch antwoord (HyDE). Een vraag en haar antwoord zien er in embedding-ruimte anders uit. HyDE, in december 2022 gepubliceerd door onderzoekers van Carnegie Mellon en de University of Waterloo, laat het model eerst een korte passage schrijven die het antwoord zou kunnen zijn, en zoekt dan met die passage. Die passage bevat verzonnen details, dat geeft de paper zelf toe, maar ze lijkt op de tekst die je wil vinden, en de embedding-stap vlakt die details uit.

Van een vraag een filter maken. Een deel van wat mensen typen is een zoekterm, een ander deel is een vermomde filter. "Wat hebben we met Vandenbroucke afgesproken over levering" is een klantfilter plus een onderwerpsvraag ("leveringsvoorwaarden, levertermijn"). Dat gestructureerde deel als metadatafilter aan de index doorgeven werkt beter dan hopen dat de embedding van "maart" toevallig bij de juiste maand landt. LlamaIndex noemt dit auto-retrieval: uit een vraag geeft het model een zoekstring en een lijst filters terug.

Wat kost het?

Elke herschrijving is een modeloproep voor het zoeken begint, dus elke herschrijving voegt bij elke vraag wachttijd en tokens toe. Multi-query vermenigvuldigt het aantal zoekopdrachten, en HyDE laat het model een alinea schrijven in plaats van een regel. Achter een chatvenster waar iemand zit te wachten tikt dat aan, dus loont een check op lengte die de herschrijving overslaat bij korte, duidelijke vragen. Beheerde diensten rekenen net zo: de query rewrite van Azure draait enkel met de betalende semantic ranker, in een beperkt aantal regio's, en is nog in preview. Mislukt de oproep, dan valt de dienst terug op de oorspronkelijke vraag en meldt hij dat. Bouw diezelfde terugval in als je de stap zelf schrijft.

Hoe weet je of het helpt?

Query rewriting is een van de makkelijkste aanpassingen aan een RAG-systeem, en ook een van de makkelijkste om toe te voegen zonder dat het iets opbrengt. De eerlijke test is de recall van je retrieval. Neem vijftig tot honderd echte vragen uit je logs, ook de rommelige, en noteer bij elke vraag welk fragment er hoort terug te komen. Draai de retrieval twee keer, op de ruwe vraag en via de herschrijving, en tel hoe vaak het juiste fragment in de top vijf belandt.

Hou enkel de herschrijvingen die dat cijfer doen bewegen. In onze ervaring maken gespreksoplossing en filterextractie een groot verschil bij helpdesk- en klantendata, maakt synoniemen toevoegen een klein verschil, en helpt HyDE in de ene collectie terwijl het in de andere schaadt.

De optie debug: queryRewrites van Azure geeft de varianten naast de resultaten terug, zodat je kan lezen waar effectief op gezocht is. Een zelfgebouwde herschrijfstap hoort hetzelfde te loggen. Zonder die log kan je een slechte herschrijving niet onderscheiden van ontbrekende inhoud, en die twee vragen een andere oplossing.

Query rewriting versus reranking

Allebei zijn het extra modeloproepen bovenop een gewone zoekopdracht, en het verschil zit in waar ze ingrijpen. Query rewriting werkt voor de retrieval: het verandert waarop je zoekt, dus het kan fragmenten binnenhalen die de ruwe vraag nooit had bereikt. Reranking werkt na de retrieval: het herschikt wat terugkwam, dus het kan enkel een fragment naar boven duwen dat al gevonden was. Zit het juiste document niet in de top vijftig, dan redt geen enkele reranker het, en een herschrijving misschien wel. Staat het op plaats twaalf, dan lost een reranker dat op en doet een herschrijving er niet toe. De meeste pijplijnen eindigen met allebei, en de recall-test hierboven vertelt je welke jouw data eerst nodig heeft.

Waar moet je op letten bij query rewriting?

Herschrijvingen drijven af. Het model kan een vraag herschrijven tot iets wat de persoon niet gevraagd heeft. Het voorbeeld van LlamaIndex zelf haalt de filterwaarde "mafia" uit een vraag terwijl de index "Mafia" bevatte, en er kwam niets terug. Log de oorspronkelijke vraag naast de herschreven zoekopdracht, en toon de gebruiker op welke van de twee gezocht is als een antwoord er vreemd uitziet.

Exacte codes gaan verloren. Microsoft waarschuwt dat herschreven zoekopdrachten niet altijd alle exacte termen van het origineel bevatten, en dat telt bij artikelnummers en productcodes. Hou het origineel in de zoekopdracht naast de herschrijvingen, of stuur alles wat op een code lijkt rechtstreeks naar de trefwoordzoekopdracht.

Het gesprek kan de verkeerde context zijn. "Die" oplossen uit de vorige beurt veronderstelt dat de persoon nog over hetzelfde bezig is. Wie van onderwerp verandert, krijgt het oude onderwerp mee. Een venster van een of twee beurten is meestal genoeg.