比較アプローチ：グラフ構造検索は優れていない

大規模言語モデルを搭載したエージェントは当たり前の存在になりつつあるが、見落とされがちなボトルネックがある。スキルライブラリが数百件に膨れ上がったとき、エージェントはどのスキルを読み込み、どの順序で実行するかをどう決定すべきなのか。全スキルをむやみにコンテキストへ詰め込むのは、コストが莫大なだけでなく、実行順序に関する構造も一切もたらさない。最近arXivに公開された論文（番号 2608.06196）は、主流の2つの検索手法を直接比較し、直感に反する結論を示している。丹念に構築した知識グラフは、素朴なハイブリッドランカーに勝てなかったのだ。

2つのアプローチの正面対決

論文では、690個のスキルを含むコーパス上で2つのシステムを評価している。1つ目はハイブリッドランカーで、語彙マッチングと稠密ベクトル検索を組み合わせ、スパースなオンデマンド読み込みを行う。2つ目は型付き知識グラフで、前提条件・データフロー・実行順序といったワークフロー関係を型付きエッジとしてエンコードし、LLMにそれらのエッジを生成させる。研究者らは、117件の現実的かつ非エコーなクエリを使用した。非エコーとは、クエリがスキル名をそのまま書き写すのではなく、具体的なタスクを自然言語で記述することを指し、明らかに実使用シナリオに近い。

結果によれば、ハイブリッドランカーが正しいスキルをトップ5に並べた割合は73.5%±8.0で、およそ4分の1のクエリがカバーされていないことを意味する。一方、設計意図どおりにグラフの近傍ノードを追加結果としてランカーの出力に差し替えた場合（トークン予算を同じに保ったまま）、グラフの性能は有意に悪化し、差は11.2ポイント（p=0.0007）に達した。言い換えれば、同じコストでは、グラフは利益をもたらさないどころか、足を引っ張ったのである。

なぜグラフは期待どおりに機能しなかったのか

論文は極めてメカニズム的な説明を提示している。グラフの候補エッジは、実はランカーがすでに検索した埋め込み近傍から抽出されている。統計によれば、98.6%の型付きエッジは、ランカーが既に同時にリコールしていたスキル同士を結んでいる。つまり、グラフができるのはランカーがすでに発見した関係を言い換えることだけであり、検索の境界を一歩たりとも外側へ押し広げてはいない。LLMが生成したエッジ層も付加価値をもたらさず、その貢献はローカル埋め込みから直接得られる近傍には及ばなかった。

さらに警戒すべきは、評価方法が生み出す幻想である。研究者らは、著者自身が作成したクエリでテストすると、hit@5が最大44ポイント過大評価されることを発見した。この差は、ある手法が完全に無効であることを覆い隠し、もっともらしい結論を説得力のないものにしてしまう。論文は、核となる貢献はメカニズムの解明にあるとしている。すなわち、強力なランカーに構造を追加してもリコールが向上しない理由、そしてどのような条件で構造依存が真に有益になるのか、という問いへの答えである。

「何が役立つか」よりも「なぜ役立たないのか」を理解することのほうが、時に価値がある。この論文の厳密さは、グラフの限界を事前フィルタリングのトポロジー的境界に帰着させ、すべての比較データを公開している点にある。

エージェント開発者への3つの示唆

• まずランカーを磨く：スキル検索において、適切に訓練されたハイブリッドランカーはすでに大部分の利益を得ている可能性が高い。グラフに投資する前に、まず検索ベースラインの上限を確認すべきだ。
• グラフを反響室にするな：グラフのエッジがランカーでは到達できない外部情報（たとえばスキル横断的な経験則）を導入できる場合にのみ、構造のために追加コストを払う価値がある。
• 実クエリで評価する：手軽に数件のクエリを書いて検証すると、過大評価した結論に陥りやすい。実際の使用で発生したリクエストを可能な限り収集するか、非エコーな自然言語タスクを使うこと。

この論文は既存のシステムを否定するものではないが、非常に実用的なベースラインデータを提供している。大規模スキルライブラリのシナリオでは、優れたハイブリッド検索器がすでに問題の大部分を解決している可能性が高く、追加の構造化知識は、より説得力のある利益を示して自らの価値を証明する必要がある。エージェント向けのスキル層や記憶メカニズムを設計中のチームにとって、これは精読に値する実証的な参考資料であり、少なくとも数か月の遠回りを省いてくれるはずだ。