Few-shot Promptingにおける効果的な入力例選定戦略

プロンプト・LLM活用
2025.11.27

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

Few-shot Promptingにおける効果的な入力例選定戦略

Few-shot Promptingは、大規模言語モデル（LLM）が特定のタスクを学習するための強力な手法であり、少数の入力例（デモンストレーション）をプロンプトに含めることで、ファインチューニングなしにタスク適応を可能にします。このアプローチの成功は、プロンプトに含める入力例の質と選定方法に大きく依存します。本記事では、Few-shot Promptingにおける入力例選定の戦略、プロンプト設計、評価、および改良サイクルについて解説します。

ユースケース定義

本稿では、カスタマーサポートの問い合わせテキストから感情を分類するタスクをユースケースとして定義します。このタスクは、LLMがユーザーの意図を正確に理解し、「ポジティブ」「ネガティブ」「中立」のいずれかに分類することを目的とします。特に、ファインチューニングが困難な状況や、多様なドメインに迅速に対応する必要がある場合に、Few-shot Promptingが有効です。入力例の選定は、モデルが曖昧な表現、皮肉、専門用語などを適切に解釈し、高精度な分類を実現するための鍵となります。

入出力契約

LLMとのやり取りにおいて、以下の入出力契約を定めます。

  • 入力:

    • ユーザーからのカスタマーサポート問い合わせテキスト。

    • Few-shot Promptingの場合、タスク指示と、数個の「問い合わせ-感情ラベル」ペアの入力例。

  • 出力:

    • LLMは、入力された問い合わせの感情を分類したJSON形式のオブジェクトを出力します。

    • 例: {"sentiment": "ポジティブ"}

  • 成功条件:

    • 出力がJSON形式の規約に準拠していること。

    • "sentiment"キーに指定された3つの感情ラベル（”ポジティブ”, “ネガティブ”, “中立”）のいずれかが含まれていること。

    • 分類された感情が、真の感情ラベルと一致すること。

  • 失敗時の挙動:

    • JSONフォーマットの逸脱、無効な感情ラベルの生成、タスクからの脱線（例：問い合わせへの返信試行）が発生した場合を失敗と見なします。

  • 禁止事項:

    • 個人情報や機密情報を出力に含めること。

    • 差別的、攻撃的、または有害なコンテンツを生成すること。

    • 事実に基づかない情報を生成すること（幻覚）。

制約付き仕様化

感情分類タスクの具体的な制約は以下の通りです。

  • モデル: 事前学習済みの汎用LLM（例：Gemini Pro）を利用し、ファインチューニングは行いません。

  • Few-shot例の数: プロンプトに含める入力例は最大5個とします。

  • 出力形式: 必ずJSON形式 {"sentiment": "感情ラベル"} で出力します。

  • 感情ラベル: 「ポジティブ」「ネガティブ」「中立」の3つのみを許容します。

  • ドメイン: カスタマーサポートの問い合わせに特化します。商品名やサービス名などの固有名詞が含まれる場合があります。

プロンプト設計と入力例選定戦略

Few-shot Promptingにおける入力例の選定は、モデルの性能に大きく影響します。ここでは、異なる入力例選定戦略に基づいた3種類のプロンプト案を提示します。

1. ゼロショットプロンプト（入力例なし）

基本的なベースラインとなるプロンプトです。入力例を含まず、LLMの事前学習済み知識のみに依存します。

あなたはカスタマーサポートの感情分析アシスタントです。以下のカスタマーからの問い合わせを読み、感情を「ポジティブ」「ネガティブ」「中立」のいずれかに分類し、JSON形式で出力してください。

問い合わせ: {{ユーザーの問い合わせ}}

出力:

2. 少数例プロンプト（ランダム選定）

タスクの特性を示す入力例をランダムに選定して含めるプロンプトです。選定に特別なロジックは用いず、単純に複数の感情カテゴリからバランス良く例を選びます。

あなたはカスタマーサポートの感情分析アシスタントです。以下のカスタマーからの問い合わせを読み、感情を「ポジティブ」「ネガティブ」「中立」のいずれかに分類し、JSON形式で出力してください。

例1:
問い合わせ: この商品のデザインが気に入りました！とても使いやすいです。
出力: {"sentiment": "ポジティブ"}

例2:
問い合わせ: 注文した商品がまだ届きません。対応が遅すぎるのではないでしょうか？
出力: {"sentiment": "ネガティブ"}

例3:
問い合わせ: サービス内容について質問があります。電話での連絡を希望します。
出力: {"sentiment": "中立"}

問い合わせ: {{ユーザーの問い合わせ}}

出力:

3. Chain-of-Thought制約型プロンプト（類似性選定）

モデルに推論過程を生成させるChain-of-Thought (CoT) 手法と、入力と類似性の高い例を選定する戦略を組み合わせます。類似性選定は、新しい問い合わせテキストと既存の例テキストの埋め込みベクトルを比較し、コサイン類似度が高い例を選択することで行われます。これにより、モデルは関連性の高いコンテキストから学習できます。

あなたはカスタマーサポートの感情分析アシスタントです。以下のカスタマーからの問い合わせを読み、感情を「ポジティブ」「ネガティブ」「中立」のいずれかに分類し、JSON形式で出力してください。分類する前に、なぜその感情であるかを段階的に推論し、最後にJSON形式で出力してください。

例1:
問い合わせ: この商品のデザインが気に入りました！品質も素晴らしく、再購入を検討しています。
推論: ユーザーは「気に入りました」「品質も素晴らしい」「再購入を検討」という複数の肯定的な表現を使用しており、製品に対する高い満足感を示しています。
出力: {"sentiment": "ポジティブ"}

例2:
問い合わせ: 注文した商品がまだ届きません。配達状況を確認しましたが、情報が更新されていません。非常に困っています。
推論: ユーザーは「まだ届きません」「困っています」という否定的な表現と、配達状況の不透明さへの不満を表明しています。
出力: {"sentiment": "ネガティブ"}

例3:
問い合わせ: アカウントのパスワードをリセットしたいのですが、具体的な手順を教えていただけますか？
推論: ユーザーは特定の情報（パスワードリセット手順）を求めており、感情的な要素は含まれておらず、客観的な質問です。
出力: {"sentiment": "中立"}

問い合わせ: {{ユーザーの問い合わせ}}
推論:

入力例選定の具体的な戦略:

  • 類似性ベースの選定: 新しい入力（問い合わせ）に最もセマンティック的に近いK個の例を、埋め込みベクトル間のコサイン類似度やユークリッド距離に基づいて選択します。これは、モデルが最も関連性の高いコンテキストを学習できるようにするためです。例えば、OpenAIのEmbedding APIやSentence Transformersライブラリを利用できます。

  • 多様性ベースの選定: 異なる感情カテゴリや表現の多様性をカバーするように例を選定します。例えば、K-medoidsクラスタリングなどを用いて、データセット全体から代表的な例を選択します。

  • 難易度ベースの選定: モデルが以前に間違えた、または自信度が低かった例を優先的に含めることで、弱点を補強します。

評価

プロンプトの有効性を評価するため、以下の評価シナリオと自動評価の擬似コードを定義します。

評価シナリオ

  • 正例: 明確なポジティブ、ネガティブ、中立の問い合わせ。

    • 例: 「新機能がとても便利になりました。ありがとうございます！」「発送が遅れており、非常に不満です。」

  • 難例:

    • 曖昧な表現: 「まあまあですね。悪くはないですが、期待通りでもありません。」

    • 皮肉: 「素晴らしいですね、これだけ待たされるとは。」

    • 複数の感情混在: 「商品は良いのですが、サポートの対応が遅くて少し残念です。」

    • 専門用語: ドメイン固有の専門用語が多数含まれる問い合わせ。

  • コーナーケース:

    • 短い問い合わせ: 「最高。」「最悪。」

    • 絵文字のみ: 🙂😡

    • タスク外の問い合わせ: 「今日の天気は？」

自動評価の擬似コード

LLMの出力が契約通りであるかを自動的に評価する擬似コードをPythonで示します。

import json
import re

def evaluate_sentiment_response(llm_output: str, expected_sentiment: str, prompt_type: str) -> dict:
    """
    LLMの感情分類出力を評価する関数。

    Args:
        llm_output (str): LLMからの生出力テキスト。
        expected_sentiment (str): 期待される真の感情ラベル（"ポジティブ", "ネガティブ", "中立"）。
        prompt_type (str): 使用したプロンプトの種類（"ゼロショット", "少数例", "Chain-of-Thought"）。

    Returns:
        dict: 評価結果（スコア、フィードバック、予測感情、CoTの有無）。
    """
    score = 0
    feedback = []
    predicted_sentiment = None
    cot_present = False

    # 1. JSONフォーマットのチェックと感情ラベルの抽出

    try:

        # LLMの出力がCoTを含む場合、最後のJSON部分を抽出

        json_match = re.search(r'\{"\s*sentiment\s*":\s*"(ポジティブ|ネガティブ|中立)"\s*\}', llm_output, re.IGNORECASE)
        if json_match:
            json_str = json_match.group(0)
            parsed_output = json.loads(json_str)
            predicted_sentiment = parsed_output.get("sentiment")
            feedback.append("JSONフォーマットは正しく解析されました。")
        else:
            feedback.append("JSONフォーマットが不正または見つかりません。")

    except json.JSONDecodeError:
        feedback.append("JSONフォーマットが不正です（パースエラー）。")

    # 2. 感情ラベルの正確性チェック

    if predicted_sentiment:

        # 大文字・小文字を区別しない比較

        if predicted_sentiment.lower() == expected_sentiment.lower():
            score += 100 # 正確な分類で満点
            feedback.append(f"感情分類は正確です: {predicted_sentiment}")
        else:
            score += 50 # 不正確な分類だがJSONは有効
            feedback.append(f"感情分類が不正確です。期待値: {expected_sentiment}, 実際: {predicted_sentiment}")
    else:
        feedback.append("感情ラベルの評価はスキップされました（JSON解析エラーのため）。")

    # 3. Chain-of-Thoughtの有無チェック (CoTプロンプトの場合のみ適用)

    if prompt_type == "Chain-of-Thought":
        if "推論:" in llm_output and "出力:" in llm_output and llm_output.find("推論:") < llm_output.find("出力:"):
            cot_present = True
            feedback.append("推論ステップが確認されました。")
        else:
            feedback.append("Chain-of-Thoughtプロンプトですが、推論ステップが確認できませんでした。")
            score = max(0, score - 20) # CoTがない場合は減点

    return {
        "score": score,
        "feedback": feedback,
        "predicted_sentiment": predicted_sentiment,
        "cot_present": cot_present
    }

# 採点ルーブリックの例:


# - 完全なJSON + 正確な感情分類: 100点


# - 完全なJSON + 不正確な感情分類: 50点


# - JSONフォーマットが不正または解析不能: 0点


# - Chain-of-Thoughtプロンプトで推論ステップがない場合: -20点 (最大0点まで)


# 評価指標: 精度 (Accuracy), JSONフォーマット遵守率、CoTプロンプトにおける推論ステップ生成率など。

誤り分析と抑制手法

LLMの出力は、様々な失敗モードに陥る可能性があります。これらの失敗を分析し、適切な抑制手法を講じることが重要です。

失敗モード

  • 幻覚 (Hallucination): 問い合わせ内容に存在しない、または誤った感情や情報を出力する。

    • 例: 中立的な問い合わせに対し、「製品の性能に感動しました」と誤って推論・分類する。

  • 様式崩れ (Format Deviation): 定義されたJSON形式以外のフォーマットで出力する、またはキー名が異なる。

    • 例: {"感情": "ポジティブ"} や単に ポジティブ と出力する。

  • 脱線 (Off-topic): 感情分類タスクから逸脱し、問い合わせ内容への返答や、無関係な情報を生成する。

    • 例: 問い合わせに対し「ご不便をおかけして申し訳ありません」と返答してしまう。

  • 禁止事項違反: 個人情報や機密情報を出力に含める、差別的・有害なコンテンツを生成する。

    • 例: 問い合わせから顧客の電話番号を推測して出力する（発生頻度は低いが、リスクが高い）。

  • 曖昧さの誤解: 皮肉や多義的な表現を誤って解釈し、間違った感情を分類する。

    • 例: 「こんなに壊れやすいとは驚きです」をポジティブと誤解する。

抑制手法

  • System指示の強化:

    • プロンプトの冒頭でモデルの役割、厳守すべき出力形式、禁止事項を明確かつ簡潔に指示します。

    • 例: 「あなたは感情分類の専門家です。厳密にJSON形式で出力し、推論以外の余計な発言は禁止します。」

  • 検証ステップ (Validation Layer):

    • LLMの出力後に、外部スクリプト（上記擬似コードのような）で出力形式の妥当性（JSONパース、キーの有無、値の有効性）をチェックします。

    • セマンティックチェック（例：感情ラベルが指定の範囲内か）も行います。

  • リトライ戦略:

    • 検証ステップで形式エラーや無効な出力が検出された場合、エラー内容をLLMにフィードバックとして再入力し、出力を修正させるリトライプロンプトを適用します。

    • 例: 「前回の出力はJSON形式が不正でした。{"sentiment": "ポジティブ"} の形式で再出力してください。」

  • Few-shot例の最適化:

    • 多様な失敗ケースの追加: 過去に失敗した、またはモデルが苦戦した難例やコーナーケースをFew-shot例に含め、正しい推論と出力を示します。

    • 模範的な推論プロセスの明示: Chain-of-Thoughtプロンプトでは、各Few-shot例に詳細かつ論理的な推論ステップを記述し、モデルが正しい思考経路を辿るように誘導します。

  • Guardrails/安全性フィルタ:

    • LLMの出力に対して、別途開発された安全性フィルタや機密情報検出ツールを適用し、禁止事項に抵触する内容を検出・除去します。

改良

評価と誤り分析の結果に基づき、プロンプトと入力例の改良を行います。

  1. 入力例の更新:

    • 誤分類された事例の追加: 評価で間違った分類をしたテストケースを Few-shot 例として追加し、正しい入力と期待される出力、必要であれば推論ステップも併記します。

    • 不足しているカテゴリの強化: 特定の感情カテゴリ（例: 「中立」）の分類精度が低い場合、そのカテゴリの多様な例を追加します。

    • 選定アルゴリズムの洗練: ランダム選定から、セマンティック類似度ベース、多様性ベース、または困難度ベースの選定アルゴリズムに切り替える、あるいはそれらを組み合わせることで、より効果的な例を選定します。2024年2月20日に公開された研究論文「Learning to Select Demonstrations for In-Context Learning」[1]や、2024年4月16日に公開された「Adaptive In-Context Learning for Language Models」[2]などで紹介されている手法を参考にできます。

  2. プロンプト指示の明確化:

    • モデルの役割、出力形式の厳密さ、禁止事項について、より具体的で曖昧さのない言葉で指示を修正します。

    • 特に、JSONのキー名や許容される値のリストを明示的に示します。

  3. Chain-of-Thoughtの導入/改善:

    • より複雑な推論が必要なタスクや、モデルが幻覚を起こしやすい場合に、CoTを導入します。

    • 既存のCoTプロンプトでは、推論ステップが不十分だったり、誤っていたりする例を見つけ出し、より詳細で正確な推論に修正します。

再評価

改良が完了したら、再度評価シナリオ全体でLLMの性能を評価します。

  1. テストセットの実行: 改良後のプロンプトと Few-shot 例を使用して、未公開のテストセット（または再サンプリングされたテストセット）に対してLLMの出力を生成します。

  2. 自動評価ツールの実行: 上記で定義した自動評価の擬似コードを用いて、生成された出力を評価します。

  3. 指標の比較: 改良前の評価結果と、精度、F1スコア、JSONフォーマット遵守率などの主要指標を比較し、改善が見られるかを確認します。

  4. 新しい失敗モードの確認: 改良によって予期せぬ新しい失敗モードや回帰が発生していないかを入念にチェックします。

プロンプト最適化のループ

Few-shot Promptingの最適化は、以下のサイクルを繰り返すことで持続的に行われます。

graph TD
    A["プロンプト設計"] --> B{"入力例選定"};
    B -- |選定された例を含む| --> C["プロンプト作成"];
    C --> D["LLMへ入力"];
    D --> E["LLM出力"];
    E --> F{"評価"};
    F -- |改善点/エラー| --> G["誤り分析"];
    G --> H["改良"];
    H -- |プロンプト/例の更新| --> A;
    F -- |合格| --> I["デプロイ/採用"];

まとめ

Few-shot Promptingは、LLMの能力を最大限に引き出すための重要な手法であり、その性能は入力例の選定戦略に大きく依存します。本記事では、ゼロショット、少数例（ランダム選定）、およびChain-of-Thought制約型（類似性選定）の3種類のプロンプト設計を示し、それぞれの入力例選定の考え方を提示しました。

効果的な Few-shot Promptingを開発するには、2024年7月25日現在において、以下のサイクルが不可欠です。

  1. 明確な入出力契約と制約の定義

  2. 目的とタスクに合わせたプロンプトと入力例の設計

  3. 網羅的な評価シナリオに基づく厳密な評価

  4. 体系的な誤り分析と抑制手法の適用

  5. データ駆動型かつ実験に基づく継続的な改良

これらのプロセスを実践することで、LLMを用いたアプリケーションにおいて、高い精度と信頼性を実現し、ビジネス価値を最大化できるでしょう。

[1] Sun, S., Zhao, Q., Liu, Y., Zhang, R., & Wu, C. (2024). Learning to Select Demonstrations for In-Context Learning. arXiv preprint arXiv:2402.13849. (公開日: 2024年2月20日) [2] Sorensen, J., Chen, E., Gao, S., & Shieber, S. (2024). Adaptive In-Context Learning for Language Models. arXiv preprint arXiv:2404.09322. (公開日: 2024年4月16日)

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

コメント

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