Query Rewriting: Definition, Verfahren, Abgrenzung

Query Rewriting formt eine Nutzeranfrage in eine oder mehrere bessere Suchanfragen um, bevor eine Suchmaschine oder ein KI-Assistent (Retrieval-System) darin nach passenden Dokumenten sucht. Ziel ist es, mehrdeutige, unvollständige oder umgangssprachliche Anfragen so aufzubereiten, dass die Suche passendere Treffer liefert.

Was ist Query Rewriting?

Query Rewriting sitzt zwischen der Nutzer-Eingabe und dem Nachschlage-Schritt (Retrieval): dem Moment, in dem das System die Wissensdatenbank nach passenden Dokumenten durchsucht. Eine Roh-Anfrage läuft zuerst durch einen Rewriter, der eine oder mehrere aufbereitete Suchanfragen erzeugt. Diese werden gegen einen Suchindex gestellt, entweder klassisch nach Stichwort, per Bedeutungs-Ähnlichkeit (Vektor-Suche) oder als Kombination aus beidem (Hybrid-Suche). Ein optionaler Reranker sortiert die Trefferliste anschließend nach Relevanz, bevor die Top-Ergebnisse als Kontext an ein Sprachmodell (LLM, Large Language Model) übergeben werden. Der Rewriter selbst kann ein regelbasiertes Modul sein; üblich ist inzwischen ein Sprachmodell mit einem spezialisierten Prompt.

Der Schritt existiert, weil reale Nutzeranfragen selten so formuliert sind, dass sie ein Vektorraum-Index gut trifft. Anfragen sind kurz ("PTO Regeln?"), mehrdeutig ("Wie läuft das hier ab?" ohne Bezug), umgangssprachlich ("was zahlt die Firma für Fortbildung"), tippfehlerbehaftet oder ein Follow-up mit unaufgelösten Pronomen ("Und für Werkstudenten?"). Embeddings dieser Rohanfragen liegen im Vektorraum oft ungünstig; die Trefferliste enthält dann entweder gar keine oder nur schwach passende Dokumente. Ein aufbereiteter Rewrite hebt Recall und Precision spürbar, ohne den Index oder das Sprachmodell zu verändern.

Es existieren mehrere Verfahren, die sich in Aufwand, Latenz und Zielrichtung unterscheiden:

LLM-Rewrite: Ein Sprachmodell schreibt die Anfrage in eine klarere, vollständigere Suchanfrage um. Typische Operationen sind Pronomen-Auflösung, Ausbuchstabieren von Abkürzungen und die Reformulierung einer Frage als Aussage. Das Verfahren wurde von Ma et al. 2023 als Teil des [Rewrite-Retrieve-Read-Frameworks](https://arxiv.org/abs/2305.14283) formalisiert.
HyDE (Hypothetical Document Embeddings): Das Sprachmodell erzeugt eine hypothetische Antwort auf die Anfrage; deren Embedding dient als Retrieval-Anfrage. Der Vektor der (potenziell erfundenen) Antwort liegt näher an den Zieldokumenten als der Vektor der kurzen Frage. Ursprung: [Gao et al. 2022](https://arxiv.org/abs/2212.10496).
Query Expansion: Der Anfrage werden Synonyme, verwandte Begriffe oder Übersetzungen hinzugefügt (klassisch statistisch aus dem Korpus, modern per LLM). Enge Untermenge von Query Rewriting ohne strukturelle Änderung.
Query Decomposition: Eine komplexe Anfrage wird in mehrere Teilanfragen zerlegt (etwa zwei getrennte Vertrags-Lookups für einen SLA-Vergleich). Die Trefferlisten werden anschließend fusioniert.
Multi-Query-Retrieval: Das Modell erzeugt mehrere paraphrasierte Varianten derselben Anfrage; jede läuft parallel gegen den Index, und die Trefferlisten werden per Reciprocal Rank Fusion oder gewichteter Score-Fusion zusammengeführt. Kanonisch umgesetzt in [LangChains MultiQueryRetriever](https://python.langchain.com/docs/how_to/MultiQueryRetriever/).
Chat-History-Kondensation: In mehrturnigen Dialogen wird der Dialogverlauf zu einer eigenständigen, kontextfreien Suchanfrage kondensiert (Standalone-Question). Standard-Baustein in Chat-basierten RAG-Anwendungen.

Der Preis ist zusätzliche Latenz und Kosten. Ein LLM-Rewrite kostet typisch 200 bis 800 Millisekunden pro Anfrage plus die Token-Kosten des Rewrite-Aufrufs; Multi-Query erhöht die Retrieval-Last um den Faktor der Varianten. Der Rewriter kann die ursprüngliche Absicht verfehlen und dadurch das Retrieval schlechter machen. Nutzen und Aufwand werden daher am Retrieval-Recall, an der Precision und an nachgelagerten Antwortmetriken gemessen.

Abgrenzung zu Query Routing, Expansion, Reranking und HyDE

Der Begriff wird in der Praxis häufig mit angrenzenden Schritten derselben Pipeline vermischt.

Verfahren	Was passiert?	Wann in der Pipeline?
Query Rewriting	Umformulierung der Anfrage in eine oder mehrere Suchanfragen	Vor dem Retrieval
Query Routing	Wahl der Datenquelle (Vertragsindex vs. Ticket-Index vs. SQL-Tabelle vs. Websuche)	Vor oder nach dem Rewrite
Query Expansion	Hinzufügen von Synonymen und verwandten Termen ohne strukturelle Änderung	Vor dem Retrieval (Untermenge des Rewrites)
Reranking	Neusortierung der Trefferliste durch einen Cross-Encoder oder ein Sprachmodell	Nach dem Retrieval
HyDE	Einbettung einer hypothetischen Antwort als Retrieval-Anfrage	Vor dem Retrieval (spezialisierte Rewrite-Variante)

Der wichtigste Unterschied besteht zu Query Routing. Routing entscheidet, welche Datenquelle eine Anfrage bedient, ohne die Anfrage selbst zu verändern. Query Rewriting verändert die Anfrage, ohne die Quelle festzulegen. Beide Schritte sind kombinierbar: erst umformulieren, dann routen, oder umgekehrt. In agentischen RAG-Architekturen laufen beide Schritte als separate Tool-Aufrufe.

Query Expansion ist eine enge Untermenge des Rewritings. Sie fügt der Anfrage Synonyme oder verwandte Terme hinzu, verändert aber die Struktur nicht. Query Rewriting umfasst zusätzlich Umformulierung, Aufteilung, HyDE und Chat-History-Kondensation. Wer nur Expansion einsetzt, adressiert lexikalische Lücken, kann aber weder Pronomen auflösen noch komplexe Anfragen zerlegen.

Reranking greift nach dem Retrieval. Ein Cross-Encoder oder ein Sprachmodell sortiert die zurückgegebene Kandidatenliste um. Query Rewriting arbeitet vor dem Retrieval an der Anfrage; Reranking sortiert die Trefferliste. Die beiden Schritte sind orthogonal und werden häufig kombiniert: erst umformulieren, dann retrieven, dann reranken.

HyDE ist keine eigene Kategorie neben Query Rewriting. Der Ansatz ist eine spezialisierte Rewrite-Variante: Statt die Frage in eine bessere Frage zu übersetzen, erzeugt das Sprachmodell eine hypothetische Antwort und nutzt deren Embedding als Retrieval-Anfrage. Damit fällt HyDE als Rewrite-Technik unter denselben Oberbegriff.

Beispiel: HR-Wissensassistent mit Chat-Follow-ups

Ein interner HR-Wissensassistent auf Personalrichtlinien und Betriebsvereinbarungen zeigt den Nutzen des Verfahrens im Alltag. Ein Mitarbeiter fragt im Chat zuerst "Wie viele Urlaubstage habe ich?"; das Standard-Retrieval funktioniert, weil die Anfrage vollständig ist. Als Follow-up folgt "Und für Werkstudenten?". Diese zweite Anfrage ist ohne den vorherigen Kontext bedeutungslos: Das Embedding trifft allgemeine Werkstudenten-Dokumente wie Verträge oder Meldepflichten und verfehlt den Urlaubsanspruch-Passus in der Betriebsvereinbarung.

Ein Query-Rewriter (LLM-Aufruf mit Dialoghistorie und einem spezialisierten Prompt) kondensiert die Anfrage zu "Wie viele Urlaubstage stehen Werkstudenten laut Personalrichtlinie zu?". Das Embedding dieser umformulierten Anfrage trifft den relevanten Absatz in der Betriebsvereinbarung. Zusätzlich erzeugt ein Multi-Query-Ansatz drei Varianten ("Urlaubsanspruch Werkstudent", "Werkstudentenvertrag Urlaub", "Studentischer Mitarbeiter Urlaubstage"), fusioniert die Trefferlisten per Reciprocal Rank Fusion und übergibt die Top-Chunks an das Sprachmodell. Ohne Query Rewriting würde der Assistent eine allgemeine Erklärung zu Werkstudenten liefern oder ausweichen; mit Rewriting liegt der richtige Passus im Kontext, und die Antwort verweist auf die Fundstelle.

Vergleichbare Muster finden sich in Vendor-Diensten wie Azure AI Search, Cloudflare AI Search oder Databricks Mosaic AI Vector Search, die Query Rewriting als optionalen Schritt der Retrieval-Konfiguration anbieten.