Routage RAG — Une API, plusieurs architectures

Les trois architectures, conceptuellement

La plupart des systèmes RAG en production livrent une seule architecture de récupération et considèrent l'affaire close. Nous livrons un routeur qui choisit parmi des stacks architecturalement distincts — le bon choix est rarement le même pour toutes les requêtes de votre corpus.

Comment le routeur décide réellement

La plupart des routeurs RAG publiés classifient la requête d'emblée selon sa complexité. Le nôtre, non. Nous utilisons un routage appris : chaque requête réussie est stockée avec le backend qui y a répondu, et les nouvelles requêtes sont rapprochées de cet historique par similarité d'embedding.

Les dix backends entre lesquels nous routons aujourd'hui

Le routeur dispatche vers l'un de dix backends nommés. Trois d'entre eux sont de forme « Tier 3 » (hiérarchiques ou enrichis par graphe) ; les autres sont des moteurs purement vectoriels que nous traitons comme Tier 1 avec différents arbitrages opérationnels.

PI

pageindexArbre de table des matières hiérarchique + traversée agentique. L'archétype Tier 3.

RT

raptorRécupération par traversée d'arbre sur des hiérarchies de documents résumées récursivement (ICLR 2024).

neo4j-hybridRécupération enrichie par graphe combinant embeddings vectoriels et structure explicite d'entités / relations.

LR

lightragRécupération bi-mode sur graphe plat — recherche d'entités + de communautés, l'approche LightRAG de HKU.

qdrantMoteur vectoriel dense auto-hébergé pour des lookups à fort débit et faible latence.

cloudflare-v2Vectorize en edge — p95 sous 300 ms depuis le réseau global de Cloudflare.

couchbase-byokStore vectoriel Couchbase BYO pour les clients ayant des dépendances opérationnelles existantes.

vertex-ai-vector-search-v2Recherche vectorielle Google Cloud Vertex AI pour les clients sur la stack data de Google.

mongodb-atlasAtlas Vector Search pour les clients exploitant des données documentaires sur MongoDB.

redis-vector-searchRecherche vectorielle Redis pour les charges de récupération in-memory à très faible latence.

Tier 2 (BM25 + fusion dense + reranker cross-encoder) est livré comme nœud composable dans notre canvas de workflow aujourd'hui. Le routeur automatique le ciblera ensuite, à mesure que les données de routage par corpus le justifieront.

Surface API — un endpoint, transparence niveau audit

Le routeur est invisible pour l'appelant. Une seule forme de requête ; la réponse inclut la décision de routage pour que vous puissiez auditer quel backend a répondu (et pourquoi).

# Un seul endpoint. Le routeur décide quel backend utiliser.
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"
  }'
# Réponse — chunks dont l'agent a besoin pour fonder la réponse.
{
  "items": [
    {
      "content":  "Section 7.3 is superseded by …",
      "metadata": { "doc": "amendment-2024.pdf", "section": "II.4.b" },
      "score":    0.91
    }
    /* … */
  ],
  "routing": {
    "backend":      "pageindex",           // page-index tier-3 dispatché
    "match_source": "learned-history",     // arena · auto-fix · ou fallback
    "similarity":   0.92,                  // seuil ≥ 0.88
    "ttl_remaining":"23d 14h"              // fenêtre de fraîcheur avant re-benchmark
  }
}

Les métadonnées routing sont aujourd'hui journalisées en interne et exposées via la piste d'audit. La livraison inline dans la réponse est en cours de déploiement durant le Q3 2026.

En quoi cela diffère des routeurs existants

Le routage RAG n'est pas une idée neuve — des routeurs académiques comme Adaptive-RAG et Probing-RAG classifient déjà les requêtes par complexité. La différenciation, c'est que Divinci route entre des stacks de récupération architecturalement distincts, en apprenant à partir de votre propre trafic, derrière un seul endpoint managé.

La faiblesse honnête dans notre pitch : le routage RAG par requête, en tant que concept, n'est pas neuf. Nous n'avons pas inventé le routage. La vraie différenciation, c'est la combinaison de (a) router entre des stacks architecturalement distincts plutôt qu'entre des variantes de profondeur, (b) inclure la traversée hiérarchique de type PageIndex / RAPTOR / LightRAG comme backend de première classe plutôt que comme produit séparé, et (c) un seul endpoint managé au lieu d'une bibliothèque que vous assemblez et exploitez vous-même.

Comment les préférences de routage sont initialisées

Votre modèle de routage n'est pas pré-entraîné — il apprend de votre trafic. Trois signaux alimentent le store d'historique de routage.

Quand cela compte le plus

Un corpus homogène avec des formes de requêtes uniformes en tire peu de bénéfice — choisissez un backend manuellement et c'est plié. Le coin d'entrée, ce sont les corpus mixtes et les formes de requêtes mixtes.