大きなコンテキストウィンドウはキャパシティの上限であって、検索戦略ではない。モデルが数十万トークンを受け付けるという事実は、そのすべてに均等な注意を払って読んでいることを意味しないし、まして送る価値があることも意味しない。位置と長さを実際に計測した長文コンテキストのベンチマークは、どれも同じ結論に達している。入力が長くなるほど精度は落ち、プロンプトの中間に埋もれた根拠は最も使われない。

身につけるべき捉え方はこうだ。コンテキストウィンドウは使い切る予算であって、問い合わせるデータベースではない。ストレージのように扱うチームは、省略した検索パイプラインよりも遅く、コストがかかり、精度の低いシステムを作ることになる。

2つの失敗モードは別物だ

この2つは混同されがちだが、対処法はまったく異なる。

  • 位置による劣化。Liu et al.(2023)が示した「Lost in the Middle」効果だ。関連情報が入力の冒頭か末尾にあるとき精度は最も高く、中間にあると落ち込み、U字カーブを描く。他の条件を何一つ変えなくても、同じ事実を端から中央に移すだけで回答の質は下がる。
  • 長さによる劣化。根拠の位置が固定され、しかも有利な場所にあっても、入力が長くなるにつれて精度は下がっていく。RULER(Hsieh et al., 2024)のような後続研究は、複数のneedleやコンテキスト全体にわたる推論タスクで長文コンテキストモデルを検証し、実効的なコンテキスト長は謳われている数値より常に短いことを明らかにした。

位置による劣化は並べ替えで回避できることもある。だが長さによる劣化はそうはいかない。問題は干し草の山そのものの大きさにあるからだ。解決策は投入する量を減らすことに尽きる。

ベンチマークの数値が誤解を招く理由

Needle-in-a-haystackテストが人気を得たのは、実行しやすく合格しやすいからだ。長い文書のさまざまな深さに場違いな一文を隠し、モデルにそれを復唱させ、緑一色のグリッドを描く。このテストでほぼ満点を取ったモデルでも、実際に必要なタスクでは失敗しうる。現実の質問は字面の検索ではないからだ。

ユーザーが実際に聞いてくるのは、コーパス全体に散らばった4つの関連事実を見つけ出し、そのうち2つが矛盾していることに気づき、残りを踏まえて推論するといった作業だ。これはRULERが測定するタスクであり、謳われているウィンドウと実際に使えるウィンドウが乖離する地点でもある。単一needleの再現率は、ウィンドウが機能している証拠ではなく、あくまで簡易チェックとして扱うべきだ。

コスト面はごまかしがきかない

検索精度の劣化については議論の余地があるかもしれない。しかし請求額には議論の余地がない。入力トークンは呼び出しごとに課金されるため、毎回のリクエストに20万トークンのコンテキストを詰め込む設計は、回答に必要だったのが12トークンでもゼロでも、常に20万トークン分を支払うことになる。

# Stuff-the-window: whole handbook, every turn
200,000 input tokens x 50,000 calls/month = 10,000,000,000 tokens

# Retrieve-then-answer: system prompt + 6 chunks
  3,000 input tokens x 50,000 calls/month =    150,000,000 tokens

これは入力トークンだけで66倍の差になり、しかもレイテンシはまだ勘定に入れていない。最初のトークンが返るまでの時間はモデルが読む量に比例するため、詰め込んだプロンプトは遅くもある。より悪い回答に、より多くの金を払い、しかも到着が遅い。どの軸で見ても勝ち目はない。

プロンプトキャッシュはひとつの特定のケースでこの計算を複雑にする。呼び出しをまたいで本当に変化しない接頭辞は、大幅な割引で読み込める。これは実際に効果があり、使う価値がある。ただしそれが救うのは静的な前置き部分のコストであって、肥大化した干し草の山の再現率ではない。キャッシュされた悪いプロンプトは、安くなった悪いプロンプトにすぎない。

代わりにすべきこと

地味だが、効く規律だ。

  • 検索してから答える。モデルの前段に検索ステップを置き、上位数個のチャンクだけを渡す。Bedrock Knowledge Baseを使えば、自前でインデックスを持たずにこれができる。質の良い6チャンクは、平凡な600チャンクに常に勝る。
  • 本気でランク付けする。10個のチャンクを渡すなら、位置が重要である以上、順番も重要になる。最も強い根拠を先頭に、次に強いものを末尾に置く。注意が最も向きやすい場所だからだ。中間には二の次の材料を詰め、要となる事実は置かない。
  • 各ステップが見られる量に上限を設ける。呼び出しごとのトークン上限を厳格に設ければ、検索層は選別を強いられる。上限がなければコンテキストは肥大化し続け、たいてい最悪のタイミングで何かが壊れる。
  • 変動する本体ではなく、安定した接頭辞をキャッシュする。システムプロンプトやツールスキーマは呼び出しごとに変わらないため、キャッシュに置くべきものだ。検索で得た根拠は質問ごとに変わるため、キャッシュには向かない。
  • 自分自身の質問で再現率を測る。実際のクエリを実際のコーパスに対して実行し、回答を採点する。ベンダーが謳うコンテキスト長はマーケティング上の数値にすぎず、あなたのシステムを説明できるのは自分の評価だけだ。

大きなウィンドウが正解になる場合

ウィンドウを埋め尽くすのが正しい場合もあり、原則論で拒否すること自体がひとつの誤りになる。1つの文書を頭から終わりまで要約するには文書全体が必要で、すべてが関連する以上、検索すべきものは何もない。コードベースや契約書の全体を一度に視野に収める必要がある推論も、本当にその全長を必要とする。検索パイプラインを構築するコストがトークン代を上回るような一回限りの分析なら、意図的に手を抜くのは理にかなっている。

判断基準は、重要な部分集合に名前をつけられるかどうかだ。つけられるなら、それを検索すればいい。つけられないなら、つまりタスクがコーパスの一部ではなく全体にまたがるものなら、ウィンドウは本当に仕事をしているのであり、それを使うべきだ。

まとめ

より大きなコンテキストウィンドウは正真正銘の工学的成果であり、今後もさらに大きくなり続けるだろう。それは同時に、検索ステップの実装を避けるための最も高くつく方法でもある。再現率は長さと位置の両方で劣化し、請求額は送るトークンすべてに比例し、レイテンシはプロンプトのサイズに追随する。モデルが本当に見る必要があるものを見極め、それだけを送り、キャパシティを能力と取り違えるのはやめることだ。

次に読むべき記事

大規模な検索基盤運用のインフラ面については、クラウド・プラットフォームの実践ノートをercan.cloudに掲載している。ハブはercanermis.comだ。