Маршрутизация RAG — один API, множество архитектур

Три архитектуры — концептуально

Большинство продакшен-систем RAG поставляют одну архитектуру извлечения и считают задачу решённой. Мы поставляем маршрутизатор, который выбирает между архитектурно различными стеками — правильный выбор редко одинаков для всех запросов в вашем корпусе.

Как маршрутизатор на самом деле принимает решения

Большинство опубликованных маршрутизаторов RAG классифицируют запрос заранее по сложности. Наш — нет. Мы используем обучаемую маршрутизацию: каждый успешный запрос сохраняется вместе с бэкендом, который на него ответил, и новые запросы сопоставляются с этой историей по сходству эмбеддингов.

Десять бэкендов, между которыми мы сегодня маршрутизируем

Маршрутизатор направляет запросы к одному из десяти именованных бэкендов. Три из них «в стиле Tier 3» (иерархические или граф-расширенные); остальные — чисто векторные движки, которые мы рассматриваем как Tier 1 с разными операционными компромиссами.

PI

pageindexИерархическое дерево оглавления + агентный обход. Архетип Tier 3.

RT

raptorИзвлечение обходом дерева по рекурсивно резюмированным иерархиям документов (ICLR 2024).

neo4j-hybridГраф-расширенное извлечение, объединяющее векторные эмбеддинги с явной структурой сущностей и отношений.

LR

lightragПлоско-графовое извлечение в двойном режиме — поиск по сущностям и сообществам, подход HKU LightRAG.

qdrantSelf-hosted движок плотных векторов для высокопропускных поисков с низкой задержкой.

cloudflare-v2Vectorize на эдже — менее 300 мс p95 из глобальной сети Cloudflare.

couchbase-byokBYO-хранилище векторов Couchbase для клиентов с существующими операционными зависимостями.

vertex-ai-vector-search-v2Векторный поиск Google Cloud Vertex AI для клиентов на дата-стеке Google.

mongodb-atlasAtlas Vector Search для клиентов, хранящих документные данные в MongoDB.

redis-vector-searchВекторный поиск Redis для рабочих нагрузок извлечения с ультранизкой задержкой в памяти.

Tier 2 (BM25 + слияние плотных векторов + cross-encoder реранкер) поставляется сегодня в нашем canvas-воркфлоу как композируемый узел. Авто-маршрутизатор подключит его следующим, когда данные маршрутизации по корпусу это оправдают.

API-поверхность — одна конечная точка, аудитная прозрачность

Маршрутизатор невидим для вызывающего кода. Один формат запроса; ответ включает решение о маршрутизации, чтобы вы могли проаудировать, какой бэкенд ответил (и почему).

# Одна конечная точка. Маршрутизатор решает, какой бэкенд использовать.
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"
  }'
# Ответ — чанки, нужные агенту для обоснования ответа.
{
  "items": [
    {
      "content":  "Section 7.3 is superseded by …",
      "metadata": { "doc": "amendment-2024.pdf", "section": "II.4.b" },
      "score":    0.91
    }
    /* … */
  ],
  "routing": {
    "backend":      "pageindex",           // направлено на tier-3 page-index
    "match_source": "learned-history",     // arena · auto-fix · или fallback
    "similarity":   0.92,                  // порог ≥ 0.88
    "ttl_remaining":"23d 14h"              // окно свежести до переоценки
  }
}

Метаданные routing сегодня логируются внутренне и доступны через аудит-трейл. Инлайн-доставка в ответе раскатывается в течение Q3 2026.

Чем это отличается от существующих маршрутизаторов

Маршрутизация RAG не является новой идеей — академические маршрутизаторы вроде Adaptive-RAG и Probing-RAG уже классифицируют запросы по сложности. Дифференциация в том, что Divinci маршрутизирует между архитектурно различными стеками извлечения, обучаясь на вашем собственном трафике, за одной управляемой конечной точкой.

Честная слабая сторона нашего питча: маршрутизация RAG как концепция сама по себе не нова. Мы не изобрели маршрутизацию. Подлинная дифференциация — это сочетание (a) маршрутизации между архитектурно различными стеками, а не вариантами по глубине, (b) включения иерархического обхода в стиле PageIndex / RAPTOR / LightRAG как полноправного бэкенда, а не отдельного продукта, и (c) одной управляемой конечной точки вместо библиотеки, которую вы сами собираете и обслуживаете.

Как формируются предпочтения маршрутизации

Ваша модель маршрутизации не предобучена — она учится на вашем трафике. В хранилище истории маршрутизации поступают три сигнала.

Когда это важнее всего

Однородный корпус с единообразными формами запросов выигрывает мало — выберите один бэкенд вручную, и дело сделано. Точка опоры — это смешанные корпуса и смешанные формы запросов.