インデックスがウィンドウを超えると、検索パラダイムそのものが限界に達する。
検索は成功してきた
RAGの限界について論じた。 埋め込み類似度の不正確さ、チャンク分割の恣意性、品質判断の不可能性。
しかしその議論は検索の品質についてであった。 「いかにしてより正確に検索するか。」
今、別の問いを立てなければならない。 検索が完璧だと仮定する。 クエリに対して正確に関連する情報だけを返すと仮定する。
それでもうまくいかない場合がある。
スケールの問題
社内知識ベースに1,000件の記述がある。 インデックスがある。インデックスをコンテキストに入れる。クエリする。結果を取得する。 機能する。
記述が100,000件に増える。 インデックスが大きくなる。まだウィンドウに収まる。機能する。
記述が1,000万件に増える。 インデックスそのものがウィンドウを超える。
これは検索品質の問題ではない。 検索がどれほど正確であっても、 検索のために参照すべきインデックスがウィンドウに収まらなければ、 検索を開始すらできない。
そして知識は増え続ける。 企業の文書は毎日増える。 エージェントが学習したものは蓄積され続ける。 世界の知識は縮小しない。
ウィンドウを大きくすれば解決するか。 128Kが1Mになり10Mになったら？ 知識が1億件に達すれば、同じ問題が繰り返される。 ウィンドウは常に有限であり、知識は常に増える。 この不均衡は永続的である。
検索と探索の違い
検索は一回のクエリで結果を得る。
クエリ: 「サムスン電子 2024年第3四半期 営業利益」 -> 結果: 9.18兆ウォン。
一発。完了。
探索は複数のステップを経て結果に到達する。
ステップ1: 最上位の知識マップを見る。「企業」「産業」「マクロ経済」「技術」… -> 「企業」を選択。
ステップ2: 企業マップを見る。「サムスン電子」「SKハイニックス」「現代自動車」… -> 「サムスン電子」を選択。
ステップ3: サムスン電子マップを見る。「財務」「人事」「技術」「法務」… -> 「財務」を選択。
ステップ4: 財務マップを見る。「四半期業績」「年間業績」「投資計画」… -> 「四半期業績」を選択。
ステップ5: 四半期業績から「2024年第3四半期」を取得。 -> 営業利益: 9.18兆ウォン。
結果は同じである。 プロセスが異なる。
検索は「これはあるか」と尋ねることである。 探索は「どこにあるか」を追跡することである。
検索はインデックスがクエリ発行者から見えることを要求する。インデックス全体にアクセスできなければならない。 探索は現在の階層のマップだけが見えればよい。各ステップで一つの階層だけがウィンドウに入る。
図書館の比喩
近所の図書館を訪れる。 蔵書は3,000冊。 司書に尋ねる: 「李舜臣の伝記はありますか？」 司書は覚えている: 「棚3の端にあります。」 検索。機能する。
国立図書館を訪れる。 蔵書は1,000万冊。 司書に尋ねる: 「李舜臣の伝記はありますか？」 司書にもわからない。1,000万冊を暗記している人はいない。
代わりに分類体系がある。
1階の案内板を確認する。 -> 「歴史」部門は3階。 3階に行く。 -> 「韓国史」は東翼。 東翼に行く。 -> 「朝鮮時代」はD列。 D列に行く。 -> 「人物」はD列の3番目の区画。 3番目の区画を探す。 -> 李舜臣の伝記がある。
司書の記憶容量は変わっていない。 図書館の規模が変わったのである。 方法が、司書に尋ねる（検索）から分類体系を辿る（探索）に変わった。
ここがポイントである。 各ステップで見るべきもののサイズが司書の記憶容量に収まっている。 1階の案内板。3階のゾーンマップ。東翼の列リスト。D列の区画リスト。 すべて一目で把握できる。
全蔵書の完全カタログは一目では把握できない。 しかし各フロアのマップは把握できる。
これが探索と検索の違いである。 全体を一度に見る必要はない。 今いる場所から次の方向を判断できればよい。
マップのマップ
技術的に言えば、これはマップの階層構造である。
レベル1マップ: すべての知識の最上位分類。 「この知識ベースには企業、産業、マクロ経済、技術の情報がある。」 数十項目。ウィンドウに収まる。
レベル2マップ: 各最上位分類のサブカテゴリ。 「企業カテゴリにはサムスン電子、SKハイニックス、現代自動車がある…」 数十〜数百項目。ウィンドウに収まる。
レベル3マップ: 各サブカテゴリの詳細カテゴリ。 「サムスン電子には財務、人事、技術、法務がある…」 数十項目。ウィンドウに収まる。
実際の記述: 最下層のマップが指す具体的な情報。 「サムスン電子の2024年第3四半期の営業利益は9.18兆ウォンであった。」
各階層のサイズがウィンドウに収まるなら、 知識の総規模に関係なく探索が可能である。
1,000万件の記述があっても、 各階層が100項目であれば、5回の探索ステップで目標に到達する。 100 -> 100 -> 100 -> 100 -> 100 = 最大100億件をカバー。 各ステップで100項目だけがウィンドウに入る。
これはB-treeがディスク上のデータを見つける仕組みと同じである。 全データをメモリに読み込むのではない。 ツリーの現在のノードだけを読んで次に移動する。 メモリサイズに関係なく、あらゆる規模のデータを探索できる。
コンテキストウィンドウはメモリである。 知識ベースはディスクである。 マップはB-treeのノードである。
エージェントが歩く
複数ステップの探索で、各ステップの方向を選ぶのは誰か。
エージェントである。
レベル1マップをコンテキストに入れる。 エージェントがそれを読み、クエリと比較し、「企業」の方向を選択する。
レベル2マップを要求する。 企業のサブカテゴリマップがコンテキストに入る。 エージェントがそれを読み、「サムスン電子」の方向を選択する。
レベル3マップを要求する。 エージェントが「財務」を選択する。
これがエージェントのツール使用である。 マップを読むことはツールコールである。 方向を選ぶことは判断である。 次のマップを要求することは次のツールコールである。
検索では、エージェントは一度クエリして結果を受け取る。受動的。 探索では、エージェントは複数回判断し方向を選択する。能動的。
ここがコンテキストエンジニアリングとエージェント設計の交差点である。 コンテキストに何が入るかは、エージェントの判断によってステップごとに決定される。 コンテキスト構築が静的な組み立てから動的な探索へと変わる。
この問題は今日ほとんど議論されていない
RAGコミュニティの議論を見ると、 ほとんどのエネルギーは検索品質に集中している。
より良い埋め込みモデル。 より良いチャンキング戦略。 リランカーのアーキテクチャ。 ハイブリッド検索。 Graph RAG。
すべて重要である。 すべて「一回の検索でいかにより良い結果を得るか」についてである。
「一回の検索では足りない場合はどうするか」はほとんど議論されていない。
インデックスがウィンドウを超える時点。 結果が多すぎて収まらない時点。 知識の規模が検索パラダイムそのものの前提を破る時点。
その時点は来る。 知識は増え、ウィンドウは有限である。
現在のソリューションのほとんどは回避策である。 上位k件だけを取得する。残りは捨てる。 ウィンドウを拡大する。コストが増加する。 知識を分割する。ドメインごとに別のベクトルストアを用意する。
いずれも規模がさらに拡大すれば同じ問題に再び直面する。
探索の前提条件
探索が機能するためには、知識が探索可能な構造になっていなければならない。
階層が存在しなければならない。 知識がフラットに並んでいては探索は不可能である。埋め込みベクトルストアはフラットである。すべてのチャンクが同一レベルにある。階層がないため「より深く潜る」という概念が存在しない。
各階層がウィンドウに収まらなければならない。 一つのマップがウィンドウを超えれば探索は失敗する。階層の各レベルにおける選択肢の数は適切なサイズでなければならない。これは分類設計の問題である。
経路が多様でなければならない。 同一の情報に複数の経路で到達できなければならない。「サムスン電子 -> 財務 -> 営業利益」経由でも、「半導体産業 -> 主要企業 -> サムスン電子 -> 業績」経由でも到達できる。なぜなら自然な経路は質問によって異なるからである。分類基準が一つに固定されていると、ある質問には適合し、別の質問には適合しない。
フォルダ構造は階層を持つが経路は一つだけである。 ファイルは一つのフォルダにしか属さない。 「サムスン電子/財務/営業利益」の経路しか存在しない。 「半導体産業」についての質問が来たとき、このフォルダ構造では自然な探索が不可能である。
グラフは階層と多様な経路の両方を持つ。 一つのノードが複数の親ノードに接続できる。 サムスン電子ノードには「企業」経路、「半導体産業」経路、「KOSPI上場企業」経路から到達できる。 どのような文脈から質問が発せられても、自然な経路が存在する。
これは未解決の問題である
正直に言わなければならないことがある。
複数ステップの探索の必要性は明確である。 しかしこれを効果的に実装した標準的なシステムはまだ存在しない。
マップの階層をどのように自動生成するか。 各階層の適切なサイズをどのように決定するか。 エージェントが誤った方向を選んだ場合はどうするか。 探索の深さが増すにつれてレイテンシはどうなるか。
これらは未解決の問いである。
しかし問題が未解決であることは、 問題が存在しないことを意味しない。
知識は増え続けている。 ウィンドウは有限である。 検索だけでは足りなくなる時点は来る。
その時点に対する答えとして探索が用意されていなければならない。 用意されていなければ、 残る選択肢はウィンドウの拡大か知識の切り捨てだけである。
まとめ
検索は一回のクエリで結果を返す。 知識の規模が十分に大きくなると、これでは足りない。 インデックスそのものがウィンドウを超えるからである。
探索は階層的なマップを辿り、方向を選びながら下降する。 各ステップで見るべきものはウィンドウに収まる。 総規模に関係なく各ステップは有限である。 B-treeがディスク全体をメモリに読み込まずにデータを見つけるのと同じである。
エージェントが各ステップで方向を判断する。 コンテキスト構築が静的な組み立てから動的な探索へと変わる。 ここがコンテキストエンジニアリングとエージェント設計の交差点である。
探索が機能するためには、知識が階層的であり、各階層が有限であり、経路が多様でなければならない。 フォルダ構造は経路が一つだけである。グラフは多様な経路を持つ。
これは標準的な解決策のない未解決の問題である。 しかし知識が増え続けウィンドウが有限である限り、解決しなければならない問題である。