RAG Query Rewriting: Hantera uppföljningsfrågor i AI-chatbottar korrekt

En enskild fråga som ”Och hur länge gäller det?” är ofta helt tydlig för människor. De kommer ihåg den tidigare nämnda produkten, platsen och vilken tidsfrist som avsågs. En kunskapssökning ser däremot inledningsvis bara ett fåtal ord. Utan passande samtalssammanhang hittar den kanske ingenting alls eller söker efter fel ämne. RAG Query Rewriting löser detta problem genom att omvandla en kontextberoende uppföljningsfråga till en självständig sökfråga innan sökningen genomförs.

Det låter som ett litet mellansteg, men det avgör ofta kvaliteten på en flerstegs webbplatschat. Denna guide visar hur team löser uppföljningsfrågor, när det är bättre att ställa en motfråga och hur de förhindrar att en omformulering för in nya fakta, felaktiga behörigheter eller föråldrad kontext i sökningen.

Varför uppföljningsfrågor överväldigar en kunskapssökning

Användarens första fråga är oftast konkret: ”Vilken garanti gäller för Modell A?” Därefter följer korta uttryck som ”Och för den större varianten?”, ”Gäller det i Österrike också?” eller ”Vad behöver jag för det?”. Pronomen, utelämnade subjekt och hänvisningar till tidigare svar är naturliga i ett samtal. Som isolerade sökfrågor är de dock svaga.

En klassisk nyckelords-, vektor- eller Hybrid-Search-pipeline kan bara utvärdera vad den får som sökfråga. Reranking förbättrar ordningen på befintliga träffar, men ersätter inte den saknade betydelsen av ”det” eller ”för det”. Query Rewriting placeras därför före: Den formar om den aktuella frågan och relevant historik till en sökbar, självständig sökfråga.

Vad en bra omformulering måste uppnå

En lyckad Rewrite-fråga är tillräckligt fullständig för sökningen (retrieval), men håller sig nära användarens avsikt. Exempelvis kan ”Och för Österrike?” bli ”Vilka garantivillkor gäller för Modell A i Österrike?”, om Modell A och garanti är entydigt fastställda i den omedelbart föregående dialogen. Omformuleringen besvarar inte frågan ännu. Den fungerar uteslutande till att hitta passande källor.

Den aktuella Azure-arkitekturriktlinjen för Conversational RAG rekommenderar att inkludera relevant samtalshistorik och formulera den aktuella frågan före retrieval som en självständig fråga med upplösta referenser. Viktigt är den uppdelning som också framgår där: För det slutliga svaret behålls användarens ursprungliga fråga. På så sätt kan systemet kontrollera om de hittade beläggen faktiskt passar till den ställda frågan.

Komplettera, men inte hitta på

En Rewriter får ta över tydligt befintliga uppgifter: produkt, version, land, språk eller den senast nämnda processen. Den får dock inte lägga till ett saknat kundnummer, inte fastställa en förmodad produktvariant och inte förvandla en osäker tidsangivelse till ett konkret datum. En precisering som låter användbar men är påhittad skickar sökningen garanterat i fel riktning.

Behörigheter stannar utanför textmodellen

Organisation (tenant), inloggad användare, godkända dokumentområden och roller bestäms på serversidan. De hör inte hemma som fritt formulerade påståenden i Rewrite-frågan. Backend sätter tillhörande metadatafilter separat och oföränderligt. Varken ett tidigare chattsvar eller en modellomformulering får låsa upp ett större sökutrymme.

Kontexten behöver en medveten budget

Att skicka hela chatthistoriken ofiltrerad till sin Rewriter är sällan en bra lösning. Gamla ämnen kan överskugga den aktuella frågan, personuppgifter kan föras vidare i onödan och långa historiker ökar latens och kostnader. Som en praktisk vägledning nämner Microsofts riktlinjer två till fem nyare samtalsomgångar och en sammanfattning av äldre innehåll. Det är inte en universell gräns, utan en startpunkt för egna tester.

Ett kompakt kontextpaket kan bestå av följande byggstenar:

• den oförändrade aktuella användarfrågan,
• ett fåtal omedelbart relevanta meddelanden från användare och assistent,
• redan bekräftade entiteter som produkt, ärende eller plats,
• Locale och tidszon som tekniska fält,
• en kortlivad, granskad sammanfattning av äldre dialogdelar, samt
• versionen av Rewrite-regel, kunskapsindex och retrieval-konfiguration.

De faktiska dokumentbehörigheterna hålls åtskilda från detta. Likaså bör onödiga e-postadresser, ordernummer eller fullständiga svar tas bort före Rewrite. En datasnål historik underlättar dessutom framtida felsökning.

Ett robust flöde i sex steg

1. Kontrollera självständighet: En tydlig ny fråga som ”Hur ändrar jag mitt lösenord?” kan gå direkt till sökningen. Inte varje meddelande kräver en modell-Rewrite.
2. Identifiera referenser: Systemet markerar pronomen, ellipser, jämförelseord och hänvisningar som ”där”, ”båda” eller ”det andra alternativet”.
3. Välj relevant kontext: Endast de meddelanden som rimligen löser dessa referenser tas med. Ett medvetet ämnesbyte avslutar den gamla kontexten.
4. Besluta om Rewrite eller klargörande fråga: Om det finns exakt en tillförlitlig tolkning skapas en självständig sökfråga. Om det finns flera rimliga betydelser ställer chatboten en kort klargörande fråga.
5. Sök och vid behov dela upp: Frågan körs genom Keyword-, Vektor- eller Hybrid Search. Flerdelade frågor kan delas upp i tydligt namngivna underfrågor.
6. Svara på originalfrågan: Svaret genereras från de hittade källorna, relaterar till den ursprungliga ordalydelsen och redovisar osäkerhet eller saknade belägg öppet.

Microsofts översikt över Agentic Retrieval beskriver ett besläktat flöde: Fråga och samtalshistorik vävs in i planeringen, fokuserade underfrågor körs parallellt och träffarna sammanfogas sedan. Amazon Bedrock dokumenterar också planering, iterativa underfrågor och kontrollen av om det hittade innehållet räcker för ett svar. Sådana produktfunktioner kan ta över delar av pipelinen; kvalitet- och säkerhetsspärrarna i den egna applikationen behövs fortfarande.

Rewrite, klargörande fråga eller Query Decomposition?

Indata	Lämplig reaktion	Motivering
”Och gäller det i Österrike?” efter en entydig garantifråga	Formulera en självständig fråga	Sakfråga och referens är entydiga.
”Vad gäller för den andra?” efter att tre varianter nämnts	Ställ en kort klargörande fråga	Flera tolkningar är rimliga.
”Jämför pris, leveranstid och retur för båda modellerna”	Dela upp i fokuserade underfrågor	Flera oberoende aspekter kräver tillförlitliga träffar.
”Nytt ämne: Hur når jag supporten?”	Sök utan gammal produktkontext	Användaren signalerar ett ämnesbyte.

Query Decomposition är alltså inte samma sak som Query Rewriting. Rewriting gör en beroende fråga självständig; Decomposition delar upp en komplex fråga i flera sökuppgifter. Bedrock-dokumentationen om Query Decomposition visar att flera underfrågor kan förbättra täckningen. Varje extra fråga behöver dock en gräns, en gemensam behörighetsmodell och en spårbar sammanfoga-process.

Hantera Rewrite-utdata som kod

Även om resultatet bara är text bör det ha ett strikt kontrakt. Ett strukturerat objekt med fält som standaloneQuery, decision, resolvedReferences och reason är lämpligt. Tillåtna beslut är exempelvis SEARCH_AS_IS, REWRITE, CLARIFY och DECOMPOSE. Backend validerar längd, språk och tillåtna fält innan en sökning startar.

Rewritern får inga verktyg och svarar inte direkt till användaren. Systeminstruktioner från chatthistoriken, infogade dokumenttexter eller uppmaningar som ”Ignorera reglerna” förblir data, inte styrmeddelanden. För riskfyllda sökutrymmen kan en deterministisk regel dessutom tvinga fram att produkt-, Locale- eller tenant-filter aldrig härstammar från fritext.

Testa med ett eget testset för uppföljningsfrågor

Kvaliteten kan inte bevisas med enstaka lyckade demon. Komplettera det befintliga Golden Set för svarskvalitet med verkliga flersektionsdialoger. För varje fall dokumenteras ursprunglig historik, aktuell fråga, förväntat Rewrite-beslut, tillåtna entiteter, förbjudna tillägg och förväntade källor.

• Pronomen och utelämnade subjekt i korta uppföljningsfrågor
• Korrigeringar som ”Nej, jag menade Modell B”
• Ämnesbyten och återgång till ett tidigare ämne
• Mångtydiga varianter som tvingande kräver en motfråga
• Ändringar av Locale, datum och tidszon
• Otillåtna försök att byta sökutrymme eller tenant
• Långa historiker med irrelevanta äldre detaljer
• Flerdelade frågor som delas upp och sammanfogas igen

Mät separat: Stämmer omformuleringen överens med användarens avsikt? Hittar sökningen de förväntade källorna? Ställdes en motfråga vid äkta mångtydighet? Förblev behörighetsfilter oförändrade? Hur mycket extra latens orsakar steget? NIST AI RMF Core placerar upprepad testning, mätning och dokumentation i hela AI-livscykeln. För webbplatsteam innebär det: Ändra bara Rewrite-regel, modell eller kontextval med regressionstest och observerbar utrullning.

Kompakt checklista för webbplatsteam

• Behålls den ursprungliga användarfrågan oförändrad ända till svaret ges?
• Inkluderas endast relevanta och datasnåla delar av historiken?
• Kan Rewritern välja tydligt mellan omformulering, motfråga och uppdelning?
• Kompletterar den uteslutande bekräftade entiteter och inga gissningar?
• Sätter backend Locale, tenant och behörigheter oberoende av Rewrite?
• Har varje underfråga fasta gränser för mängd, tid och kostnad?
• Utvärderas retrieval-träffar mot den ursprungliga frågan?
• Täcker ett testset för flerstegsdialoger in referenser, korrigeringar och ämnesbyten?

Slutsats: Klargör sökfrågan först, svara sedan

RAG Query Rewriting gör naturligt kortfattade samtal till tillförlitliga sökfrågor. Den största nytta uppstår inte genom så kreativa omformuleringar som möjligt, utan genom tydliga gränser: ta över bekräftad kontext, lös osäkerhet med motfrågor, håll behörigheter på serversidan och utvärdera fortfarande svaret mot originalfrågan. Börja med tjugo typiska uppföljningsfrågor från er support, markera förväntat beslut och testa varje ändring mot samma fall. Då blir en chatt i flera steg mer begriplig utan att sökningen tyst besvarar en helt annan fråga.

Källor

• Microsoft Azure Architecture Center: Prompt Engineering för RAG
• Microsoft Learn: Agentic Retrieval i Azure AI Search
• Amazon Bedrock: Konfigurera sökfrågor och svarsgenerering
• Amazon Bedrock: Agentic Retrieval för kunskapsbaser
• NIST AI Risk Management Framework Core