context-optimization

コンテキストの最適化

コンテキストの最適化とは、AI モデル向けに組み立てられた未加工のコンテキストを調整し、すべてのトークンがタスクに有意義に寄与するようにするプロセスです。一般的な RAG やエージェントのパイプラインでは、取得したコンテキストに重複した文章、関連性がわずかなチャンク、順序が適切でない情報が含まれることがよくあります。最適化によって、未加工の素材を無駄がなく情報密度の高いコンテキストブロックに変換し、回答の品質を高め、推論コストを抑え、モデルの注意力の予算を最大限に活用します。

ワークフロー

1. 未加工のコンテキストを監査する: 収集したすべてのコンテキスト、つまり取得したドキュメント、会話履歴、ツールの出力、メタデータを一覧にします。合計トークン数を測定し、利用可能なコンテキスト予算と比較します。未加工のコンテキストが予算を超えている場合は、必要な圧縮率を特定します。

2. 重複するコンテンツを除去する: 同じ情報を伝える、ほぼ重複した文章がないかコンテキストを確認します。これは、オーバーラップを設定したチャンク分割によって同じ段落を含むチャンクが複数生成される場合や、複数のソースドキュメントで同じ事実が繰り返される場合など、RAG パイプラインでよく見られます。意味的類似度（コサイン距離 > 0.92）または完全一致の n グラムの重複検出を使って重複を特定し、各情報について最も完全なバージョンだけを残します。

3. 関連性と情報密度をスコア化する: 各コンテキストチャンクに、関連性スコア（現在のクエリとの関連度）と情報密度スコア（トークンあたりに伝える有用な事実の数）の 2 つのスコアを割り当てます。関連性は、取得スコアまたは軽量なクロスエンコーダーの処理で測定できます。密度は、チャンクの長さに対する固有表現、コード識別子、数値データ、重要な用語の数から推定できます。2 つのスコアを掛け合わせて、総合的な有用度スコアを算出します。

4. 価値の低いコンテンツを除外する: 総合的な有用度スコアがしきい値を下回るチャンクを削除します。まずは、有用度スコアの上位 60～70% のチャンクを残すとよいでしょう。また、情報にまったく寄与しない定型文（著作権表示、ナビゲーションメニュー、繰り返されるヘッダー）も削除します。慎重に進めてください。重要な事実を失うより、関連性がわずかにあるチャンクを含めるほうがよいでしょう。

5. 優先度順に並べ替える: モデルの注意力を最大限に活用できるよう、残ったチャンクを並べ替えます。有用度が最も高いチャンクを先頭に置き（モデルはコンテキストの冒頭に最も注意を向けます）、2 番目に高いチャンクを末尾近くに置きます（モデルは直近の情報にも注意を向けます）。長いコンテキストブロックの中ほどに重要な情報を埋もれさせないでください。モデルの注意力が最も弱くなるこの領域は、「中間部での見落とし」が起きやすい範囲です。

6. 網羅性を検証する: フィルタリングと並べ替えの後、最適化されたコンテキストがクエリのあらゆる側面を引き続き網羅していることを確認します。クエリに複数の質問が含まれる場合は、それぞれに対応するチャンクが少なくとも 1 つあることを確かめます。網羅性に不足がある場合は、有用度スコアがしきい値を下回っていても、不足を補うフィルタリング済みのチャンクを選んで再度追加します。

手法

• 重複除去：意味的類似度のしきい値や n-gram の重複検出を用いて、冗長な箇所を特定して取り除きます。重複するチャンクで同じ文が繰り返されることの多い RAG パイプラインでは特に重要です。最も完全なバージョン、またはスコアが最も高いバージョンを残します。
• 関連性フィルタリング：関連性のしきい値を下回るチャンクを取り除きます。シグナルとして、元の検索スコア、リランカーのスコア、またはクエリとのキーワードの重複を使用します。フィルタリングの強さは調整する必要があります。厳しくしすぎると、情報の欠落が生じます。
• 情報密度のスコアリング：チャンクにトークンあたりどれだけ有用な情報が含まれているかを推定します。情報密度の高いチャンク（事実、コード、データが詰まったもの）は、冗長で情報密度の低い文章より優先されます。関連性スコアが近いチャンクのどちらを残すか判断する際に役立ちます。
• 優先度に基づく並べ替え：「中間部で見失う」効果を避けるため、モデルが最も重要な情報を最初と最後に見るようにチャンクを並べます。注意力の低下がより顕著になる、コンテキストウィンドウの長いケース（32K 以上のトークン）で特に効果があります。
• コンテキストウィンドウの戦略：モデルのコンテキストウィンドウの大きさに応じて、異なる最適化アプローチが必要です。小さいウィンドウ（4K トークン）では、積極的なフィルタリングと圧縮が不可欠です。中程度のウィンドウ（32K）では、重複除去と並べ替えを重視します。大きいウィンドウ（128K 以上）では、より多くの情報を収められる一方で、中間部で見失う効果が増幅されるため、並べ替えと情報密度のスコアリングが最も重要です。

使い方

生のコンテキスト（任意のメタデータやスコアを含むテキストチャンクのリスト）、ユーザークエリ、目標とするトークン予算を指定します。このスキルは、重複除去、フィルタリング、スコアリング、並べ替えを行った最適化済みコンテキストブロックを返します。これはプロンプトの組み立てにすぐ使用できます。重要な情報がフィルタリングで除外されないよう、コンテキストで扱う必要のある主要なトピックのカバレッジチェックリストを任意で指定できます。

例

例 1：複数ファイルにまたがるコード編集タスク向けのコンテキスト最適化

タスク：「認証モジュールをリファクタリングし、コールバックの代わりに async/await を使用します。」

生のコンテキスト（7 チャンク、約 4,200 トークン）：

#	ソース	関連性	密度	内容の概要
1	src/auth/login.js:1-45	0.93	高	コールバックベースの db.findUser() を使用するログイン関数
2	src/auth/login.js:20-55	0.90	高	重複するチャンク。チャンク 1 の 20～45 行と重複し、トークンの更新ロジックを追加
3	src/auth/middleware.js:1-30	0.88	高	コールバックベースのトークン検証を行う認証ミドルウェア
4	README.md:100-130	0.45	低	プロジェクトのセットアップ手順。コードや認証の詳細はなし
5	src/auth/register.js:1-40	0.82	高	コールバックを使用する登録関数
6	package.json:1-25	0.35	低	依存関係の一覧。認証関連のロジックはなし
7	src/auth/login.js:40-70	0.91	高	コールバックを使ったトークン生成とセッション作成

最適化の手順：

1. 重複除去： チャンク 1 と 2 は 20～45 行が重複しています。統合して、login.js の 1～55 行を含む単一のチャンクにします。
2. フィルタリング： チャンク 4（README のセットアップ手順、関連性 0.45）とチャンク 6（package.json、関連性 0.35）を取り除きます。どちらもしきい値の 0.50 を下回っています。
3. 並べ替え： 統合した login.js のチャンクを最初に配置し（関連性が最も高いため）、続いてトークン生成のチャンク、middleware.js、register.js の順に並べます。

最適化済みコンテキスト（約 2,800 トークン、33% 削減）：

1. src/auth/login.js:1-55（統合）-- コールバックベースの DB 検索とトークン更新を行うログイン関数
2. src/auth/login.js:40-70 -- トークン生成とセッション作成
3. src/auth/middleware.js:1-30 -- コールバックによるトークン検証を行う認証ミドルウェア
4. src/auth/register.js:1-40 -- コールバックを使用する登録関数

例 2：冗長性を排除するための RAG 取得コンテキストの最適化

クエリ：「当社の電子機器の返品ポリシーを教えてください。」

取得した未加工のチャンク（6 チャンク、約 3,000 トークン）：

1. returns-policy.md（スコア 0.95） -- 「当店で購入した電子機器は、購入から 30 日以内であれば返品できます。商品はすべての付属品とともに、元の梱包に入っている必要があります。開封済みの商品には 15% の再入荷手数料がかかります。」
2. faq.md（スコア 0.88） -- 「Q：電子機器を返品できますか？ A：はい、30 日以内であれば可能です。商品は元の梱包に入っている必要があります。開封済みの商品には 15% の再入荷手数料がかかります。詳しくは返品ポリシーをご覧ください。」
3. holiday-policy.md（スコア 0.72） -- 「ホリデーシーズン（11 月 15 日～1 月 15 日）は、電子機器を含むすべての商品の返品期間が 60 日に延長されます。その他の条件はすべて適用されます。」
4. shipping-info.md（スコア 0.40） -- 「電子機器は保険付きの陸上輸送で発送します。配送には 3～7 営業日かかります。」
5. returns-policy.md（スコア 0.85） -- 「返金は 5～10 営業日以内に、元の支払い方法に対して処理されます。不良品には再入荷手数料は適用されず、90 日以内であれば返品できます。」
6. store-locator.md（スコア 0.30） -- 「全国 200 か所の店舗のいずれかにお越しください。」

最適化の手順：

1. 重複を排除： チャンク 1 と 2 はほぼ同じ情報（30 日間の返品期間、元の梱包、15% の手数料）を伝えています。チャンク 1（スコアが高く、より権威のある情報源）を残します。
2. フィルタリング： チャンク 4（配送情報で、返品とは無関係。スコア 0.40）とチャンク 6（店舗検索で、無関係。スコア 0.30）を削除します。
3. 並べ替え： チャンク 1（基本ポリシー）、次にチャンク 5（返金処理）、最後にチャンク 3（ホリデーシーズンの延長）の順にします。

最適化後のコンテキスト（約 900 トークン、70% 削減）：

1. 基本ポリシー：返品期間は 30 日間。元の梱包が必要。開封済みの商品には 15% の再入荷手数料がかかります。
2. 返金の詳細：5～10 営業日以内に元の支払い方法に対して処理されます。不良品には再入荷手数料は適用されず、返品期間は 90 日間です。
3. ホリデーシーズンの延長：11 月 15 日～1 月 15 日は、返品期間が 60 日に延長されます。

ベストプラクティス

• フィルタリングの前に重複を排除する -- まず重複する文章を削除すると、利用可能な固有の情報が明確になり、より適切なフィルタリング判断につながります。
• しきい値を対象ドメインに合わせて調整する -- 関連性と密度のスコアのしきい値は、ユースケースによって異なります。コード生成タスクでは、一般的な Q&A タスクよりも厳格な関連性フィルタリングが必要になる場合があります。ラベル付きの評価セットを使って調整してください。
• 情報源の多様性を保つ -- 複数のチャンクのスコアが同程度の場合は、異なるソースドキュメントのチャンクを残すことを優先し、網羅性を高め、単一の情報源への偏りを抑えてください。
• 「中間部が失われる」効果を考慮する -- コンテキストウィンドウが 8K トークンを超える場合は、最も重要なチャンクをコンテキストブロックの先頭と末尾に配置してください。この効果はアーキテクチャによって異なるため、使用するモデルでテストしてください。
• フィルタリングの内容を記録する -- 削除したチャンクとその理由を記録してください。必要なチャンクがフィルタリングで除外されたためにモデルが不完全な回答をした場合のデバッグに役立ちます。
• クエリが変わったら再最適化する -- あるクエリに最適なコンテキストが、後続のクエリにも最適とは限りません。複数ターンの会話では、ユーザーの意図が変化したときに最適化を再実行してください。

エッジケース

• すべてのチャンクの関連性が非常に高い場合：すべてのチャンクがしきい値を上回る場合は、フィルタリングを省略し、重複排除と並べ替えに重点を置きます。任意の削減目標に達するためだけに、適切なコンテンツを無理に削除しないでください。
• クエリが複数の異なるトピックを扱う場合：「返品ポリシーと保証条件を比較する」のような複雑なクエリでは、両方のトピックを扱うコンテキストが必要です。カバレッジ検証の手順で両方を確認し、一方のトピックに関するすべてのチャンクがフィルタリングされないようにしてください。
• コンテキストウィンドウが非常に小さい場合（4K トークン）：予算に余裕がない場合は、最適化後も積極的な圧縮が必要になることがあります。まず最適化で無駄を取り除き、それでも予算を超える場合は残りを圧縮してください。
• ソースデータが急速に変化する場合：ドキュメントが頻繁に更新されるライブシステムでは、キャッシュされた最適化結果が古くなることがあります。ソースドキュメントが変更されたら、キャッシュを無効化して再最適化してください。
• コンテキストに複数のコンテンツタイプが混在する場合：コンテキストに散文、コード、テーブル、JSON が含まれる場合は、タイプごとの密度スコアリングを適用してください。通常、コードの 10 行のスニペットは散文の 10 行の段落より密度が高くなります。