検索を置き換える実行時ナビゲーション

Corpus2Skillを説明するときに「検索なし」とだけ言うと、原文を参照せずに回答する仕組みのように聞こえるかもしれません。しかし、公開されている公式リポジトリの設計は、検索を放棄するものではありません。文書群をあらかじめ辿れるスキルツリーへコンパイルし、実行時にはエージェントが要約と索引を読みながら関連する枝を選び、必要な原文だけを取得します。置き換えているのは原文アクセスではなく、ベクトル類似度やキーワードに基づく検索器のランキングです。本稿では、コンパイル時と実行時を分けて、この設計の射程とRAGとの違いを整理します。

「検索なし」が指す範囲

一般的なRAGでは、質問を埋め込みに変換し、ベクトルデータベースや全文検索で候補チャンクを順位付けしてから、上位の断片をモデルへ渡します。Corpus2Skillは、公式READMEの説明によれば、実行時にベクトルDB、BM25、検索インデックスを前提にしません。代わりに、エージェントがツリー上の説明を読んで「次に確認すべき領域」を判断します。

ただし、これは「原文が不要」という意味ではありません。ツリーの末端まで辿り着いたあと、エージェントはget_documentツールを通じて必要な文書の全文を取得します。ナビゲーション用の情報と原文ストアは分かれており、公開実装では後者がdocuments.jsonとして保持されます。回答の根拠を本文へ戻せることは、企業のナレッジ活用で特に重要です。

つまり、問い直すべきなのは「検索を使うか、使わないか」ではなく、候補を誰がどの根拠で絞り込むかです。RAGでは検索器がスコア順に候補を出し、Corpus2Skillでは言語モデルが階層の意味を読み取って次の枝を選びます。

コンパイル時：知識の地図を作る

この方式の土台は、質問を受ける前に行うコンパイル処理です。公式実装は入力文書を埋め込み、階層クラスタリングし、各まとまりに要約とラベルを付けます。こうしてできる各ノードは、エージェントが読むためのSKILL.mdやINDEX.mdとして出力されます。上位ほど広い領域を説明し、下位ほど具体的な文書群へ近づく構造です。

この前処理にはコストも時間もかかります。さらに、クラスタの切り方や要約ラベルが不適切なら、エージェントは入口で誤った枝へ導かれます。そのため、ツリーは単なる生成物として保存するのではなく、代表質問で辿り方を確認し、文書更新に合わせて再コンパイルする運用対象として扱う必要があります。

実行時：エージェントが枝を辿る

実行時の流れは、上位のSKILL.mdで担当領域を把握し、関連する下位ノードのINDEX.mdを読む、という段階的なものです。質問に合う枝を選んだら、葉にひも付く原文をget_documentで取得して回答を組み立てます。最初から大量のチャンクをプロンプトへ詰め込まず、探索の途中でコンテキストを絞る点が特徴です。

このときエージェントには、検索スコアの代わりに「この説明は質問にどの程度関係するか」「次にどの索引を読むべきか」を判断する役割が与えられます。判断経路をログに残せば、どのノードを経由して原文に着いたかを後から確認できます。類似度上位の断片だけが並ぶ方式よりも、調査の手順を説明しやすくなる可能性があります。

一方で、ツリーが深すぎれば読み込むファイル数と探索ターン数が増え、浅すぎれば各ノードの説明が粗くなります。公式実装には分岐数やトップレベルスキル数、コンパクト出力を選ぶ設定があり、情報設計は固定値ではありません。コーパスの規模、質問の粒度、許容レイテンシを踏まえて調整するべきです。

RAG比較で見落とせない判断軸

Corpus2SkillとRAGを「どちらが高精度か」だけで比較すると、導入判断を誤ります。両者は候補を絞る仕組みが異なるため、評価では少なくとも次の観点を分けて観測します。

• 品質：正答率だけでなく、原文の根拠に到達できた割合、引用の妥当性、質問の取り違えを確認します。
• 実行時コスト：入力・出力トークン、探索ターン数、原文取得回数、プロンプトキャッシュの読込・作成トークンを記録します。
• 初期・更新コスト：埋め込み、クラスタリング、要約、ラベル付けに要する処理量と、更新時の再コンパイル範囲を測ります。
• 監査性：回答の根拠だけでなく、どの枝を選ばなかったかを含めて探索経路をレビューできるかを見ます。

公式READMEには、WixQAの200クエリでプロンプトキャッシュの利用により1クエリ当たりの費用が0.172ドルから0.089ドルになったという掲載値があります。ただし、これはモデル、キャッシュ条件、データセット、実装設定に依存する報告値です。自社の質問分布で再現できると決めつけず、比較実験の基準値として扱うのが適切です。

導入前に確認したい五つのこと

スキルツリー型の知識基盤は、検索基盤を別の名前に置き換えるだけでは成立しません。小規模な代表コーパスで、次の項目を確認してから対象範囲を広げると安全です。

1. 原文の品質と権限：重複、古い規程、アクセス権を整理し、取得ツールが文書ごとの権限を守ることを検証します。
2. 分類の妥当性：業務担当者がツリーのラベルを読んで、質問がどの枝に入るべきかを説明できるか確認します。
3. 経路の評価：正答でも偶然に辿り着いていないか、誤答時にどのノードで分岐を誤ったかを記録します。
4. 更新の手順：文書の追加・削除・改訂を検知し、再コンパイルと差分レビューを実施する責任者を決めます。
5. 失敗時の扱い：該当枝がないときに推測で答えず、原文確認や人へのエスカレーションへ切り替える条件を定めます。

Corpus2Skillは初期段階のプロジェクトであり、クラスタリングや評価機能も変化し得ます。だからこそ、導入の成否を「検索を消せたか」ではなく、原文へ辿る経路を品質・コスト・監査性の面から継続的に改善できるかで判断することが重要です。ナビゲーションという発想は、RAGを否定するためではなく、知識アクセスの設計をより明示的にするための選択肢として捉えるとよいでしょう。