より良いスニペットのためのクエリ認識型コンテキスト圧縮

あらゆる回答は証拠から始まります。検索システムにおいて、この証拠は通常、ドキュメント（タイトル、要約、チャンク、スニペット）から得られ、回答モデルやエージェントへのコンテキストとして渡されます。

この生データであるコンテキストにはノイズが含まれています。例えば、Webページにはユーザーのリクエストに必要な情報が含まれていることもあれば、注意をそらす要素が含まれていることもあります。これらの注意をそらす要素は、本文だけでなく、ナビゲーションテキスト要素、無関係な広告、メタデータなどの補助的な要素にも現れる可能性があります。これらの要素を下流のエージェントに渡すと、3つの問題が生じます。

第一に、精度の低下を招きます。最も強力なモデルであっても処理能力には限界があります。関連性のない情報が長く続くストリームはモデルの処理能力を無駄にし、「コンテキストの劣化（context rot）」を引き起こし、実際のユーザーのリクエストに対応するモデルの能力を損ないます。その結果、最終的な回答は重要な事実を見落としたり、低品質な情報を過大評価したり、ソースに基づいて立証することが困難な主張を生み出したりする可能性が高くなります。

第二に、レイテンシ（遅延）の増大を招きます。コンテキストが長くなると、特にクエリが多数の候補ページからの証拠を必要とする場合、下流のモデルが処理すべきトークン数が増加します。このレイテンシコストの一部はプリフィル段階で発生しますが、より大きなコストは推論段階で発生します。これは、モデルが無関係なコンテキストを処理するために、より多くの推論トークンを必要とするためです。

第三に、コストの上昇を招きます。モデルに渡される不必要なトークンはすべて、ユーザーのリクエストに対応するためのコストを増加させます。入力トークンと推論トークンの両方の使用量が増加し、コンテキストのノイズが多くなるためです。注意をそらす要素は品質を低下させるだけでなく、その低品質な結果に対してより高いコストを支払うことになります。

拡大

PerplexityのアプリケーションおよびAPIプラットフォーム全体で、精度、速度、費用対効果を同時に向上させるために、私たちはコンテキストの精度向上に多大な投資を行っています。その方法の1つは、スニペット生成アルゴリズムの改良です。私たちは、スニペット生成をコンテキスト圧縮の問題として捉えています。特定の情報を探しているモデルは、ドキュメントの一般的な要約や抜粋からは恩恵を受けられません。むしろ、ユーザーのリクエストに応えるために、ソース情報から最も小さく、かつ的確に抽出された断片を必要としています。それ以外の情報はすべて削除可能であり、また削除されなければなりません。

したがって、優れたスニペットは以下の3つのことを行う必要があります。

モデルの回答の根拠となる正確な証拠を提示することで、精度を向上させること。

LLM呼び出しの前に無関係なコンテキストを削除し、レイテンシとコストを削減すること。

引用の正確性を維持し、ソースの言い回しを損なわないことで、追跡可能性を確保すること。

今月、私たちは新しい最先端のスニペットジェネレーターをアプリケーションおよびAPIプラットフォームに展開しました。このモジュールの核となるのは、各クエリと候補結果に対して、保持すべきスパンのサブセットを決定するクエリ認識型コンテキスト圧縮モデルです。本記事では、この重要なタスクにおいてクラス最高レベルのパフォーマンスを達成するための、モデル構築とトレーニングへのアプローチについて説明します。

クエリ認識型圧縮としてのスニペット

最初に取り組むべきことは、タスクそのものを定義することです。このモデルに何をさせたいのか、入力と出力のスキーマをどのように定義すべきでしょうか。

スニペットの手法は大きく分けて2つの系統があります。1つ目は選択ベースの手法で、関連するウィンドウ、チャンク、文、またはパッセージを見つけて下流に渡します。2つ目は生成ベースの手法で、ページからクエリに焦点を当てた要約を作成するようモデルに指示します。

精度、レイテンシ、コストへの注力を考慮すると、設計上の選択は明確です。すべてのページに対して新しい要約を作成することは3つの焦点すべてにおいてパフォーマンスを低下させるため、生成の手法は除外されます。要約は、私たちが重視する証拠層には適していません。ソースを言い換えてしまう可能性があり、引用との整合性をとるのが難しくなるためです。また、スニペットが最終的な回答ではなく証拠として使用される場合、ページ内に存在しなかった言い回しを導入することはリスクを伴います。生成に伴うレイテンシとコストも、なおさら受け入れがたいものです。

むしろ、私たちはタスクを「クエリ認識型抽出圧縮（query-aware extractive compression）」として定義します。つまり、取得されたコンテキストから有益な部分を、注意をそらす部分から切り離すのです。具体的には、モデルがクエリと候補結果を受け取り、保持すべきスパン（クエリを最も強力に裏付ける部分）と、削除すべきスパン（それ以外）を決定する必要があります。モデルの出力は、ソーステキストを書き換えるのではなく、そのまま保持します。これにより、結果の引用、検証が容易になり、下流への受け渡しコストも削減されます。

例えば、次のクエリと取得結果を検討してみます。

拡大

妥当なモデル出力は、太字の文「In Comet, the assistant can ...」を選択することでしょう。

私たちのアプローチは、FliCo、Provence、LooCompといった従来のコンテキスト圧縮研究と同様の広範な概念に従っており、本番環境の検索システムにおけるスニペット生成向けに調整されています。重要な点として、このモデルは未加工の検索段階の後の精度向上フェーズとして機能します。前回のPerplexityリサーチ記事「Perplexity Search APIの紹介」で論じたように、私たちは検索システムをドキュメント以下のレベル（スニペットレベル）でネイティブに動作するように設計しており、これにより精度と再現率のバランスを既によく調整できています。クエリ認識型コンテキスト圧縮モデルの導入により、この精度と再現率のパレートフロンティアをさらに外側へと押し広げます。

コンテキスト圧縮モデルの構築とトレーニング

私たちは、クエリとコンテキストの共同理解、詳細な文レベルの選択、そして極めて厳しいレイテンシ予算に収まるための効率性を考慮してモデルを開発しています。

モデルアーキテクチャ

私たちはバックボーンとしてpplx-diffusionモデルを使用しています。これはpplx-embed-v1の背後にあるモデルファミリーと同じであり、私たちの以前の学術研究である「Diffusion-Pretrained Dense and Contextual Embeddings」および本番環境のベンチマークの両方において、クエリとコンテキストのペアに対する強力な双方向エンコーダーであることが確認されています。このモデルファミリーの重要な特性の1つは双方向コンテキストです。各トークンの表現は、モデルが保持すべきものを決定する前に、クエリ全体および候補コンテキスト全体を照合することができます。

このバックボーンの上に、コンテキストのどの部分を保持すべきかを予測する軽量な圧縮ヘッドをトレーニングします。生成プロセスを含まないため、これらの予測はコンテキスト全体で並行して行われます。サービス提供時には、スニペットエンジンがこれらの予測を文レベルで集約し、しきい値を適用し、要求されたトークン予算に合わせて結果をトリミングします。

教師あり学習パイプライン

このコンプレッサーをトレーニングするには、適切な粒度での監視（スーパービジョン）が必要です。ドキュメントレベルの関連性ラベルは、私たちの抽出圧縮タスクには明らかに不適切です。教師あり学習のために十分に詳細なデータを生成するため、私たちは、クエリに関連する証拠スパンと、削除すべきノイズスパンをマークするスパンラベリングパイプラインを構築しました。

私たちのパイプラインでは、「LLMを評価者として使用する（LLM-as-a-judge）」構成を採用しています。ユーザーのクエリと、そのリンク、タイトル、要約を含む候補Webページが与えられると、評価者はまずクエリを理解し、クエリを分析してユーザーの意図のリストを作成します。これらの意図を基に、評価者は候補となるコンテキストを処理し、テキストからそのままコピーされたスパンを返します。各スパンには、ラベルの確認を容易にするためのカテゴリが付与されます。

次に、返されたスパンをソーステキストと照合しました。当然のことながら、ほとんどの評価者の出力は既に正確なコピーでした。単純な文字列一致でスパンの98%が回収できました。単純な正規表現ベースのマッチングパスを追加することで、スパンの回収率は100%に達しました。これにより、トークンレベルの「保持/破棄」の教師データに変換可能な、信頼性の高い詳細なスパンを得ることができました。

私たちは、手動でラベル付けされたスパンを含む小規模な精選データセットを使用して、この教師パイプラインを評価しました。比較したのは、より小さな評価者モデル、異なるプロンプト、異なるステップ設定です。最もパフォーマンスが高かったのは、クエリ理解を最初に行い、その後にカテゴリ分けされたスパンラベリングを行うという2段階のパイプラインでした。また、抽出されたスパンセットは、BrowseCompやSimpleQAなどの下流の検証可能な評価を通じて検証しました。ここでは、保持された証拠スパンのみを使用することで、強力なスコアを維持しつつ、入力トークンを大幅に削減できました。

このパイプラインを使用して、75万件のクエリとドキュメントのペアにラベルを付け、その結果得られたスパンを使用して、バイナリ交差エントロピーを用いた圧縮ヘッドのトレーニングを行いました。このプロセスにより、クエリ認識型圧縮モデルは、下流のモデルがユーザーのリクエストに対応するのに役立たない可能性が高いコンテキストを削除しつつ、ソーステキストをそのまま維持できるようになりました。

リアルタイムレイテンシの確保

コンテキスト圧縮は下流モデルの前段に配置されるため、ブロッキング操作となります。さらに、各圧縮はクエリに依存します。そのため、オンラインパスでは、厳格なレイテンシ制限の中で、すべての候補ドキュメントに対してクエリとコンテキストのペアをスコアリングする必要があります。圧縮モデルが遅ければ、高い精度によって得られたレイテンシのメリットが圧縮そのもののレイテンシによって相殺されてしまい、本末転倒となります。同時に、知能の低い圧縮モデルでは、何を切り捨て何を保持すべきかという判断が不十分になります。

実務上の疑問は、圧縮品質が低下し始める前に、どの程度のモデル容量を安全に削除できるかという点です。私たちは、28層の完全なpplx-diffusionバックボーンを、レイヤープルーニングによって作成され、検索パスを対象とした11層および17層のバリアントと比較します。それぞれについて、圧縮しきい値を変化させながら、クエリごとに下流に送信されるコンテキストトークンの平均数と、圧縮後に保持された有用な証拠の割合という2つの指標を測定します。

図2は、品質と効率のフロンティアを示しています。モデルは、左上（より少ない下流トークンで、より多くの有用な証拠が保持される）へ向かうほど優れています。28層モデルは品質の基準となります。11層モデルは、モデルを過度に圧縮するリスクを示しています。プルーニングされた17層モデルは中間的な位置を占めており、飽和領域では28層モデルに追随しますが、ほとんどの本番トラフィックが動作する曲線の急峻な部分ではわずかな差が開きます。

その差を埋めるために、トークンレベルの知識蒸留を採用しています。私たちのアプローチは標準的なものです。標準的な損失関数に、教師モデルの予測に基づいたソフト交差エントロピー項を追加し、蒸留係数で重み付けを行います。これにより、生徒モデル（student model）は教師モデルと同等の性能に達し、本番環境で蒸留済みの17層モデルに完全に切り替えることが可能になりました。この新しい本番用モデルは、28層の教師モデルと比較して、推論レイテンシを35〜40%削減し、合計GPU計算量を40〜45%削減しつつ、品質低下は全くありません。本番環境のレイテンシは20ms（p99）未満であり、回答モデルに渡されるトークン総数を大幅に削減しながら、サービングパスに追加するのに十分な小ささを実現しています。

拡大

品質とトークンの効率

私たちはPerplexityのAgent APIをテストベッドとして使用し、コンテキスト圧縮の有効性を分析します。3つのAgent APIプリセットを評価します。

各結果セットのトークン予算を1000トークンに制限する「低（low）」コンテキストプリセット。

各結果セットのトークン予算を4000トークンに制限する「中（medium）」コンテキストプリセット。

各結果セットのトークン予算を10000トークンに制限する「高（high）」コンテキストプリセット。

標準（圧縮なし）および圧縮設定はどちらも、これらのトークン予算を遵守するように構成されています。

エージェント型マルチステップ検索（BrowseComp）

まず、BrowseCompベンチマークにおけるエージェント型マルチステップ検索ワークフローへの圧縮の影響を調査します。この評価には、オープンソースのsearch_evalsハーネスを使用します。評価はすべての実行において同一であり、OpenAIの標準的なBrowseComp LLM judgeプロンプトを使用しています。

興味深い2つの側面は、ベンチマークの精度とトークン使用量です。重要な点として、私たちはリクエストライフサイクル全体で発生する実際のトークン負荷を測定するために、個々のステップレベルではなくクエリレベルでトークン使用量を測定します。図3は、「スコアとトークン」のフロンティア（精度スコア対トークン使用量）を示しています。

拡大

圧縮は全体として新しいパレートフロンティアを実現します。各設定において、圧縮を導入することでクエリレベルのトークン使用量が10%から70%削減され、精度は4から4.81パーセントポイント向上しました。圧縮を導入することで、私たちの「低」プリセットでさえも、圧縮なしの「高」プリセットを上回ることが可能になり、同時にトークン使用量を3分の1以下に削減できました。

圧縮を使用することで、「高」が「中」よりも高い精度をもたらすことがわかります。しかし興味深いことに、それはより低いトークン使用量で達成されています。これは圧縮の微細かつ重要な効果を明らかにしています。圧縮を用いると、ステップごとのコンテキストサイズを大きくしても、モデルが正解に到達するために必要なステップ数を減らすことができるのです。この非単調性の調査は、今後の有望な研究方向です。

SimpleQA：シングルステップの事実確認

BrowseCompはマルチステップの調査に重点を置いていますが、多くの本番環境のワークフローにはシングルステップの事実検索が含まれます。圧縮がシングルステップ環境でも役立つかどうかを判断するため、エージェントループではなく単一の検索ステップで回答する4,326問の質問からなるベンチマークであるSimpleQAにおけるパフォーマンスも調査します。

前述と同様に、標準の評価者プロンプトを使用して、タスクごとの平均総トークン数に対する精度をプロットしました。図4は、このシングルステップ環境におけるスコアとトークンのフロンティアを示しています。シングルステップ環境では効果のサイズはより小さくなりますが、ここでも圧縮がすべてのプリセットで精度と効率を同時に改善し、新しいパレートフロンティアを導入していることがわかります。圧縮を有効にすると、中プリセットはドキュメントあたり平均わずか200トークンで95%の精度を達成します。平均ドキュメント長が10,000トークンを超えることを考えると、これは50倍以上の圧縮率でフロンティアレベルのパフォーマンスを実現していることを意味します。

拡大

スニペットには何が残るのか？

セクション4.1および4.2における下流の利益は、エンドツーエンドのものです。圧縮が個々のスニペットをどのように変化させるかを理解するため、私たちはLLM評価者を使用して、取得されたすべてのスニペットのすべてのトークンを6つのカテゴリのいずれかに分類する別の評価を実施しました。

重要（Vital）：ユーザーのクエリに回答するために不可欠な証拠。

トピック外（Off-topic）：他の目的には役立つ可能性があるが、対象のクエリには関連しない情報。

広告（Ads）：ユーザーのクエリへの回答を妨げる、無関係な広告。

メタデータ（Metadata）：ドキュメントのコンテンツに関するメタデータ。

UIおよびナビゲーション（UI & navigation）：フロントエンドの表示およびナビゲーションのための要素。

重複（Duplicate）：以前に取り込まれた情報の繰り返し。

私たちの評価は、検証セットから抽出した1,000件の混合ドメインクエリで実行し、本番環境のスタックと、圧縮を無効にした同一のベースラインを比較しました。図5に示すように、圧縮により、スニペットあたりの重要トークンの割合が、圧縮なしのベースラインと比較して平均63%増加しました。無関係なトークンは29%減少しており、特にUI/ナビゲーション（-58%）、メタデータ（-46%）、広告（-43%）で大幅な減少が見られました。これらの結果は、上述の品質と効率の改善メカニズムを裏付けています。つまり、圧縮は個々のスニペットの信号対雑音比（SN比）を鋭く高めることで、両方の次元でパフォーマンスを向上させているのです。

拡大

図6は、個別のクエリにおけるこの変化を示しています。クエリ「6 day old newborn milk intake per feeding（生後6日の新生児の1回あたりの授乳量）」に対して、圧縮なしのベースラインスニペットと、圧縮済みスニペットの両方を示します。圧縮は重要でないコンテンツカテゴリを除去し、新生児の授乳に関する情報のみを保持します。重要なことに、圧縮はページ全体としては一般的に関連性がある可能性があるものの、この特定の新生児に焦点を当てたクエリには無関係なコンテンツを、成功裏に排除しています。

拡大

結論

AIシステムは、ユーザーのリクエストに知的かつ効率的に対応するために、信号精度の高い情報に依存しています。この情報は、各リクエストへの関連性を最大化するために、可能な限り的確に提示される必要があります。私たちの新しいクエリ認識型圧縮モデルは、スニペットあたりのトピック内証拠を最大化し、無関係なノイズ要素を積極的に排除することで、まさにこれを実現しています。

これらの新しいモデルを検索スタック内に展開することで、私たちは製品やAPIを信頼してくださるユーザーに対して、より高速で質の高い回答を提供できます。私たちのアプローチはシンプルな制御面を作成し、システムやAPIの利用者が圧縮の度合いを調整して、再現率、レイテンシ、コストのバランスをとることを可能にします。

コンテキストのキュレーションは発展途上の分野であり、今日のフロンティア知能システム内で使用される各トークンの価値を最適化するためには、まだやるべきことがたくさんあります。私たちは、モデルの改善とシステムアーキテクチャの両面から、コンテキストキュレーション技術をさらに向上させ、これらのモデルをより広範に活用できるように積極的に取り組んでいます。

参考文献

N. Chirkova, T. Formal, V. Nikoulina, and S. Clinchant. Provence: Efficient and Robust Context Pruning for Retrieval-Augmented Generation, 2025. Accepted to ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim, and D. Kim. LooComp: Leverage Leave-One-Out Strategy to Encoder-only Transformer for Efficient Query-Aware Context Compression, 2026. arXiv:2603.09222.

S. Eslami, M. Gaiduk, M. Krimmel, L. Milliken, B. Wang, and D. Bykov. Diffusion-Pretrained Dense and Contextual Embeddings, 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez, and G. Neubig. Learning to Filter Context for Retrieval-Augmented Generation, 2023. arXiv:2311.08377.

引用

@online{perplexity2026QueryAwareContextCompressionForBetterSnippets,
  author = {{Perplexity} and Bo Wang and Hao Zhang and Ismail Gadzhiev and Kirill Priemko and Markus Krimmel and Nandor Licker and Vitalii Polshkov and Sarah Eslami and Louis Milliken and Maksim Gaiduk and Nikita Kireev and Jerry Ma},
  title = {{Query-aware context compression for better snippets}},
  date = {2026-05-14},
  url = {https://perplexity.coolkeypoint.com/hub/blog/query-aware-context-compression-for-better-snippets}
}