RAG 라우팅 — 하나의 API, 여러 아키텍처

세 가지 아키텍처, 개념적으로

대부분의 프로덕션 RAG 시스템은 하나의 검색 아키텍처를 배포하고 끝냅니다. 우리는 아키텍처적으로 서로 다른 스택들 사이에서 선택하는 라우터를 제공합니다 — 코퍼스 내 모든 쿼리에 동일한 선택이 최적인 경우는 거의 없기 때문입니다.

라우터가 실제로 결정하는 방식

대부분의 공개된 RAG 라우터는 쿼리를 사전에 복잡도로 분류합니다. 우리는 그렇게 하지 않습니다. 학습형 라우팅(learned routing)을 사용합니다 — 성공한 모든 쿼리는 답변한 백엔드와 함께 저장되며, 새 쿼리는 임베딩 유사도를 기준으로 그 이력과 매칭됩니다.

현재 라우팅 대상인 열 개의 백엔드

라우터는 명명된 열 개의 백엔드 중 하나로 디스패치합니다. 그중 세 개는 "Tier 3 형태"(계층적 또는 그래프 강화형)이고, 나머지는 운영상의 트레이드오프가 다른 순수 벡터 엔진으로 Tier 1으로 취급합니다.

PI

pageindex계층적 TOC 트리 + 에이전트형 탐색. Tier 3의 원형.

RT

raptor재귀적으로 요약된 문서 계층에 대한 트리 탐색 검색 (ICLR 2024).

neo4j-hybrid벡터 임베딩과 명시적 엔티티/관계 구조를 결합한 그래프 강화형 검색.

LR

lightrag평면 그래프 듀얼 모드 검색 — 엔티티 + 커뮤니티 검색, HKU LightRAG 접근법.

qdrant고처리량, 저지연 조회를 위한 자체 호스팅 dense-vector 엔진.

cloudflare-v2엣지의 Vectorize — Cloudflare 글로벌 네트워크에서 sub-300 ms p95.

couchbase-byok기존 운영 의존성을 가진 고객을 위한 BYO Couchbase 벡터 스토어.

vertex-ai-vector-search-v2Google 데이터 스택을 사용하는 고객을 위한 Google Cloud Vertex AI 벡터 검색.

mongodb-atlasMongoDB에서 문서 데이터를 운영하는 고객을 위한 Atlas Vector Search.

redis-vector-search초저지연 인메모리 검색 워크로드를 위한 Redis 벡터 검색.

Tier 2(BM25 + dense fusion + cross-encoder reranker)는 오늘 우리 워크플로 캔버스에서 구성 가능한 노드로 제공됩니다. 자동 라우터는 코퍼스별 라우팅 데이터가 이를 정당화하는 시점에 다음 대상으로 삼습니다.

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 · 또는 폴백
    "similarity":   0.92,                  // ≥ 0.88 임계값
    "ttl_remaining":"23d 14h"              // 재벤치마크 전 신선도 윈도우
  }
}

routing 메타데이터는 현재 내부적으로 로깅되며 감사 추적을 통해 노출됩니다. 인라인 응답 전달은 2026년 3분기 동안 순차 출시됩니다.

기존 라우터와 어떻게 다른가

RAG 라우팅은 새로운 아이디어가 아닙니다 — Adaptive-RAG, Probing-RAG 같은 학계의 라우터들은 이미 쿼리를 복잡도로 분류합니다. 차별점은 Divinci가 아키텍처적으로 서로 다른 검색 스택들 사이를 라우팅하고, 그것을 자체 트래픽으로부터 학습하며, 하나의 관리형 엔드포인트 뒤에 제공한다는 점입니다.

우리 피치의 솔직한 약점: 쿼리별 RAG 라우팅이라는 개념 자체는 새롭지 않습니다. 우리가 라우팅을 발명한 것은 아닙니다. 진정한 차별점은 (a) 깊이 변형이 아니라 아키텍처적으로 서로 다른 스택들 사이를 라우팅한다는 점, (b) PageIndex / RAPTOR / LightRAG 스타일의 계층적 탐색을 별개의 제품이 아닌 일등 백엔드로 포함한다는 점, (c) 직접 조립·운영해야 하는 라이브러리가 아닌 하나의 관리형 엔드포인트로 제공한다는 점 — 이 조합에 있습니다.

라우팅 선호도가 시드되는 방식

당신의 라우팅 모델은 사전 학습되어 있지 않습니다 — 당신의 트래픽으로부터 학습합니다. 세 가지 신호가 라우팅 이력 저장소에 공급됩니다.

이것이 가장 중요해지는 순간

동질적인 코퍼스에 균일한 쿼리 형태가 들어오는 환경에서는 이점이 거의 없습니다 — 백엔드 하나를 수동으로 선택하면 끝입니다. 진가는 혼합 코퍼스와 혼합 쿼리 형태에서 드러납니다.