RAG Routing — One API, Many Architectures

The three architectures, conceptually

Most production RAG systems ship one retrieval architecture and call it done. We ship a router that picks across architecturally distinct stacks — the right choice is rarely the same for every query in your corpus.

How the router actually decides

Most published RAG routers classify the query upfront by complexity. Ours doesn't. We use learned routing: every successful query is stored with the backend that answered it, and new queries are matched against that history by embedding similarity.

The ten backends we route between today

The router dispatches to one of ten named backends. Three of them are "Tier 3-shaped" (hierarchical or graph-enhanced); the others are pure-vector engines we treat as Tier 1 with different operational tradeoffs.

PI

pageindexHierarchical TOC tree + agentic traversal. The Tier 3 archetype.

RT

raptorTree-traversal retrieval over recursively summarised document hierarchies (ICLR 2024).

neo4j-hybridGraph-enhanced retrieval combining vector embeddings with explicit entity / relationship structure.

LR

lightragFlat-graph dual-mode retrieval — entity + community search, the HKU LightRAG approach.

qdrantSelf-hosted dense-vector engine for high-throughput, low-latency lookups.

cloudflare-v2Vectorize at the edge — sub-300 ms p95 from Cloudflare's global network.

couchbase-byokBYO Couchbase vector store for customers with existing operational dependencies.

vertex-ai-vector-search-v2Google Cloud Vertex AI vector search for customers on Google's data stack.

mongodb-atlasAtlas Vector Search for customers running document data on MongoDB.

redis-vector-searchRedis vector search for ultra-low-latency in-memory retrieval workloads.

Tier 2 (BM25 + dense fusion + cross-encoder reranker) ships in our workflow canvas as a composable node today. The auto-router targets it next as the per-corpus routing data justifies.

API surface — one endpoint, audit-grade transparency

The router is invisible to your caller. One request shape; the response includes the routing decision so you can audit which backend answered (and why).

# One endpoint. The router decides which backend to use.
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"
  }'
# Response — chunks the agent needs to ground the answer.
{
  "items": [
    {
      "content":  "Section 7.3 is superseded by …",
      "metadata": { "doc": "amendment-2024.pdf", "section": "II.4.b" },
      "score":    0.91
    }
    /* … */
  ],
  "routing": {
    "backend":      "pageindex",           // dispatched tier-3 page-index
    "match_source": "learned-history",     // arena · auto-fix · or fallback
    "similarity":   0.92,                  // ≥ 0.88 threshold
    "ttl_remaining":"23d 14h"              // freshness window before re-benchmark
  }
}

The routing metadata is currently logged internally and surfaced via the audit trail. Inline response delivery is rolling out across Q3 2026.

How this differs from existing routers

RAG routing isn't a new idea — academic routers like Adaptive-RAG and Probing-RAG already classify queries by complexity. The differentiation is that Divinci routes across architecturally distinct retrieval stacks, learned from your own traffic, behind one managed endpoint.

The honest weakness in our pitch: per-query RAG routing as a concept isn't new. We didn't invent routing. The genuine differentiation is the combination of (a) routing across architecturally distinct stacks rather than depth variants, (b) PageIndex / RAPTOR / LightRAG-style hierarchical traversal included as a first-class backend rather than a separate product, and (c) one managed endpoint instead of a library you assemble and operate yourself.

How routing preferences get seeded

Your routing model isn't pre-trained — it learns from your traffic. Three signals feed the routing-history store.

When this matters most

A homogeneous corpus with uniform query shapes benefits little — pick one backend manually and you're done. The wedge is mixed corpora and mixed query shapes.