Language: 日本語 | English
確率と決定論の並走
― タグを共有意味空間にした検索設計
「全部」と「深さ」は別の問いである
検索に対して、人は2種類の問いを立てる。
「全部ある？」 — 特定の条件を満たすものを漏れなく返してほしい。条件の明確なもの、関係性が定義済みのもの、網羅性が保証されなければならないもの。これは確定的な問いだ。
「深くつながっているのは？」 — 意味的に近い、文脈として関連する、明示的な条件には現れないが確かに結びついている何か。これは確率的な問いだ。
この2つは性質が違う。どちらか一方で他方を代替することはできない。確定的な手法を使って「深さ」を問うと、ルールに書いていないものはすべて零点になる。確率的な手法を使って「全部」を問うと、確信度が低いものが混入し、漏れを検出できない。
設計の起点はここにある。2つの問いは最初から別のバックエンドに渡すべきだ。
tag as document — タグを検索可能なエンティティとして扱う
2系統を並走させる前に、共通の土台を作る必要がある。それが tag as document だ。
従来の設計において、タグはレコードに付属するラベルだ。メタデータとして付属し、フィルタリング条件として使われる。タグそのものを検索する対象とは見なさない。
この前提を変える。
対象に紐づくあらゆる属性を「タグ」として抽出し、それぞれを独立した検索可能なドキュメントとして格納する。タグは付属物ではなく、エンティティとして存在する。
この変換が重要なのは、曖昧入力の処理責任がどこに移るかという問題と直結しているからだ。
ユーザーの入力は常に曖昧だ。「〜に関するもの」「〜っぽいもの」という問いは、精確な検索条件として最初から定式化されていない。この曖昧さをどう処理するか。LLM に任せれば、同じ入力でも文脈の揺れによって毎回異なる検索条件が生まれる。
タグを独立したドキュメントとして持つと、曖昧な入力に対して「どのタグに近いか」を検索エンジンが判断できる。変換の責任が LLM から検索エンジンに移る。確率的な存在（LLM）が担っていた変換を、決定論的な存在（検索エンジン）が引き受ける。
タグは DB のラベルではない。検索可能な意味の節点だ。
直列分離から並走へ
tag as document の思想は、既存の設計原則（第3章・第9章）にすでに埋め込まれている。
直列分離の設計では、確定的な処理を上流に置き、LLM の確率性を下流に閉じ込める。
ユーザー入力
↓ 確定的変換（検索エンジン）
タグ検索 → 候補ドキュメント
↓ 確率的読解（LLM）
回答この直列構造は安定性をもたらした。しかし「全部」と「深さ」を同時に問う状況では、1系統の検索に直列でつなぐだけでは足りない。「全部」を取りに行くバックエンドと「深さ」を取りに行くバックエンドは、本質的に異なる処理を行う。
拡張の方向は自然だ。直列分離を維持したまま、上流の検索を2系統に分岐させる。
ユーザー入力
↓ タグ検索
├── Track 1: 意味的バックエンド（確率的）
│ └── 「なぜ」「どんな文脈で」→ 深さの候補
└── Track 2: 構造的バックエンド（決定論的）
└── 「全部」「必ずある」→ 網羅の候補
↓
統合 → LLM が読むLLM が担うのは依然として「読解」だけだ。確定的な処理は上流にある。ただしその上流が2系統になった。
Track 1（確率的）は意味的近傍を探す。クエリと意味的に近いタグ、文脈として結びついているタグを確率的に見つける。「なぜこれが関係あるか」の問いに答える。
Track 2（決定論的）は関係性を確定的に辿る。タグ間のグラフ構造を使って、「このタグを持つものをすべて返す」「この関係を持つタグを辿る」を確実に処理する。「全部あるか」の問いに答える。
同一タグスキーマを複数 DB に共有する
2系統並走の設計で、最も重要な問いがある。2つのバックエンドをどう設計するか。
既存の二系統並走設計（HybridRAG）は、それぞれのバックエンドを独立して構築し、クエリ時に結果を concat して rerank する。この設計では「2つのバックエンドが何を共有しているか」という問いを立てない。共有するのは入力クエリと最終的な出力だけだ。
この設計の限界は、2つのバックエンドが意味の言語を別々に持つ点にある。ベクトル DB はドキュメントをベクトルとして持つ。グラフ DB はドキュメントをノードと辺として持つ。両者の間に「意味的に同じものを指している」という対応関係がない。クエリ時の統合は意味基盤のない合流だ。
Dual-Track では起点を変える。
タグスキーマを設計段階で統一し、同じスキーマを両バックエンドに適用する。
同一のタグ定義が両バックエンドに存在するということは、「意味的に同一のエンティティが、確率的バックエンドと決定論的バックエンドの両方に、別の形で存在している」状態だ。
- 確率的バックエンドでは「このタグはセマンティック空間のこの座標にある」
- 決定論的バックエンドでは「このタグはグラフのこのノードにある」
同じタグが両方に存在する。どちらを経由してクエリを投げても、同じ意味的基盤から出発できる。
タグが両 DB をまたぐ意味空間の橋渡しになる。
統合のタイミングもここで変わる。HybridRAG が「クエリ時の統合」であるのに対して、Dual-Track は「設計時のスキーマ統一」だ。上流で意味の言語を合わせるから、クエリ時の統合がはじめて意味を持つ。
| HybridRAG | TigerVector | Dual-Track | |
|---|---|---|---|
| 設計の核心 | 二系統並走 + 無差別 concat | 単一 DB 内にベクトル + グラフ統合 | タグスキーマを複数 DB に共有 |
| タグの役割 | なし | なし | 意味空間の橋渡し |
| 統合タイミング | クエリ時 | - | 設計時（スキーマ統一） |
| 曖昧入力の処理 | LLM またはクエリ時ロジック | - | 検索エンジン（タグ検索） |
| 役割分担の明示 | なし | なし | 確率的 → 深さ、決定論的 → 網羅性 |
同時代的収束
TagRAG（arXiv:2601.05254 — v1 2025年10月投稿、最新版 v3 2026年5月、ACL 2026 Findings 採録）は、タグを意味空間のアンカーとして扱い、DAG（有向非巡回グラフ）を遡及する設計を発表した。
この論文の発表は、興味深い事実を示している。
TagRAG は独立して「タグを意味空間のアンカーとして使う」という方向に到達した。本設計が記述した tag as document の考え方と構造的に近い結論だ。これは先行されたのではなく、同じ問題意識が同時代の設計者を同じ方向に向かわせたという観察だ。
同時代的収束は、方向性の正しさを外部から確認する機能を持つ。1つの設計者が独自に到達した考え方が、独立した別の研究でも確認されるとき、それは特定の文脈への過剰適応ではなく、問題そのものの構造から来るアイデアであることを示す。
一方で差分もある。TagRAG は単一ライブラリ内での設計だ。本設計が核心に置く「同一タグスキーマを複数の独立したバックエンド DB に設計段階から共有する」という構造は、TagRAG には存在しない。TagRAG との収束は部分的なものであり、分岐点が明確にある。
同時代に同じ方向に向かう設計が複数現れたとき、それはアイデアの正しさではなく、問いの構造の正しさを示している。
このパターンが成立する前提
Dual-Track は単独では成立しない。上流にある2つの設計が前提になる。
レポート化アーキテクチャ（第6章）: LLM が読むべきデータが事前集約されたレポートとして存在している。Dual-Track は「どのレポートを読むか」の選択精度を上げる層だ。選択対象のレポートがなければ、検索の精度は意味を持たない。
曖昧入力の構造的解決（第3章・第9章）: ユーザーの曖昧な入力から正しいレポートに到達する経路がある。Dual-Track はこの経路を2系統に分岐させた拡張だ。経路そのものがなければ、分岐は何もしない。
この章のまとめ
- 「全部」と「深さ」は別の問いであり、別のバックエンドを必要とする
- tag as document: タグは DB ラベルではなく独立した検索可能エンティティ。曖昧入力の変換責任を検索エンジンに渡す
- 直列分離から並走へ: 上流の検索を確率的（深さ）と決定論的（網羅性）の2系統に分岐させる
- スキーマ共有が核心: 設計段階でタグスキーマを統一することで、タグが両バックエンドをまたぐ意味空間の橋渡しになる。HybridRAG の「クエリ時統合」とは根本的に異なる
- TagRAG との同時代的収束: 独立した研究が同じ方向に到達したことは、アイデアの正しさでなく問いの構造の正しさを示す
Last Updated: 2026-05-27