RAG Routing — Una sola API, molte architetture

Le tre architetture, a livello concettuale

La maggior parte dei sistemi RAG in produzione spedisce una sola architettura di retrieval e considera il lavoro concluso. Noi spediamo un router che sceglie tra stack architettonicamente distinti — la scelta giusta è raramente la stessa per ogni query del tuo corpus.

Come decide davvero il router

La maggior parte dei router RAG pubblicati classifica la query a priori in base alla complessità. Il nostro no. Usiamo il routing appreso: ogni query andata a buon fine viene memorizzata insieme al backend che ha risposto, e le nuove query vengono confrontate con quella storia tramite similarità di embedding.

I dieci backend tra cui instradiamo oggi

Il router fa dispatch verso uno dei dieci backend nominati. Tre di loro hanno la "forma Tier 3" (gerarchici o graph-enhanced); gli altri sono motori puramente vettoriali che trattiamo come Tier 1 con tradeoff operativi diversi.

PI

pageindexAlbero TOC gerarchico + traversal agentica. L'archetipo Tier 3.

RT

raptorRetrieval tree-traversal su gerarchie di documenti ricorsivamente riassunte (ICLR 2024).

neo4j-hybridRetrieval graph-enhanced che combina embedding vettoriali con struttura esplicita di entità e relazioni.

LR

lightragRetrieval dual-mode flat-graph — ricerca per entità + community, l'approccio LightRAG di HKU.

qdrantMotore dense-vector self-hosted per lookup ad alto throughput e bassa latenza.

cloudflare-v2Vectorize all'edge — sotto i 300 ms p95 dalla rete globale di Cloudflare.

couchbase-byokVector store Couchbase BYO per clienti con dipendenze operative esistenti.

vertex-ai-vector-search-v2Google Cloud Vertex AI vector search per clienti sullo stack dati Google.

mongodb-atlasAtlas Vector Search per clienti che fanno girare dati documentali su MongoDB.

redis-vector-searchRicerca vettoriale Redis per carichi di retrieval in-memory a latenza ultra-bassa.

Il Tier 2 (BM25 + dense fusion + cross-encoder reranker) viene spedito oggi nel nostro workflow canvas come nodo componibile. L'auto-router lo punterà come prossimo obiettivo quando i dati di routing per corpus lo giustificheranno.

Superficie API — un solo endpoint, trasparenza audit-grade

Il router è invisibile a chi chiama. Una sola forma di richiesta; la risposta include la decisione di routing così puoi controllare quale backend ha risposto (e perché).

# Un solo endpoint. Il router decide quale backend usare.
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"
  }'
# Risposta — chunk di cui l'agente ha bisogno per fondare la risposta.
{
  "items": [
    {
      "content":  "Section 7.3 is superseded by …",
      "metadata": { "doc": "amendment-2024.pdf", "section": "II.4.b" },
      "score":    0.91
    }
    /* … */
  ],
  "routing": {
    "backend":      "pageindex",           // dispatched al page-index tier-3
    "match_source": "learned-history",     // arena · auto-fix · oppure fallback
    "similarity":   0.92,                  // soglia ≥ 0.88
    "ttl_remaining":"23d 14h"              // finestra di freschezza prima del re-benchmark
  }
}

I metadata di routing sono attualmente loggati internamente ed esposti tramite l'audit trail. La consegna inline nella risposta è in rollout nel Q3 2026.

In cosa differisce dai router esistenti

Il routing RAG non è un'idea nuova — router accademici come Adaptive-RAG e Probing-RAG classificano già le query per complessità. La differenziazione è che Divinci instrada attraverso stack di retrieval architettonicamente distinti, appresi dal tuo traffico, dietro un unico endpoint gestito.

Il punto debole onesto del nostro pitch: il routing RAG per query, come concetto, non è nuovo. Non abbiamo inventato il routing. La differenziazione genuina è la combinazione di (a) routing tra stack architettonicamente distinti invece che varianti di profondità, (b) traversal gerarchica in stile PageIndex / RAPTOR / LightRAG inclusa come backend di prima classe invece che come prodotto separato, e (c) un unico endpoint gestito invece di una libreria che assembli e operi da solo.

Come vengono seminate le preferenze di routing

Il tuo modello di routing non è pre-addestrato — impara dal tuo traffico. Tre segnali alimentano lo store cronologico di routing.

Quando questo conta di più

Un corpus omogeneo con forme di query uniformi ne beneficia poco — scegli un backend manualmente e hai chiuso. Il cuneo sono i corpora misti e le forme di query miste.