Hello there, ('ω')ノ
～LLMに「参考情報」をどう渡すかが回答の質を決める～
RAG（Retrieval-Augmented Generation）では、 ユーザーの質問に対して、まず情報を検索し、それを元にAIが文章を作ります。
ここで重要になるのが──
「検索した情報をどうLLMに渡すか？」
この統合のやり方次第で、文章の精度・一貫性・正確性が大きく変わります。
🧱 統合の基本パターンは2つ
✅ 1. 単純連結（Simple Concatenation）
取得した情報をそのまま1つのプロンプトに貼り付ける方法。
[質問] 「在宅勤務の交通費ルールは？」 [検索結果] ・文書A：2023年改訂の交通費ルール ・文書B：リモートワーク時の例外条件 → [プロンプト] 質問＋文書A＋文書B → LLMに送信
- 利点：実装が簡単、即席で使える
- 課題：情報が多すぎると文脈が薄れる／長すぎてトークン制限に引っかかる
✅ 2. 要約・整形して渡す（Pre-processing or Rewriting）
検索結果をそのままではなく、整形・要約・分類してからLLMに渡す方法。
パターン例：
- 検索文書を簡潔にまとめてから渡す
- それぞれの文書の出典をラベル付けして提示
- LLMに「どの情報に基づいて回答すべきか」を明示する
文書A（2023年版） →「在宅勤務の交通費は、月1回を上限に精算可能」 文書B（2022年版） →「原則として、リモート勤務者は交通費支給対象外」 → LLMに渡すプロンプト： 「最新ルール（2023年）を優先して、交通費について回答してください」
➡ これにより、LLMがどの情報を重視すべきか判断しやすくなります。
🔍 よく使われる統合技術と設計パターン
| 名称 | 概要 | 適したケース |
|---|---|---|
| Context Stuffing | 検索結果をそのまま詰め込む | 情報が少量かつ短文で十分な場合 |
| Context Selection | 複数の検索結果から重要なものを選ぶ | 文書が多すぎるときのフィルター処理 |
| Reranking | LLMで再評価し、順位を並べ直す | 精度重視の場面で、ベストな情報を選びたいとき |
| Chunk Fusion | 各文書を分割して、複数情報を“融合”して提示 | 一部ずつ異なる視点を統合したいとき |
| Map-Reduce型要約 | 複数文書を一度ずつ要約し、さらに総まとめする | 数十件以上の情報がある大規模RAG |
🧠 実際のプロンプト構造（例）
[System Prompt] あなたは社内ルールに精通したヘルプデスクAIです。 [User Prompt] 社員から次の質問が来ています： 「在宅勤務中にオフィスに来た場合、交通費は出ますか？」 [Context] 文書①：2023年ガイドラインより 「在宅勤務日でも、出社が業務命令である場合は交通費支給対象」 文書②：過去の申請事例より 「週1日程度の出社は支給されていた」 → これらの情報を参考に、社員にわかりやすく説明してください。
➡ 「質問・文脈・指示」の3層構造で統合するのが基本スタイルです。
💼 業務での応用ポイント
| 項目 | ヒント |
|---|---|
| 精度を上げたい | 「出典を明示」＋「情報を整理」して渡す |
| 嘘を減らしたい | 検索結果に含まれていない内容を出さないよう指示する |
| 一貫性を持たせたい | 時代や部署ごとのルール差異を「優先順位」で指定 |
| 文書数が多い | 一次要約→統合要約のステップを踏む（Map-Reduce） |
✅ まとめ：検索と生成は“別々”ではなく“協調”がカギ
- 検索した情報をどの順番・形式・優先度でLLMに渡すかが重要
- 単純な「貼り付け」ではなく、「意味を整理して渡す設計」が精度を高める
- 特に業務でのAI活用では、誤解を防ぐための文脈整理・明示的なプロンプト設計が成功のカギ
Best regards, (^^ゞ
