Roteamento RAG — Uma API, Várias Arquiteturas

As três arquiteturas, conceitualmente

A maioria dos sistemas RAG em produção entrega uma única arquitetura de recuperação e considera o trabalho encerrado. Nós entregamos um roteador que escolhe entre stacks arquiteturalmente distintos — a escolha certa raramente é a mesma para cada consulta no seu corpus.

Como o roteador realmente decide

A maioria dos roteadores RAG publicados classifica a consulta de antemão por complexidade. O nosso não. Usamos roteamento aprendido: cada consulta bem-sucedida é armazenada junto com o backend que a respondeu, e novas consultas são comparadas a esse histórico por similaridade de embedding.

Os dez backends entre os quais roteamos hoje

O roteador despacha para um entre dez backends nomeados. Três deles têm "formato Tier 3" (hierárquicos ou enriquecidos por grafos); os demais são mecanismos puramente vetoriais que tratamos como Tier 1 com diferentes tradeoffs operacionais.

PI

pageindexÁrvore hierárquica de sumário + traversal agêntico. O arquétipo do Tier 3.

RT

raptorRecuperação por traversal de árvore sobre hierarquias de documentos sumarizadas recursivamente (ICLR 2024).

neo4j-hybridRecuperação enriquecida por grafos combinando embeddings vetoriais com estrutura explícita de entidades e relações.

LR

lightragRecuperação dual-mode em grafo plano — busca por entidade e por comunidade, a abordagem do LightRAG da HKU.

qdrantMecanismo denso-vetorial self-hosted para lookups de alta vazão e baixa latência.

cloudflare-v2Vectorize na edge — sub-300 ms p95 a partir da rede global da Cloudflare.

couchbase-byokVector store Couchbase BYO para clientes com dependências operacionais existentes.

vertex-ai-vector-search-v2Busca vetorial do Google Cloud Vertex AI para clientes no stack de dados do Google.

mongodb-atlasAtlas Vector Search para clientes que rodam dados documentais no MongoDB.

redis-vector-searchBusca vetorial Redis para cargas de recuperação in-memory com latência ultrabaixa.

O Tier 2 (BM25 + fusão densa + cross-encoder reranker) já é entregue hoje no nosso canvas de workflow como um nó componível. O roteador automático o adiciona em seguida, conforme os dados de roteamento por corpus justifiquem.

Superfície da API — um endpoint, transparência em nível de auditoria

O roteador é invisível para quem chama. Um único formato de requisição; a resposta inclui a decisão de roteamento para que você possa auditar qual backend respondeu (e por quê).

# Um único endpoint. O roteador decide qual backend usar.
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"
  }'
# Resposta — chunks de que o agente precisa para fundamentar a resposta.
{
  "items": [
    {
      "content":  "Section 7.3 is superseded by …",
      "metadata": { "doc": "amendment-2024.pdf", "section": "II.4.b" },
      "score":    0.91
    }
    /* … */
  ],
  "routing": {
    "backend":      "pageindex",           // despachado para page-index tier-3
    "match_source": "learned-history",     // arena · auto-fix · ou fallback
    "similarity":   0.92,                  // ≥ 0.88 de limiar
    "ttl_remaining":"23d 14h"              // janela de frescor antes de novo benchmark
  }
}

Os metadados de routing são atualmente registrados internamente e expostos via trilha de auditoria. A entrega inline na resposta está sendo liberada gradualmente ao longo do Q3 de 2026.

Como isso se diferencia dos roteadores existentes

Roteamento RAG não é uma ideia nova — roteadores acadêmicos como Adaptive-RAG e Probing-RAG já classificam consultas por complexidade. A diferenciação é que a Divinci roteia entre stacks de recuperação arquiteturalmente distintos, aprendidos a partir do seu próprio tráfego, atrás de um único endpoint gerenciado.

A fraqueza honesta no nosso pitch: roteamento RAG por consulta como conceito não é novo. Não inventamos o roteamento. A diferenciação genuína está na combinação entre (a) rotear entre stacks arquiteturalmente distintos em vez de variantes de profundidade, (b) traversal hierárquico nos moldes de PageIndex / RAPTOR / LightRAG incluído como backend de primeira classe, e não como produto separado, e (c) um único endpoint gerenciado em vez de uma biblioteca que você monta e opera por conta própria.

Como as preferências de roteamento são alimentadas

Seu modelo de roteamento não é pré-treinado — ele aprende com o seu tráfego. Três sinais alimentam o armazenamento de histórico de roteamento.

Quando isso importa mais

Um corpus homogêneo com formatos de consulta uniformes se beneficia pouco — escolha um backend manualmente e está pronto. A cunha está em corpora mistos e formatos de consulta mistos.