Query Expansion und Rewriting: HyDE, Decomposition, Multi-Query, Step-Back-Prompting

Was ist Query Expansion?

Query Expansion und Query Rewriting sind Techniken, die zwischen Nutzer-Frage und Retrieval-Schritt eine Umformulierung schalten. Die Annahme: Nutzer fragen kurz, ungenau und ambivalent ("Kündigung?"). Dokumente sind ausführlich, präzise und kontextualisiert ("Ordentliche Kündigung eines Mietverhältnisses unter Anwendung von Art. 266a OR"). Embedding und BM25 können den semantischen Sprung zwischen beiden nicht immer überbrücken. Eine bessere Formulierung der Anfrage löst viele Retrieval-Probleme.

Vier Techniken haben sich im Mai 2026 als wirkungsvoll etabliert.

HyDE (Hypothetical Document Embeddings, Gao et al. 2022): das LLM bekommt die Nutzer-Frage und schreibt einen fiktiven idealen Antwort-Text. Dieser fiktive Text wird dann embedded und gegen den Index gesucht. Die Annahme: ein fiktives Dokument liegt im Vektor-Raum näher an realen Antwort-Dokumenten als die kurze Frage selbst. In Studien (Gao et al., empirisch reproduziert) verbessert HyDE Retrieval-Recall um 5 bis 20 Prozent bei kurzen, ungenauen Anfragen.

Query Decomposition: das LLM zerlegt eine komplexe Anfrage in Teil-Anfragen. "Wie hat sich der MWST-Saldo unserer Mandanten zwischen 2023 und 2025 entwickelt und welche Branchen haben am meisten zugelegt?" wird zu drei Teil-Anfragen, die jede einzeln retrieved werden. Die Ergebnisse werden zusammengeführt.

Multi-Query (Diversification): das LLM generiert 3 bis 5 verschiedene Paraphrasen der gleichen Frage. Jede wird einzeln retrieved, die Ergebnisse werden via RRF gemerged. Robuster gegen Formulierungs-Glück.

Step-Back-Prompting (Zheng et al. 2023, Deepmind): vor der eigentlichen Anfrage wird eine abstrakte Vorfrage gestellt ("Was ist die allgemeine Regel für Kündigungen im Schweizer Mietrecht?"), die einen breiteren Kontext retrieved. Anschliessend wird mit Kontext die spezifische Frage beantwortet.

Alle vier Techniken setzen ein LLM zwischen Nutzer und Retriever - sie kosten Token und Latenz. Wer sie blind einsetzt, verbrennt Geld ohne Nutzen. Wer sie selektiv einsetzt (basierend auf Frage-Komplexität), gewinnt deutlich an Antwortqualität.

Warum es wichtig ist

Im Treuhand- und Anwaltsbüro sehen wir ein wiederkehrendes Muster: 30 bis 50 Prozent der RAG-Anfragen sind kurz, telegraphisch und mehrdeutig. "MWST 2024?", "Bachmann Vertrag?", "Mahnung?". Ohne Rewriting findet der Retriever oft das Falsche, weil die Vektor-Distanz zwischen einer 2-Wort-Frage und einem 800-Token-Chunk gross ist.

Die Folge: erhöhte Fehlanfragen, frustrierte Nutzer, schwindendes Vertrauen in das System. Wir messen das über "Retrieval-Recall@5" auf einem Eval-Set echter Anfragen. Vor Rewriting liegen die Werte oft bei 50 bis 65 Prozent. Nach selektivem HyDE plus Multi-Query bei guten Setups bei 75 bis 85 Prozent. Das ist der Unterschied zwischen "unbrauchbar" und "Standard-Werkzeug".

Zweiter Vorteil: schwierige Fragen werden überhaupt erst beantwortbar. Eine Anfrage wie "Welche unserer Mandanten müssen 2026 neu unter den Schwellenwert von Art. 957a OR fallen?" enthält eine implizite Wissens-Anforderung (Was sagt Art. 957a OR? Welche Schwellenwerte? Welche Mandanten?). Decomposition zerlegt das in beantwortbare Teile.

Kosten-Nutzen ist nicht trivial. Jeder Rewriting-Schritt ist ein zusätzlicher LLM-Call. Bei naiver Aktivierung (immer Multi-Query plus HyDE) verdreifachen sich die Kosten pro Anfrage. Die Kunst ist: ein leichtgewichtiges Routing-LLM (Claude Haiku, Mistral Small) entscheidet pro Anfrage, ob Rewriting nötig ist - und welche Technik. Einfache Anfragen ("Steuersatz Kanton Zug?") brauchen kein Rewriting. Komplexe Anfragen schon.

Für Schweizer Büro ist die Datensouveränität eine zusätzliche Schicht: das Rewriting-LLM sieht die Original-Anfrage, die oft Mandanten-Bezug hat. Bei sensiblen Setups läuft das Rewriting-LLM lokal (Ollama mit Llama 3.3 oder Mistral Small), nicht in der Cloud.

Wie es funktioniert

HyDE Implementation: vor dem Retrieval ruft die Pipeline ein leichtgewichtiges LLM auf mit dem Prompt "Bitte beantworten Sie die folgende Frage in 3 bis 5 Sätzen, als wäre es ein internes Wissens-Dokument: {Frage}". Der generierte Text wird embedded und gegen den Vektor-Index gesucht. Der Trick: das LLM darf halluzinieren - der Text ist nur eine Vektor-Sonde, nicht die finale Antwort. Wird die Halluzination "in der Nähe" der echten Antwort liegen, findet der Retriever die echte Quelle.

Query Decomposition: das Routing-LLM analysiert die Frage und entscheidet, ob sie atomar oder zusammengesetzt ist. Bei zusammengesetzt erzeugt es eine geordnete Liste von Teil-Fragen: "[1] Wie hoch ist die MWST-Schwelle 2024? [2] Welche unserer Mandanten lagen 2023 über dieser Schwelle?". Jede Teil-Frage durchläuft die volle RAG-Pipeline; die Ergebnisse werden in den finalen Antwort-Prompt zusammengeführt.

Multi-Query: das LLM bekommt den Prompt "Erzeugen Sie 4 unterschiedliche Paraphrasen dieser Frage". Jede Paraphrase wird retrieved (in der Praxis: Top-k=5 pro Paraphrase). Die 20 Chunks werden via RRF gemerged und dedupliziert; die Top-k=8 gehen in den Antwort-Prompt.

Step-Back-Prompting: zwei sequentielle Retrieval-Schritte. Erst die abstrakte Frage ("Was ist die generelle Regel für X im Schweizer Recht?") retrieved Kontext-Wissen. Dann die spezifische Frage retrieved konkrete Anwendungs-Fälle. Beide Ergebnis-Sets gehen in den Antwort-Prompt.

Selective Activation: ein Router-LLM (Claude Haiku, ca. 0.0005 USD pro Anfrage) entscheidet pro Eingabe: "Diese Frage ist atomar, kein Rewriting nötig" oder "Diese Frage ist multi-step, Decomposition aktivieren" oder "Diese Frage ist sehr kurz und ungenau, HyDE aktivieren".

In der Praxis empfehlen wir folgenden Stack: Router-LLM entscheidet pro Anfrage. Default: kein Rewriting (sparen). Bei kurzer/ungenauer Frage: HyDE. Bei komplexer/multi-step Frage: Decomposition. Multi-Query als Spezial-Werkzeug bei kritischen Recherchen, wo Robustheit wichtiger ist als Token-Sparsamkeit. Step-Back für juristische Anfragen, in denen die generelle Regel den spezifischen Fall erst klärt.

LLM-Wahl für Rewriting: Claude Haiku oder Mistral Small (lokal) - schnell, billig, gut genug für Umformulierung. Volles Modell (Claude Sonnet) ist Overkill.

Query-Rewriting-Workflow in 6 Schritten

1. 01Eval-Set bauen: 50 echte Anfragen mit manuell-markierten Ziel-Chunks. Vor Rewriting Recall@5 messen als Baseline.
2. 02Router-LLM definieren: Claude Haiku oder Mistral Small entscheidet pro Anfrage, welche Technik (oder keine) sinnvoll ist.
3. 03HyDE-Prompt schärfen: "Antwort als 3 bis 5 Sätze, sachlich, ohne Vermutungen". Modell-Wahl: kleines schnelles Modell, nicht das Antwort-Modell.
4. 04Decomposition-Prompt: "Zerlege die Anfrage in atomare Teil-Fragen, gib Liste zurück". Pro Teil-Frage volle RAG-Pipeline.
5. 05Multi-Query: "Erzeuge 4 unterschiedliche Paraphrasen". Top-5 pro Paraphrase, RRF-merge, Top-8 in Antwort.
6. 06Eval messen: Recall@5 mit und ohne Rewriting, pro Technik separat. Latenz und Token-Kosten dokumentieren. Routing iterativ verbessern.

Wann was

HyDE: bei kurzen, ungenauen Fragen (1 bis 4 Worte), bei Begriffs-Anfragen ohne Kontext, bei Konzept-Suchen im Embedding-Raum. Besonders wirksam bei juristischen und steuerrechtlichen Anfragen.

Decomposition: bei zusammengesetzten Anfragen mit "und", "sowie", Zeitvergleich, Aggregation. Auch bei impliziten Mehrfach-Anfragen ("Wer ist verantwortlich und seit wann?").

Multi-Query: bei kritischen Recherchen, in denen ein Treffer absolut nicht fehlen darf. Compliance-Audits, Forensik-Anfragen. Teuer (3 bis 5x Token-Kosten), aber robust.

Step-Back: bei juristischen Anfragen, in denen Auslegung der generellen Regel den spezifischen Fall klärt. Bei medizinischen oder steuerrechtlichen Fragen mit hierarchischem Wissensaufbau.

Selective Routing: immer. Ein Router-LLM, das pro Anfrage entscheidet, spart 60 bis 80 Prozent der Rewriting-Kosten gegenüber blanker Aktivierung.

Wann nicht

Atomare, präzise Anfragen ("Welcher Steuersatz gilt 2024 für Kanton Zug?"): kein Rewriting nötig. BM25 plus Vektor findet das direkt.

Latenz-kritische Anwendungen unter 200 ms: Rewriting fügt 200 bis 600 ms pro Schritt hinzu. Bei harten SLAs nicht machbar.

Kostendruck unter ein paar Cent pro Anfrage: Rewriting verdoppelt bis verdreifacht die LLM-Kosten pro Anfrage. Bei sehr hohen Volumen relevant.

Korpora mit sehr klarer Struktur und kontrollierter Sprache (z.B. internes Glossar mit Standard-Begriffen): Nutzer-Anfragen treffen die Quellen direkt, Rewriting bringt wenig.

Wenn Eval-Set zeigt, dass Rewriting die Präzision verschlechtert: ein Zeichen, dass das Rewriting-LLM zu kreativ paraphrasiert. Prompt enger fassen oder kleineres Modell wählen.

Vorsicht bei HyDE in sensiblen Kontexten: das Rewriting-LLM erzeugt potentiell halluzinierte Inhalte, die zwar nur als Vektor-Sonde genutzt werden, aber im Audit-Log auftauchen. Bei Berufsgeheimnis-Kontexten den HyDE-Output ebenfalls verschlüsselt und mit Disposable-Marker speichern.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Gao et al. - Precise Zero-Shot Dense Retrieval without Relevance Labels (HyDE) · 2026-05
2. Zheng et al. - Take a Step Back: Evoking Reasoning via Abstraction in LLMs · 2026-05
3. LangChain - Query Transformations cookbook · 2026-05
4. Anthropic - Contextual Retrieval and pre-query rewriting · 2026-05