RAG Query Rewriting: Jak správně vyřešit doplňující otázky AI chatbotu

Jedna otázka jako „A jak dlouho to platí?“ je pro člověka často jednoznačná. Pamatuje si dříve probíraný produkt, místo i zamýšlenou lhůtu. Vyhledávání ve znalostní bázi však nejprve vidí jen několik slov. Bez správného kontextu nemusí najít nic, nebo začne hledat úplně jiné téma. RAG Query Rewriting tento problém řeší tím, že kontextovou doplňující otázku před vyhledáním převede na samostatný dotaz.

Jde o malý mezikrok, který však často rozhoduje o kvalitě vícekrokového chatu na webu. Tento průvodce vysvětluje, jak týmy vyřeší doplňující otázky, kdy se mají raději doptat a jak zabránit tomu, aby přepsání do vyhledávání vložilo nové skutečnosti, chybné oprávnění nebo zastaralý kontext.

Proč doplňující otázky přetěžují vyhledávání znalostí

První otázka bývá konkrétní: „Jaká záruka platí pro model A?“ Poté přijdou krátké obraty jako „A pro větší variantu?“, „Platí to i v Rakousku?“ nebo „Co k tomu potřebuji?“. Zájmena, vynechané podměty a odkazy na předchozí odpověď jsou v rozhovoru přirozené. Jako izolovaný vyhledávací dotaz jsou ale slabé.

Klasická pipeline klíčových slov, vektorů nebo hybridního vyhledávání umí vyhodnotit jen to, co dostane jako dotaz. Reranking zlepší pořadí existujících výsledků, nenahradí však chybějící význam slov „to“ či „pro to“. Query rewriting proto stojí před ním: z aktuální otázky a relevantní historie vytváří vyhledatelný samostatný dotaz.

Co musí dobré přepsání splnit

Povedený přepsaný dotaz je pro retrieval dostatečně úplný, ale zůstává těsně u záměru uživatele. Z „A pro Rakousko?“ se může stát „Jaké záruční podmínky platí pro model A v Rakousku?“, pokud jsou model A a záruka v předchozím dialogu jasně potvrzené. Přepsání ještě otázku nezodpovídá; slouží výhradně k nalezení vhodných zdrojů.

Aktuální architektonický návod Azure pro konverzační RAG doporučuje zahrnout relevantní historii a aktuální otázku před retrievalem formulovat jako samostatný dotaz s vyřešenými odkazy. Pro následnou odpověď musí zůstat zachována původní otázka, aby systém mohl ověřit, že nalezené doklady skutečně odpovídají tomu, na co se uživatel ptal.

Doplňovat, ale nevymýšlet

Rewriter smí převzít jednoznačně přítomné údaje: produkt, verzi, zemi, jazyk nebo naposledy zmíněný postup. Nesmí však doplnit chybějící zákaznické číslo, určit domnělou variantu výrobku ani změnit neurčitý čas na konkrétní datum. Užitečně znějící, ale vymyšlené upřesnění pošle vyhledávání spolehlivě špatným směrem.

Oprávnění zůstávají mimo textový model

Tenanta, přihlášeného uživatele, povolené oblasti dokumentů a role určuje server. Nejde o volně formulovatelné tvrzení v přepsaném dotazu. Backend přidává odpovídající filtry metadat odděleně a neměnně. Ani starší zpráva v chatu, ani přepsání modelem nesmí otevřít větší vyhledávací prostor.

Kontext potřebuje vědomý rozpočet

Posílat rewriteru celý chat bez filtru bývá zřídka dobré řešení. Starší témata mohou překrýt novou otázku, osobní údaje se zbytečně přenášejí a dlouhá historie zvyšuje latenci i náklady. Návod Microsoftu uvádí jako praktický výchozí bod dvě až pět novějších kol rozhovoru a shrnutí staršího obsahu. Nejde o univerzální limit, ale o hypotézu pro vlastní testy.

Kompaktní balíček kontextu může obsahovat následující části:

• nezměněná aktuální otázka uživatele,
• jen několik bezprostředně relevantních příspěvků uživatele a asistenta,
• potvrzené entity jako produkt, případ nebo místo,
• locale a časové pásmo jako technická pole,
• krátkodobé ověřené shrnutí starší části dialogu a
• verze pravidla přepisování, indexu znalostí a konfigurace retrievalu.

Skutečná oprávnění dokumentů zůstávají oddělená. Před přepsáním je vhodné odstranit nepotřebné e-mailové adresy, čísla objednávek a celé odpovědi. Datově úsporná historie zároveň zjednodušuje pozdější analýzu chyb.

Robustní postup v šesti krocích

1. Ověřit samostatnost: jasná nová otázka může do vyhledávání přímo; ne každá zpráva potřebuje přepsání modelem.
2. Rozpoznat odkazy: systém označí zájmena, elipsy, srovnání a odkazy jako „tam“, „oba“ nebo „druhá možnost“.
3. Vybrat relevantní kontext: převezmou se pouze příspěvky, které odkazy věrohodně vysvětlují; vědomá změna tématu starý kontext ukončí.
4. Rozhodnout mezi přepsáním a dotazem: je-li jedna interpretace podložená, vznikne samostatný dotaz; při více možnostech položí chatbot krátkou upřesňující otázku.
5. Vyhledat a případně rozdělit: dotaz prochází keyword, vector nebo hybrid search; vícedílné otázky lze rozdělit na pojmenované poddotazy.
6. Odpovědět na původní otázku: odpověď vychází z nalezených zdrojů, vztahuje se k původnímu znění a otevřeně uvede nejistotu či chybějící doklady.

Přehled agentic retrieval od Microsoftu popisuje příbuzný postup: dotaz a historie vstupují do plánování, zaměřené poddotazy se provedou souběžně a výsledky se pak spojí. Amazon Bedrock dokumentuje také plánování, iterativní poddotazy a kontrolu dostatečnosti nalezeného obsahu. Tyto funkce mohou část pipeline převzít, ale kvalitativní a bezpečnostní brány vlastní aplikace zůstávají nutné.

Přepsání, upřesňující otázka nebo query decomposition?

Vstup	Vhodná reakce	Důvod
„Platí to i v Rakousku?“ po jednoznačné otázce k záruce	Formulovat samostatný dotaz	Předmět i odkaz jsou jednoznačné.
„A co ta druhá?“ po třech zmíněných variantách	Položit krátkou upřesňující otázku	Je pravděpodobných více interpretací.
„Porovnej cenu, dodání a vrácení pro oba modely“	Rozdělit na zaměřené poddotazy	Více nezávislých hledisek potřebuje ověřené výsledky.
„Nové téma: jak se spojím s podporou?“	Hledat bez starého produktového kontextu	Uživatel signalizuje změnu tématu.

Query decomposition tedy není totéž jako query rewriting. Rewriting osamostatní závislou otázku, decomposition rozdělí složitou otázku na několik úloh. Dokumentace Bedrocku k query decomposition ukazuje, že více poddotazů může zlepšit pokrytí. Každý další dotaz ale potřebuje limit, společný model oprávnění a vysvětlitelné spojení výsledků.

Se vstupem rewriteru zacházejte jako s kódem

I když je výsledek jen text, má mít úzký kontrakt. Vhodný je strukturovaný objekt s poli standaloneQuery, decision, resolvedReferences a reason. Povolené volby mohou být SEARCH_AS_IS, REWRITE, CLARIFY a DECOMPOSE. Backend před spuštěním hledání ověří délku, jazyk a povolená pole.

Rewriter nedostává nástroje a neodpovídá přímo uživateli. Systémové instrukce z historie, vložený text dokumentu nebo výzvy typu „ignoruj pravidla“ jsou data, nikoli příkazy. U rizikových prostorů může deterministické pravidlo navíc vynutit, aby filtry produktu, locale a tenanta nikdy nevycházely z volného textu.

Ověřujte na vlastním testsetu doplňujících otázek

Kvalitu nelze dokázat několika vydařenými ukázkami. Rozšiřte stávající golden set pro kvalitu odpovědí o skutečné vícekrokové dialogy. U každého případu uchovejte původní historii, aktuální otázku, očekávané rozhodnutí, povolené entity, zakázaná doplnění a očekávané zdroje.

• zájmena a vynechané podměty v krátkých doplňujících otázkách,
• opravy jako „Ne, myslel jsem model B“,
• změnu tématu a návrat ke staršímu tématu,
• nejednoznačné varianty, které vyžadují dotaz,
• změnu locale, data a časového pásma,
• nepřípustné pokusy změnit vyhledávací prostor nebo tenanta,
• dlouhé historie s nerelevantními staršími detaily a
• vícedílné otázky, které se rozdělí a znovu spojí.

Měřte odděleně: odpovídá přepsání záměru uživatele, najde retrieval očekávané zdroje, systém se při skutečné nejednoznačnosti doptal a filtry oprávnění zůstaly beze změny? Sledujte také přidanou latenci. NIST AI RMF Core řadí opakované testování, měření a dokumentování do celého životního cyklu AI. Pravidlo přepisování, model i výběr kontextu proto měňte jen s regresním testem a pozorovatelným rolloutem.

Kompaktní kontrolní seznam pro webové týmy

• Zůstává původní otázka uživatele do odpovědi nezměněná?
• Zahrnuje se jen relevantní a datově úsporný kontext?
• Rozliší rewriter přepsání, upřesnění a rozdělení?
• Doplňuje výhradně potvrzené entity, nikoli domněnky?
• Nastavuje backend locale, tenanta a oprávnění nezávisle na přepsání?
• Má každý poddotaz pevné limity množství, času a nákladů?
• Vyhodnocují se výsledky retrievalu vůči původní otázce?
• Pokrývá testset odkazy, opravy i změny tématu?

Závěr: nejdříve ujasnit vyhledávací otázku, pak odpovídat

RAG Query Rewriting promění přirozenou stručnost rozhovoru v použitelný vyhledávací dotaz. Největší přínos nepřinášejí kreativní formulace, ale jasné hranice: převzít potvrzený kontext, nejistotu řešit doplňující otázkou, držet oprávnění na serveru a odpověď dál ověřovat proti původní otázce. Začněte s dvaceti typickými doplňujícími otázkami podpory, označte očekávané rozhodnutí a každou změnu testujte na stejných případech. Vícekrokový chat pak bude srozumitelnější, aniž by vyhledávání potichu odpovídalo na jinou otázku.

Zdroje

• Microsoft Azure Architecture Center: Prompt Engineering pro RAG
• Microsoft Learn: Agentic Retrieval v Azure AI Search
• Amazon Bedrock: Konfigurace dotazů a generování odpovědí
• Amazon Bedrock: Agentic Retrieval pro znalostní báze
• NIST AI Risk Management Framework Core