分析：長大なコンテキストは検索を不要にしたのではなく、その役割を変えた

コンテキストウィンドウが桁違いに拡大するたびに、決まって同じ主張が流布する。検索(リトリーバル)はウィンドウが小さかった時代の苦肉の策であり、今やウィンドウは巨大になったのだから、検索はもう不要だ、という主張である。文書をすべてプロンプトに放り込み、あとはモデルに任せればよいというわけだ。

この主張はあながち的外れではない。コードベース全体、一年分のメール、あるいは契約書の山を丸ごと一つのリクエストに収めることが、今や実際に可能になっている。それでも多くの本番システムが検索を使い続けているのは、単なる惰性ではない。「容量」と「利用」はまったく別物であることに加え、検索が持つ三つの特性がそもそもウィンドウのサイズとは無関係だからだ。

容量は利用ではない

100万トークンを受け付けるモデルは、確かに100万トークンを受け付ける。しかし、それを均等に使うかどうかはまったく別の実証的な問題であり、この現象が初めて特徴づけられて以来、答えは一貫している。長い入力の冒頭と末尾で想起精度が最も高く、中間部で最も低くなるのだ。

これが実務にもたらす帰結は、あまり心地よいものではない。文書がプロンプトのどこに位置するかは、その文書がどれほど関連性が高いかとは無関係に、モデルがそれを実際に使うかどうかを左右するのだ。50個の文書を無作為な順序で連結するシステムは、誰も監視していない品質変数を紛れ込ませていることになり、その変数は連結順序が変わるたびに揺れ動く。

よく持ち出される安心材料は「干し草の山の中の針」テストの結果である。巨大なウィンドウの中に特徴的な一文を仕込み、それが確実に見つかるというものだ。だが、このテストは見た目よりもずっと易しい。特異な文字列を一つ見つけ出すのは、語彙的なマッチングの作業にすぎない。実際の問いは、複数のパッセージを横断して情報を集約したり、二つの箇所が食い違っていることに気づいたり、答えがそもそも存在しないと判断したりすることを要求する。そうしたより厳しい形式で構築されたベンチマークは、一貫して、実効的な作業コンテキストが公称容量をはるかに下回ることを示している。

誰もやりたがらない算数

コストとレイテンシは、送信を許可されている量ではなく、実際に送信する量に比例して増える。

20万トークン規模のナレッジベースを相手に、1日1万件の質問をさばくサポートアシスタントを考えてみよう。毎回のリクエストにナレッジベース全体を詰め込めば、1日あたり20億入力トークンになる。現行のフロンティアモデルのどの価格帯であっても、これは無視できない予算項目として目に留まるだろう。一方、質問ごとに関連する4000トークンだけを検索して渡せば、1日あたり4000万トークンで済む。つまり50倍の差が、すべてのリクエストに対して、永続的に生じ続けるということだ。

レイテンシも同じ曲線を描く。最初のトークンが出るまでの時間は入力の長さに応じて伸び、回答が900ミリ秒で表示され始めるサポートウィジェットと、8秒かかるそれとでは、回答の質にかかわらず、まったく別の製品になってしまう。

プロンプトキャッシュはこの計算を複雑にするが、それは正確に記しておく価値がある。というのも、これは「詰め込み派」にとって最も強力な論拠だからだ。大きなプレフィックスが多数のリクエストにわたって同一であれば、キャッシュによってそのコストを大幅に、レイテンシも大きく削減できる。コーパスが本当に共有され、かつ安定している場合──固定の製品マニュアルや固定の法令集のような場合──であれば、この計算は変わってくるし、実際にはまだ十分に活用されていない手法でもある。しかしキャッシュは、大量のコンテンツがユーザーごと、リクエストごとに異なる場合には何の効果ももたらさない。そしてこれこそが、ユーザーごとに見せる文書が異なることそのものが要件であることの多い、大半のエンタープライズ導入の実態なのだ。

検索にあってコンテキストにない三つの特性

ウィンドウが大きくなっても揺るがない論点はここにある。

出典の明示性。 検索によって取り出されたパッセージには、モデルがそれを目にする前から、文書ID、URL、ページ、改訂版といった固有の識別情報が備わっている。モデルがそれを引用すれば、その引用は機械的に検証可能だ。一方、ウィンドウに放り込まれただけのテキストにはそうした識別情報がなく、未分化の塊から引用させようとすれば、検証が難しく、捏造もしやすい参照が生まれる。誤った回答であっても出典まで遡れる必要があるアプリケーション──法務、医療、金融、コンプライアンス──では、この一点だけで設計方針が決まってしまう。

鮮度。 コーパスは変化する。検索インデックスは新しい行を書き込むだけで更新できるが、詰め込み型のプロンプトはペイロード全体を再構築し、送り直すことで更新するしかない。ナレッジベースが1時間ごとに変わるような環境では、前者はバックグラウンドジョブで済むが、後者はリクエストのたびに課される税金のようなものになる。

アクセス制御。 これこそが、多くのエンタープライズアーキテクチャの選択を静かに決定づけている要因である。ユーザーごとに閲覧を許される文書は異なる。検索システムでは、権限はクエリの時点で──テキストがモデルに到達するより前に──適用されるフィルターであり、ごく普通の、監査可能な認可境界として機能する。一方、詰め込み型のシステムでは、権限の判断をペイロードの組み立て時に行わなければならず、そこでひとつでも誤りがあれば、あるユーザーの機密文書が別のユーザーのプロンプトの中に紛れ込むことになる。いったんウィンドウに入ってしまえば、下流のどんな制御をもってしても、それを「見なかったこと」にはできない。

ロングコンテキストが本当に優れている領域

その裏返しの誤りは、検索が常に勝ると結論づけてしまうことだ。大きなウィンドウは、特定の、しかも増えつつあるタスク群において、明確に優れている。

成果物全体を対象とする推論。 契約書全体を要約する、コードベース全体を横断してバグを追跡する、長大な二つの文書を条項ごとに突き合わせる、といったタスクである。こうしたタスクが依拠する構造は、チャンク分割によって積極的に破壊されてしまう。問いが「全体の形」に関するものであるなら、検索が返してくるのは、本来は無傷のまま必要だった論旨の断片にすぎない。

エージェントの作業記憶。 あるタスクの40ステップ目に差し掛かったエージェントは、それまでの経緯──ツールの出力、途中の推論、読み込んだファイル──を自ら抱えている。これはセッション内で積み上がったコンテキストであり、どんな検索インデックスにもそれは存在しない。ウィンドウが大きくなれば、それだけ、エージェントが以前の判断を圧縮せずに作業を続けられる時間が直接的に延びる。

低頻度・高リスクの読み取り。 タスクが1日に数十回程度しか実行されず、しかも1回あたりのコストよりも正確さの方がはるかに重要である場合、すべてをプロンプトに放り込むというシンプルさには、その対価を払うだけの価値がある。あらゆるシステムがインデックスを必要とするわけではない。

実際に機能するアーキテクチャ

これを二者択一として語るのは誤った二分法である。現時点で最も有力なパターンは、両者を順に組み合わせて使うものだ。

広く検索し、たっぷり読ませる。 検索を使って大きなコーパスを候補集合まで絞り込む──ただし、旧来のシステムなら500トークンのチャンクを3つ渡していたところを、丸ごとの文書を20件渡す。検索には検索が得意な仕事、すなわちアクセス制御を効かせつつ出典を保ったまま選別を行うという仕事をさせる。ロングコンテキストにはロングコンテキストが得意な仕事、すなわち人為的な断片化なしに素材全体を推論させるという仕事をさせるのだ。

これは、多くの旧来のRAGコードに埋め込まれた前提──ウィンドウが希少だからチャンクは小さくすべきだ、という前提──を反転させる発想である。もはやウィンドウは希少ではない。チャンク分割は、ウィンドウの予算ではなく検索品質のために行うべきだ。マッチングの精度が上がる粒度で検索を行い、ヒットした箇所はプロンプトに渡す前に、それぞれ完全なセクションないし文書全体まで展開する。

加えて、以前よりも重要性を増している二つの小さな実践がある。意図的に順序を組むことだ。位置による効果を踏まえれば、スコアの高いパッセージは組み立てたコンテキストの中央ではなく端に配置すべきである。そしてすべてのパッセージに出典IDのラベルを付すことだ。プロンプト中でそうしておけば、引用はモデルの善意に頼るものではなく、機械的なものであり続けられる。

正しいコンポーネントを評価する

ここで無駄な労力の大半を防いでくれる、ひとつの診断習慣がある。回答が誤っていた場合、まず必要な文書がそもそもコンテキストに含まれていたかどうかを確認することだ。

含まれていなかったのであれば、失敗したのは検索の段階であり、モデルをどう変えても解決しない。含まれていたにもかかわらずモデルが誤ったのであれば、それは生成の問題であり、ここで初めてウィンドウサイズや順序、プロンプト構造といった論点が関係してくる。エンドツーエンドの品質だけを計測しているシステムでは、この二つを区別できない。そうしたシステムを運用するチームは、壊れたインデックスを直すために、何カ月もかけてモデルを取り替え続ける羽目になりがちだ。

要約すればこうなる。ロングコンテキストは、検索を必須にしていた制約を取り払った。しかし検索を必要とする他のあらゆる理由は、そのまま手つかずで残された。 大半の本番システムは今後も両方を使い続けるだろう。興味深い設計上の課題は、もはや検索するかどうかではなく、検索した後で、どれだけの量をモデルに渡すかへと移っている。