RAG Routing — Una API, muchas arquitecturas

Las tres arquitecturas, conceptualmente

La mayoría de los sistemas RAG en producción lanzan una sola arquitectura de recuperación y dan por terminado el trabajo. Nosotros lanzamos un router que elige entre stacks arquitectónicamente distintos — la elección correcta rara vez es la misma para cada consulta dentro de un corpus.

Cómo decide el router en realidad

La mayoría de los routers RAG publicados clasifican la consulta de entrada por complejidad. El nuestro no. Usamos enrutamiento aprendido: cada consulta exitosa se almacena junto con el backend que la respondió, y las nuevas consultas se comparan con ese historial mediante similitud por embeddings.

Los diez backends entre los que enrutamos hoy

El router despacha a uno de diez backends nombrados. Tres son "del tipo Tier 3" (jerárquicos o con grafos); los demás son motores puramente vectoriales que tratamos como Tier 1 con distintos tradeoffs operativos.

PI

pageindexÁrbol jerárquico tipo TOC + traversal agéntica. El arquetipo Tier 3.

RT

raptorRecuperación por traversal de árbol sobre jerarquías de documentos resumidas recursivamente (ICLR 2024).

neo4j-hybridRecuperación potenciada con grafos que combina embeddings vectoriales con estructura explícita de entidades y relaciones.

LR

lightragRecuperación dual-mode sobre grafos planos — búsqueda por entidad + comunidad, el enfoque LightRAG de HKU.

qdrantMotor de vectores densos self-hosted para búsquedas de alto throughput y baja latencia.

cloudflare-v2Vectorize en el edge — sub-300 ms p95 desde la red global de Cloudflare.

couchbase-byokVector store en Couchbase BYO para clientes con dependencias operativas existentes.

vertex-ai-vector-search-v2Búsqueda vectorial de Google Cloud Vertex AI para clientes sobre el stack de datos de Google.

mongodb-atlasAtlas Vector Search para clientes que corren datos documentales en MongoDB.

redis-vector-searchBúsqueda vectorial en Redis para cargas de recuperación en memoria con latencia ultrabaja.

Tier 2 (BM25 + fusión densa + reranker cross-encoder) está disponible hoy como nodo componible en nuestro canvas de workflows. El auto-router lo incorporará a continuación, a medida que los datos de enrutamiento por corpus lo justifiquen.

Superficie de la API — un endpoint, transparencia con grado de auditoría

El router es invisible para quien llama. Una sola forma de petición; la respuesta incluye la decisión de enrutamiento para que puedas auditar qué backend respondió (y por qué).

# Un solo endpoint. El router decide qué 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"
  }'
# Respuesta — chunks que el agente necesita para sustentar la respuesta.
{
  "items": [
    {
      "content":  "Section 7.3 is superseded by …",
      "metadata": { "doc": "amendment-2024.pdf", "section": "II.4.b" },
      "score":    0.91
    }
    /* … */
  ],
  "routing": {
    "backend":      "pageindex",           // despachado a page-index tier-3
    "match_source": "learned-history",     // arena · auto-fix · o fallback
    "similarity":   0.92,                  // umbral ≥ 0.88
    "ttl_remaining":"23d 14h"              // ventana de frescura antes de re-benchmark
  }
}

Actualmente los metadatos routing se registran internamente y se exponen a través del audit trail. La entrega inline en la respuesta se irá desplegando durante el Q3 de 2026.

En qué se diferencia esto de los routers existentes

El enrutamiento RAG no es una idea nueva — routers académicos como Adaptive-RAG y Probing-RAG ya clasifican consultas por complejidad. La diferenciación está en que Divinci enruta entre stacks de recuperación arquitectónicamente distintos, aprendiendo de tu propio tráfico, detrás de un único endpoint gestionado.

La debilidad honesta de nuestro pitch: el enrutamiento RAG por consulta, como concepto, no es nuevo. No inventamos el enrutamiento. La diferenciación genuina es la combinación de (a) enrutar entre stacks arquitectónicamente distintos en lugar de variantes de profundidad, (b) incluir la traversal jerárquica al estilo PageIndex / RAPTOR / LightRAG como backend de primera clase y no como producto aparte, y (c) un único endpoint gestionado en vez de una librería que tú ensamblas y operas.

Cómo se siembran las preferencias de enrutamiento

Tu modelo de enrutamiento no viene pre-entrenado — aprende de tu tráfico. Tres señales alimentan el almacén de historial de enrutamiento.

Cuándo importa más

Un corpus homogéneo con formas de consulta uniformes se beneficia poco — elige un backend manualmente y listo. La cuña son los corpus mixtos y las formas de consulta mixtas.