RAG-Query-Rewriting: Folgefragen für KI-Chatbots richtig auflösen

Eine einzelne Frage wie „Und wie lange gilt das?“ ist für Menschen oft eindeutig. Sie erinnern sich an das zuvor besprochene Produkt, den Standort und die gemeinte Frist. Eine Wissenssuche sieht dagegen zunächst nur wenige Wörter. Ohne passenden Gesprächskontext findet sie vielleicht gar nichts oder sucht nach dem falschen Thema. RAG Query Rewriting löst dieses Problem, indem es eine kontextabhängige Folgefrage vor der Suche in eine eigenständige Suchanfrage überführt.

Das klingt nach einem kleinen Zwischenschritt, entscheidet aber häufig über die Qualität eines mehrstufigen Website-Chats. Dieser Leitfaden zeigt, wie Teams Folgefragen auflösen, wann sie besser nachfragen und wie sie verhindern, dass eine Umschreibung neue Fakten, falsche Berechtigungen oder veralteten Kontext in die Suche einschleust.

Warum Folgefragen eine Wissenssuche überfordern

Die erste Nutzerfrage ist meist konkret: „Welche Garantie gilt für Modell A?“ Danach folgen kurze Wendungen wie „Und für die größere Variante?“, „Gilt das in Österreich auch?“ oder „Was brauche ich dafür?“. Pronomen, ausgelassene Subjekte und Verweise auf frühere Antworten sind im Gespräch natürlich. Als isolierte Suchanfrage sind sie jedoch schwach.

Eine klassische Keyword-, Vektor- oder Hybrid-Search-Pipeline kann nur bewerten, was sie als Anfrage erhält. Reranking verbessert die Reihenfolge vorhandener Treffer, ersetzt aber nicht die fehlende Bedeutung von „das“ oder „dafür“. Query Rewriting sitzt deshalb davor: Es formt aus aktueller Frage und relevantem Verlauf eine suchbare, eigenständige Anfrage.

Was eine gute Umschreibung leisten muss

Eine gelungene Rewrite-Anfrage ist vollständig genug für das Retrieval, bleibt aber eng an der Nutzerabsicht. Aus „Und für Österreich?“ kann beispielsweise „Welche Garantiebedingungen gelten für Modell A in Österreich?“ werden, wenn Modell A und Garantie im unmittelbar vorherigen Dialog eindeutig feststehen. Die Umschreibung beantwortet die Frage noch nicht. Sie dient ausschließlich dazu, passende Quellen zu finden.

Die aktuelle Azure-Architekturleitlinie zu Conversational RAG empfiehlt, relevante Gesprächshistorie einzubeziehen und die aktuelle Frage vor dem Retrieval als eigenständige Anfrage mit aufgelösten Referenzen zu formulieren. Wichtig ist die dort ebenfalls erkennbare Trennung: Für die spätere Antwort bleibt die ursprüngliche Nutzerfrage erhalten. So kann das System prüfen, ob die gefundenen Belege tatsächlich zur gestellten Frage passen.

Ergänzen, aber nicht erfinden

Ein Rewriter darf eindeutig vorhandene Angaben übernehmen: Produkt, Version, Land, Sprache oder den zuletzt genannten Vorgang. Er darf jedoch keine fehlende Kundennummer ergänzen, keine vermutete Produktvariante festlegen und keine unsichere Zeitangabe in ein konkretes Datum verwandeln. Eine nützlich klingende, aber erfundene Präzisierung schickt die Suche zuverlässig in die falsche Richtung.

Berechtigungen bleiben außerhalb des Textmodells

Mandant, angemeldeter Nutzer, freigegebene Dokumentbereiche und Rollen werden serverseitig bestimmt. Sie gehören nicht als frei formulierbare Behauptung in die Rewrite-Anfrage. Das Backend setzt die dazugehörigen Metadatenfilter separat und unveränderbar. Weder ein früherer Chatbeitrag noch eine Modellumschreibung darf einen größeren Suchraum freischalten.

Der Kontext braucht ein bewusstes Budget

Den kompletten Chatverlauf ungefiltert an den Rewriter zu senden ist selten eine gute Lösung. Alte Themen können die aktuelle Frage überlagern, personenbezogene Inhalte unnötig weitergetragen werden und lange Verläufe erhöhen Latenz und Kosten. Als praktische Orientierung nennt die Microsoft-Leitlinie zwei bis fünf jüngere Gesprächsrunden und eine Zusammenfassung älterer Inhalte. Das ist kein universeller Grenzwert, sondern ein Startpunkt für eigene Tests.

Ein kompaktes Kontextpaket kann aus folgenden Bausteinen bestehen:

• der unveränderten aktuellen Nutzerfrage,
• wenigen unmittelbar relevanten Nutzer- und Assistentenbeiträgen,
• bereits bestätigten Entitäten wie Produkt, Vorgang oder Standort,
• Locale und Zeitzone als technische Felder,
• einer kurzlebigen, geprüften Zusammenfassung älterer Dialogteile und
• der Version von Rewrite-Regel, Wissensindex und Retrieval-Konfiguration.

Die eigentlichen Dokumentberechtigungen bleiben davon getrennt. Ebenso sollten nicht benötigte E-Mail-Adressen, Bestellnummern oder vollständige Antworten vor dem Rewrite entfernt werden. Ein datensparsamer Verlauf erleichtert zusätzlich die spätere Fehlersuche.

Ein robuster Ablauf in sechs Schritten

1. Eigenständigkeit prüfen: Eine klare neue Frage wie „Wie ändere ich mein Passwort?“ kann direkt in die Suche. Nicht jede Nachricht benötigt ein Modell-Rewrite.
2. Referenzen erkennen: Das System markiert Pronomen, Ellipsen, Vergleichswörter und Verweise wie „dort“, „beide“ oder „die zweite Option“.
3. Relevanten Kontext auswählen: Nur die Beiträge, die diese Referenzen plausibel auflösen, werden übernommen. Ein bewusster Themenwechsel beendet den alten Kontext.
4. Rewrite oder Rückfrage entscheiden: Ist genau eine Auflösung belastbar, entsteht eine eigenständige Suchanfrage. Gibt es mehrere plausible Bedeutungen, stellt der Chatbot eine kurze Klärungsfrage.
5. Suchen und gegebenenfalls zerlegen: Die Anfrage läuft durch Keyword-, Vektor- oder Hybrid Search. Mehrteilige Fragen können in klar benannte Unterfragen zerlegt werden.
6. Zur Originalfrage antworten: Die Antwort wird aus den gefundenen Quellen erzeugt, bezieht sich auf den ursprünglichen Wortlaut und nennt Unsicherheit oder fehlende Belege offen.

Microsofts Übersicht zu Agentic Retrieval beschreibt einen verwandten Ablauf: Anfrage und Gesprächshistorie fließen in die Planung ein, fokussierte Unteranfragen werden parallel ausgeführt und die Treffer anschließend zusammengeführt. Amazon Bedrock dokumentiert ebenfalls Planung, iterative Unteranfragen und die Prüfung, ob die gefundenen Inhalte für eine Antwort ausreichen. Solche Produktfunktionen können Teile der Pipeline übernehmen; die Qualitäts- und Sicherheitsgates der eigenen Anwendung bleiben dennoch notwendig.

Rewrite, Klärungsfrage oder Query Decomposition?

Eingabe	Passende Reaktion	Begründung
„Und gilt das in Österreich?“ nach einer eindeutigen Garantiefrage	Eigenständige Anfrage formulieren	Gegenstand und Bezug sind eindeutig.
„Was ist mit der anderen?“ nach drei genannten Varianten	Kurze Klärungsfrage stellen	Mehrere Auflösungen sind plausibel.
„Vergleiche Preis, Lieferzeit und Rückgabe für beide Modelle“	In fokussierte Unteranfragen zerlegen	Mehrere unabhängige Aspekte brauchen belastbare Treffer.
„Neues Thema: Wie erreiche ich den Support?“	Ohne alten Produktkontext suchen	Der Nutzer signalisiert einen Themenwechsel.

Query Decomposition ist damit nicht dasselbe wie Query Rewriting. Rewriting macht eine abhängige Frage eigenständig; Decomposition teilt eine komplexe Frage in mehrere Suchaufgaben. Die Bedrock-Dokumentation zur Query Decomposition zeigt, dass mehrere Unteranfragen die Abdeckung verbessern können. Jede zusätzliche Anfrage benötigt jedoch ein Limit, ein gemeinsames Berechtigungsmodell und eine nachvollziehbare Zusammenführung.

Rewrite-Ausgaben wie Code behandeln

Auch wenn das Ergebnis nur Text ist, sollte es einen engen Vertrag besitzen. Sinnvoll ist ein strukturiertes Objekt mit Feldern wie standaloneQuery, decision, resolvedReferences und reason. Zulässige Entscheidungen sind beispielsweise SEARCH_AS_IS, REWRITE, CLARIFY und DECOMPOSE. Das Backend validiert Länge, Sprache und erlaubte Felder, bevor eine Suche startet.

Der Rewriter erhält keine Werkzeuge und antwortet nicht direkt an den Nutzer. Systemanweisungen aus dem Chatverlauf, eingefügte Dokumenttexte oder Aufforderungen wie „Ignoriere die Regeln“ bleiben Daten, nicht Steuerbefehle. Für riskante Suchräume kann eine deterministische Regel zusätzlich erzwingen, dass Produkt-, Locale- oder Mandantenfilter niemals aus Freitext stammen.

Mit einem eigenen Folgefragen-Testset prüfen

Die Qualität lässt sich nicht mit einzelnen gelungenen Demos belegen. Ergänzen Sie das bestehende Golden Set für Antwortqualität um echte Mehrfachdialoge. Für jeden Fall werden ursprünglicher Verlauf, aktuelle Frage, erwartete Rewrite-Entscheidung, zulässige Entitäten, verbotene Ergänzungen und erwartete Quellen festgehalten.

• Pronomen und ausgelassene Subjekte in kurzen Folgefragen
• Korrekturen wie „Nein, ich meinte Modell B“
• Themenwechsel und Rückkehr zu einem früheren Thema
• mehrdeutige Varianten, die zwingend eine Rückfrage brauchen
• Locale-, Datums- und Zeitzonenwechsel
• unzulässige Versuche, den Suchraum oder Mandanten zu wechseln
• lange Verläufe mit irrelevanten älteren Details
• mehrteilige Fragen, die zerlegt und wieder zusammengeführt werden

Messen Sie getrennt: Stimmt die Umschreibung mit der Nutzerabsicht überein? Findet das Retrieval die erwarteten Quellen? Wurde bei echter Mehrdeutigkeit nachgefragt? Blieben Berechtigungsfilter unverändert? Wie viel zusätzliche Latenz verursacht der Schritt? Der NIST AI RMF Core ordnet wiederholtes Testen, Messen und Dokumentieren in den gesamten KI-Lebenszyklus ein. Für Website-Teams heißt das: Rewrite-Regel, Modell oder Kontextauswahl nur mit Regressionstest und beobachtbarem Rollout ändern.

Kompakte Checkliste für Website-Teams

• Bleibt die ursprüngliche Nutzerfrage unverändert bis zur Antwort erhalten?
• Werden nur relevante und datensparsame Verlaufsteile einbezogen?
• Kann der Rewriter klar zwischen Umschreibung, Rückfrage und Zerlegung wählen?
• Ergänzt er ausschließlich bestätigte Entitäten und keine Vermutungen?
• Setzt das Backend Locale, Mandant und Berechtigungen unabhängig vom Rewrite?
• Besitzt jede Unteranfrage feste Mengen-, Zeit- und Kostenlimits?
• Werden Retrieval-Treffer gegen die ursprüngliche Frage bewertet?
• Deckt ein Mehrfachdialog-Testset Referenzen, Korrekturen und Themenwechsel ab?

Fazit: Erst die Suchfrage klären, dann antworten

RAG Query Rewriting macht aus natürlicher Gesprächskürze eine belastbare Suchanfrage. Der größte Nutzen entsteht nicht durch möglichst kreative Umschreibungen, sondern durch klare Grenzen: bestätigten Kontext übernehmen, Unsicherheit per Rückfrage lösen, Berechtigungen serverseitig halten und die Antwort weiterhin an der Originalfrage prüfen. Starten Sie mit zwanzig typischen Folgefragen aus Ihrem Support, markieren Sie die erwartete Entscheidung und testen Sie jede Änderung gegen dieselben Fälle. So wird ein mehrstufiger Chat verständlicher, ohne dass die Suche stillschweigend eine andere Frage beantwortet.

Quellen

• Microsoft Azure Architecture Center: Prompt Engineering für RAG
• Microsoft Learn: Agentic Retrieval in Azure AI Search
• Amazon Bedrock: Abfragen und Antwortgenerierung konfigurieren
• Amazon Bedrock: Agentic Retrieval für Wissensbasen
• NIST AI Risk Management Framework Core