4.3 コンテキストの整形とLLMへの統合
RAG（Retrieval-Augmented Generation）の構成において、Retrieverは関連する文書や情報チャンクを取得する役割を担います。しかし、それらをどのように生成モデル（LLM）へ渡すかは、RAG全体の回答品質を大きく左右する重要な設計ポイントです。
ただ単に複数の文書を連結してプロンプトに詰め込むだけでは、適切な文脈の理解や、正確な回答生成が期待できません。
このセクションでは、Retrieverの出力をいかにして「整形（Context Formatting）」し、LLMにとってわかりやすく、かつトークン制限を超えない形で渡すかという統合設計のベストプラクティスを紹介します。
なぜ「整形」が必要なのか？
Retrieverによって取得された文書は、通常は複数の非構造なチャンクです。
例：
「第5条 本サービスの解約には、...」
「なお、契約満了後に更新手続きを行わない場合、...」
「キャンペーン期間中に限り、...」
これらをそのままLLMに与えても、モデル側が**「どれをどう使えばよいか」**を判断できず、以下のような問題が起こります。
重要な情報が埋もれて使われない
不正確または曖昧な内容が混在して、回答がぶれる
プロンプト内の情報量が多すぎて、トークン制限を超過する
したがって、「どの情報を、どの順で、どのような文脈で提示するか」を設計することが極めて重要になります。
基本的な整形フロー
以下は典型的なコンテキスト整形の流れです：
チャンクのスコア付けと並び替え
類似度やヒット率の高い順に並び替える。場合によっては重要語やメタ情報を加味して再評価。チャンクの選定（トークン最適化）
トークン上限（例：4096 / 8192 / 32kなど）を意識して、必要な文書のみを選択。整形テンプレートへの組み込み
プレーンに連結するのではなく、構造的なフォーマットに整えてLLMに渡す。
よく使われる整形テンプレートの例
パターン①：文書付き質問テンプレート
この形式は、LLMに対して「使うべき情報はこれです」と明示的に指示し、文脈の境界をはっきりさせることで、誤解や幻覚（hallucination）を減らす効果があります。
パターン②：ナレッジリスト＋質問テンプレート
この形式は、要点ベースで構造化された情報を与えることで、簡潔な応答を引き出しやすくなります。
注意すべき点：トークンと構造のバランス
LLMは、与えられたプロンプトを一文の流れとして読み取る傾向があるため、整形時には以下の点に注意が必要です。
同種の情報は近接させる（話題の散乱を防ぐ）
重要な情報を先に配置する（冒頭が最も注目されやすい）
出典や文書タイトルを明記する（出所を明示し信頼性を高める）
文書の間には明確な区切りを設ける（コンテキスト境界を誤解させない）
また、あまりに多くのチャンクを無造作に詰め込むと、かえって重要な文脈が埋もれてしまいます。むしろ、適切に取捨選択し、よく整形された少数の情報を渡す方が、出力の品質は高まります。
補足：プロンプトエンジニアリングの役割
この整形プロセス全体は、「プロンプトエンジニアリング」の一環と捉えることができます。
具体的には、
質問形式の統一（例：「〜について教えてください」）
モデルへの指示文の設計（例：「以下の文書にのみ基づいて答えてください」）
出力形式の誘導（例：「箇条書きで答えてください」）
などが含まれ、単なるテキスト加工ではなく、生成品質を保証するための設計行為です。
検索技術の再整理と融合
このセクションでは、Retrieverの出力をLLMに統合する際に重要となる「コンテキスト整形」の実践的設計について解説しました。
次のセクション「4.4 セマンティック検索とキーワード検索の違いとは？RAGの精度を左右する検索技術」では、検索という行為を「キーワードベース」から「意味ベース」へと進化させたセマンティック検索と従来検索の違いに着目し、RAGにおける検索技術の意義を再確認します。
| 整形ポイント | 具体的な工夫 | 得られる効果 |
|---|---|---|
| 並び順 | 重要チャンクを冒頭に配置 | 先頭ほど注目され、回答に反映されやすい |
| 区切り | 【文書1】【文書2】など明確な境界を挿入 | 文脈の混同・幻覚を防ぐ |
| 出典 | 文書タイトルやURLを併記 | 信頼性と検証可能性を担保 |
| 取捨選択 | 類似度上位のみを厳選 | トークン節約と精度の両立 |
| 指示文 | 「以下の文書にのみ基づき回答」を明示 | 外部知識の混入を抑制 |
