RAG Routing — Eén API, Meerdere Architecturen

De drie architecturen, conceptueel

De meeste productie-RAG-systemen leveren één retrieval-architectuur en noemen het klaar. Wij leveren een router die kiest tussen architectonisch verschillende stacks — de juiste keuze is zelden dezelfde voor elke vraag in uw corpus.

Hoe de router daadwerkelijk beslist

De meeste gepubliceerde RAG-routers classificeren de query vooraf op complexiteit. De onze niet. Wij gebruiken geleerde routing: elke succesvolle query wordt opgeslagen samen met de backend die hem heeft beantwoord, en nieuwe queries worden gematcht tegen die historie op basis van embedding-similariteit.

De tien backends waartussen we vandaag routen

De router stuurt door naar één van tien benoemde backends. Drie ervan zijn "Tier 3-vormig" (hiërarchisch of grafiek-versterkt); de andere zijn pure vector-engines die we behandelen als Tier 1 met andere operationele afwegingen.

PI

pageindexHiërarchische TOC-boom + agentische traversal. Het archetype van Tier 3.

RT

raptorTree-traversal retrieval over recursief samengevatte documenthiërarchieën (ICLR 2024).

neo4j-hybridGrafiek-versterkte retrieval die vector-embeddings combineert met expliciete entiteit-/relatiestructuur.

LR

lightragPlatte-grafiek dual-mode retrieval — entiteit- + community-zoekopdracht, de LightRAG-aanpak van HKU.

qdrantSelf-hosted dense-vector engine voor opzoekingen met hoge doorvoer en lage latency.

cloudflare-v2Vectorize aan de edge — sub-300 ms p95 vanuit het wereldwijde netwerk van Cloudflare.

couchbase-byokBYO Couchbase vector store voor klanten met bestaande operationele afhankelijkheden.

vertex-ai-vector-search-v2Google Cloud Vertex AI vector search voor klanten op de datastack van Google.

mongodb-atlasAtlas Vector Search voor klanten die documentdata op MongoDB draaien.

redis-vector-searchRedis vector search voor in-memory retrieval-workloads met ultralage latency.

Tier 2 (BM25 + dense fusion + cross-encoder reranker) is vandaag beschikbaar in ons workflow-canvas als composable node. De auto-router pakt dit als volgende op zodra de routing-data per corpus dit rechtvaardigt.

API-oppervlak — één endpoint, audit-grade transparantie

De router is onzichtbaar voor uw caller. Eén request-vorm; het antwoord bevat de routing-beslissing, zodat u kunt auditen welke backend heeft geantwoord (en waarom).

# Eén endpoint. De router beslist welke backend gebruikt wordt.
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 die de agent nodig heeft om het antwoord te onderbouwen.
{
  "items": [
    {
      "content":  "Section 7.3 is superseded by …",
      "metadata": { "doc": "amendment-2024.pdf", "section": "II.4.b" },
      "score":    0.91
    }
    /* … */
  ],
  "routing": {
    "backend":      "pageindex",           // doorgestuurd naar tier-3 page-index
    "match_source": "learned-history",     // arena · auto-fix · of fallback
    "similarity":   0.92,                  // ≥ 0.88 drempel
    "ttl_remaining":"23d 14h"              // versheidsvenster voor herbenchmark
  }
}

De routing-metadata wordt momenteel intern gelogd en zichtbaar gemaakt via het audit-spoor. Inline-respons-aflevering wordt gedurende Q3 2026 uitgerold.

Hoe dit verschilt van bestaande routers

RAG-routing is geen nieuw idee — academische routers zoals Adaptive-RAG en Probing-RAG classificeren queries al op complexiteit. Het onderscheidende is dat Divinci routeert tussen architectonisch verschillende retrieval-stacks, geleerd van uw eigen verkeer, achter één managed endpoint.

De eerlijke zwakte in onze pitch: per-query RAG-routing als concept is niet nieuw. We hebben routing niet uitgevonden. Het echte onderscheid is de combinatie van (a) routen tussen architectonisch verschillende stacks in plaats van diepte-varianten, (b) PageIndex- / RAPTOR- / LightRAG-achtige hiërarchische traversal als first-class backend in plaats van een apart product, en (c) één managed endpoint in plaats van een bibliotheek die u zelf samenstelt en beheert.

Hoe routing-voorkeuren worden gevoed

Uw routing-model is niet voorgetraind — het leert van uw verkeer. Drie signalen voeden de routing-historie-store.

Wanneer dit het meest uitmaakt

Een homogeen corpus met uniforme queryvormen heeft hier weinig baat bij — kies handmatig één backend en u bent klaar. De wedge ligt bij gemengde corpora en gemengde queryvormen.