RAGプロンプト最適化とContext Window管理：LLM性能向上への実践的アプローチ

Tech

LLM", "secondary_categories": ["プロンプトエンジニアリング", "RAG"], "tags": ["RAG", "プロンプト最適化", "Context Window", "Gemini", "評価", "LLM"], "summary": "RAGシステムにおけるLLMのContext Windowを最適化し、正確な回答を生成するためのプロンプト設計、評価、改良の具体的手法を解説。", "mermaid": true, "verify_level": "L0", "tweet_hint": {"text":"RAGプロンプト最適化とContext Window管理は、LLMの性能を最大化する鍵です。本記事では、プロンプト設計から評価、失敗モード分析、改良までを網羅した実践的なアプローチを解説しています。 #プロンプトエンジニアリング ","hashtags":["#RAG","#プロンプトエンジニアリング","#LLM"]}, "link_hints": [ "https://arxiv.org/abs/2405.02517", "https://arxiv.org/abs/2405.08985", "https://blog.google/technology/ai/gemini-1-5-flash-announcement/", "https://cloud.google.com/blog/products/ai-ml/gemini-1-5-pro-generally-available-new-capabilities-for-developers" ] } --> 本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

RAGプロンプト最適化とContext Window管理：LLM性能向上への実践的アプローチ

Retrieval-Augmented Generation（RAG）システムにおけるLLMの性能は、与えるプロンプトの質と、それに含まれるコンテキスト情報の管理に大きく依存します。特に、大規模言語モデル（LLM）のContext Window（コンテキストウィンドウ）が拡大する中で、この大容量をいかに効率的かつ効果的に利用するかが重要となっています。本記事では、RAGにおけるプロンプトの最適化とContext Window管理に焦点を当て、実践的な設計、評価、改良のサイクルを詳述します。

ユースケース定義

本稿では、企業内の長大なドキュメント群（例：技術仕様書、社内規定、Q&Aデータベース、過去のレポートなど）から、ユーザーの自然言語クエリに対して正確かつ簡潔な回答を生成するRAGシステムを主要なユースケースとします。このシステムは、特に以下の課題に対処することを目的とします。

  • Context Windowの制約: 取得した関連情報がLLMのContext Windowサイズを超える場合、または長大なContext Window内で重要な情報が「Lost in the Middle」となる問題 [1]。

  • 関連性の低い情報の混入: RAGの検索フェーズで、クエリに直接関係のない情報がコンテキストに紛れ込むことによる幻覚（Hallucination）や回答精度の低下。

  • 幻覚の抑制: LLMが提供された情報以外の内容を生成することを防ぎ、情報の信頼性を確保する。

制約付き仕様化

RAGシステムにおけるLLMプロンプトの入出力、性能要件、および失敗時の挙動を明確に定義します。

入出力契約

  • 入力フォーマット:

    • ユーザーからの質問 (query: string)

    • RAG検索によって取得された関連ドキュメントのリスト (documents: array of objects)。各ドキュメントは一意のID (id: string) と内容 (content: string) を持つ。

      {
  "query": "Gemini 1.5 ProのContext Windowサイズはいくつですか？",
  "documents": [
    {"id": "doc_001", "content": "Gemini 1.5 Proは最大100万トークン（1Mトークン）のContext Windowを提供します。これは従来のモデルと比較して大幅な拡張です。Google Cloud Blogは2024年5月14日にこの機能が一般提供されたと発表しました。"},
    {"id": "doc_002", "content": "Gemini 1.5 Flashは効率性と高速性に重点を置いたモデルで、特定のユースケースに最適化されています。"}
  ]
}

  • 出力フォーマット:

    • 質問に対する回答本文 (answer: string)

    • 回答に利用したドキュメントのIDリスト (sources: array of strings)

    • 処理ステータス (status: “success”, “no_info”, “format_error”)

      {
  "answer": "Gemini 1.5 ProのContext Windowサイズは最大100万トークン（1Mトークン）です。",
  "sources": ["doc_001"],
  "status": "success"
}

  • 失敗時の挙動:

    • 関連情報が見つからない場合: statusは"no_info"とし、answerは「関連情報が見つかりませんでした。」という固定メッセージを返す。sourcesは空の配列。

    • 出力フォーマット違反: statusは"format_error"とし、answerはエラーの詳細を示すメッセージを返す。

  • 禁止事項:

    • 提供された関連ドキュメントにない情報を生成すること（幻覚）。

    • 個人情報や機密情報を開示すること。

    • 差別的または不適切なコンテンツを生成すること。

    • モデルの内部動作やプロンプト指示そのものを開示すること。

性能要件

  • 正確性: ゴールデンアンサーとの比較において、主要な情報抽出のF1スコアが90%以上。

  • 簡潔性: 回答は質問に対し、冗長でなく、要点を押さえたものであること。

  • 応答時間: 平均応答時間は5秒以内。95パーセンタイルで8秒以内。

  • Context Window利用効率: 投入された関連ドキュメントのうち、回答に貢献した情報の割合が70%以上（特に長大なContext Windowにおいて）。

RAGにおけるContext Window管理の重要性

LLMのContext Windowは、モデルが一度に処理できる情報の量を示します。GoogleのGemini 1.5 Proは、最大100万トークン（1Mトークン）という驚異的なContext Windowを提供しており [3][4]、これにより膨大な情報を一度に処理できる可能性が広がりました。しかし、単に多くの情報をContext Windowに詰め込むだけでは、必ずしも性能が向上するわけではありません。

  • 「Lost in the Middle」問題: 長いコンテキストでは、LLMが関連性の高い情報をコンテキストの中間部分で見落とし、回答の質が低下することが報告されています [1]。

  • 関連性の最適化: プロンプトに含める情報の量と質を最適化することが不可欠です。関連性の低い情報が多いと、モデルの推論を妨げ、幻覚や誤った結論につながる可能性があります [2]。

効果的なContext Window管理は、プロンプト設計、チャンキング戦略、関連性フィルタリングなど、多岐にわたるアプローチを必要とします。

プロンプト設計

以下に、RAGにおける異なるアプローチのプロンプト案を3種提示します。System instructionsは共通の前提として機能します。

共通のSystem Instructions

あなたはユーザーの質問に対し、提供された情報のみに基づいて回答を生成するAIアシスタントです。

- 回答は日本語で、簡潔かつ正確に要点をまとめてください。

- 提供された情報に回答が存在しない場合、決して推測せず「関連情報が見つかりませんでした。」と回答してください。

- 出力はJSONフォーマットで、以下のキーを含めてください: "answer" (string), "sources" (array of strings), "status" (string)。

- 回答に利用した情報源の`id`を`sources`リストに含めてください。

- 決して個人的な意見や感想を述べたり、提供された情報以外の知識を使用したりしないでください。

プロンプト案1：ゼロショット (Zero-shot)

最もシンプルな形式で、基本的な指示とRAGで取得した情報をそのまま渡します。モデルは事前の例なしにタスクを遂行します。

<<SYSTEM_INSTRUCTIONS>>

以下の関連ドキュメントから情報を抽出し、ユーザーの質問に回答してください。

--- 関連ドキュメント ---
{{#each documents}}
ID: {{this.id}}
内容: {{this.content}}
---
{{/each}}

--- ユーザーの質問 ---
{{query}}

--- 回答 ---

プロンプト案2：少数例 (Few-shot)

具体的な入出力例を提供することで、モデルが期待される回答フォーマットやトーンをより明確に理解できるように促します。特に、複雑な構造の回答や特定の参照形式を求める場合に有効です。

<<SYSTEM_INSTRUCTIONS>>

以下に、質問と関連ドキュメント、そしてそれに対する模範的な回答例を示します。この例を参考に、あなたの質問に回答してください。

--- 例1 ---
関連ドキュメント:
ID: doc_ex1
内容: 弊社製品Xは2023年4月1日にリリースされました。主な特徴は高精度AIと省電力モードです。
ID: doc_ex2
内容: 製品Xの保守契約は購入から1年間無償で提供されます。
ユーザーの質問: 弊社製品Xのリリース日と主な特徴は何ですか？
回答:
```json
{
  "answer": "弊社製品Xは2023年4月1日にリリースされ、高精度AIと省電力モードが主な特徴です。",
  "sources": ["doc_ex1"],
  "status": "success"
}

— 関連ドキュメント — {{#each documents}} ID: {{this.id}}

内容: {{this.content}}

{{/each}}

— ユーザーの質問 — {{query}}

— 回答 —

### プロンプト案3：Chain-of-Thought (CoT)制約型

モデルに思考プロセスを段階的に踏ませることで、推論の透明性を高め、複雑な質問に対する正確性を向上させます。ここでは、回答生成前に重要な情報を特定するステップを指示しています。

```text
<<SYSTEM_INSTRUCTIONS>>

以下の関連ドキュメントとユーザーの質問に基づき、以下の思考ステップで回答を生成してください。

--- 思考ステップ ---

1. 関連ドキュメントの中から、ユーザーの質問に直接関連するキーワードや文を特定し、抽出する。

2. 抽出した情報のみを用いて、質問に対する簡潔かつ正確な回答を作成する。

3. 回答に使用したドキュメントのIDを特定する。

4. 定義されたJSONフォーマットで出力する。

--- 関連ドキュメント ---
{{#each documents}}
ID: {{this.id}}
内容: {{this.content}}
---
{{/each}}

--- ユーザーの質問 ---
{{query}}

--- 回答 ---

評価

プロンプト設計後の重要なステップは、その有効性を評価することです。様々なシナリオと自動評価手法を組み合わせることで、プロンプトの強みと弱みを特定します。

評価シナリオ

  • 正例 (Positive Case):

    • 明確な回答: 質問に対して、関連ドキュメント内に直接的かつ明確な回答が1箇所に存在するケース。

    • 複数ドキュメントからの統合: 回答に必要な情報が複数の関連ドキュメントに分散しており、それらを統合して回答を生成する必要があるケース。

  • 難例 (Challenging Case):

    • 曖昧な質問: 質問自体が曖昧で、複数の解釈が可能な場合。

    • 否定形クエリ: 「Xではないもの」といった、否定形の情報を抽出する必要がある場合。

    • 矛盾する情報: 複数のドキュメント間で情報が矛盾している場合（RAGシステム自体が検出・対処すべき課題）。

  • コーナーケース (Corner Case):

    • 関連情報なし: RAG検索で関連ドキュメントが全く取得できなかった、または取得されたドキュメントに回答に必要な情報が一切含まれていないケース。

    • Context Windowの限界: RAGによって取得されたドキュメントがContext Windowの最大サイズに非常に近いか、または僅かに超過する状況で、重要な情報が欠落する可能性のあるケース。Context Windowの最後に関連性の高い情報が配置されている場合、モデルがそれを適切に利用できるか。

    • 幻覚誘発: 質問が曖昧で、モデルが推測しやすい構造になっているケース。

自動評価の擬似コード

自動評価は、大規模なテストセットに対して一貫した評価を可能にします。

import json
import re
from typing import List, Dict, Any

# 評価ルーブリックと正規表現によるフォーマットチェックの擬似コード

def evaluate_answer(model_output: Dict[str, Any], gold_answer: Dict[str, Any], documents: List[Dict[str, str]]) -> Dict[str, Any]:
    """
    RAGシステムからのモデル出力とゴールデンアンサーを比較し、採点を行う。
    入力:
        model_output (Dict[str, Any]): モデルの出力JSON (answer, sources, status)
        gold_answer (Dict[str, Any]): 正解のJSON (answer, sources, status)
        documents (List[Dict[str, str]]): 入力として与えられたドキュメント
    出力:
        Dict[str, Any]: 評価結果 (スコア、詳細)
    計算量: O(N) where N is the length of answers for substring/F1 comparison.
    メモリ: O(M) where M is the total size of strings.
    """
    score = 0
    feedback = []

    # 1. JSONフォーマットチェック

    if not isinstance(model_output, dict) or not all(k in model_output for k in ["answer", "sources", "status"]):
        feedback.append("JSONフォーマットが不正です。")
        return {"score": 0, "details": feedback}

    # 2. ステータスの一致

    if model_output.get("status") == gold_answer.get("status"):
        score += 1
    else:
        feedback.append(f"ステータスが不一致です。期待: {gold_answer.get('status')}, 実際: {model_output.get('status')}")

    # 3. 回答の正確性 (status: success の場合のみ)

    if model_output.get("status") == "success":

        # 例: 簡単な部分文字列マッチング、より高度なものにはF1/ROUGEスコアを使用

        if gold_answer.get("answer") in model_output.get("answer", ""):
            score += 2 # 正確な回答に2点
        else:
            feedback.append("回答が不正確です。")

        # 4. ソースの参照 (status: success の場合のみ)

        if all(src in model_output.get("sources", []) for src in gold_answer.get("sources", [])):
            score += 1 # 必要なソースが全て含まれている

            # さらに、余計なソースが含まれていないかのチェックも可能

            if any(src not in gold_answer.get("sources", []) for src in model_output.get("sources", [])):
                feedback.append("不要なソースが含まれています。")
        else:
            feedback.append("参照ソースが不適切です。")

        # 5. 幻覚の検出 (ドキュメント外の情報を使用していないか)


        # ドキュメント内容を結合し、モデル出力がその範囲内にあるかを確認

        combined_doc_content = " ".join([d["content"] for d in documents])

        # これは単純なチェックであり、意味的な幻覚検出にはより高度な手法が必要

        if gold_answer.get("status") == "success" and gold_answer.get("answer") not in combined_doc_content and gold_answer.get("answer") != model_output.get("answer"):

            # 正しい回答がドキュメントにない、かつモデルも間違っている場合、幻覚とみなすこともある


            # ここでは単純に、モデルの回答がドキュメントに存在するかどうかを確認

            if model_output.get("answer", "") not in combined_doc_content:
                feedback.append("提供されたドキュメント外の情報を生成した可能性があります（幻覚）。")


    # 6. 回答の簡潔性 (具体的な文字数、冗長表現の有無など)


    # 例: 理想的な文字数範囲やキーワード密度で評価

    if gold_answer.get("status") == "success" and model_output.get("status") == "success":
        if len(model_output.get("answer", "")) > len(gold_answer.get("answer", "")) * 1.5: # 1.5倍より長いと冗長
            feedback.append("回答が冗長です。")
        else:
            score += 0.5 # 簡潔性に加点

    return {"score": score, "details": feedback}

def check_format(output_string: str) -> bool:
    """
    モデルの出力がJSON形式であることを正規表現で検証する。
    """

    # 簡略化したJSON形式チェック（厳密なJSONパーサが望ましい）

    return re.match(r'^\s*\{.*"answer":.*"sources":.*"status":.*\}\s*$', output_string, re.DOTALL) is not None

# 使用例:


# model_raw_output = '```json\n{"answer": "Gemini 1.5 ProのContext Windowサイズは最大100万トークン（1Mトークン）です。", "sources": ["doc_001"], "status": "success"}\n```'


# # コードブロックからJSONを抽出


# json_match = re.search(r'```json\s*(.*?)\s*```', model_raw_output, re.DOTALL)


# if json_match:


#     extracted_json_str = json_match.group(1)


#     try:


#         model_output_data = json.loads(extracted_json_str)


#     except json.JSONDecodeError:


#         model_output_data = {"status": "format_error", "answer": "JSONデコードエラー"}


# else:


#     model_output_data = {"status": "format_error", "answer": "JSONコードブロックが見つかりません"}

#


# gold_data = {


#     "answer": "Gemini 1.5 ProのContext Windowサイズは最大100万トークン（1Mトークン）です。",


#     "sources": ["doc_001"],


#     "status": "success"


# }


# input_docs = [


#     {"id": "doc_001", "content": "Gemini 1.5 Proは最大100万トークン（1Mトークン）のContext Windowを提供します。"}


# ]

#


# evaluation_result = evaluate_answer(model_output_data, gold_data, input_docs)


# print(evaluation_result)

より高度な評価には、生成された回答とゴールデンアンサー間のセマンティックな類似度を測るためのROUGEやBLEU、またはF1スコアが使用されます。

失敗モードと抑制手法

プロンプト設計において、LLMの失敗モードを予測し、その抑制策を講じることは不可欠です。

失敗モード 説明 抑制手法
幻覚 (Hallucination) 提供された情報にない内容を、あたかも事実であるかのように生成する。 System指示: 「提供された情報のみを使用し、推測は行わないこと」を明記。
検証ステップ: 出力された回答がRAGソースドキュメント内に存在するかを検証する後処理。
プロンプト内の強調: 「厳密に」「唯一の」といったキーワードで制約を強化。
様式崩れ (Format Deviation) 期待する出力フォーマット（例: JSON, 箇条書き）から逸脱する。 Few-shotプロンプト: 明確な入出力例を提示。
正規表現/スキーマ検証: 出力後の文字列を自動で検証し、失敗時には再生成を促すリトライ戦略。
XMLタグ/マークダウン: 構造化を明示する。
脱線 (Topic Drift) ユーザーの質問や提供されたドキュメントの範囲から逸脱し、無関係な情報を生成する。 プロンプトの明確化: 質問の範囲を明確に指定。
関連性フィルタリング: RAG検索結果のドキュメントに、より厳密な関連性スコア閾値を適用し、コンテキストに含める情報を精査。
CoT: 思考ステップで関連情報の特定を強制。
禁止事項違反 個人情報、差別的表現、モデルの内部情報など、出力してはならない内容を生成する。 System指示: 禁止事項を明示的にリストアップ。
出力フィルタリング: コンテンツモデレーションAPI（例: Perspective API）やキーワードフィルタを適用し、不適切な出力を検出・ブロック。
安全レイヤー: プロンプトとモデルの間に安全フィルタを導入。
Context Windowの乱用 長いContext Windowが与えられた際に、重要な情報を無視したり、逆に無関係な情報に影響されたりする（”Lost in the Middle”） 情報配置の最適化: 重要な情報をプロンプトの最初または最後に配置 [2]。
要約/チャンキング: コンテキスト内の情報をより簡潔に要約したり、意味のあるチャンクに分割し、最も関連性の高いものを選択的に投入。
CoT: 思考ステップで関連情報の特定を強制し、モデルの注意を引く。

改良と再評価のループ

プロンプト設計は一度きりの作業ではなく、継続的な改良と再評価のサイクルを通じて最適化されます。

graph TD
    A["プロンプト設計"] --> |プロンプトとコンテキスト| B{"LLMモデル実行"};
    B --> |モデル出力| C["評価"];
    C --> |評価結果と失敗モード| D{"誤り分析"};
    D --> |洞察と改善案| E["プロンプト改良"];
    E --> A;
    C --|評価セットの追加| F["テストデータ拡充"];
    D --|モデルの挙動理解| G["ドメイン知識更新"];
    F --> A;
    G --> A;

解説:

  1. プロンプト設計: 初期プロンプトを作成し、RAGシステムを通じてLLMに質問とコンテキストを与えます。

  2. LLMモデル実行: LLMはプロンプトに従って回答を生成します。

  3. 評価: 生成された回答を、定義された評価シナリオと自動評価スクリプト（上記参照）を用いて多角的に評価します。ここでは、正確性、簡潔性、参照性、フォーマット遵守などを測ります。

  4. 誤り分析: 評価結果に基づき、特に失敗したケース（幻覚、様式崩れ、脱線など）を詳細に分析します。どのプロンプト要素が原因か、Context Windowのどの部分で問題が発生したかを特定します。

  5. プロンプト改良: 誤り分析から得られた洞察に基づき、プロンプトの指示、Few-shot例、CoTステップ、またはSystem instructionsを調整します。例えば、「Lost in the Middle」問題が頻発する場合は、重要な情報の配置を調整したり、コンテキストをより厳選するよう指示を追加したりします。

  6. テストデータ拡充: 新たな難例やコーナーケースを発見した場合、それらをテストセットに追加し、評価の網羅性を高めます。

  7. ドメイン知識更新: モデルが誤った推論をした場合、その原因がプロンプトの曖昧さにあるのか、RAGで取得した情報の不足や誤りにあるのかを特定し、RAG検索戦略やチャンキング手法の改善に繋げます。

このループを繰り返すことで、プロンプトは徐々に堅牢になり、RAGシステムの全体的な性能が向上します。

まとめ

RAGプロンプトの最適化とContext Windowの効率的な管理は、LLMを用いた情報検索システムにおいて不可欠な要素です。Gemini 1.5 Proのような大規模なContext Windowを持つモデルの登場は、より多くの情報を活用できる可能性をもたらしましたが、同時に「Lost in the Middle」問題 [1] のような新たな課題も提示しています。 、詳細な入出力契約と性能要件の設定から始まり、ゼロショット、Few-shot、Chain-of-Thought制約型といった具体的なプロンプト設計案、そして自動評価可能なシナリオと擬似コードを提供しました。さらに、幻覚や様式崩れなどの失敗モードに対する具体的な抑制手法と、継続的な改良と再評価のループが、RAGシステムの性能を最大化するための鍵であることを示しました。2024年5月現在、プロンプト工学は進化を続けており、これらの実践的なアプローチは、より信頼性が高く、効率的なRAGシステムの構築に貢献するでしょう。

参照: [1] Lee, J., et al. (2024, May 3). Long Context Does Not Necessarily Mean Better RAG. arXiv. https://arxiv.org/abs/2405.02517 [2] Liu, Y., et al. (2024, May 14). The Devil in the Details: A Tailored Context Window Optimizes In-context Learning. arXiv. https://arxiv.org/abs/2405.08985 [3] Google AI Blog. (2024, May 14). Gemini 1.5 Flash: Efficient and fast multimodal performance. https://blog.google/technology/ai/gemini-1-5-flash-announcement/ [4] Google Cloud Blog. (2024, May 14). What’s next in generative AI: Gemini 1.5 Pro generally available, new capabilities for developers. https://cloud.google.com/blog/products/ai-ml/gemini-1-5-pro-generally-available-new-capabilities-for-developers

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました