Corpus2Skillの導入を検討する際、最初に問われるのは「いま動いているRAGと何が違うのか」です。本ページでは、単発の密検索からエージェント型RAGまでの代表的な方式を取り上げ、アーキテクチャ・回答品質・運用コストの3つの観点からCorpus2Skillと比較します。
比較の観点と対象方式
論文「Don't Retrieve, Navigate」の評価では、Corpus2Skillは次の4種類のベースラインと比較されています。いずれもエンタープライズQAの現場で実際に使われている代表的な構成です。
- 単発の密検索RAG（single-shot dense）：質問をベクトル化して一度だけ類似検索し、上位チャンクをプロンプトに挿入する最も標準的な構成です。
- ハイブリッド検索RAG：ベクトル検索とキーワード検索（BM25など）を併用し、検索漏れを減らす構成です。
- 階層検索RAG：文書を階層的に要約・インデックス化し、粗い検索から細かい検索へ段階的に絞り込む構成です。
- エージェント型RAG：LLMエージェントが検索クエリを自分で発行し直しながら、複数回の検索を繰り返す構成です。
比較の軸は3つあります。第一にサーブ時アーキテクチャ（何を運用し続ける必要があるか）、第二に回答品質とグラウンディング（正確で根拠の裏付けがある回答を返せるか）、第三にコスト（1クエリあたりの処理コスト）です。
なお、コストの比較では「クエリ単価」と「基盤の固定費」を分けて考える必要があります。従来RAGはクエリ単価が安い一方、ベクトルDBや埋め込みサービングの常時稼働費用と運用工数という固定費を抱えます。Corpus2SkillはLLM API費用としてのクエリ単価が上がる代わりに、検索基盤の固定費がゼロになります。トラフィックの規模によってどちらが総額で有利かは変わるため、比較は総所有コストの視点で行うことをおすすめします。
サーブ時アーキテクチャの違い
従来RAG系の方式は、程度の差はあれサーブ時に検索基盤を運用し続ける必要があります。ベクトルデータベース、埋め込みモデルのサービング、キーワードインデックス、リランカーなど、構成要素が増えるほど、監視・スケーリング・更新の運用負荷は積み上がります。エージェント型RAGはさらに、検索APIとエージェントの協調動作という複雑さが加わります。
一方、Corpus2Skillのサーブ時ランタイム構成要素はLLMのみです。スキルツリーは静的なファイル群であり、データベースとしての運用は発生しません。埋め込みモデルもベクトルDBもコンパイル時にだけ使われるため、サーブ環境の構成は「LLM APIとファイル一式」まで単純化されます。
この違いは、障害対応やセキュリティ運用にも波及します。従来RAGでは、検索基盤の障害・性能劣化・データ同期漏れがそれぞれQA品質の劣化要因となり、原因の切り分けに複数コンポーネントの調査が必要です。Corpus2Skillでは、サーブ時の可変要素が実質的にLLM APIだけであるため、障害点が少なく、品質劣化の原因調査も「ツリーが適切か」「エージェントの探索が適切か」の2点に絞られます。また、静的ファイルは読み取り専用で配布できるため、アクセス制御やバックアップといった管理もファイル管理の標準的な手法がそのまま使えます。
方式別の比較表
各方式の特徴を、サーブ時に必要な基盤、探索の適応性、コスト傾向の観点で整理すると次のようになります。
| 方式 | サーブ時基盤 | 全体像の把握 | 探索の適応性 | コスト傾向 |
|---|---|---|---|---|
| 単発の密検索RAG | ベクトルDB＋埋め込み | 不可 | なし（一発勝負） | 低い |
| ハイブリッド検索RAG | ベクトルDB＋キーワード索引 | 不可 | なし | 低〜中 |
| 階層検索RAG | 階層インデックス＋検索基盤 | 部分的 | 限定的 | 中 |
| エージェント型RAG | 検索基盤＋エージェント | 不可 | クエリ再発行で対応 | 中〜高 |
| Corpus2Skill | LLMのみ | 鳥瞰ビューで可 | ドリルダウン＋バックトラック | 中程度（キャッシュで削減可） |
論文のエンタープライズ顧客サポートベンチマークでは、Corpus2Skillは回答品質とグラウンディングの両方で全ベースラインを上回り、その代償は中程度のコスト増にとどまると報告されています。エージェント型RAGとの違いは特に重要です。エージェント型RAGは「検索を繰り返す」ことで適応性を得ますが、検索エンジン越しにしかコーパスを見られない点は変わりません。Corpus2Skillはコーパスの構造そのものをエージェントに開示するため、探索の見通しが根本的に異なります。
両者の違いを比喩で表すなら、エージェント型RAGは「地図を持たずに、通行人（検索エンジン）への質問を繰り返しながら目的地を探す」やり方であり、Corpus2Skillは「地図を渡されて、自分で経路を選びながら歩く」やり方です。前者は質問の仕方（クエリ）が上手ければ目的地に着けますが、街全体の構造は最後まで分かりません。後者は現在地と全体の関係を常に把握でき、行き止まりに入っても地図を見て引き返せます。質問が曖昧であったり、答えが複数の場所に分散していたりするほど、地図を持つことの優位が効いてきます。
強みと弱み：トレードオフの正体
公平を期すため、Corpus2Skillのトレードオフも明確にしておきます。第一に、ナビゲーションは複数ステップのLLM呼び出しを伴うため、単発検索よりも1クエリあたりのトークン消費は増えます。ただし、上位ノードの読み込みはクエリ間で共通するためプロンプトキャッシュが強力に効き、WixQAベンチマークでは1クエリコストが0.172ドルから0.089ドルへ約48%削減されています。第二に、コーパス更新のたびに再コンパイルが必要で、リアルタイム性の高いデータには不向きです。第三に、後述する適用領域の制約があり、あらゆるコーパスで優位なわけではありません。
10種類のサブセットを用いた汎化研究では、「復元可能なトピック分類体系を持つ単一ドメインのコーパス」では一貫して有効である一方、「オープンドメインの事実断片のプール」や「均質な表形式データ」ではフラット検索が優位という結果が示されています。つまり、社内マニュアルやヘルプセンターのような構造化されたナレッジには強く、雑多な断片集合には従来型RAGが適するという適材適所の関係です。
選定の目安
実務での選定は、次のような整理が出発点になります。既存RAGの回答品質、特に「検索が外れたときの誤答」に課題があり、対象が社内マニュアル・製品ドキュメント・ヘルプセンター記事のような単一ドメインコーパスであれば、Corpus2Skillの検証価値は高いといえます。逆に、対象コーパスが雑多な事実断片の集合であったり、秒単位の更新反映が必要だったりする場合は、従来RAGの改善（ハイブリッド化・リランキング）を先に検討すべきです。
また、選定を検討するチームの体制も考慮に値します。従来RAGの精度改善には、検索エンジニアリング（チャンク設計・リランカー調整・クエリ書き換え）の専門知識が求められ、改善の当たり外れも読みにくい領域です。Corpus2Skillの改善は「ツリーを読み、文書を直し、再コンパイルする」という、ナレッジ管理に近い作業が中心になります。検索の専門家を抱えない組織にとって、改善作業の性質が業務知識側に寄っていることは、運用体制を組むうえで現実的な利点となります。
両者は排他的ではありません。構造化されたナレッジにはスキルツリー、更新頻度の高いデータには従来検索と、データ特性ごとに使い分けるハイブリッド戦略も現実的です。たとえばカスタマーサポートであれば、製品マニュアルとFAQはスキルツリーでナビゲートし、障害情報やお知らせのような日次更新データは従来検索で引く、という分担が考えられます。エージェントから見れば、スキルツリーも検索APIも「使えるツールの一つ」であるため、両方をツールとして持たせて質問の性質に応じて使い分けさせる構成は、エージェント設計として自然に実現できます。既存RAGからの移行を検討する場合も、一括の置き換えは不要です。まず対象コーパスの一部でCorpus2Skillをコンパイルし、既存RAGと同じ質問セットを両方に流して品質・グラウンディング・コストを並走比較する方法なら、本番トラフィックへの影響なしに判断材料が得られます。評価モジュールが同梱されているため、この比較検証は比較的低コストで実施できます。判断基準の詳細なフローチャートは「エンタープライズ活用と適用判断」に掲載しています。また、実測データに基づく品質比較は「ベンチマークと評価指標」をご覧ください。
- 従来RAG系はサーブ時に検索基盤の運用が必須ですが、Corpus2SkillはLLMと静的ファイルのみで動作します。
- ベンチマークでは回答品質・グラウンディングの両方で全ベースラインを上回り、コスト増は中程度です。
- 単一ドメインの構造化ナレッジに強く、雑多な断片集合ではフラット検索が優位という適材適所があります。
