Query Routing (RAG): Definition, Verfahren, Beispiel

Query Routing ist eine Weiche vor der Suche: In Systemen, die eine Frage erst in Firmen-Daten nachschlagen und dann eine KI-Antwort schreiben (RAG, Retrieval-Augmented Generation), entscheidet ein Router, in welcher Datenquelle die Antwort gesucht wird, etwa in Vertragsdokumenten, in Support-Tickets oder in einer Datenbank. Ziel ist eine treffsicherere Antwort, weil nur die passende Quelle durchsucht wird, sowie eine bessere Kontrolle über Kosten und Antwortzeit.

Was ist Query Routing?

Query Routing sitzt in einer Such-Kette zwischen der Nutzer-Frage und dem eigentlichen Nachschlagen. Die Frage läuft zuerst durch einen Router, der aus mehreren möglichen Zielen (Datenquellen wie Vertrags-Datenbanken, Ticket-Systeme, SQL-Tabellen oder eine Websuche) genau das Ziel auswählt, das die Frage bedient. Der Router beantwortet die Frage nicht selbst, er entscheidet, wer sie beantwortet. Optional wird die Frage vorher noch umformuliert (Query Rewriting), das ist ein eigener Schritt.

Der Schritt existiert, weil Retrieval-Systeme in realen Umgebungen selten gegen einen einzigen Index arbeiten. Wissensbestände sind entlang von Zugriffsrechten, Aktualisierungs-Frequenzen, Datenformaten und fachlichen Domänen getrennt: Vertragsdokumente liegen in einem Vektor-Index, Support-Tickets in einem zweiten, transaktionale Fakten in einer SQL-Datenbank, Produktkatalog-Beschreibungen in einem dritten Index. Ein Sammel-Index über alle Quellen verwässert die Precision und macht Zugriffsrechte pro Quelle kaum noch durchsetzbar. Query Routing löst dieses Problem, indem die Quellen-Segmentierung erhalten bleibt und die Verteilungs-Entscheidung explizit wird.

Vier Grundverfahren dominieren die Routing-Ebene:

LLM-basierter Router. Ein Sprachmodell klassifiziert die Anfrage anhand einer Beschreibung pro Route, häufig via Function-Call oder Structured Output auf ein Zielschema. Das ist die flexibelste Variante, kostet aber Latenz und Token pro Anfrage. Kanonisch in [LlamaIndex Router Query Engine](https://developers.llamaindex.ai/python/framework/module_guides/querying/router/) (LLMSingleSelector, LLMMultiSelector).
Embedding-basierte Ähnlichkeitswahl. Jede Route bekommt einen Beschreibungs-String; dessen Embedding wird mit dem Embedding der Anfrage verglichen, die höchste Ähnlichkeit gewinnt. Deterministisch, günstig, ohne LLM-Aufruf. Beispiel: [aurelio-labs semantic-router](https://github.com/aurelio-labs/semantic-router).
Regelbasierter Router. Keyword-Filter, Regex, Metadaten-Bedingungen oder ein kleiner Klassifikator lenken die Anfrage. Vorhersagbar und testbar, aber pflegeintensiv bei wachsendem Route-Katalog.
Hybride Router. Regel-Vorfilter fangen eindeutige Fälle ab, ein LLM oder Embedding-Router entscheidet den Rest. In Multi-Route-Setups ergänzt um einen Fallback-Index für nicht-klassifizierbare Anfragen.

Das Ergebnis kann eine einzelne Zielroute sein, mehrere parallele Routen mit anschließender Fusion der Trefferlisten (Multi-Route-Fanout) oder ein Fallback auf einen Default-Index. Der Preis hängt am Verfahren: ein LLM-Router kostet typisch 200 bis 800 Millisekunden pro Anfrage plus Token, ein embedding-basierter Router liegt im einstelligen Millisekunden-Bereich und einem Ähnlichkeits-Lookup.

Abgrenzung zu Query Rewriting, Reranking, Semantic Search und Agentic Router

Der Begriff wird in der Diskussion häufig mit angrenzenden Schritten derselben Pipeline vermischt. Die folgende Tabelle ordnet die Unterschiede ein:

Begriff	Rolle	Position in der Pipeline
Query Routing	Wahl der Datenquelle, des Index oder des Modells	Vor dem Retrieval
Query Rewriting	Umformulierung der Anfrage in eine oder mehrere Suchanfragen	Vor dem Retrieval
Reranking	Neusortierung der Trefferliste	Nach dem Retrieval
Semantic Search	Retrieval-Verfahren (Vektor-Ähnlichkeitssuche)	Der Retrieval-Schritt selbst
Agentic Router	Kontrollfluss-Entscheidung über Agenten/Modelle/Tools in Multi-Agenten-Systemen	Auf jedem Agent-Turn

Der wichtigste Unterschied besteht zu Query Rewriting. Rewriting verändert die Anfrage (Umformulierung, HyDE, Multi-Query); Routing lässt die Anfrage unverändert und wählt stattdessen die Zielquelle. Beide Schritte sind orthogonal und werden häufig kombiniert: zuerst rewrite (klarere Anfrage), dann route (passende Quelle). Umgekehrt ist ebenfalls verbreitet, wenn die Route die Rewrite-Strategie steuert.

Reranking greift nach dem Retrieval. Ein Cross-Encoder oder ein Sprachmodell sortiert die zurückgegebene Kandidatenliste um. Ein Reranker ersetzt keinen Router: Er kann eine schlechte Quellenwahl nicht korrigieren, weil die relevanten Dokumente in der falschen Quelle gar nicht erst zurückgegeben wurden.

Semantic Search bezeichnet ein Retrieval-Verfahren; die Verteilungs-Schicht darüber ist ein anderer Baustein. Ein Query Router wählt zwischen mehreren Semantic-Search-Indizes oder zwischen einem Vektor-Index und einem BM25-, SQL- oder Websuche-Backend. Semantic Search kann ein Kandidat unter mehreren Routen sein.

Agentic Router oder Agent Routing ist der breitere Kontrollfluss in Multi-Agenten-Systemen: welcher Agent, welches Modell, welcher nächste Turn. Query Routing ist der Spezialfall auf Retrieval-Ebene und bearbeitet die Frage, welche Datenquelle eine konkrete Anfrage bedient. In agentischen RAG-Architekturen tritt Query Routing typischerweise als eigenes Tool des Agenten auf, das der Agentic Router aufruft.

Beispiel: Unternehmens-Wissensassistent mit drei Quellen

Ein interner Wissensassistent bedient drei Quellen: einen Vektor-Index über Betriebsvereinbarungen und Personalrichtlinien, einen Vektor-Index über gelöste Support-Tickets und eine SQL-Datenbank mit offenen Bestellungen und Verträgen. Ohne Router würden alle Anfragen gegen einen Sammel-Index oder gegen alle drei Quellen parallel laufen. Der Sammel-Index verwässert die Precision, weil HR-Passagen im gleichen Vektorraum liegen wie Support-Ticket-Zusammenfassungen; der Parallel-Fanout verdreifacht die Retrieval-Kosten und liefert für jede Anfrage viele irrelevante Kandidaten.

Ein embedding-basierter Router mit einer kurzen Beschreibung pro Route (etwa "Personalrichtlinien, Urlaub, Elternzeit, Arbeitszeit" für die HR-Route) klassifiziert jede Anfrage vor dem Retrieval. Die Anfrage "Wie viele Urlaubstage habe ich?" landet auf der HR-Route, "Wann wurde Ticket 4711 zuletzt aktualisiert?" auf der Ticket-Route (ergänzt um eine Regel, die Ticket-IDs per Regex extrahiert und direkt an das SQL-Backend übergibt), "Welche Bestellungen sind für Kunde X offen?" auf der SQL-Route. Ambivalente Anfragen ("Wie ist die Regelung für Homeoffice bei kranken Kindern?") lösen einen Multi-Route-Fanout aus, weil sowohl die HR-Route als auch eine mögliche Betriebsvereinbarungs-Untermenge relevant sind; die Trefferlisten werden per Reciprocal Rank Fusion zusammengeführt.

Kanonische Umsetzungen des Musters finden sich in LlamaIndex Router Query Engine (LLM- und Pydantic-Selektoren, Single- und Multi-Route), in semantic-router (embedding-basiert), in [Azure AI Search Agentic Retrieval](https://learn.microsoft.com/en-us/azure/search/search-agentic-retrieval-concept) (Query-Planning inklusive Routing) und in Databricks Mosaic AI mit mehreren Vector-Search-Indizes hinter einem Router-LLM. Anthropic beschreibt Routing als eines der agentischen [Workflow-Muster](https://www.anthropic.com/engineering/building-effective-agents) (Router-Pattern) und positioniert es als Standard-Baustein für Systeme mit mehreren fachlich getrennten Aufgabentypen.