prompt-engineering

プロンプトエンジニアリングのパターン

LLM のパフォーマンス、信頼性、制御性を最大化するための高度なプロンプトエンジニアリング技法です。

中核となる機能

1. Few-Shot Learning

ルールを説明するのではなく、例を示してモデルに学習させます。望ましい動作を示す入力と出力のペアを 2〜5 組含めてください。一貫したフォーマット、特定の推論パターン、エッジケースへの対応が必要な場合に使用します。例を増やすと精度は向上しますが、トークンを多く消費するため、タスクの複雑さに応じてバランスを取ってください。

例:

Extract key information from support tickets:

Input: "My login doesn't work and I keep getting error 403"
Output: {"issue": "authentication", "error_code": "403", "priority": "high"}

Input: "Feature request: add dark mode to settings"
Output: {"issue": "feature_request", "error_code": null, "priority": "low"}

Now process: "Can't upload files larger than 10MB, getting timeout"

2. Chain-of-Thought Prompting

最終的な回答の前に、段階的な推論を求めます。ゼロショットの場合は「Let's think step by step」を追加し、Few-Shot の場合は推論の例を含めます。多段階の論理を必要とする複雑な問題、数学的推論、またはモデルの思考過程を検証したい場合に使用します。分析系のタスクで精度が 30〜50% 向上します。

例:

Analyze this bug report and determine root cause.

Think step by step:

1. What is the expected behavior?
2. What is the actual behavior?
3. What changed recently that could cause this?
4. What components are involved?
5. What is the most likely root cause?

Bug: "Users can't save drafts after the cache update deployed yesterday"

3. Prompt Optimization

テストと改良を通じてプロンプトを体系的に改善します。まずはシンプルに始め、パフォーマンス(精度、一貫性、トークン使用量)を計測してから反復します。エッジケースを含む多様な入力でテストしてください。A/B テストを使って変更案を比較します。一貫性とコストが重要な本番用プロンプトでは不可欠です。

例:

Version 1 (Simple): "Summarize this article"
→ Result: Inconsistent length, misses key points

Version 2 (Add constraints): "Summarize in 3 bullet points"
→ Result: Better structure, but still misses nuance

Version 3 (Add reasoning): "Identify the 3 main findings, then summarize each"
→ Result: Consistent, accurate, captures key information

4. Template Systems

変数、条件付きセクション、モジュール化されたコンポーネントを用いて、再利用可能なプロンプト構造を構築します。マルチターンの会話、ロールベースのやり取り、または同じパターンを異なる入力に適用する場合に使用します。重複を減らし、類似したタスク間での一貫性を確保できます。

例:

# Reusable code review template
template = """
Review this {language} code for {focus_area}.

Code:
{code_block}

Provide feedback on:
{checklist}
"""

# Usage
prompt = template.format(
    language="Python",
    focus_area="security vulnerabilities",
    code_block=user_code,
    checklist="1. SQL injection\n2. XSS risks\n3. Authentication"
)

5. System Prompt Design

会話全体を通して持続する、グローバルな動作と制約を設定します。モデルの役割、専門知識のレベル、出力フォーマット、安全性に関するガイドラインを定義します。ターンごとに変わるべきではない安定した指示にはシステムプロンプトを使用し、ユーザーメッセージのトークンを可変のコンテンツに充てられるようにします。

例:

System: You are a senior backend engineer specializing in API design.

Rules:

- Always consider scalability and performance
- Suggest RESTful patterns by default
- Flag security concerns immediately
- Provide code examples in Python
- Use early return pattern

Format responses as:

1. Analysis
2. Recommendation
3. Code example
4. Trade-offs

主要なパターン

Progressive Disclosure

シンプルなプロンプトから始め、必要な場合にのみ複雑さを加えます:

1. レベル 1: 直接的な指示

   • 「この記事を要約してください」

2. レベル 2: 制約を追加

   • 「この記事を、主要な発見に焦点を当てて 3 つの箇条書きで要約してください」

3. レベル 3: 推論を追加

   • 「この記事を読み、主要な発見を特定してから、3 つの箇条書きで要約してください」

4. レベル 4: 例を追加

   • 入力と出力のペアからなる要約の例を 2〜3 個含めます

Instruction Hierarchy

[System Context] → [Task Instruction] → [Examples] → [Input Data] → [Output Format]

Error Recovery

失敗を適切に処理できるプロンプトを構築します:

• フォールバックの指示を含める
• 確信度スコアを求める
• 不確かな場合は別の解釈を尋ねる
• 情報が不足している場合の示し方を指定する

ベストプラクティス

1. 具体的にする: 曖昧なプロンプトは一貫性のない結果を生みます
2. 説明するより示す: 例は説明文よりも効果的です
3. 十分にテストする: 多様で代表的な入力で評価します
4. 素早く反復する: 小さな変更が大きな影響を与えることがあります
5. パフォーマンスを監視する: 本番環境でメトリクスを追跡します
6. バージョン管理する: プロンプトを適切なバージョニングを施したコードとして扱います
7. 意図を文書化する: プロンプトをそのような構造にしている理由を説明します

よくある落とし穴

• 過剰な設計: シンプルなプロンプトを試す前に複雑なプロンプトから始めてしまうこと
• 例の汚染: 対象タスクに合わない例を使用すること
• コンテキストのオーバーフロー: 例を過剰に用いてトークン上限を超えること
• 曖昧な指示: 複数の解釈の余地を残してしまうこと
• エッジケースの無視: 異常な入力や境界的な入力でテストしないこと