RAG-Routing — Eine API, viele Architekturen

Die drei Architekturen, konzeptionell betrachtet

Die meisten produktiven RAG-Systeme liefern eine einzige Retrieval-Architektur aus und erklären die Sache für erledigt. Wir liefern einen Router, der zwischen architektonisch unterschiedlichen Stacks auswählt — die richtige Wahl ist selten für jede Anfrage in Ihrem Korpus dieselbe.

Wie der Router tatsächlich entscheidet

Die meisten veröffentlichten RAG-Router klassifizieren die Anfrage vorab nach Komplexität. Unserer nicht. Wir setzen auf gelerntes Routing: Jede erfolgreiche Anfrage wird zusammen mit dem Backend, das sie beantwortet hat, gespeichert, und neue Anfragen werden über Embedding-Ähnlichkeit gegen diese Historie abgeglichen.

Die zehn Backends, zwischen denen wir heute routen

Der Router leitet an eines von zehn benannten Backends weiter. Drei davon sind „Tier-3-förmig" (hierarchisch oder graph-erweitert); die übrigen sind reine Vektor-Engines, die wir als Tier 1 mit unterschiedlichen operativen Trade-offs behandeln.

PI

pageindexHierarchischer Inhaltsverzeichnis-Baum + agentische Traversierung. Der Tier-3-Archetyp.

RT

raptorBaumtraversierungs-Retrieval über rekursiv zusammengefassten Dokumenthierarchien (ICLR 2024).

neo4j-hybridGraph-erweitertes Retrieval, das Vektor-Embeddings mit expliziter Entitäts- und Beziehungsstruktur kombiniert.

LR

lightragDual-Mode-Retrieval auf flachem Graphen — Entitäts- + Community-Suche, der LightRAG-Ansatz der HKU.

qdrantSelbst gehostete Dense-Vector-Engine für Lookups mit hohem Durchsatz und niedriger Latenz.

cloudflare-v2Vectorize am Edge — Sub-300-ms-p95 aus Cloudflares globalem Netzwerk.

couchbase-byokBYO-Couchbase-Vektorspeicher für Kunden mit bestehenden operativen Abhängigkeiten.

vertex-ai-vector-search-v2Google Cloud Vertex AI Vector Search für Kunden, die auf Googles Datenstack setzen.

mongodb-atlasAtlas Vector Search für Kunden, die Dokumentdaten auf MongoDB betreiben.

redis-vector-searchRedis Vector Search für In-Memory-Retrieval-Workloads mit ultraniedriger Latenz.

Tier 2 (BM25 + Dense-Fusion + Cross-Encoder-Reranker) wird heute in unserem Workflow-Canvas als komponierbarer Knoten ausgeliefert. Der Auto-Router nimmt ihn als Nächstes ins Visier, sobald die korpusspezifischen Routing-Daten dies rechtfertigen.

API-Oberfläche — ein Endpunkt, audittaugliche Transparenz

Der Router ist für Ihren Aufrufer unsichtbar. Eine einzige Anfrageform; die Antwort enthält die Routing-Entscheidung, sodass Sie auditieren können, welches Backend geantwortet hat (und warum).

# Ein Endpunkt. Der Router entscheidet, welches Backend genutzt wird.
curl -X POST https://api.divinci.app/v1/rag/query \
  -H "Authorization: Bearer $DIVINCI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "question": "What clauses in the 2024 amendment override section 7.3?",
    "corpus":   "legal-contracts-q4"
  }'
# Antwort — Chunks, die der Agent zur Verankerung der Antwort benötigt.
{
  "items": [
    {
      "content":  "Section 7.3 is superseded by …",
      "metadata": { "doc": "amendment-2024.pdf", "section": "II.4.b" },
      "score":    0.91
    }
    /* … */
  ],
  "routing": {
    "backend":      "pageindex",           // an Tier-3-Page-Index weitergeleitet
    "match_source": "learned-history",     // Arena · Auto-Fix · oder Fallback
    "similarity":   0.92,                  // ≥ 0.88 Schwellenwert
    "ttl_remaining":"23d 14h"              // Frischefenster vor erneutem Benchmark
  }
}

Die routing-Metadaten werden derzeit intern protokolliert und über den Audit-Trail ausgewiesen. Die Inline-Auslieferung in der Response wird im Verlauf von Q3 2026 ausgerollt.

Wie sich das von bestehenden Routern unterscheidet

RAG-Routing ist keine neue Idee — akademische Router wie Adaptive-RAG und Probing-RAG klassifizieren Anfragen bereits nach Komplexität. Die Differenzierung liegt darin, dass Divinci über architektonisch unterschiedliche Retrieval-Stacks routet, gelernt aus Ihrem eigenen Traffic, hinter einem einzigen verwalteten Endpunkt.

Die ehrliche Schwäche in unserem Pitch: RAG-Routing pro Anfrage ist als Konzept nicht neu. Wir haben Routing nicht erfunden. Die echte Differenzierung ist die Kombination aus (a) Routing über architektonisch unterschiedliche Stacks statt nur über Tiefenvarianten, (b) PageIndex-/RAPTOR-/LightRAG-artige hierarchische Traversierung als erstklassiges Backend statt als separates Produkt und (c) einem verwalteten Endpunkt statt einer Bibliothek, die Sie selbst zusammenbauen und betreiben.

Wie Routing-Präferenzen befüllt werden

Ihr Routing-Modell ist nicht vortrainiert — es lernt aus Ihrem Traffic. Drei Signale speisen den Routing-Verlaufsspeicher.

Wann das am wichtigsten ist

Ein homogenes Korpus mit einheitlichen Anfrageformen profitiert kaum — wählen Sie manuell ein Backend, und Sie sind fertig. Der Hebel sind gemischte Korpora und gemischte Anfrageformen.