Retrieval-Augmented Context（コンテキスト検索拡張）（リトリーバルオーグメンテッドコンテキスト）
ロングコンテキストウィンドウの性能評価・活用において、入力コンテキストから特定情報を正確に検索・抽出する技術群。Needle in a Haystack（NIAH）テストで検索精度を評価し、LLMLinguaやAutoCompressorなどのコンテキスト圧縮技術で効率化を図る。RAGとの統合設計パターンも含む。
Retrieval-Augmented Contextとは
Retrieval-Augmented Context（RAC）は、LLMのロングコンテキストウィンドウ内に投入された大量のテキストから、クエリに関連する情報を正確に検索・抽出するための技術体系である。単にコンテキストを長くするだけでは「情報は入っているが見つけられない」という問題が発生するため、コンテキスト内検索の精度向上とコンテキスト圧縮の2つのアプローチが研究されている。
従来のRAG（Retrieval-Augmented Generation）が外部データベースからの検索を前提とするのに対し、RACは「既にコンテキスト内にある情報」の活用を最大化する技術である。2024年以降、ロングコンテキストモデルの普及に伴い、両者を組み合わせたハイブリッドアーキテクチャが主流となっている。
コンテキスト内検索の課題
Lost in the Middle 問題
2023年のStanford大学の研究（Liu et al.）により、LLMはコンテキスト内の情報位置によって検索精度が大きく変動することが判明した。
| 情報の位置 | 検索精度（GPT-3.5） | 検索精度（Claude 2） | 検索精度（GPT-4 Turbo） |
|---|---|---|---|
| 先頭（Top 10%） | 85-95% | 90-97% | 92-98% |
| 中間（40-60%） | 40-60% | 55-70% | 70-85% |
| 末尾（Bottom 10%） | 80-90% | 85-95% | 90-96% |
この「U字型カーブ」はモデルの世代が進むにつれて緩和されているが、2025年時点でも完全には解消されていない。Claude 3.5/4やGemini 2.5 Proなど最新モデルでは大幅に改善されているが、128K以上の超長文では依然として中間部分の精度低下が観察される。
情報密度と検索精度
コンテキスト内の関連情報の密度（signal-to-noise ratio）も検索精度に影響する。
- 高密度: 関連情報がコンテキストの10%以上を占める → 精度90%以上
- 中密度: 関連情報が1-10% → 精度70-90%
- 低密度: 関連情報が0.1%未満（Needle in a Haystack） → 精度50-95%（モデル依存）
Needle in a Haystack（NIAH）テスト
NIAHテストは、ロングコンテキストモデルの検索精度を評価する標準的なベンチマークである。大量の無関係なテキスト（haystack）の中に特定の事実（needle）を埋め込み、モデルがそれを正確に検索・回答できるかを測定する。
テスト設計
- 「ハンバーガーの最も美味しい隠し味はピーナッツバターである」などの固有の事実を用意
- Paul Grahamのエッセイなど無関係な長文テキストの任意の位置に挿入
- 「ハンバーガーの隠し味は何ですか？」と質問
- コンテキスト長×挿入位置のマトリクスで精度をヒートマップ化
主要モデルのNIAH結果（2025年時点）
| モデル | コンテキスト長 | NIAH精度（全位置平均） | 最弱位置 |
|---|---|---|---|
| Claude 3.5 Sonnet | 200K | 99.2% | 中間120K付近 |
| Claude 4 Opus | 200K | 99.7% | ほぼ均一 |
| GPT-4 Turbo | 128K | 97.8% | 中間60-80K |
| Gemini 1.5 Pro | 1M | 99.5% | 500K以降でやや低下 |
| Gemini 2.5 Pro | 1M | 99.3% | ほぼ均一 |
| LLaMA 3.1 70B | 128K | 95.5% | 中間40-80K |
| Mistral Large 2 | 128K | 96.2% | 中間50-70K |
コンテキスト圧縮技術
LLMLingua / LongLLMLingua
Microsoft Researchが開発したコンテキスト圧縮フレームワーク。小型のLLM（GPT-2レベル）を使って入力テキストのperplexityを計算し、冗長なトークンを除去する。
- LLMLingua: 2-20倍の圧縮率でコンテキストを削減。85%以上の情報保持率
- LongLLMLingua: ロングコンテキスト向けに最適化。クエリ条件付きの圧縮で検索関連トークンを優先保持
- LLMLingua-2: Transformerベースのトークン分類器で高速圧縮。GPT-4で5倍圧縮時に93%の性能保持
AutoCompressor
トークン列を「要約ベクトル」に圧縮し、コンテキスト内に展開する手法。長い文書を段階的に要約ベクトルに変換し、有限のコンテキスト枠内により多くの情報を収容する。
ICAE（In-Context Autoencoder）
入力コンテキストをオートエンコーダで圧縮し、少数のメモリトークンとして保存する手法。コンテキスト長を4〜10倍に実効拡張できる。
ハイブリッドRAG + ロングコンテキスト設計
2025年時点の推奨アーキテクチャパターン：
- ベースコンテキスト層: システムプロンプト、固定的な参照文書、few-shot例をロングコンテキストで直接投入（〜50Kトークン）
- 動的検索層: ユーザークエリに応じてベクトルDBから関連チャンクを検索し、コンテキストに追加（〜20Kトークン）
- コンテキスト圧縮層: LLMLinguaで全体を圧縮し、最終的なコンテキストを最適化
この3層構成により、「固定知識はロングコンテキスト、動的知識はRAG」という分業が実現する。
よくある質問（FAQ）
Q1: ロングコンテキストがあればRAGは不要になりますか？ A: 不要にはならない。ロングコンテキストには物理的な上限があり（最大でも数百万トークン）、数百万〜数億件の文書を扱うユースケースではRAGが必須。また、リアルタイム更新データ（株価、ニュース）はRAG経由でないと取得できない。2025年の最適解はロングコンテキスト＋RAGのハイブリッド構成。
Q2: コンテキスト圧縮の品質劣化はどの程度ですか？ A: LLMLingua-2で5倍圧縮時、GPT-4の各種ベンチマークで93%の性能保持が報告されている。10倍圧縮では80-85%程度に低下する。圧縮率は用途に応じて調整し、要約・分類タスクでは高圧縮率、事実検索タスクでは低圧縮率が推奨される。
Q3: Needle in a Haystackテストで100%にならないのはなぜですか？ A: 主に3つの要因がある。(1) 位置依存の精度変動（Lost in the Middle）、(2) needleの表現と質問の表現の乖離（言い換えや間接的な参照）、(3) コンテキスト内の類似情報によるdistractioneffect。最新モデル（Claude 4 Opus、Gemini 2.5 Pro）では99%以上を達成しているが、完全な100%は理論的に困難。
まとめ
- ロングコンテキスト内の情報検索精度は「Lost in the Middle」問題の影響を受ける
- NIAHテストが検索精度評価の標準ベンチマーク
- LLMLingua、AutoCompressor、ICAEなどのコンテキスト圧縮で実効コンテキスト長を拡張
- ロングコンテキスト＋RAGのハイブリッド構成が2025年の推奨アーキテクチャ
- 最新モデル（Claude 4 Opus、Gemini 2.5 Pro）はNIAH 99%以上を達成