RAGにおけるプロンプト拡張戦略

Tech

RAG", "secondary_categories": ["プロンプトエンジニアリング", "情報検索"], "tags": ["RAG", "Prompt Engineering", "LLM", "Query Expansion", "Context Window", "Gemini", "HyDE", "CoT"], "summary": "RAGにおけるプロンプト拡張戦略を網羅的に解説。プロンプト設計、評価、改良のループを定義。", "mermaid": true, "verify_level": "L0", "tweet_hint": {"text":"RAGの回答品質を高めるプロンプト拡張戦略を解説。クエリ拡張からCoT制約型プロンプト設計、自動評価までを網羅。幻覚抑制策も提示。 #PromptEngineering","hashtags":["#RAG","#PromptEngineering"]}, "link_hints": ["https://arxiv.org/abs/2212.10496", "https://arxiv.org/abs/2310.06117", "https://docs.llamaindex.ai"] } --> 本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

RAGにおけるプロンプト拡張戦略

Retrieval Augmented Generation (RAG) システムにおいて、大規模言語モデル (LLM) の性能を最大限に引き出すためには、単に情報を検索して与えるだけでなく、その情報をいかに効果的にプロンプトに組み込むかが鍵となります。本稿では、RAGにおけるプロンプト拡張戦略に焦点を当て、そのユースケース定義、制約付き仕様化、具体的なプロンプト設計、評価方法、および誤り分析から改良までのプロセスを詳述します。

ユースケース定義

ユーザーからの質問に対し、指定された外部知識ベースから関連情報を検索し、その情報を基に、正確かつ整合性の取れた回答を生成することを目的とします。この際、単なる情報抽出だけでなく、推論、要約、比較といった高度な処理も要求されます。特に、専門性の高い質問や、複数の情報源を統合する必要がある場合に、LLMへのプロンプトを最適化することで、回答品質を最大化します。

制約付き仕様化（入出力契約）

入力契約

  • user_query (string): ユーザーからの質問テキスト。

  • retrieved_documents (list of strings): 検索エンジンやベクトルデータベースから取得された関連ドキュメントのリスト。各要素はドキュメントの内容を表す文字列。ドキュメントには、可能であればソース情報（例: ドキュメントID、タイトル、URL）を含める。

出力契約

  • llm_response (string): LLMが生成した回答テキスト。

  • citations (list of objects, optional): 回答の根拠となったretrieved_documentsのソースを示す情報。各オブジェクトは{"document_id": "...", "url": "..."}形式。

失敗時の挙動

  • 関連情報がretrieved_documents内に不足している場合、LLMは「情報不足のため、ご質問に正確に回答できません。提供された情報からは〜。」と明示的に伝えるか、提供された情報に基づく推測は行わない。

  • 幻覚（Hallucination）が発生したと評価ステップで検出された場合、システムは回答を破棄し、再試行を行うか、評価者にフラグを立てて通知する。

禁止事項

  • retrieved_documentsにない情報を捏造（幻覚）して回答に含めること。

  • 不適切な言葉、差別的な表現、またはセキュリティ上の脆弱性につながる可能性のある出力。

  • 指定された出力フォーマット（例: JSON, Markdown）を遵守しないこと。

プロンプト拡張戦略と設計

プロンプト拡張戦略とは、RAGシステムにおいてLLMに与えるプロンプトの質を高めるための手法全般を指します。これには、より関連性の高いドキュメントを取得するための「クエリ拡張」と、取得したドキュメントを効果的にLLMに提示し、望ましい形式で回答を生成させるための「コンテキスト提示と指示の最適化」が含まれます。

クエリ拡張戦略

ユーザーの元の質問を直接検索するだけでなく、質問の意図を深掘りしたり、複数の視点から情報を探したりするために、検索クエリを加工・生成する手法です。

  1. Multi-Query Retrieval: 元のユーザー質問から複数の異なる検索クエリを生成し、それぞれでドキュメントを検索し、結果を統合します（例: Reciprocal Rank Fusion, RRF）。

  2. Hypothetical Document Embedding (HyDE): LLMに元の質問に対する仮説的な回答を生成させ、その仮説回答の埋め込みを検索クエリとして使用します。

    • 参考: Gao et al., “Precise and Scalable Document Retrieval with Large Language Models,” arXiv:2212.10496, 2022年12月20日公開（JST）。

  3. Step-Back Prompting: LLMにユーザー質問の背後にあるより一般的な概念的質問を特定させ、その概念的質問に対する回答をまず導き出し、その後、元の質問に回答するためにその知識を利用します。

    • 参考: Zou et al., “Step-Back Prompting: Adding an Abstraction Step to Enable More Complex Tool Use and Reasoning in Large Language Models,” arXiv:2310.06117, 2023年10月9日公開（JST）。

プロンプト案の提示

ここでは、取得したretrieved_documentsをLLMに提示する際の具体的なプロンプト設計を3種類提示します。{{user_query}}はユーザーの質問、{{context}}は結合されたretrieved_documentsを表します。

1. ゼロショットプロンプト (Zero-Shot Prompt)

最も基本的な形式で、特別な推論指示や例を含まず、単に質問とコンテキストを提示します。

あなたは情報提供を目的とするアシスタントです。
以下の「参照情報」を基に、「質問」に回答してください。
参照情報にない内容は推測せず、「参照情報に記載がありません」と回答してください。

===参照情報===
{{context}}

===質問===
{{user_query}}

===回答===

2. 少数例プロンプト (Few-Shot Prompt)

プロンプト内に質問と回答の具体例を複数含めることで、LLMが望ましい出力形式や推論パターンを学習できるようにします。RAGにおいては、回答生成タスクの例や、特定の形式（例: 箇条書き、要約）の例を含めます。

あなたは情報提供を目的とするアシスタントです。
以下の「参照情報」を基に、「質問」に回答してください。
参照情報にない内容は推測せず、「参照情報に記載がありません」と回答してください。
回答は必ず参照情報を引用し、箇条書きで分かりやすく要約してください。

===例1===
参照情報:

- ドキュメントA: 「Gemini 1.5 Proは、2024年2月21日にGoogleから発表された。」

- ドキュメントB: 「その最大コンテキストウィンドウは100万トークンである。」
質問: Gemini 1.5 Proの発表日と特徴は何ですか？
回答:
Gemini 1.5 Proは、以下の特徴を持ちます。

- 発表日: 2024年2月21日（ドキュメントAより）

- 最大コンテキストウィンドウ: 100万トークン（ドキュメントBより）

===例2===
参照情報:

- ドキュメントX: 「RAGシステムは、検索コンポーネントと生成コンポーネントから構成される。」

- ドキュメントY: 「検索コンポーネントは、外部知識ベースから関連ドキュメントを取得する。」
質問: RAGシステムの主要な構成要素は何ですか？
回答:
RAGシステムは主に以下の要素で構成されます。

- 検索コンポーネント: 外部知識ベースから関連ドキュメントを取得します。（ドキュメントX, Yより）

- 生成コンポーネント: 取得したドキュメントを基に回答を生成します。（ドキュメントXより）

===参照情報===
{{context}}

===質問===
{{user_query}}

===回答===

3. Chain-of-Thought (CoT) 制約型プロンプト

LLMに最終回答に至るまでの思考プロセス（推論ステップ）を明示的に出力させ、その後で回答を生成するように指示します。これにより、透明性が向上し、幻覚を抑制する効果も期待できます。

あなたは情報提供を目的とするアシスタントです。
以下の「参照情報」を基に、「質問」に回答してください。
参照情報にない内容は推測せず、「参照情報に記載がありません」と回答してください。
回答は、まず思考プロセスを記述し、その後に最終回答を生成してください。

===参照情報===
{{context}}

===質問===
{{user_query}}

===思考プロセス===

1. 質問の意図を理解する。

2. 参照情報から質問に関連するキーポイントを特定する。

3. キーポイントを統合し、矛盾がないか確認する。

4. 最終回答の構成案を検討する。

===最終回答===

評価

プロンプト拡張戦略の効果を測定するために、以下のシナリオと自動評価手法を組み合わせます。

評価シナリオ

  • 正例: 関連情報がretrieved_documentsに明確に存在し、直接的な回答が期待されるケース。

  • 難例: 複数のドキュメントからの情報統合、推論、またはわずかな矛盾解消が必要なケース。

  • コーナーケース:

    • retrieved_documentsに関連情報が全くない、または非常に少ないケース（情報不足検出）。

    • retrieved_documentsに誤った情報や矛盾する情報が含まれるケース（幻覚・矛盾検出）。

    • 出力フォーマットの厳守が求められるケース（例: JSON形式、特定のキーワードの有無）。

自動評価の擬似コード

import re

def evaluate_response(user_query, retrieved_documents, llm_response, expected_answer=None, format_regex=None):
    """
    LLMの回答を自動評価する関数。

    Args:
        user_query (str): ユーザーの質問。
        retrieved_documents (list): 検索されたドキュメントのリスト。
        llm_response (str): LLMの生成した回答。
        expected_answer (str, optional): 正解回答のキーワードやフレーズ。
        format_regex (str, optional): 出力フォーマットを検証する正規表現。

    Returns:
        dict: 評価結果 (正確性スコア, 幻覚フラグ, フォーマット準拠フラグ)。
    """
    accuracy_score = 0.0
    hallucination_flag = False
    format_compliant = True

    # 1. 幻覚の検出（簡易版: retrieved_documentsにない固有名詞や日付がないか）


    # 大規模な幻覚検出には、NLIモデルやRAGASのようなフレームワークが必要。


    # ここでは簡易的に、想定されるキーワードが参照情報に存在するかを確認。

    relevant_terms = set(re.findall(r'\b\w+\b', user_query.lower()))
    context_text = " ".join(retrieved_documents).lower()

    # 回答内の各文が参照情報に根拠を持つかを検証する（非常に複雑なタスクのため、ここでは抽象化）


    # 例: LLMの回答から抽出されたエンティティが、retrieved_documentsに存在するか


    # 実際には、RAGASなどのツールで「Faithfulness」を評価


    # faithfulness_score = calculate_faithfulness(llm_response, context_text)


    # if faithfulness_score < threshold:


    #     hallucination_flag = True

    # 簡易幻覚チェック：回答中のキーワードが参照情報内に全く見られない場合

    response_keywords = set(re.findall(r'\b\w+\b', llm_response.lower()))

    # 質問由来のキーワードは除く

    response_keywords_filtered = [kw for kw in response_keywords if kw not in relevant_terms and len(kw) > 2]

    for keyword in response_keywords_filtered:
        if keyword not in context_text:

            # これは厳密な幻覚検出ではないが、関連性の低い語句の出現を示す

            pass # より洗練された評価が必要

    # 2. 正確性の評価（キーワードマッチ、または意味的類似度）

    if expected_answer:
        if expected_answer.lower() in llm_response.lower():
            accuracy_score = 1.0
        else:

            # 意味的類似度スコア (Sentence-BERTなどを用いる)


            # accuracy_score = semantic_similarity(llm_response, expected_answer)

            accuracy_score = 0.0 # 簡易のため完全一致のみ

    # 3. フォーマット準拠の評価

    if format_regex:
        if not re.search(format_regex, llm_response):
            format_compliant = False

    # 4. 情報不足の検出（"情報不足"というフレーズが出力されたか、または回答が空の場合）

    if "情報不足のため" in llm_response or not llm_response.strip():

        # もし実際に情報が不足しているシナリオであれば、これは正しい挙動


        # そうでない場合は失敗

        if not retrieved_documents or len(context_text.strip()) < 50: # コンテキストが少ない場合
             accuracy_score = 1.0 # 正しい挙動と評価
        else:
             accuracy_score = 0.0 # 参照情報があるのに「情報不足」と回答した場合は誤り

    # 簡易的な幻覚フラグ設定


    # もし正確性スコアが低く、かつ情報不足の旨も述べられていない場合は幻覚の可能性

    if accuracy_score < 0.5 and "情報不足のため" not in llm_response.lower():
        hallucination_flag = True

    return {
        "accuracy_score": accuracy_score, # 0.0 to 1.0
        "hallucination_detected": hallucination_flag,
        "format_compliant": format_compliant,
        "llm_response": llm_response # デバッグ用に含める
    }

# 例の実行 (評価シナリオの模倣)


# response_zero_shot = "Gemini 1.5 Proは2024年2月21日にGoogleから発表され、最大コンテキストウィンドウは100万トークンです。"


# eval_result = evaluate_response("Gemini 1.5 Proの発表日と特徴は？", ["..."], response_zero_shot, 


#                                 expected_answer="2024年2月21日", format_regex=None)


# print(eval_result)

誤り分析と抑制手法

失敗モード

  • 幻覚（Hallucination）: retrieved_documentsに存在しない情報を捏造して回答する。

  • 様式崩れ: 指定された出力フォーマット（例: JSON、箇条書き）を遵守しない。

  • 脱線（Off-topic）: 質問の意図から逸脱した回答を生成する。

  • 禁止事項違反: 不適切な言葉やセキュリティ上のリスクとなる内容を出力する。

  • 情報不足による誤回答: retrieved_documentsに情報が不足しているにもかかわらず、断定的な回答をしてしまう。

抑制手法

  • System指示の強化: プロンプトのSystem部分で、役割、遵守事項（「参照情報のみを使用し、推測しない」）、出力形式を明確かつ繰り返し指示します。

    • 例: 「あなたは厳格な情報源に基づき回答するアシスタントです。提供された参照情報以外は決して利用せず、情報がない場合はその旨を伝えてください。」

  • 検証ステップの導入:

    • ファクトチェック: 生成された回答内の主要な事実やエンティティがretrieved_documents内に存在するかを自動的にチェックします（例: RAGASのFaithfulnessメトリクス）。

    • 形式バリデーション: 正規表現やJSONスキーマを用いて、出力フォーマットを検証します。

  • リトライ戦略:

    • 検証ステップで失敗が検出された場合、異なるプロンプト（例: より詳細なCoT指示、異なるfew-shot例）または異なるモデルパラメータ（例: temperatureを下げる）で再試行します。

    • 幻覚が検出された場合、LLMに回答の根拠を提示させ、それが参照情報に存在するかを二次的に検証するステップを設けます。

  • Contextual Compression: 検索後のドキュメントから、質問との関連性が低い部分を削除し、LLMに与えるコンテキストのノイズを減らします。これにより、LLMが重要な情報に集中しやすくなります。

  • Sentence Window Retrieval: 埋め込み生成時は小さなチャンク（例: 1文）を使用し、LLMにコンテキストとして渡す際はその前後を拡張したより大きなウィンドウ（例: 段落全体）を提供する戦略です。これにより、高精度な検索と豊富なコンテキストの両立を図ります。

改良

評価と誤り分析の結果に基づき、以下のサイクルでプロンプト戦略を改良します。

  1. プロンプトテンプレートの調整: 失敗モードに応じて、System指示の具体化、few-shot例の追加・修正、CoTステップの最適化を行います。

  2. クエリ拡張戦略の調整: 特定の質問タイプで検索精度が低い場合、HyDE、Multi-Query、Step-Backなどのクエリ拡張手法の適用やパラメータ調整を検討します。

  3. コンテキスト処理の最適化: retrieved_documentsの量や粒度、Contextual CompressionやSentence Window Retrievalのような後処理の導入・調整を行います。

  4. モデル選択/ファインチューニング: プロンプトだけでは解決できない根本的な問題がある場合、基盤モデルの変更やドメイン特化型データでのファインチューニングを検討します。

再評価

改良が施されたプロンプト拡張戦略に対して、再度同じ評価シナリオと自動評価スクリプトを用いて性能を測定します。これにより、改良の効果を定量的に確認し、次のイテレーションへと繋げます。

まとめ

RAGにおけるプロンプト拡張戦略は、LLMの回答品質を飛躍的に向上させるための重要な要素です。クエリ拡張、適切なコンテキスト提示、そしてゼロショット、少数例、Chain-of-Thoughtといったプロンプト設計手法を組み合わせることで、より正確で、整合性の取れた、そしてユーザーの期待に応える回答を生成することが可能になります。評価と継続的な改良のループを回すことで、RAGシステムの堅牢性と性能を最大化できます。

graph TD
    A["ユーザーの質問"] --> B{"クエリ拡張"};
    B -- HyDE, Multi-Query, Step-Back --> C["拡張されたクエリ群"];
    C -- 検索 --> D["外部知識ベース"];
    D -- 関連ドキュメントの取得 --> E["Retrieved Documents"];
    E -- コンテキスト圧縮, Sentence Window --> F["最適化されたコンテキスト"];
    A -- 元の質問 --> G["プロンプトテンプレート"];
    G -- コンテキストと結合 --> H{"LLMへのプロンプト"};
    H -- ゼロショット, Few-Shot, CoT制約型 --> I[LLM];
    I -- 回答生成 --> J["LLM応答"];
    J --> K{"評価"};
    K -- 正確性, 幻覚, 形式 --> L["誤り分析"];
    L -- 失敗モード特定 --> M["改良"];
    M -- プロンプト調整, 戦略変更 --> H;
    K -- 成功 --> N["最終回答"];
ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

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