翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

高度なトピックと戦略

このページのトピック

マルチオブジェクト最適化

高度なプロンプト最適化では、実行ごとに 1 つのメトリクス、つまりサンプルごとに 1 つのスカラースコアを使用できます。ただし、マルチオブジェクト (多次元) 最適化を暗黙的にサポートしています。複数の目標を 1 つのスカラー (複合メトリクス) にバンドルでき、サービスはそのバンドルに対してプロンプトを最適化します。このセクションでは、推奨されるパターン、それぞれが適切な場合、および注意すべき障害モードについて説明します。

これは、精度 + トーン、ツールコールの正確性 + 安全性、忠実度 + 簡潔性、レイテンシーフレンドリ性 + 完全性など、複数のモノを同時に重視するあらゆる業種に適用されます。

1 つのメトリクスが実際にマルチオブジェクトである理由

システムに関する 2 つの事実により、この作業が行われます。

したがって、「実行ごとに 1 つのメトリクス」はシグナルシェイプに関する契約であり、最適化できるものの制限ではありません。

複数の目標を 1 つのメトリクスにバンドルするパターン

目標の相互関係に基づいて 1 つ選択します。

パターン 1 — 加重合計 (最も一般的)

final = w₁·s₁ + w₂·s₂ + ... + wₖ·sₖ。重みの合計は 1 です。

使用するタイミング: 目標はほぼ独立しており、ランク付けできます。トレードオフは許容されます。合計が上がれば、別の を犠牲にして改善しても問題ありません。

重みの選択:

例 (エージェント/ツールの使用):

final = 0.5 * tool_correctness + 0.3 * answer_correctness + 0.2 * format_compliance

パターン 2 — ハードフェイルゲート (安全重要)

1 つ以上のゲート目標を定義します。ゲートが失敗した場合、残りのゲートに関係なくスコアは 0 (または床) になります。それ以外の場合、スコアは残りの目標の加重合計です。

if not safety_check_passed:
    return 0.0
if wrong_tool_called_for_destructive_action:
    return 0.0
return 0.6 * accuracy + 0.4 * tone

使用するタイミング: 少なくとも 1 つの目標が交渉不可能 (PII リーク、間違ったアカウント変更、refusal-on-prohibited-content。これは、「平均して良い」プロンプトが安全バーに時折失敗した場合に受け入れられない場合に使用します。

これが単なる重み付けに勝る理由: 重みだけで、オプティマイザは安全性を品質と交換しながら、スコアを丘陵に登ることができます。ゲートは、構築によってトレードオフを不可能にします。

パターン 3 — 制約 + 報酬 (パレートスタイル)

報酬として最も重要な目標を選択します。残りの部分を制約として表現し、違反した場合は (ゼロにするのではなく) 報酬から減算します。

reward = task_accuracy
penalty = 0.0
if response_too_long:
    penalty += 0.1
if missed_required_disclosure:
    penalty += 0.2
return max(0.0, reward - penalty)

使用するタイミング: 1 つの主要目的を先導したいが、ソフトセカンダリ目的はプロンプトを形作る必要があります。ハードゲートよりも脆弱で、加重合計よりもあいまいではありません。

パターン 4 — Lambda 外部、LLM-as-a-Judge 内部 (あいまい + 構造ミックスに推奨)

Lambda メトリクスは、決定的なサブスコア (regex、JSON 解析、スキーマ検証) を計算し、LLM-as-a-Judge サブ評価を呼び出して、Lambda 関数内のあいまいな部分 (トーン、忠実度、有用性) を評価します。次に、それらを 1 つのスカラーに集約します。

def compute_score(prompt, prediction, gold, ...):
    structural = grade_format_and_tools(prediction)        # 0..1 from regex
    semantic   = call_llm_judge(prediction, gold, criteria) # 0..1 from LLMJ
    if structural < 1.0 and is_safety_critical(prompt):
        return 0.0
    return 0.6 * semantic + 0.4 * structural

使用するタイミング: 目標は、「コードでテストしやすい」 (形式、ツール名、長さ、引用の有無) と「判断するモデルが必要」 (トーン、忠実さ、有用性) を混在させます。これは、決定論的な部分がrun-to-runをドリフトしないため、1 つの LLM-as-a-Judge プロンプトに 1 つの複合スコアを生成するように求めるよりも簡単です。

パターン 5 — 多次元 LLM-as-a-Judge (Lambda なし)

組み込みの LLM-as-a-Judge フローを使用し、オプションで独自のディメンションと重みcustomLLMJConfig.customLLMJPromptを定義する を使用します。審査員は、ディメンションごとのスコアと を発行しますOverall。システムは、[0, 1] スカラーに解析 Overall (または欠落している場合はディメンションの平均化) Overallします。

使用するタイミング: すべての目標はセマンティック/あいまいであり、決定的なサブチェックはありません。最速で作成できます。判断分散に注意する — 同じデータセットを 2 回再実行し、スコアの安定性を確認してから、最適化シグナルとして信頼します。

パターンの選択

パターンを組み合わせることができます。一般的な本番メトリクスは、「加重合計 + 安全上のハードフェイルゲート」です。

監視する障害モード

起動前チェックリスト

マルチターンプロンプトとステージングプロンプトの最適化

高度なプロンプト最適化は、サンプルごとの評価に対して単一のプロンプトテンプレートを最適化します。ネイティブにターンアウェアではありません。ダイアログを反復したり、特定のターンで動作を最適化したりすることはできません。ステージングされたプロンプトは、複数ターンの会話またはワークフローが同じプロンプトをターン間で再利用し、プロンプト自体にワークフローの各ステージ、ステップ、またはフェーズの手順が含まれるプロンプトテンプレートです。これらのプロンプトを最適化するには、ダイアログの状態をテンプレートの入力変数にフラット化し、 に絞り込むシステム指示をベイクしpromptTemplate、サンプルごとのリファレンスレスポンスで実際に注意するターンを調べます。

このパターンは垂直に依存しません。これは、カスタマーサービスフロー、エージェントツール使用ループ、マルチステップ推論、チュートリアル、コードアシストターン、ドキュメントベースの QA、トリアージワークフローなど、増大するコンテキストでモデルが繰り返し呼び出されるあらゆる場所に適用されます。

高度なプロンプト最適化が実際に最適化するもの

最適化が必要なものは、それpromptTemplate自体の内部に存在する必要があります。サンプルごとに異なるモノ (会話履歴、現在のユーザークエリ、取得されたコンテキスト) は です{{variables}}。絞り込むシステム指示はテンプレートの一部です。入力変数ではないか、サービスに書き換えるものはありません。

サービスでターン N 時の動作を改善したい場合は、ターン N を 1 つのサンプルのレンダリングされた prompt-plus-input-variables として表現し、それを目的のターン N モデル出力referenceResponseにします。

パターン A — Stage-at-a-time (推奨スターター)

ダイアログの 1 つのフェーズを一度に最適化します。各評価サンプルは、そのフェーズ内の単一の決定ポイントを表します。

ここで「ステージ」とは、一貫した一連の成功基準で説明できるものです。垂直方向の例:

パターン A を使用するタイミング

テンプレートシェイプ

ステージ固有のシステム手順がテンプレートにベイクされます (これはサービスが書き換えるものです）。会話履歴と現在のターンのみが変数です。以下の構造は説明用であり、規定されていません。モデルが最適に処理する区切り文字またはレイアウトを使用します。唯一の要件は、(a) テンプレート内で最適化するシステム手順、および (b) サンプルごとの変数は として参照されます{{variablename}}。

You are an assistant in the {STAGE_NAME} phase of a multi-turn task.
- ...the policy / goals / format / tool-use rules for this phase...
- ...constraints the model must satisfy at this point in the conversation...

Conversation so far:
{{conversation_so_far}}

User's current message:
{{user_query}}

サンプルシェイプ

{
    "inputVariables": [
        {"conversation_so_far": "user: ...\nassistant: ...\n... (turns 1..N-1)"},
        {"user_query": "...the user input that triggers this stage..."}
    ],
    "referenceResponse": "...the assistant output that satisfies the stage's success criteria..."
}

メリットとデメリット

長所: 厳密なフィードバックシグナル、小さなプロンプト、より高速な最適化の実行、焦点を絞ったメトリクスの作成が容易です。

短所: ステージ間のドリフトをキャッチしません。ステージごとに 1 回サービスを実行するため、最終的な統合テストが必要になる場合があります。

パターン B — 完全に平坦化された会話 (高度)

マルチステージポリシー全体を所有する 1 つの大きなモノリシックプロンプトを最適化します。各サンプルは、プローブターンまでの完全なダイアログです。

パターン B を使用するタイミング

テンプレートシェイプ

完全なモノリシック多相システムプロンプトは、文字通りテンプレート内に配置されます。サービスは、最適化中にこの本文を書き換えます。履歴と現在のターンは変数のままです。モデルが適切に処理するレイアウトを選択します。要件は、最適化する手順がテンプレートの一部であり、サンプルごとのデータが を介して参照されることのみです{{name}}。

You are an assistant for {TASK}. The conversation may proceed through phases:
1. {PHASE_1} — ...
2. {PHASE_2} — ...
3. {PHASE_3} — ...
(...the entire multi-phase policy, tool-use rules, tone, formatting, refusal rules...)

Conversation so far (turns 1..N-1, with role tags):
{{conversation_so_far}}

User's current message:
{{user_query}}

サンプルシェイプ (任意のターン N でプローブ)

{
    "inputVariables": [
        {"conversation_so_far": "user: ...\nassistant: ...\n[tool_call: X(...)]\n... (turns 1..N-1)"},
        {"user_query": "...the user input at turn N..."}
    ],
    "referenceResponse": "...desired assistant output at turn N..."
}

パターン B がパターン A よりもうまく機能する理由

パターン B の注意事項

特定のターンでのツールコールの検証

サービスにはアシスタントのテキスト出力が表示されます。「モデル呼び出しツール X を右の引数で N 番にランク付けした」には、いずれかを選択します。

多くのターンまたは多くのサブチェック (ツールの正確性とトーンと完全性) にわたる複合基準については、マルチオブジェクト最適化「」セクションを参照してください。

推奨パス

マルチターンに高度なプロンプト最適化を使用しない場合

スターターチェックリスト