RAGルーティング — 1つのAPI、複数のアーキテクチャ

3つのアーキテクチャ — コンセプト概要

多くの本番RAGシステムは、1つの検索アーキテクチャを出荷してそれで完結としています。私たちは、アーキテクチャ的に異なるスタック間で選択するルーターを提供します。コーパス内のすべてのクエリに対して最適な選択肢が同じであることは、ほとんどありません。

ルーターが実際にどのように判断するか

公開されている多くのRAGルーターは、クエリを事前に複雑さで分類します。私たちのものは違います。学習型ルーティングを採用しており、成功したクエリはすべて、それに回答したバックエンドとともに保存され、新しいクエリは埋め込み類似度によってその履歴と照合されます。

現在ルーティング対象としている10のバックエンド

ルーターは10種類の名前付きバックエンドのいずれかへ振り分けます。そのうち3つは「Tier 3型」（階層的またはグラフ拡張型）です。残りはピュアベクトルエンジンで、運用上のトレードオフが異なるTier 1として扱われます。

PI

pageindex階層的TOCツリー + エージェント型走査。Tier 3のアーキタイプ。

RT

raptor再帰的に要約された文書階層上のツリー走査型検索（ICLR 2024）。

neo4j-hybridベクトル埋め込みと明示的なエンティティ／関係構造を組み合わせたグラフ拡張型検索。

LR

lightragフラットグラフのデュアルモード検索 — エンティティ検索とコミュニティ検索、香港大学のLightRAGアプローチ。

qdrant高スループット・低レイテンシ検索のためのセルフホスト型dense-vectorエンジン。

cloudflare-v2エッジ上のVectorize — Cloudflareのグローバルネットワークからp95でサブ300ms。

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サーフェス — 1つのエンドポイント、監査グレードの透明性

ルーターは呼び出し側からは見えません。リクエスト形式は1つで、レスポンスにはルーティング判断が含まれるため、どのバックエンドが回答したか（そしてその理由）を監査できます。

# 1つのエンドポイント。ルーターがどのバックエンドを使用するか判断します。
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年Q3にかけて段階的に展開されます。

既存のルーターとの違い

RAGルーティングは新しいアイデアではありません。Adaptive-RAGやProbing-RAGなどの学術的ルーターは、既にクエリを複雑さで分類しています。差別化要因は、Divinciが1つのマネージドエンドポイントの背後で、お客様自身のトラフィックから学習しながら、アーキテクチャ的に異なる検索スタック間でルーティングする点にあります。

私たちの提案における正直な弱点：クエリごとのRAGルーティングというコンセプト自体は新しくありません。私たちがルーティングを発明したわけではありません。本当の差別化要因は、(a)深さのバリエーションではなくアーキテクチャ的に異なるスタック間でルーティングすること、(b)PageIndex／RAPTOR／LightRAG型の階層的走査を別製品ではなくファーストクラスのバックエンドとして組み込んでいること、そして(c)自前で組み立てて運用するライブラリではなく1つのマネージドエンドポイントであること — この組み合わせにあります。

ルーティング設定の種データはどのように投入されるか

ルーティングモデルは事前学習されていません — お客様自身のトラフィックから学習します。3種類のシグナルがルーティング履歴ストアに供給されます。

最も価値を発揮する場面

同質なコーパスで一様なクエリ形式しか扱わない場合、恩恵はわずかです — 手動で1つのバックエンドを選べば終わりです。本当の強みは、混在したコーパスと混在したクエリ形式にあります。