RAG Query Rewriting: Løs opfølgende spørgsmål til AI-chatbots korrekt

Et enkelt spørgsmål som "Og hvor længe gælder det?" er ofte helt tydeligt for mennesker. De husker det tidligere drøftede produkt, placeringen og den omtalte frist. En videnssøgning ser derimod i første omgang kun få ord. Uden den rette samtalekontekst finder den måske slet ingenting eller søger efter det forkerte emne. RAG Query Rewriting løser dette problem ved at omdanne et kontekstafhængigt opfølgende spørgsmål til en selvstændig søgeforespørgsel inden søgningen.

Det lyder som et lille mellemtrin, men det afgør ofte kvaliteten af en flerleddet website-chat. Denne guide viser, hvordan teams løser opfølgende spørgsmål, hvornår det er bedre at stille opklarende spørgsmål, og hvordan de forhindrer, at en omskrivning sniger nye kendsgerninger, forkerte rettigheder eller forældet kontekst ind i søgningen.

Hvorfor opfølgende spørgsmål overbelaster en videnssøgning

Det første brugerspørgsmål er for det meste konkret: "Hvilken garanti gælder for Model A?" Derefter følger korte sætninger som "Hvad med den større variant?", "Gælder det også i Danmark?" eller "Hvad skal jeg bruge til det?". Pronominer, udeladte subjekter og henvisninger til tidligere svar er naturlige i en samtale. Som isoleret søgeforespørgsel er de dog svage.

En klassisk søgepipeline med søgeord, vektorer eller Hybrid Search kan kun vurdere det, den modtager som forespørgsel. Reranking forbedrer rækkefølgen af eksisterende resultater, men erstatter ikke den manglende betydning af "det" eller "til det". Query Rewriting placeres derfor foran: Det former en søgbar, selvstændig forespørgsel ud fra det aktuelle spørgsmål og det relevante samtaleforløb.

Hvad en god omskrivning skal yde

En vellykket rewrite-forespørgsel er tilstrækkelig fuldstændig til retrieval, men holder sig tæt op ad brugerens hensigt. Ud fra "Og hvad med Danmark?" kan der for eksempel opstå "Hvilke garantibetingelser gælder for Model A i Danmark?", hvis Model A og garanti er entydigt fastlagt i den umiddelbart foregående dialog. Omskrivningen besvarer endnu ikke spørgsmålet. Den tjener udelukkende til at finde relevante kilder.

Den aktuelle Azure-arkitekturvejledning til Conversational RAG anbefaler at inddrage relevant samtalehistorik og formulere det aktuelle spørgsmål før retrieval som en selvstændig forespørgsel med opløste referencer. Vigtig er den opdeling, der også fremgår der: Til det efterfølgende svar bevares det oprindelige brugerspørgsmål. På den måde kan systemet kontrollere, om de fundne dokumenter rent faktisk passer til det stillede spørgsmål.

Suppler, men opfind ikke

En rewriter må gerne overtages entydigt eksisterende oplysninger: produkt, version, land, sprog eller den senest nævnte proces. Den må dog ikke tilføje et manglende kundenummer, fastlægge en formodet produktvariant eller forvandle en usikker tidsangivelse til en konkret dato. En tilsyneladende nyttig, men opdigtet præcisering sender søgningen sikkert i den forkerte retning.

Rettigheder forbliver uden for tekstmodellen

Klient, tilmeldt bruger, frigivede dokumentområder og roller bestemmes på serversiden. De hører ikke hjemme som en frit formuleret påstand i rewrite-forespørgslen. Backend sætter de tilhørende metadatafiltre separat og uforanderligt. Hverken et tidligere chatbidrag eller en modelomskrivning må låse op for et større søgeområde.

Konteksten kræver et bevidst budget

At sende hele chatforløbet ufiltreret til rewriteren er sjældent en god løsning. Gamle emner kan skygge for det aktuelle spørgsmål, personhenførbare oplysninger kan blive ført unødigt videre, og lange forløb øger latenstid og omkostninger. Som praktisk pejlemærke nævner Microsoft-vejledningen to til fem af de seneste samtalerunder samt et resumé af ældre indhold. Dette er ikke en universel grænseværdi, men et startpunkt for egne tests.

En kompakt kontekstpakke kan bestå af følgende elementer:

• det uændrede aktuelle brugerspørgsmål,
• få umiddelbart relevante bruger- og assistentbidrag,
• allerede bekræftede enheder som produkt, proces eller placering,
• locale og tidszone som tekniske felter,
• et kortfattet, kontrolleret resumé af ældre dialogdele og
• versionen af rewrite-regel, vidensindeks og retrieval-konfiguration.

De faktiske dokumentrettigheder holdes adskilt herfra. Ligeledes bør unødvendige e-mailadresser, ordrenumre eller fuldstændige svar fjernes før rewrite. Et dataminimeret forløb gør det desuden lettere at fejlsøge senere.

En robust proces i seks trin

1. Kontroller selvstændighed: Et klart nyt spørgsmål som "Hvordan ændrer jeg min adgangskode?" kan sendes direkte til søgningen. Ikke alle beskeder kræver en model-rewrite.
2. Identificer referencer: Systemet markerer pronominer, ellipser, sammenligningsord og henvisninger som "dér", "begge" eller "den anden mulighed".
3. Vælg relevant kontekst: Kun de bidrag, der sandsynliggør en opløsning af disse referencer, inddrages. Et bevidst emneskift afslutter den gamle kontekst.
4. Afgør rewrite eller opklarende spørgsmål: Hvis præcis én opløsning er pålidelig, oprettes en selvstændig søgeforespørgsel. Hvis der er flere sandsynlige betydninger, stiller chatbotten et kort opklarende spørgsmål.
5. Søg og opdel om nødvendigt: Forespørgslen kører gennem Keyword-, Vektor- eller Hybrid Search. Flerdelte spørgsmål kan opdeles i klart definerede underspørgsmål.
6. Svar på det oprindelige spørgsmål: Svaret genereres ud fra de fundne kilder, refererer til den oprindelige ordlyd og oplyser åbent om usikkerheder eller manglende dokumentation.

Microsofts oversigt over Agentic Retrieval beskriver en beslægtet proces: Forespørgsel og samtalehistorik indgår i planlægningen, fokuserede underspørgsmål udføres parallelt, og resultaterne samles bagefter. Amazon Bedrock dokumenterer ligeledes planlægning, iterative underspørgsmål og kontrol af, om det fundne indhold er tilstrækkeligt til et svar. Sådanne produktfunktioner kan overtages af dele af pipelinen; din egen applikations kvalitets- og sikkerhedskontroller er dog fortsat nødvendige.

Rewrite, opklarende spørgsmål eller Query Decomposition?

Input	Passende reaktion	Begrundelse
"Og gælder det i Danmark?" efter et entydigt garantispørgsmål	Formuler en selvstændig forespørgsel	Emne og reference er entydige.
"Hvad med den anden?" efter tre nævnte varianter	Stil et kort opklarende spørgsmål	Flere opløsninger er sandsynlige.
"Sammenlign pris, leveringstid og returret for begge modeller"	Opdel i fokuserede underspørgsmål	Flere uafhængige aspekter kræver pålidelige resultater.
"Nyt emne: Hvordan kontakter jeg support?"	Søg uden den gamle produktkontekst	Brugeren signalerer et emneskift.

Query Decomposition er således ikke det samme som Query Rewriting. Rewriting gør et afhængigt spørgsmål selvstændigt; Decomposition opdeler et komplekst spørgsmål i flere søgeopgaver. Bedrock-dokumentationen om Query Decomposition viser, at flere underspørgsmål kan forbedre dækningen. Hver ekstra forespørgsel kræver dog en grænse, en fælles rettighedsmodel og en gennemskuelig sammenfletning.

Behandl rewrite-outputs som kode

Selvom resultatet kun er tekst, bør det have en fast kontrakt. Det er hensigtsmæssigt at bruge et struktureret objekt med felter som standaloneQuery, decision, resolvedReferences og reason. Tilladte beslutninger er for eksempel SEARCH_AS_IS, REWRITE, CLARIFY og DECOMPOSE. Backend validerer længde, sprog og tilladte felter, før en søgning startes.

Rewriteren modtager ingen værktøjer og svarer ikke direkte til brugeren. Systeminstruktioner fra chatforløbet, indsatte dokumenttekster eller opfordringer som "Ignorer reglerne" forbliver data og ikke styrekommandoer. For risikofyldte søgeområder kan en deterministisk regel desuden gennemtvinge, at produkt-, locale- eller klientfiltre aldrig stammer fra fritekst.

Test med dit eget testset til opfølgende spørgsmål

Kvaliteten kan ikke dokumenteres med enkelte vellykkede demonstrationer. Suppler det eksisterende Golden Set for svarkvalitet med ægte flerleddede dialoger. For hvert tilfælde registreres det oprindelige forløb, det aktuelle spørgsmål, den forventede rewrite-beslutning, tilladte enheder, forbudte tilføjelser og forventede kilder.

• Pronominer og udeladte subjekter i korte opfølgende spørgsmål
• Rettelser som "Nej, jeg mente Model B"
• Emneskift og tilbagevenden til et tidligere emne
• Flertydige varianter, der nødvendiggør et opklarende spørgsmål
• Skift af locale, dato og tidszone
• Ulovlige forsøg på at skifte søgeområde eller klient
• Lange forløb med irrelevante ældre detaljer
• Flerdelte spørgsmål, der opdeles og samles igen

Mål adskilt: Stemmer omskrivningen overens med brugerens hensigt? Finder retrieval-processen de forventede kilder? Blev der spurgt ind ved reel flertydighed? Forblev rettighedsfiltre uændrede? Hvor meget ekstra latenstid forårsager trinnet? NIST AI RMF Core placerer gentagen testning, måling og dokumentation i hele AI-livscyklussen. For website-teams betyder det: Ændr kun rewrite-regel, model eller kontekstvalg med regressionstest og observerbar udrulning.

Kompakt tjekliste til website-teams

• Bliver det oprindelige brugerspørgsmål uændret indtil svaret genereres?
• Inddrages kun relevante og dataminimerede dele af forløbet?
• Kan rewriteren vælge klart mellem omskrivning, opklarende spørgsmål og opdeling?
• Tilføjer den udelukkende bekræftede enheder og ingen formodninger?
• Sætter backend locale, klient og rettigheder uafhængigt af rewrite?
• Har hver underforespørgsel faste grænser for mængde, tid og omkostninger?
• Vurderes retrieval-resultater op mod det oprindelige spørgsmål?
• Dækker et testset for flerleddede dialoger referencer, rettelser og emneskift?

Konklusion: Afklar søgespørgsmålet først, svar derefter

RAG Query Rewriting forvandler naturlige, korte bemærkninger i en samtale til en pålidelig søgeforespørgsel. Den største værdi opnås ikke gennem mest muligt kreative omskrivninger, men gennem klare grænser: overtag bekræftet kontekst, løs usikkerhed med opklarende spørgsmål, behold rettigheder på serversiden og evaluer fortsat svaret mod det oprindelige spørgsmål. Start med tyve typiske opfølgende spørgsmål fra din support, marker den forventede beslutning og test enhver ændring mod de samme tilfælde. På den måde bliver en flerleddet chat mere forståelig, uden at søgningen i stilhed besvarer et helt andet spørgsmål.

Kilder

• Microsoft Azure Architecture Center: Prompt Engineering til RAG
• Microsoft Learn: Agentic Retrieval i Azure AI Search
• Amazon Bedrock: Konfiguration af forespørgsler og generering af svar
• Amazon Bedrock: Agentic Retrieval til vidensbaser
• NIST AI Risk Management Framework Core