Few-shotプロンプティングの入力例選定と評価

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Few-shotプロンプティングの入力例選定と評価

Few-shotプロンプティングは、大規模言語モデル（LLM）が少数の入力例からタスクの意図を学習し、同様の新しい入力に対して適切な出力を生成する能力を指します。本記事では、このFew-shotプロンプティングにおける入力例の選定基準、効果的な評価手法、および失敗モードとその抑制策について、プロンプトエンジニアリングの観点から解説します。

ユースケース定義

Few-shotプロンプティングは、以下のような多種多様なタスクにおいて、モデルの専門知識を特定のドメインや形式に誘導するために利用されます。

  • 感情分析: レビューテキストからポジティブ/ネガティブ/中立を判定する。

  • エンティティ抽出: 文書から特定の情報（人名、地名、組織名など）を抽出する。

  • 要約: 長文を特定の文字数や形式で要約する。

  • テキスト分類: ニュース記事をカテゴリ（スポーツ、政治、経済など）に分類する。

  • Q&A: 特定の知識ベースに基づく質問応答。

これらのユースケースでは、モデルが事前に学習していない新しいタスクや、特定の出力形式が求められる場合に、少数の高品質な例を提供することで、モデルのパフォーマンスを向上させることが期待されます。

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

Few-shotプロンプティングの成功には、明確な入出力契約の定義が不可欠です。

  • 入力形式:

    • データ形式: JSON形式のテキストを基本とします。例: {"text": "これは素晴らしい商品だ。"}

    • 制約: 入力テキストは最大2000文字。個人情報や機密情報は含まない。

  • 出力形式:

    • データ形式: JSON形式のテキスト。例: {"sentiment": "Positive", "reason": "商品への高評価が明確。"}

    • 制約: 出力スキーマはプロンプトで定義された形式に厳密に従う。sentimentは”Positive”, “Negative”, “Neutral”のいずれか。reasonは50文字以内。

  • 失敗時の挙動:

    • スキーマ不一致: 定義されたJSONスキーマと異なる場合、{"error": "SCHEMA_MISMATCH", "details": "..."}を返す。

    • 幻覚/不適切コンテンツ: 事実に反する情報や禁止事項に該当するコンテンツを生成した場合、{"error": "INAPPROPRIATE_CONTENT", "details": "..."}を返す。

    • 脱線: 指示されたタスクから逸脱した場合、{"error": "OFF_TOPIC", "details": "..."}を返す。

    • タイムアウト: 応答が30秒以内にない場合、{"error": "TIMEOUT"}を返す。

  • 禁止事項:

    • 人種、宗教、性別に関する差別的な表現。

    • 暴力、ヘイトスピーチ、違法行為を助長する内容。

    • 個人を特定できる情報（PII）の出力。

プロンプト設計

以下に、感情分析タスクを例とした3種類のプロンプト案を示します。

1. ゼロショットプロンプト

あなたはテキストの感情分析を行うアシスタントです。
入力テキストの感情を「Positive」「Negative」「Neutral」のいずれかで分類し、その理由を簡潔に説明してください。
出力はJSON形式でお願いします。

入力:
{"text": "この映画は期待外れだった。"}

出力:

2. 少数例（Few-shot）プロンプト

あなたはテキストの感情分析を行うアシスタントです。
入力テキストの感情を「Positive」「Negative」「Neutral」のいずれかで分類し、その理由を簡潔に説明してください。
出力はJSON形式でお願いします。

例1:
入力:
{"text": "このサービスは顧客対応が素晴らしく、非常に満足した。"}
出力:
{"sentiment": "Positive", "reason": "顧客対応への高評価が示されている。"}

例2:
入力:
{"text": "商品の到着が遅れ、梱包も雑だった。"}
出力:
{"sentiment": "Negative", "reason": "配送遅延と梱包品質への不満が明確。"}

例3:
入力:
{"text": "特に可もなく不可もない普通の商品でした。"}
出力:
{"sentiment": "Neutral", "reason": "評価が極端にポジティブでもネガティブでもない。"}

入力:
{"text": "彼のプレゼンテーションはデータに裏付けされており、非常に説得力があった。"}

出力:

3. Chain-of-Thought（CoT）制約型プロンプト

あなたはテキストの感情分析を行うアシスタントです。
入力テキストの感情を「Positive」「Negative」「Neutral」のいずれかで分類し、その理由を簡潔に説明してください。
思考ステップを含めて、最終的なJSON形式の出力を作成してください。

例1:
入力:
{"text": "このアプリのUIは直感的で使いやすく、日々の業務効率が格段に上がった。"}
思考:

1. テキストは「UIが直感的で使いやすい」「業務効率が上がった」という肯定的な表現を含んでいる。

2. 全体として、アプリの利用体験に対する満足度が高いことが示唆される。

3. よって、感情は「Positive」。理由は「肯定的な表現と業務効率向上への言及があるため」。
出力:
{"sentiment": "Positive", "reason": "UIの直感性と業務効率向上への肯定的な表現。"}

例2:
入力:
{"text": "新しいアップデートで機能が追加されたが、既存の機能が不安定になった。"}
思考:

1. テキストは「機能追加」というポジティブな側面と、「既存機能が不安定になった」というネガティブな側面の両方を含んでいる。

2. 両側面が相殺され、全体として明確なポジティブまたはネガティブな感情が特定しにくい。

3. よって、感情は「Neutral」。理由は「ポジティブとネガティブな側面が混在するため」。
出力:
{"sentiment": "Neutral", "reason": "機能追加と既存機能の不安定化という相反する要素の混在。"}

入力:
{"text": "プロジェクトの締め切りは守られたが、結果物の品質は平均的だった。"}

出力:

Few-shotプロンプトの入力例選定基準:

  • 多様性: 複数の異なるパターンやニュアンスをカバーする例を含めます。これにより、モデルはより広い範囲の入力に対応できるようになります[2, 5, 6]。例えば、感情分析では、直接的な肯定/否定だけでなく、皮肉、間接的な表現、中立的な表現の例も加えるべきです。

  • 代表性: タスクにおいて最も一般的で重要なケースを代表する例を選びます。

  • 難易度: 簡単な例だけでなく、モデルが誤分類しやすい「難例」や、曖昧な「コーナーケース」も含めることで、ロバスト性を高めます[1]。

  • 品質と整合性: 提供する例とその出力は、正確かつ一貫している必要があります。不正確な例や矛盾する例は、モデルに誤った学習をさせ、幻覚を引き起こす原因となり得ます[3]。

評価

Few-shotプロンプティングの効果を測定するためには、体系的な評価プロセスが必要です。

評価シナリオ

  • 正例: プロンプトの指示に素直に従う典型的な入力。

    • 例: {"text": "このレストランの料理は絶品で、サービスも申し分ない。"}

  • 難例: 曖昧な表現、皮肉、二重否定、複数の感情が混在する入力など、モデルが判断に迷う可能性のあるケース。

    • 例: {"text": "結局のところ、この製品は宣伝ほど悪くはなかった。"} (否定的な表現だが結果は悪くない)

  • コーナーケース: プロンプトで明示的に扱われていないが、現実世界で発生し得る特定の状況。

    • 例: {"text": "今日の天気は晴れ。"} (感情がなく、中立だが理由付けが難しい)

    • 例: {"text": "私はその件について何も感じていない。"} (直接的な感情表現だが中立)

自動評価の擬似コード

自動評価は、生成されたJSON出力の形式検証と、内容の正確性を評価します。

import json
import re

def evaluate_sentiment_output(expected_output: dict, llm_output_str: str) -> dict:
    """
    LLMの感情分析出力を自動評価する関数。
    採点ルーブリックに基づき、形式、感情、理由の正確性を評価する。

    Args:
        expected_output (dict): 期待される出力例 {"sentiment": "Positive", "reason": "..."}
        llm_output_str (str): LLMから得られた生出力文字列

    Returns:
        dict: 評価結果 {"score": float, "details": dict}
    """
    score = 0.0
    details = {
        "format_valid": False,
        "sentiment_correct": False,
        "reason_plausible": False,
        "error_message": None
    }

    # 1. JSON形式の検証 (形式点の配点: 0.2)

    try:
        actual_output = json.loads(llm_output_str)
        details["format_valid"] = True
        score += 0.2
    except json.JSONDecodeError as e:
        details["error_message"] = f"JSON形式エラー: {e}"
        return {"score": score, "details": details}

    # 2. スキーマ検証 (スキーマ不一致はここで弾かれるべきだが、存在チェック)

    if not all(k in actual_output for k in ["sentiment", "reason"]):
        details["error_message"] = "出力スキーマが不完全です (sentiment/reasonが不足)。"
        return {"score": score, "details": details}

    # 3. 感情分類の正確性 (感情点の配点: 0.5)

    if actual_output.get("sentiment") == expected_output.get("sentiment"):
        details["sentiment_correct"] = True
        score += 0.5

    # 4. 理由の妥当性 (キーワードマッチ/セマンティック類似度) (理由点の配点: 0.3)


    # 簡単なキーワードマッチング、より高度な評価には埋め込みベクトル比較や別のLLMを使用

    expected_reason_keywords = re.split(r'\s|、|。', expected_output.get("reason", "").lower())
    actual_reason = actual_output.get("reason", "").lower()

    matched_keywords = [k for k in expected_reason_keywords if k and k in actual_reason]
    if len(matched_keywords) / max(1, len(expected_reason_keywords)) >= 0.5: # 50%以上のキーワードがマッチ
        details["reason_plausible"] = True
        score += 0.3

    # 理由の文字数制約チェック

    if len(actual_reason) > 50:
        details["reason_plausible"] = False # 長すぎる場合は減点または不正
        score = max(0, score - 0.1) # 例: 長すぎる場合は部分的に減点

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

# 例としての利用


# expected = {"sentiment": "Positive", "reason": "非常に説得力があるため。"}


# llm_output = '{"sentiment": "Positive", "reason": "データに裏付けられた説得力あるプレゼンだった。"}


# result = evaluate_sentiment_output(expected, llm_output)


# print(result)

この擬似コードでは、以下の採点ルーブリックに基づき評価を行います。

  • JSON形式の有効性: 0.2点

  • 感情分類の正確性: 0.5点

  • 理由の妥当性: 0.3点（キーワードマッチ、文字数制約など）

誤り分析と抑制手法

LLMは予測不可能な振る舞いをすることがあり、特定の失敗モードが発生します。これらを特定し、抑制する戦略が必要です。

失敗モード

  • 幻覚（Hallucination）: 事実に基づかない、もっともらしいが誤った情報を生成する。

    • 例: 感情分析で「Positive」としながら、理由として入力テキストに存在しない要素を挙げる。

  • 様式崩れ（Format Mismatch）: プロンプトで指定したJSONスキーマや出力形式に従わない。

    • 例: JSONではなく平文で出力する、キー名が異なる、値が定義外の文字列になる。

  • 脱線（Off-topic）: 指示されたタスクから逸脱し、無関係な情報を生成する。

    • 例: 感情分析の代わりに、入力テキストの要約や関連情報の検索結果を出力する。

  • 禁止事項違反: 個人情報、機密情報、不適切なコンテンツなどを生成する。

    • 例: 入力に含まれる仮名氏名に対して、実際の個人情報を推測して出力する。

抑制手法

  • System指示の強化: プロンプトの冒頭でモデルの役割、遵守すべきルール、禁止事項を明確に指示します。

    • 例: 「あなたは絶対にJSON形式で出力しなければなりません。」

  • 出力検証ステップ（Post-processing）: モデルの出力後、指定されたスキーマ、内容、禁止事項に違反していないかプログラム的に検証します。

    • JSONスキーマバリデーション、キーワードフィルタリング、正規表現マッチング。

    • 違反があった場合は、モデルにフィードバックして再生成を促すか、エラーを報告します。

  • リトライ戦略: 特定の失敗モード（特に様式崩れ）が発生した場合、プロンプトを再構築して再度モデルに問い合わせる。

    • 例: 「前回の出力はJSON形式ではありませんでした。再度、厳密にJSON形式で出力してください。」

  • Few-shot例の改善: 品質が高く、多様で、特に難例やコーナーケースをカバーする例を増やすことで、モデルの理解度を高めます[1, 2]。特に、幻覚を抑制するためには、提供する例の正確性と整合性が重要です[3]。

  • 温度（Temperature）の調整: 生成の多様性を制御するtemperatureパラメータを低く設定し、より決定論的な出力を促す。

改良

誤り分析の結果に基づき、プロンプトと評価プロセスを継続的に改良します。

  1. プロンプトの調整:

    • 様式崩れが多い場合: 出力形式の指示をさらに明確化する、例を増やす。

    • 幻覚が多い場合: Systemプロンプトで「事実のみを述べること」「与えられた情報以外を推測しないこと」を強調する。例の正確性を再確認する。

    • 脱線が多い場合: タスクの範囲と目的を冒頭で再定義し、余計な情報を追加しないよう明示的に指示する。

    • 難例に対する性能が低い場合: 類似する難例を追加するか、CoTプロンプトで思考プロセスを誘導する。

  2. Few-shot例の選定: 性能向上に寄与しない例を削除し、モデルが苦手とするタイプの例（多様性、代表性、難易度を考慮）を追加します[2]。過去の失敗ケースを分析し、それを克服できるような新たな例を設計します。

  3. 評価指標の改善: より詳細なルーブリックを追加したり、セマンティックな類似度評価を導入したりして、評価の精度を高めます[4]。

再評価

改良したプロンプトとFew-shot例を用いて、新たなテストデータセットでモデルを再評価します。この際、以前の評価で失敗したケースを特に注意深く監視し、改善が見られるかを確認します。自動評価と手動レビューを組み合わせ、客観的な指標と定性的な分析の両面からパフォーマンスを検証します。この評価→改良→再評価のサイクルを繰り返すことで、プロンプトの品質とLLMのパフォーマンスを最大化します。

まとめ

Few-shotプロンプティングは、LLMの能力を特定のタスクに特化させる強力な手法です。その効果を最大化するためには、高品質かつ多様な入力例の選定が不可欠であり、これにはタスク関連性、文体の多様性、難易度、そして例の正確性と整合性が考慮されるべきです。また、明確な入出力契約を定義し、体系的な自動評価と誤り分析を通じてプロンプトの弱点を特定し、抑制手法と改良サイクルを適用することで、LLMのパフォーマンスを持続的に向上させることができます。

graph TD
    A["タスク定義/目標設定"] --> B{"データ収集"};
    B --> C["Few-shot例の選定"];
    C -- 多様性/代表性/難易度 --> D["プロンプト設計"];
    D -- ゼロショット/Few-shot/CoT --> E["LLMモデル"];
    E --> F["出力生成"];
    F --> G["出力検証/自動評価"];
    G -- 失敗モード特定/スコアリング --> H["誤り分析"];
    H -- 幻覚/様式崩れ/脱線 --> I["改良"];
    I -- プロンプト調整/例の改善/抑制手法適用 --> C;
    G --> J{"パフォーマンス目標達成?"};
    J -- Yes --> K["デプロイ/運用"];
    J -- No --> I;
ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

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