RAGの世界で興味深い議論が起きています。
ベクトル検索を一切使わないアプローチで、企業の数百万規模のドキュメントを扱えるのか、という議論です。
きっかけはPageIndexというフレームワークの新発表でした。
海外の技術コミュニティで活発に意見が交わされています。
そして、その内容には学ぶべき視点が多く含まれています。
本記事では、議論の要点と参加者の批判的な意見を整理します。
PageIndexとはどんな仕組みか
PageIndexは「ベクトルレスRAG」を掲げるフレームワークです。
通常のRAGなら、ドキュメントを細かく分割します。
そして、それぞれを埋め込みベクトルへ変換して類似検索を回します。
一方、PageIndexのやり方はまったく違います。
ドキュメントを木構造として表現するのです。
章、節、ページ、内容という階層で組み立てた木があります。
LLMはこの木を辿りながら答えを探していきます。
GitHubで26,000を超えるスターを集めているプロジェクトです。
GitHub Trendingで1位を取った時期もあったとのこと。
注目度はそれなりに高いプロジェクトと言えます。
なぜスケールが疑問視されてきたのか
このアプローチには、根強い批判が寄せられてきました。
「1ドキュメント単位ならわかる。でも数百万のドキュメントを抱える企業環境ではどうするのか」という指摘です。
加えてコストの懸念もあります。
クエリごとにLLMが木を辿るとなれば、トークン消費が爆発的に増えそうな話です。
質問のたびに高額な計算リソースを消費する仕組みでは、現実の運用に乗りません。
ファイルシステム自体が木構造だという発想
PageIndexチームの新提案は、シンプルな観察から始まります。
ファイルシステムは、すでに木になっている、という観察です。
フォルダ、サブフォルダ、ファイルという階層は、まさに木そのもの。
だからフォルダ階層をドキュメント内部の木の上に接ぎ木します。
すると、LLMは自分の慣れた方法で全体を移動できます。
ドライブの最上位から特定ドキュメントの内部構造まで、ひとつながりの木として扱える、というアイデアです。
発想としてはエレガントに思えます。
ただし、それだけでは機能しない
この発表で興味深いのは、提案者自身が「単なる統合だけでは動かない」と率直に認めている点です。
フォルダ階層をそのまま使おうとすると、現実にはいくつかの壁にぶつかります。
主な壁は次の三つです。
頼れる階層が存在しない環境が多い
フラットなS3バケット、雑然としたSharePointの共有領域、すべての文書が一箇所に放り込まれた文書管理システム。
こうした場所には、構造を期待できません。
フォルダ階層は本質的に一次元
たとえば契約書ひとつとっても、ベンダー、地域、会計年度、製品ラインなど複数の軸に属します。
しかしフォルダに置く瞬間、どれかひとつの軸を選ぶしかなくなります。
フォルダ名が当てにならない
「misc」「final_v3_USE_THIS_ONE」「2019_legacy」といった名前を見たことがあるはずです。
LLMがこれを手がかりに辿ろうとすれば、ノイズの中を彷徨うことになります。
三つの解決策
これらの問題に対し、PageIndexチームは三つの工夫を組み合わせる戦略を取っています。
バーチャルノードの生成
使える階層がないなら、作ってしまおう、という発想です。
まず、トピッククラスタリングで似た文書をグループ化します。
そして、それを木のノードとして扱います。
さらにLLMにメタデータを推測させます。
カテゴリ、要約、主要なエンティティといった情報が、内部ノードとして加わっていきます。
面白いのは、同じドキュメントが複数の仮想的な親ノードの下に同時に存在できる点です。
これは普通のフォルダ構造では表現できません。
クエリに応じた木の構築
おそらくここがいちばん革新的な部分です。
木の構造は、ドキュメント取り込み時に固定されません。
クエリごとに、その場で組み立てられます。
たとえば、「ベンダーXに2024年いくら支払ったか」と聞いたとします。
すると、ベンダー → 年という軸の木が立ち上がります。
一方、「来四半期に更新が来る契約は何か」と聞けば、ステータス → 更新日という軸の木に変わります。
同じドキュメント群でも、聞き方しだいで違う木が現れる、というわけです。
再取り込みも再埋め込みもいりません。
利用可能なメタデータの軸から、その質問に合った構造をその場で組み立てます。
さらに、過去のクエリで辿られたパターンが、バーチャルノードを徐々に洗練していくとも説明されています。
適応的な木の探索
コストの懸念には、ここで答えが用意されています。
LLMはすべての階層を盲目的には走査しません。
各ノードで戦略を選びます。
子ノードのラベルが意味のある情報を持っているとします。
そのときは、層ごとに進みながら関係ない枝を早めに切り落とします。
逆にラベルが当てにならないときは、別の手法に切り替えます。
彼らが「ダイナミック・フラットニング」と呼ぶ手法です。
中間層を一気に潰し、葉ノードの実際の内容に直接当たる方法になります。
役に立たない中間層はスキップされる。
だから、LLMの呼び出しは構造が実際に意味を持つ場所だけに集中します。
探索の深さは、その質問にとって本当に必要な深さまで縮みます。
これが、数百万ドキュメント規模でもコストが暴走しない理由だ、というのが彼らの主張です。
コミュニティの批判的な視点
提案された手法は確かに洗練されています。
しかし、議論を読んでいると実務者からの率直な疑問や反論も多く見つかりました。
そもそも既存手法を超えられるのか
ある実務者は、品質ベンチマークとして使っているスタックを紹介していました。
具体的には、密ベクトル検索とBM25、それにリランカーを組み合わせたpgvectorのスタックです。
理論上はスケールしても、検索品質は急速に劣化するというのが彼の経験でした。
それに、LLMが検索のオーケストレーションに直接関わるなら、トークンの消費はどう抑えるのか。
そんな疑問も提示されています。
ベンチマークの評価については、もっと厳しい指摘もありました。
FinanceBenchで98.7%の精度を主張しているそうです。
しかし、これは自社で作ったベンチマークだという声が出ています。
マーケティングが派手で、宣伝されているほどの実力はないと感じる人もいるようです。
「ベクトルレス」より「チャンクレス」という見方
別の参加者は、フレーミングそのものに違和感を述べていました。
本質は「ベクトルを取り除いた」ことではない、という主張です。
むしろ、チャンク化、埋め込み、ベクトルストア、検索、再ランキングというパイプライン全体が消えたことが本質だと言います。
それを、構造化パーサとパース木をたどるLLMで置き換えた、というわけです。
だから「ベクトルレス」より「チャンクレス」と呼ぶほうが実態に近い、という指摘でした。
この視点はもっともだと思います。
ひとつの巨大なエンジニアリング機構を、別の巨大なエンジニアリング機構に差し替えただけにも見えるからです。
トピッククラスタリング、LLMによるメタデータ推測、バーチャルノード、クエリごとの木の構築、走査パターンのキャッシュ。
シンプルなシステムとはとても言えません。
「埋め込みなし」というセールスポイントの裏で、別の重いインジェスチョンパイプラインが組み込まれています。
これは鋭い読みだと思います。
多くの現場では、もっと小さい問題
加えて、実際のアプリケーションのほとんどでは、コーパスはもっと限定的だという声もあります。
数百から数千のドキュメントが普通だ、という話です。
しかも、ユーザーのコンテキストで事前に絞り込まれていることが多いそうです。
プロジェクトやフォルダ、案件ファイルなどの単位ですね。
そして、「正しい文書を見つける」問題と「文書の中で深く推論する」問題は別物だ、という指摘もありました。
ひとつの仕組みで解こうとすると、複雑性が戻ってくる、という見方です。
実用的な落とし所として提示されていたのは二段構成でした。
具体的には次のような流れです。
- 安価な検索で候補を絞る（タイトルや見出しに対するBM25、要約だけの小さなベクトルインデックスなど）
- その後で各文書内をチャンクなしで深く読む
実ユーザーは曖昧な質問をする
別の実務者は、PageIndexを実際に試したそうです。
そして、リアルなユーザーの前では破綻すると述べていました。
このシステムは、ユーザーが百科事典のように正確な用語で質問することを前提にしている、という指摘です。
しかし、現実のユーザーは曖昧な聞き方をします。
そこで普通のベクトルベースの意味検索や埋め込みが助けに来てくれる、というわけです。
本当に注目すべきは「クエリに合わせた検索」
議論を眺めていて、ある参加者の整理が頭に残りました。
「興味深いのはベクトルが死んだことではない」と。
本当に興味深いのは「クエリに応じた形の検索」だ、という指摘です。
固定的なベクトルインデックスは、すべての質問を同じ形で処理します。
クエリ → 近傍チャンク → 答え、という流れです。
これが多くのケースで機能するのは事実です。
しかし、答えに辿り着く道筋が構造に依存する場合があります。
たとえば次のような経路です。
- ベンダー → 年
- 契約タイプ → 更新日
- 口座 → 請求書 → 行項目
こういう経路は、類似検索だけでは捉えにくい構造です。
だからPageIndex方式は、別の問題に向かっている、ということになります。
「クエリが、どの構造を重視するかを決める」という問題です。
それに、検索パスが検証可能になる点も無視できません。
企業向け、法務、金融といった用途を考えてみてください。
「なぜこれが返ってきたのか」が答えそのものと同じくらい重要になります。
監査可能な検索パスを残せる利点は、構造化された専門コーパスに対して大きな価値を持つでしょう。
ハイブリッドが現実的な落とし所か
「ベクトルなしRAGがRAGを置き換える」と言うのは言い過ぎだろう、というのが大方の見方でした。
おそらく勝ち筋はハイブリッドです。
状況に応じて、次のように使い分ける構成が妥当でしょう。
- 階層やメタデータ、追跡可能性が答えに重要なときは、構造ベースの探索を使う
- 広く速く拾いたいときは、ベクトルやBM25、キーワード検索を使う
- 選んだ情報源を全文読み込むべきときは、長いコンテキストに頼る
クエリをルーティングして検索戦略を選びます。
そして証拠を取り出し、十分な原文コンテキストを引いて、根拠付きで答える。
こうした構成のほうが、特定の手法に賭けるよりも頑健に思えます。
評価という難問
もうひとつ、議論の中で印象的だった疑問があります。
クエリごとに構造が変わるなら、再現率やコストはどう測るのか、という問いです。
固定的な検索パイプラインなら、ベンチマークは比較的素直に組めます。
しかし、PageIndex方式はそうもいきません。
質問の種類によって必要な検索の形が変わるからです。
エンティティ参照、要約、コンプライアンスチェックなど、用途は多岐にわたります。
となると、評価セットも質問タイプごとに用意する必要が出てきます。
走査の深さも合わせて測る必要があるでしょう。
新しい仕組みを導入するとき、こういう評価設計の手間も含めて考える必要があります。
まとめ
ベクトルレスRAGをめぐる議論は、単なる新手法の紹介を超えていました。
検索の本質を問い直すものだったと感じます。
クエリの種類によって、適切な検索の形は変わります。
固定的な仕組みで全てを解こうとすると、どこかで無理が出てきます。
木構造の探索が活きる場面もあれば、類似検索のほうが向いている場面もあるはずです。
PageIndexチームの提案には、確かにエレガントな発想が含まれています。
一方で、実装の複雑性や評価の正当性については慎重に見たほうがいいでしょう。
新しい用語に飛びつく前に、自分のユースケースに本当に合うのかを考えることが先決です。
検索パスの検証可能性、クエリに応じた構造の選択、適応的な探索の深さ。
こうしたアイデアそのものは、たとえ全部を採用しないとしても学ぶ価値があります。
RAGアーキテクチャを設計する際の引き出しが、ひとつ増えた。
そう受け止めるのが健全な見方かもしれません。
