Query Decomposition
Query Decomposition ist eine RAG-Technik, die eine komplexe, mehrteilige Nutzerfrage in mehrere einfachere Teilfragen aufteilt, für jede den Kontext abruft und anschließend eine endgültige Antwort zusammensetzt. Statt vom Retriever zu verlangen, eine einzige Passage zu finden, die alles auf einmal beantwortet, stellt das System viele eng umrissene Fragen parallel.
Query Decomposition ist eine RAG-Technik, die eine komplexe, mehrteilige Nutzerfrage in mehrere einfachere Teilfragen aufteilt, für jede den Kontext abruft und anschließend eine endgültige Antwort zusammensetzt. Statt vom Retriever zu verlangen, eine einzige Passage zu finden, die alles auf einmal beantwortet, stellt das System viele eng umrissene Fragen parallel.
Warum das wichtig ist
Echte Nutzer stellen unordentliche Fragen: "Was ist der Unterschied zwischen LCP und FCP, und welches davon ist 2026 für Mobile SEO wichtiger?" Ein Vektor-Retriever, dem diese Anfrage übergeben wird, liefert Passagen zu entweder LCP oder FCP oder Mobile SEO oder den Trends von 2026, selten eine einzige Passage, die alle vier abdeckt. Query Decomposition teilt die Frage in Teilanfragen auf ("Was ist LCP?", "Was ist FCP?", "LCP vs. FCP", "Mobile SEO Core Web Vitals 2026"), ruft für jede getrennt ab und lässt das Modell die endgültige Antwort aus reichhaltigem Kontext zusammensetzen. Produktive RAG-Systeme bei Perplexity, Glean und Anthropic nutzen für komplexe Fragen eine Form der Dekomposition, und die Benchmarks von LangChain aus dem Jahr 2024 zeigen Genauigkeitszuwächse von 15 bis 25 % bei Multi-Hop-QA.
Wie es funktioniert
1. Aufruf des Dekomposer-LLM: Ein kleines Modell nimmt die Nutzeranfrage und gibt 2 bis 5 Teilfragen aus. Prompt: "Zerlege diese Frage in die wenigsten Teilfragen, die nötig sind, um sie vollständig zu beantworten."
2. Paralleler Abruf: Jede Teilfrage durchläuft den Retriever, ob Vektor, hybrid oder Keyword, unabhängig.
3. Kontextaggregation: Die abgerufenen Passagen aus allen Teilfragen werden zu einem einzigen Kontextblock zusammengeführt.
4. Erzeugung der endgültigen Antwort: Das Hauptmodell sieht die ursprüngliche Frage samt allem abgerufenen Kontext und schreibt eine einheitliche Antwort.
5. Optionaler Syntheseschritt: Bei Multi-Hop-Fragen setzt ein Zwischenschritt Teilantworten zusammen, bevor die endgültige Generierung erfolgt.
Varianten
Parallele Dekomposition: Alle Teilfragen laufen gleichzeitig. Schnell, gut für Fragen, deren Teile unabhängig sind.
Sequenzielle Dekomposition (Multi-Hop): Spätere Teilfragen hängen von früheren Antworten ab. "Wer ist der CEO des größten Wettbewerbers von inblog?" erfordert, zuerst "Wer ist der größte Wettbewerber von inblog?" zu beantworten und dann den CEO dieses Unternehmens nachzuschlagen.
Step-Back-Prompting: Vor der Dekomposition stellt das LLM eine abstraktere Version der Frage, um breiteren Kontext einzubeziehen. Von Google Research im Jahr 2024 bekannt gemacht.
HyDE (Hypothetical Document Embeddings): Zuerst eine hypothetische Antwort erzeugen, diese einbetten und dann abrufen, eine leichtgewichtige Alternative zur expliziten Dekomposition.
Wann Sie es einsetzen
Vergleichsfragen: "X vs. Y", "Welches ist besser für Z"
Multi-Hop-Schlussfolgern: "Wer gründete das Unternehmen, das Figma übernommen hat?"
Zusammengesetzte Fragen: "Wie und warum" in einer Anfrage kombiniert.
Long-Tail-Spezifität: Seltene Fragen, zu denen keine einzelne Quellseite existiert, bei denen aber mehrere Seiten jeweils einen Teil abdecken.
Fragen, die Konzepte vermischen: "Technisches SEO für SaaS-Blogs auf Koreanisch"
Wann Sie es nicht einsetzen
Einfache Einzelfaktfragen: "Was ist die Hauptstadt von Frankreich?" braucht keine Dekomposition, denn sie erhöht Latenz und Kosten.
Budgetbeschränkte Anwendungen: Dekomposition vervielfacht die Retriever-Aufrufe. Bei hohem Chat-Volumen ist die Kostenbelastung real.
Domänen mit starken Einzeldokumentantworten: Rechtsverträge, Produkthandbücher, denn eine gute Passage schlägt fünf mittelmäßige.
Kompromisse
Latenz: Jede Teilfrage ist ein Hin und Her. Parallele Ausführung hilft, beseitigt sie aber nicht.
Retriever-Kosten: Vektorsuchaufrufe skalieren linear mit den Teilfragen.
Qualität des Dekomposers: Schlechte Dekomposition erzeugt schlechte Abrufe. Der Dekomposer-Prompt und das Modell sind ebenso wichtig wie der endgültige Generator.
Redundanter Abruf: Teilfragen überschneiden sich oft und rufen dieselben Passagen wiederholt ab. Deduplizierung hilft.
Häufige Fehler
Überdekomposition: Eine einfache Frage in 10 Teilfragen zu zerlegen, verschwendet Token und verwirrt das endgültige Modell.
Dekomposition ohne Grounding: Teilantworten anstelle von Quellpassagen weiterzureichen, lässt Halluzinationen über die Hops hinweg kumulieren.
Abhängigkeiten ignorieren: Eine Multi-Hop-Frage parallel auszuführen, wenn der zweite Schritt vom ersten abhängt, liefert falsche Antworten.
Keine Evaluation: Ohne einen Benchmark lässt sich nicht feststellen, ob die Dekomposition gegenüber dem Basis-RAG mit einem einzigen Durchlauf tatsächlich geholfen hat.
Quellen: