LLMコンテキストの刈り込み：より良いRAGとエージェントAIの結果を得るための開発者ガイド

LLMのコンテキストウィンドウは最近巨大化している。モデルによっては1回のパスで100万個以上のトークンを扱えるものもあり、新しいリリースが出るたびにその数はさらに増えているようだ。それはエキサイティングなことだが、実際に長いコンテキストを使うものを作ったことがある人なら、可能なことと有用なことの間にギャップがあることを知っているだろう。

モデルが1回のプロンプトで本全体を読めるからといって、それを与えるべきだということにはならない。ほとんどの長い入力は、モデルが必要としないものでいっぱいだ。1つのプロンプトに何十万ものトークンを入力し始めると、通常、応答が遅くなり、計算コストが高くなり、時には質の低い回答になります。

そのため、コンテキストウィンドウが大きくなり続けても、本当の問題は、そこに何を入れるべきか、ということになる。そこでコンテキスト・プルーニングの出番だ。コンテキスト刈り込みとは、基本的に、検索された、あるいは組み立てられたコンテキストのうち、モデルが質問に答えるのに役立たない部分を切り捨てる処理のことである。正しく行うことで、システムは高速で安定し、より予測しやすくなります。

この記事では、長いコンテキストがしばしば予想と異なる振る舞いをする理由、プルーニングがどのように物事をコントロールするのに役立つか、そしてProvenceのようなプルーニングツールがどのように実際のRAGパイプラインに適合し、セットアップを複雑にしないかについて説明する。

ロングコンテキストシステムにおける4つの一般的な失敗モード

コンテキストウィンドウを大きくしたからといって、魔法のようにモデルが賢くなるわけではない。むしろ、いったん大量の情報をプロンプトに詰め込み始めると、物事がうまくいかなくなる可能性のある全く新しいセットの鍵を開けることになる。ここでは、ロングコンテキストシステムやRAGシステムを構築する際によく見られる4つの問題を紹介する。

1.コンテキストの衝突

コンテキストの衝突は、複数のターンにわたって蓄積された情報が内部的に矛盾するようになったときに起こる。

例えば、あるユーザーが会話の早い段階で "リンゴが好き "と言い、後に "果物は嫌い "と言ったとする。両方の発言がコンテキストに残っている場合、モデルには矛盾を解決する信頼できる方法がないため、一貫性のない、またはためらった回答につながります。

2.文脈の混乱

コンテキストの混乱は、コンテキストの中に無関係な情報や関連性の弱い情報が大量に含まれてい る場合に生じ、モデルが正しい行動やツールを選択することを困難にする。

この問題は、特にツール拡張システムで顕著に現れる。コンテキストが無関係な詳細で乱雑になると、モデルはユーザーの意図を誤って解釈し、間違ったツールやアクションを選択することがあります。正しい選択肢がないからではなく、信号がノイズに埋もれているからです。

3.コンテキストディストラクション

コンテキストディストラクションは、過剰なコンテキスト情報がモデルの注意を支配し、事前に学習された知識や一般的な推論への依存を低下させる場合に起こります。

広範に学習されたパターンに依存する代わりに、モデルは、たとえそれが不完全であったり信頼性に欠けるものであっても、文脈の中の最近の詳細を過度に重視する。これは、より高いレベルの理解を適用するのではなく、コンテクストをあまりにも忠実に反映する、浅い、またはもろい推論につながる可能性がある。

4.文脈毒

文脈毒は、誤った情報が文脈に入り込み、複数のターンにわたって繰り返し参照され、強化されることで発生する。

会話の初期に導入された1つの誤った発言が、その後の推論の基礎になることがある。対話が続くにつれて、モデルはこの欠陥のある仮定を基礎とし、誤りを複雑化し、正しい答えからさらに遠ざかる。

コンテキストの刈り込みとは何か、なぜ重要なのか

長いコンテクストを扱い始めると、物事をコントロールし続けるためには、1つ以上のトリックが必要であることにすぐに気づく。RAG、ツールのロードアウト、要約、特定のメッセージの隔離、古い履歴のオフロードなどだ。これらはすべて、さまざまな方法で役立っている。しかし、Context Pruningは、実際に何がモデルに供給されるかを直接決定するものである。

コンテキスト・プルーニングとは、簡単に言えば、モデルのコンテキスト・ウィンドウに入る前に、無関係な情報、価値の低い情報、矛盾する情報を自動的に取り除くプロセスのことだ。基本的には、現在のタスクにとって最も重要と思われるテキスト部分のみを保持するフィルターである。

他のストラテジーは、コンテキストを再編成したり、圧縮したり、ある部分を後回しにしたりする。プルーニングはより直接的である。"この情報の一部をプロンプトに入れるべきか "という問いに答えるものである。

これが、RAGシステムでプルーニングが特に重要になる理由である。ベクトル検索は素晴らしいが、完璧ではない。有用なもの、関連性の薄いもの、完全に的外れなものなど、候補の大きな福袋が返されることがよくある。それらをすべてプロンプトに放り込むと、先に説明したような失敗モードにぶつかることになる。プルーニングは検索とモデルの間に位置し、どのチャンクを残すかを決めるゲートキーパーの役割を果たす。

プルーニングがうまく機能すると、コンテキストがすっきりし、答えがより一貫し、トークンの使用量が減り、無関係なテキストが紛れ込むことによる奇妙な副作用が減るというメリットがすぐに現れます。検索セットアップを何も変えなくても、しっかりとしたプルーニングのステップを追加することで、システム全体のパフォーマンスを顕著に向上させることができる。

実際には、プルーニングはロングコンテキストやRAGパイプラインで最も活用度の高い最適化のひとつである。

Provence：実用的なコンテキスト・プルーニング・モデル

コンテキスト・プルーニングのアプローチを模索しているとき、私はNaver Labs Europeで開発された2つの魅力的なオープンソースモデルに出会った：Provenceとその多言語版であるXProvenceだ。

Provenceは、特に質問に答えることに焦点を当てた、検索補強された生成のための軽量なコンテキスト・プルーニング・モデルをトレーニングする方法である。ユーザーからの質問と検索された文章が与えられた場合、最終的な回答に寄与する情報のみを残し、無関係な文章を識別して削除する。

生成の前に価値の低いコンテンツを刈り込むことで、Provenceはモデルの入力のノイズを減らし、プロンプトを短くし、LLM推論の待ち時間を短縮します。また、プラグアンドプレイであるため、緊密な統合やアーキテクチャの変更を必要とせず、どのようなLLMや検索システムでも動作する。

Provenceは、実世界のRAGパイプラインにいくつかの実用的な機能を提供する。

1.ドキュメントレベルの理解

Provenceは、センテンスを単独でスコアリングするのではなく、ドキュメント全体について推論する。実世界の文書には、"it"、"this"、"the method above "といった参照が頻繁に含まれるため、これは重要である。単独では、これらの文章は曖昧であったり、無意味であったりする。文脈の中で見れば、それらの関連性が明らかになる。文書を全体的にモデル化することで、Provenceはより正確で首尾一貫した刈り込み決定を行う。

2.適応的な文の選択

Provenceは、検索された文書からどれだけのセンテンスを残すかを自動的に決定する。上位5文を残す」というような固定されたルールに頼るのではなく、クエリとコンテンツに適応する。

一つの文章で答えられる質問もあれば、複数の補足が必要な質問もある。Provenceはこの変化を動的に処理し、ドメイン間でうまく機能し、必要なときに調整できる関連性のしきい値を使用します。

3.統合リランキングによる高効率

Provenceは効率的に設計されている。コンパクトで軽量なモデルであるため、LLMベースの刈り込みアプローチよりも大幅に高速かつ安価に実行できる。

さらに重要なことは、Provenceはリランキングとコンテキストの刈り込みを1つのステップに統合できることである。リランキングはすでに最新のRAGパイプラインの標準的な段階であるため、この時点でプルーニングを統合することで、言語モデルに渡されるコンテキストの質を向上させながら、コンテキストのプルーニングの追加コストをゼロに近づけることができる。

4.XProvenceによる多言語サポート

ProvenceにはXProvenceという亜種もあり、同じアーキテクチャを使用するが、多言語データで学習される。これにより、中国語、英語、韓国語などの言語をまたいだクエリーやドキュメントの評価が可能となり、多言語やクロスリンガルのRAGシステムに適している。

Provenceの学習方法

Provenceはクロスエンコーダーアーキテクチャに基づいたクリーンで効果的な学習設計を採用している。学習中、クエリーと検索された各パッセージは1つの入力に連結され、一緒にエンコードされる。これにより、モデルは質問と文章両方の完全な文脈を一度に観察し、それらの関連性を直接推論することができる。

この結合エンコーディングにより、Provenceはきめ細かい関連性シグナルから学習することができる。このモデルは軽量エンコーダとしてDeBERTa上で微調整され、2つのタスクを同時に実行するように最適化されている：

1. 文書レベルの関連性スコアリング（再ランクスコア）：このモデルは文書全体の関連性スコアを予測し、クエリとの一致度を示す。例えば、スコア0.8は強い関連性を表す。

2. トークンレベルの関連性ラベリング（バイナリマスク）：並行して、モデルは各トークンにバイナリラベルを割り当て、クエリに関連（1 ）か無関係（0 ）かをマークする。

その結果、訓練されたモデルは文書全体の関連性を評価し、どの部分を残すべきか削除すべきかを特定することができる。

推論時に、Provenceは関連性ラベルをトークン単位で予測する。これらの予測は文レベルで集約され、関連性の高いトークンが関連性の低いトークンより多ければ文は保持され、そうでなければ削除される。このモデルは文レベルの監視で学習されるため、同じ文内のトークン予測は一貫している傾向があり、この集約戦略は実際に信頼できる。プルーニングの動作は、より保守的またはより積極的なプルーニングを達成するために、集約しきい値を調整することによって調整することもできる。

Provenceは、ほとんどのRAGパイプラインが既に含んでいるリランキングステップを再利用する。つまり、コンテキスト刈り込みは、ほとんどオーバーヘッドを追加することなく追加することができ、Provenceを実世界のRAGシステムにとって特に実用的なものにしている。

モデル間のコンテキスト刈り込み性能の評価

ここまで、Provenceの設計とトレーニングに焦点を当ててきた。次のステップは、Provenceが実際にどのように動作するかを評価することである。すなわち、Provenceがどの程度うまくコンテキストを刈り込んでいるか、他のアプローチと比較してどうか、実世界の条件下でどのように動作するか、である。

これらの質問に答えるために、我々は、現実的な評価設定において、複数のモデル間でコンテキスト刈り込みの品質を比較する一連の定量的実験を設計した。

実験では、次の2つの主要な目標に焦点を当てる：

• 刈り込みの有効性：Precision、Recall、F1スコアなどの標準的な測定基準を用いて、各モデルが関連性のない情報を除去しながら、関連性のあるコンテンツをどれだけ正確に保持しているかを測定する。

• ドメイン外汎化：各モデルが、学習データとは異なるデータ分布に対してどの程度のパフォーマンスを発揮するかを評価し、領域外のシナリオにおける頑健性を評価します。

比較モデル

• プロヴァンス

• XProvence

• OpenSearchセマンティックハイライター（セマンティックハイライティングタスクのために特別に設計された、BERTアーキテクチャに基づく刈り込みモデル）

データセット

WikiText-2を評価データセットとして使用する。WikiText-2はウィキペディアの記事から派生したもので、多様な文書構造を含み、関連する情報がしばしば複数の文にまたがり、意味的な関係が自明でない場合がある。

重要なことは、WikiText-2は、コンテキスト・プルーニング・モデルの学習に一般的に使用されるデータとは大きく異なるということである。このため、私たちの実験の主な焦点であるアウトオブドメインの評価に適しています。

クエリー生成とアノテーション

領域外刈り込みタスクを構築するために、GPT-4o-miniを用いて生のWikiText-2コーパスから質問と回答のペアを自動的に生成する。各評価サンプルは3つの要素から構成される：

• 質問：文書から生成された自然言語による質問。

• コンテキスト：変更されていない完全な文書。

• グランドトゥルース：どの文が答えを含み（保持され）、どれが無関係か（刈り込まれる）を示す文レベルの注釈。

クエリと完全な文書が与えられた場合、モデルは実際に重要な文を特定しなければならない。答えを含む文は関連文としてラベル付けされ、保持されるべきであり、それ以外の文は無関係として扱われ、刈り込まれるべきである。この定式化により、Precision、Recall、F1スコアを用いて、刈り込みの品質を定量的に測定することができる。

重要なことは、生成された質問はどの評価モデルのトレーニングデータにも現れないということである。その結果、性能は暗記ではなく真の汎化を反映する。実世界の使用パターンをよりよく反映するために、単純な事実に基づく質問、マルチホップ推論タスク、およびより複雑な分析プロンプトにまたがる、合計300のサンプルを生成します。

評価パイプライン

ハイパーパラメータの最適化：各モデルについて、事前に定義されたハイパーパラメータ空間上でグリッド探索を行い、F1スコアを最大化する構成を選択する。

結果と分析

結果は、3つのモデル間で明確な性能差があることを明らかにした。

Provenceは、F1スコア66.76%という最強の総合性能を達成した。Precision（69.53%）とRecall（64.19%）はバランスが取れており、領域外の汎化が強固であることを示している。最適な構成は0.6の刈り込み閾値とα=0.051を使用しており、モデルの関連性スコアがよく較正されていること、刈り込み動作が直感的で実際に調整しやすいことを示唆している。

XProvenceの F1スコアは58.97%で、高い再現率(75.52%)と低い精度(48.37%)が特徴である。これは、積極的にノイズを除去するよりも、潜在的に関連性のある情報を保持することを優先する、より保守的な刈り込み戦略を反映している。このような動作は、ヘルスケアや法的アプリケーションのような偽陰性がコストのかかる領域では望ましいが、偽陽性を増加させ、精度を低下させる。このトレードオフにもかかわらず、XProvenceの多言語機能は、非英語またはクロスリンガルな環境での強力な選択肢となる。

対照的に、OpenSearch Semantic Highlighterは 46.37%のF1スコア（Precision62.35%、Recall36.98%）と大幅にパフォーマンスが悪い。ProvenceとXProvenceとの相対的なギャップは、スコアのキャリブレーションとドメイン外での汎化の両方、特にドメイン外の条件下での限界を示しています。

セマンティックハイライト：テキストで実際に重要なことを見つけるもう一つの方法

さて、コンテキストの刈り込みについて話してきたが、パズルの関連する部分、つまりセマンティック・ハイライトを見てみる価値がある。技術的には、どちらの機能も、クエリとの関連性に基づいてテキストの断片をスコアリングするという、基本的な仕事はほとんど同じです。違いは、その結果がパイプラインでどのように使われるかである。

多くの人は「ハイライト」と聞いて、ElasticsearchやSolrで見かける古典的なキーワードハイライターを思い浮かべるだろう。これらのツールは基本的に、文字通りのキーワードのマッチを探し、<em> のようなもので包みます。これらは安価で予測可能ですが、クエリと全く同じ単語が使われている場合にのみ機能します。文書が言い換えたり、同義語を使ったり、異なる言い回しをしたりすると、従来の蛍光ペンは完全に見逃してしまいます。

セマンティック・ハイライトは別の方法をとります。文字列の完全一致をチェックする代わりに、クエリと異なるテキストスパンとの意味的類似性を推定するモデルを使用します。これにより、文言が全く異なっていても、関連するコンテンツをハイライトすることができる。RAGパイプライン、エージェントワークフロー、あるいはトークンよりも意味が重要なAI検索システムにとって、セマンティックハイライトは、文書が検索された理由をはるかに明確に把握することができる。

問題は、既存のセマンティックハイライティングソリューションのほとんどが、本番のAIワークロード用に構築されていないことだ。私たちは利用可能なものをすべてテストしましたが、どれも実際のRAGやエージェントシステムに必要なレベルの精度、待ち時間、多言語の信頼性を提供するものではありませんでした。そのため、私たちは、zilliz/semantic-highlight-bilingual-v1という独自のモデルをトレーニングし、オープンソース化することにしました。

高レベルでは、コンテキストの刈り込みとセマンティックハイライトは同じコアタスクを解決する。唯一の違いは、次に何が起こるかである。

• コンテキストの刈り込みは、生成前に無関係な部分を削除する。

• セマンティックハイライトはテキスト全体を保持しながら、重要な部分を視覚的に浮かび上がらせる。

基本的な操作は非常に似ているため、同じモデルで両方の機能を動かすことができる。そのため、スタック全体のコンポーネントの再利用が容易になり、RAGシステムは全体的にシンプルで効率的になります。

MilvusとZilliz Cloudのセマンティックハイライト機能

セマンティックハイライトは、Milvusと Zilliz Cloud（Milvusのフルマネージドサービス）で完全にサポートされ、RAGやAI主導の検索に携わる人にとってすでに有用であることが証明されています。ベクトル検索が大量のチャンクを返すとき、そのチャンク内のどの文章が実際に重要なのかを素早く把握するにはどうすればいいのか？

ハイライトがなければ、ユーザーは検索された理由を理解するためだけに文書全体を読むことになる。MilvusとZilliz Cloudは、セマンティックハイライト機能により、たとえ文言が異なっていても、クエリにセマンティックに関連する特定のスパンを自動的にマークします。キーワードの一致を探したり、チャンクが表示された理由を推測する必要はもうありません。

これにより、検索の透明性が格段に向上します。Milvusは単に「関連文書」を返すのではなく、関連性がどこにあるかを示す。RAGパイプラインにとって、これは特に有用である。なぜなら、モデルが何に注目すべきかが即座にわかるので、デバッグやプロンプトの作成がずっと簡単になるからだ。

このサポートをMilvusとZilliz Cloudに直接組み込んだので、使えるアトリビューションを得るために外部モデルを追加したり、別のサービスを実行したりする必要はありません。ベクトル検索→関連性スコアリング→ハイライトされたスパン。また、zilliz/semantic-highlight-bilingual-v1モデルで多言語ワークロードをサポートします。

今後の展望

コンテキスト・エンジニアリングはまだかなり新しく、解明すべきことがたくさん残っている。Milvusと Zilliz Cloudの内部でプルーニングとセマンティック・ハイライトがうまく機能しているとしても、物語の終わりには程遠い。物事を遅くすることなくプルーニング・モデルをより正確にすること、奇妙なクエリやドメイン外のクエリをよりうまく処理すること、検索→再ランク→プルーニング→ハイライトが、ハックの集合を接着剤でくっつけたようなものではなく、1つのクリーンなパイプラインのように感じられるように、すべてのピースを配線することなどです。

コンテキスト・ウィンドウが増え続けるにつれ、こうした判断の重要性は増すばかりだ。優れたコンテキスト管理は、もはや「素敵なおまけ」ではなく、ロングコンテキストやRAGシステムを確実に動作させるための核となる部分になりつつある。

私たちは、実験を続け、ベンチマークを行い、開発者にとって実際に違いをもたらすものを出荷していくつもりです。ゴールは単純明快で、乱雑なデータ、予測不可能なクエリー、大規模なワークロードの下でも壊れないシステムを簡単に構築できるようにすることです。

Milvusオフィスアワーでは、20分間の1対1のセッションを予約することができます。

他のビルダーとのチャットやメモ交換はいつでも大歓迎です。