RAG Query-Routing in der Praxis: Multi-Vektorspeicher und intelligente Retrieval-Verteilung

Ein Nutzer fragt: „Welche Auswirkungen hat der Lieferantenstreik auf den Aktienkurs?“ Das System liefert fragmentierte Nachrichten – darunter zwei Meldungen über Wettbewerber. Der Kunde fragt: „Warum ist eure KI so dumm?“ Dasselbe RAG-System beantwortet „Umsatz Ostchina-Region Q3 2023“ blitzschnell und korrekt, scheitert aber bei Multi-Hop-Fragen.

Die Ursache: Ersteres ist eine einfache Faktenabfrage – Vektor-Retrieval reicht. Letzteres braucht Multi-Hop-Reasoning: Lieferant, Streik, Kursbewegung – die Beziehungen liegen im Wissensgraph. Eine Retrieval-Strategie für alle Abfragen ist wie ein Schlüssel für alle Türen.

Es braucht einen „intelligenten Router“, der je nach Fragemerkmalen automatisch die Retrieval-Strecke wählt. Dieser Artikel vergleicht drei Ansätze: logisches Routing (LLM analysiert Intent), semantisches Routing (Fuzzy-Matching im Embedding-Raum) und EnsembleRetriever (RRF-Fusion). Es gibt keine „beste“ Lösung – nur die passendste für Ihr Szenario.

Kapitel 1: Warum Query-Routing? – Vom „Single-Vektorspeicher“ zur Multi-Quellen-Koordination

Ich habe einmal ein Unternehmens-Wissenssystem mit drei Datenquellen gebaut: Finanzdatenbank (MySQL), Technikdokumentation (Vektorspeicher) und Beziehungsgraph (Neo4j). Mein erster Ansatz war simpel: alles in einen Vektorspeicher packen.

Das Ergebnis? Bei „Umsatz Ostchina-Region“ fand das System die richtige Antwort in der Finanztabelle. Bei „Welche Produktlinien sind vom Lieferantenstreik betroffen?“ kam ein Haufen irrelevanter Nachrichten – Nutzer schüttelten den Kopf.

Nicht jede Abfrage eignet sich für Vektor-Retrieval. Manchmal ist SQL schneller und genauer; manchmal verbindet nur der Wissensgraph Beziehungen; manchmal braucht es Web-Suche für aktuelle Infos. Eine Strategie für alles führt zu „zu wenig Leistung“ oder Over-Engineering.

1.1 Engpass des Single-Vektorspeichers: Zwei reale Szenarien

Szenario A: Einfache Faktenabfrage (Vektor-Retrieval reicht)

Frage: „Wie hoch war der Gesamtumsatz der Ostchina-Region in Q3 2023?“

Systemverhalten: Vektor-Retrieval findet die Finanztabelle, Antwort „Ostchina Q3: 120 Mio. Yuan“. Gesamt ~300 ms – Nutzer zufrieden.

Wissensgraph erzwingen? Verschwendete GPU-Leistung, +500 ms Latenz. Wie Rakete für Paketlieferung – geht, aber unnötig.

Szenario B: Komplexe Reasoning-Abfrage (Multi-Hop nötig)

Frage: „Welche Auswirkungen hat der Lieferantenstreik auf den Aktienkurs?“

Systemverhalten: Vektor-Retrieval liefert Fragmente – „Aktie von Firma XX −5 %“, „Bericht über Lieferantenstreik“. Dem LLM fehlt die Kette: Welcher Lieferant? Für wen? Wie lange der Streik? Wie stark der Kursrückgang? LLM erfindet leicht Antworten.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Richtig: Wissensgraph verbindet „Lieferant → Streik → Vertragsbeziehung → Kurs“ – die Logikkette ist klar. Aber wie erkennt das System automatisch „diese Frage braucht den Wissensgraph“?

Das ist das Kernproblem des Query-Routings.

1.2 Vierdimensionale Abfrageanalyse

In Projekten nutze ich einen einfachen Rahmen – vier Dimensionen bestimmen die Retrieval-Strategie:

Beispiel: „Umsatz Ostchina-Region“ ist Single-Hop, strukturiert, statisch – SQL am schnellsten. „Lieferantenstreik und Aktienkurs“ ist hoch kontextabhängig, Multi-Hop, unstrukturiert – Wissensgraph passender.

Vielleicht denken Sie: „Kann ich nicht einfach alle drei Quellen parallel abfragen und mergen?“ Ja – aber die Kosten explodieren. Drei Retriever pro Abfrage: +200–500 ms Latenz, doppelte LLM-Kosten. Es sei denn, Budget spielt keine Rolle.

Klüger: Das System „wägt ab“ und wählt dynamisch die Retrieval-Strecke. Das ist der Wert des Query-Routers – Balance zwischen Präzision, Effizienz und Kosten.

Kapitel 2: Logisches Routing – LLM analysiert Intent, wählt Datenquelle

Logisches Routing ist der intuitivste Ansatz: Dem LLM eine „Auswahlliste“ geben, die Frage analysieren lassen und die passendste Datenquelle wählen.

Wie beim Arzt: „Wo tut es weh?“ – „Magen“ → Gastroenterologie; „Kopf“ → Neurologie. Das LLM ist die Aufnahme, Ihre Frage das Symptom, die Datenquelle die Fachabteilung.

Umsetzung: LangChain + Structured Output

Zuerst der vollständige Code, dann typische Fallstricke:

from langchain_core.prompts import ChatPromptTemplate
from langchain_deepseek import ChatDeepSeek
from pydantic import BaseModel, Field
from typing import Literal

# Datenquellen-Enum (vermeidet mehrdeutige LLM-Ausgaben)
class DataSource(BaseModel):
    """Ergebnis der Datenquellenauswahl"""
    source: Literal["finance_db", "tech_docs", "knowledge_graph", "web_search", "general_search"] = Field(
        description="Gewählte Datenquelle"
    )

# Routing-Prompt
system_prompt = """
Sie sind ein Query-Routing-Experte. Leiten Sie die Nutzerfrage an die passende Datenquelle:

- Finanz-/Umsatzdaten → "finance_db" (relationale DB)
- Technikdokumentation, Handbücher → "tech_docs" (Vektordatenbank)
- Personen-, Organisationsbeziehungen → "knowledge_graph" (Graph-DB)
- Aktuelle Echtzeitinformationen → "web_search"
- Unklar → "general_search"

Nur den Datenquellennamen zurückgeben, sonst nichts.
"""

prompt = ChatPromptTemplate.from_messages([
    ("system", system_prompt),
    ("human", "{question}"),
])

# DeepSeek-Modell (günstig und zuverlässig)
llm = ChatDeepSeek(model="deepseek-chat", temperature=0.1)
structured_llm = llm.with_structured_output(DataSource)

# Routing-Chain
route_chain = prompt | structured_llm

# Test
query1 = "Wie hoch war der Gesamtumsatz der Ostchina-Region in Q3 2023?"
result1 = route_chain.invoke({"question": query1})
print(result1.source)  # Ausgabe: finance_db

query2 = "Welche Auswirkungen hat der Lieferantenstreik auf den Aktienkurs?"
result2 = route_chain.invoke({"question": query2})
print(result2.source)  # Ausgabe: knowledge_graph

Wichtiges Detail: temperature=0.1. Bei 0,7 route dieselbe Abfrage mal zum Wissensgraph, mal zur Web-Suche. Router brauchen Stabilität, keine Zufälligkeit.

Das Pydantic-Enum DataSource ist ebenso entscheidend. Ohne Enum kamen Antworten wie „sollte finance_db prüfen“ oder „finance_db oder general_search“. Mit Enum: saubere Werte.

Vor- und Nachteile

In Tests funktioniert logisches Routing am besten bei <= 5 Quellen. Darüber verlängert sich der Prompt, das LLM verwechselt Quellen. Bei 10 Quellen: semantisches Routing oder gestaffeltes logisches Routing (erst Kategorie, dann Detail).

Kapitel 3: Semantisches Routing – Fuzzy If/Else im Embedding-Raum

Semantisches Routing ist schneller. Logisches Routing „denkt“ 500–800 ms; semantisches Routing rechnet Embedding-Ähnlichkeit in ~50 ms – mehr als 10× schneller.

Prinzip: Vordefinierte Beispielabfragen (Utterances), z. B. „Umsatz abfragen“, „Finanzbericht“, „Wie läuft der Umsatz?“ – alle zeigen auf Intent „Finanzabfrage“. Bei Nutzerfrage: Ähnlichkeit zu Utterances berechnen, über Schwellwert → Routing.

Wie die Mutter fragt „Was möchtest du essen?“ und Sie sagen „Egal, nicht zu scharf.“ Im Kopf: „Nicht scharf“ ≈ „Tomaten-Ei“, „Gedämpfter Fisch“, „Kürbissuppe“. Semantisches Routing ist dieses Fuzzy-Matching.

Umsetzung: semantic-router + vordefinierte Utterances

Code ist noch einfacher als logisches Routing:

from semantic_router import RouteLayer, Route
from semantic_router.encoders import HuggingFaceEncoder

# Routing-Regeln (Ähnlichkeitsschwelle)
routes = [
    Route(
        name="finance_query",
        utterances=[
            "Umsatz abfragen",
            "Finanzberichtsdaten",
            "Wie läuft der Umsatz?",
            "Gewinnanalyse",
        ],
    ),
    Route(
        name="tech_support",
        utterances=[
            "Wie benutze ich das Produkt?",
            "Wo ist die Technikdokumentation?",
            "Fehlerbehebung",
            "Funktionsbeschreibung",
        ],
    ),
    Route(
        name="graph_query",
        utterances=[
            "Wer kooperiert mit wem?",
            "Organisationsstruktur",
            "Lieferkette upstream/downstream",
            "Beziehungsgraph Personen",
        ],
    ),
]

# RouteLayer (kostenloses HuggingFace-Embedding)
encoder = HuggingFaceEncoder()
route_layer = RouteLayer(encoder=encoder, routes=routes)

# Test (~50 ms, kein LLM)
query1 = "Welche Auswirkungen hat der Lieferantenstreik auf den Aktienkurs?"
route1 = route_layer(query1)
print(route1.name)  # Ausgabe: graph_query

query2 = "Wie hoch war der Umsatz Ostchina Q3 2023?"
route2 = route_layer(query2)
print(route2.name)  # Ausgabe: finance_query

Schlüssel: utterances. Pro Intent 4–10 Beispielabfragen; System berechnet semantische Ähnlichkeit. Standard-Schwelle 0,85 – über 85 % Similarity → Routing.

Zu wenige Utterances (z. B. 2) → niedrige Recall; zu viele (>20) → mehr Rechenaufwand. Empfehlung: 4–10 pro Intent, gängige Formulierungen abdecken.

Vorteil HuggingFaceEncoder: kostenloses lokales Embedding, keine OpenAI-API. Bei 100.000 Abfragen/Tag wirken $0,0001 pro Routing harmlos – aber $10/Tag, $300/Monat. Semantisches Routing: kostenlos.

Vor- und Nachteile

Grenze: Keine logischen Bedingungen wie „wenn Finanzdaten und hohe Aktualität, dann Echtzeit-DB“. Dafür braucht es LLM. In Projekten: semantisches Routing für Intent (Finanz/Technik/Beziehung), logisches Routing für komplexe Bedingungen.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Kapitel 4: EnsembleRetriever – RRF fusioniert mehrere Retriever

Die ersten beiden Ansätze wählen einen Retriever; EnsembleRetriever kombiniert Ergebnisse mehrerer.

Klassisches Szenario: BM25 (Keyword) + Vektor-Retrieval (Semantik). Frage „Umsatz Q3 2023“: BM25 trifft „Umsatz“ exakt, verpasst aber „Revenue“; Vektor versteht Synonyme, holt aber irrelevante Finanzdokumente.

Kombination verbessert Recall und Präzision – das ist der Wert des EnsembleRetriever.

Umsetzung: LangChain EnsembleRetriever + RRF

Überraschend einfach:

from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever
from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings

# BM25 (Keyword)
bm25_retriever = BM25Retriever.from_texts(
    ["Finanzbericht Q3 2023", "Umsatzdaten Ostchina", "Lieferantenliste"],
    k=2,
)

# Vektor-Retrieval (Semantik)
vectorstore = Chroma.from_texts(
    ["Finanzbericht Q3 2023", "Umsatzdaten Ostchina", "Lieferantenliste"],
    embedding=OpenAIEmbeddings(),
)
vector_retriever = vectorstore.as_retriever(k=2)

# EnsembleRetriever (RRF)
ensemble_retriever = EnsembleRetriever(
    retrievers=[bm25_retriever, vector_retriever],
    weights=[0.4, 0.6],  # BM25 0,4, Vektor 0,6
)

# Test
query = "Umsatz Ostchina Q3 2023"
docs = ensemble_retriever.invoke(query)
print(docs)  # Fusion nach RRF-Score

Kern ist RRF (Reciprocal Rank Fusion). Beispiel: Dokument Rang 1 bei BM25, Rang 3 bei Vektor:

BM25 Rang 1 → 1/(60+1) = 0,0164
Vektor Rang 3 → 1/(60+3) = 0,0159
Gesamtscore = 0,0164 + 0,0159 = 0,0323

k=60 ist Erfahrungswert, projektabhängig anpassbar. Größeres k → geringerer Rank-Unterschied; kleineres k → stärkerer Vorteil für Top-Ränge.

Warum RRF wirkt

RRF nutzt nur Rankings, nicht incomparable Roh-Scores. So lassen sich BM25, Vektor, Wissensgraph, Web-Suche kombinieren.

In Tests: reines BM25 Recall 70 %, reiner Vektor 85 %, EnsembleRetriever bis 92 %. Zusatzkosten ~50 ms (parallele Retriever).

Vor- und Nachteile

Grenze: Nur gleichartige Ergebnisse fusionierbar. Vektorspeicher + Wissensgraph parallel braucht logisches oder semantisches Routing.

Kapitel 5: Kostenoptimierung in Produktion

Bisher ging es um „schlauer“ – hier um „günstiger“. Mein größter Fehler: Kostenexplosion in Woche 1 – $500 LLM, Chef unzufrieden.

Drei Strategien halfen: Semantic Caching, Tiered Retrieval, Parallel Processing. Kosten auf ~$50/Woche, Präzision gestiegen.

5.1 Semantic Caching

Einfach und effektiv: Embeddings häufiger Abfragen cachen; bei Ähnlichkeit > 0,95 gecachte Antwort, kein LLM.

In Produktion: Cache-Hit-Rate 30–50 %. Antwortzeit ~500 ms → ~50 ms bei Hit – spürbar bessere UX.

from langchain.cache import InMemoryCache
from langchain.embeddings import CacheBackedEmbeddings
from langchain_openai import OpenAIEmbeddings

# Embeddings cachen
underlying_embeddings = OpenAIEmbeddings()
cached_embeddings = CacheBackedEmbeddings.from_bytes_store(
    underlying_embeddings,
    InMemoryCache(),  # Produktion: Redis empfohlen
)

# Gecachte Embeddings fürs Routing
# Ähnlichkeit > 0,95 → gecachte Antwort

Produktion: Redis oder Memcached, nicht InMemoryCache (verloren beim Neustart). Alte Einträge (>30 Tage ungenutzt) regelmäßig löschen.

5.2 Tiered Retrieval

Einfache Abfragen → günstiges Modell; komplexe → teures Modell.

from langchain_openai import ChatOpenAI
from langchain_anthropic import ChatAnthropic

# Günstig für einfache Abfragen
simple_llm = ChatOpenAI(model="gpt-4o-mini", temperature=0.1)

# Teuer für komplexes Reasoning
complex_llm = ChatAnthropic(model="claude-opus-4-20250514", temperature=0.2)

# Routing-Logik
if route_layer(query).name in ["finance_query", "tech_support"]:
    response = simple_llm.invoke(query)
elif route_layer(query).name == "graph_query":
    response = complex_llm.invoke(query)

Kostenvergleich:

Faktor 100. Bei 80 % einfachen Abfragen: Kosten auf ~20 %.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

5.3 Parallel Processing

Hybrid-Routing (logisch + EnsembleRetriever) addiert 200–500 ms – aber Retriever parallel: Latenz steigt wenig.

import asyncio
from langchain_community.retrievers import BM25Retriever

# BM25 + Vektor parallel
async def parallel_retrieval(query):
    bm25_task = asyncio.create_task(bm25_retriever.invoke(query))
    vector_task = asyncio.create_task(vector_retriever.invoke(query))

    bm25_docs, vector_docs = await asyncio.gather(bm25_task, vector_task)

    # RRF-Fusion
    return ensemble_docs

Gemessen: seriell 600 ms, parallel 320 ms – Hybrid-Latenz fast ausgeglichen.

Alle drei kombiniert: von $500/Woche auf $50, schnellere Antworten. Kostenoptimierung ist kluge Ressourcenverteilung, kein Sparzwang.

Kapitel 6: Vergleich und Auswahl

Welcher Ansatz für Ihr Projekt? Vergleichstabelle und Entscheidungsbaum.

Kernvergleich der drei Ansätze

Entscheidungsbaum

Schritt 1: Routing zu unterschiedlichen Datenquellen nötig?
├─ Ja → Schritt 2: Anzahl Quellen <= 5?
│   ├─ Ja → 【Logisches Routing】(LLM Intent)
│   └─ Nein → Schritt 2: Anzahl <= 20?
│       ├─ Ja → 【Semantisches Routing】(Utterances)
│       └─ Nein → Multi-Agent-Koordinator (außerhalb dieses Artikels)
└─ Nein → Schritt 3: Gleichartige Retriever mergen?
    ├─ Ja → 【EnsembleRetriever】(RRF)
    └─ Nein → Single-Vektorspeicher reicht

Praxisempfehlung

Unternehmens-Wissenssystem mit Finanz-DB, Technikdokumentation, Wissensgraph:

1. Semantisches Routing für Intent (Finanz/Technik/Beziehung) – schnell und kostenlos.
2. Logisches Routing für Spezialfälle (z. B. hohe Aktualität → Web-Suche).
3. EnsembleRetriever pro Quelle intern (BM25 + Vektor) für höhere Recall.
4. Kostenoptimierung (Semantic Caching, Tiered Retrieval) zum Schluss.

Diese „Drei-Ebenen-Routing“-Architektur habe ich in 3 Projekten validiert: ~$50/Woche, <800 ms, Nutzerzufriedenheit >85 %.

Nur eine Quelle (z. B. Vektorspeicher)? Nicht sofort Routing einführen. Erst EnsembleRetriever (BM25 + Vektor) testen. Oft reicht Optimierung der Retrieval-Strategie – kein Routing nötig.

Fazit und nächste Schritte

Essenz des Query-Routings: Je nach Abfragemerkmalen (Kontext, Hops, Datentyp, Aktualität) dynamisch die Retrieval-Strecke wählen – wie Navigation nach Verkehrslage, nicht starrer Pfad.

Drei Ansätze:

• Logisches Routing: klare Quellentypen (<=5), tiefes Intent-Verständnis.
• Semantisches Routing: Intent-Klassifikation (<=20), schnell und kostensensibel.
• EnsembleRetriever: gleichartige Retriever (BM25 + Vektor), höhere Recall.

Kosten in Produktion: Semantic Caching, Tiered Retrieval, Parallel Processing kombiniert – Kosten auf ~10 %, oft schnellere Antworten.

Empfohlene Schritte

Schritt 1: Engpass diagnostizieren
Fehlfälle analysieren: niedrige vs. hohe Kontextabhängigkeit. Nicht überspringen – sonst Over-Engineering.

Schritt 2: Ansatz wählen
Nach Quellenanzahl, Intent-Anzahl, Budget: logisch / semantisch / EnsembleRetriever. Nicht alle drei sofort – erst einen validieren.

Schritt 3: Kostenoptimierung
Zuerst Semantic Caching (einfach, starker Effekt), dann Tiered Retrieval und Parallel Processing. Iterativ, nicht alles auf einmal.

Bei konkreten Projektfragen gerne im Kommentar diskutieren – vielleicht helfen Erfahrungen aus bereits gemachten Fehlern.