翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 高度なトピックと戦略
## このページのトピック
+ [マルチオブジェクト最適化](#advanced-prompt-optimization-multi-objective)
+ [マルチターンプロンプトとステージングプロンプトの最適化](#advanced-prompt-optimization-multi-turn)
## マルチオブジェクト最適化
高度なプロンプト最適化では、実行ごとに 1 つのメトリクス、つまりサンプルごとに 1 つのスカラースコアを使用できます。ただし、マルチオブジェクト (多次元) 最適化を暗黙的にサポートしています。複数の目標を 1 つのスカラー (複合メトリクス) にバンドルでき、サービスはそのバンドルに対してプロンプトを最適化します。このセクションでは、推奨されるパターン、それぞれが適切な場合、および注意すべき障害モードについて説明します。
これは、精度 \+ トーン、ツールコールの正確性 \+ 安全性、忠実度 \+ 簡潔性、レイテンシーフレンドリ性 \+ 完全性など、複数のモノを同時に重視するあらゆる業種に適用されます。
### 1 つのメトリクスが実際にマルチオブジェクトである理由
システムに関する 2 つの事実により、この作業が行われます。
+ **メトリクスは、サンプルごとに 1 つの浮動小数点値を返します。**最適化フィードバックループは、このスカラーを最適化シグナルとして読み取ります。これは、内部の任意の数のサブスコアから計算できます。
+ **両方のメトリクスバックエンドは、サブスコアを内部で既に集計しています。**
+ デフォルトの LLM-as-a-Judge テンプレートは、3 つのディメンション (回答精度、回答完全性、式品質) で評価され、重みを割り当て、[0, 1] に正規化された単一の`Overall`スコアを出力します。カスタム条件は同じスカラーにマージされます。詳細については、「[カスタム LLM-as-a-judge](advanced-prompt-optimization-evaluation.md#advanced-prompt-optimization-evaluation-llmj)」を参照してください。
+ Lambda / カスタムコードメトリクスは 1 つの数値を返し、サブオブジェクトの複合を含む、その計算方法を制御できます。
したがって、「実行ごとに 1 つのメトリクス」はシグナルシェイプに関する契約であり、最適化できるものの制限ではありません。
### 複数の目標を 1 つのメトリクスにバンドルするパターン
目標の相互関係に基づいて 1 つ選択します。
#### パターン 1 — 加重合計 (最も一般的)
`final = w₁·s₁ + w₂·s₂ + ... + wₖ·sₖ`。重みの合計は 1 です。
**使用するタイミング:** 目標はほぼ独立しており、ランク付けできます。トレードオフは許容されます。合計が上がれば、別の を犠牲にして改善しても問題ありません。
**重みの選択:**
+ データセット内の頻度ではなく、ユーザーにとって重要な重み。
+ 粗い開始: `0.5 / 0.3 / 0.2` 問題ありません。重みをオーバーチューニングしないでください。これは別の最適化の問題です。
**例 (エージェント/ツールの使用):**
```
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 回再実行し、スコアの安定性を確認してから、最適化シグナルとして信頼します。
### パターンの選択
| \# | 次のものがあります。 | 使用アイテム |
| --- | --- | --- |
| 1 | 2～4 個のあいまいな目標、すべてのセマンティック | パターン 5 (複数ディメンション LLM-as-a-Judge) |
| 2 | 構造とセマンティックを混在させる 2～4 つの目標 | パターン 4 (Lambda 外部 \+ LLM-as-a-Judge 内部) |
| 3 | 少なくとも 1 つの交渉不可能な安全性/正確性の基準 | パターン 2 (ハードフェイルゲート) — 1 または 4 と組み合わせる |
| 4 | 1 つの明確な主要目的 \+ ソフトプリファレンス | パターン 3 (制約 \+ 報酬) |
| 5 | いくつかのほぼ等しい独立した目標 | パターン 1 (加重合計) |
パターンを組み合わせることができます。一般的な本番メトリクスは、「加重合計 \+ 安全上のハードフェイルゲート」です。
### 監視する障害モード
+ **表面フォームでのハッキングに報酬を与えます。**サブスコアが「'sure' という単語がレスポンスに含まれていたか」の場合、オプティマイザはすべての出力に「sure」を強制するプロンプトを書き込みます。キーワードの存在よりも、結果に基づくサブスコア (ツール名、スロット値、構造的妥当性) を優先します。
+ **判事ドリフト。**重みが呼び出しごとに異なるマルチディメンション LLM-as-a-Judge メトリクス (審査員に選択を求められるため) は、ノイズの多い最適化シグナルを提供します。カスタム条件の重みを固定するか、ディメンションの重みを Lambda コードに移動します。
+ **複合スコアが飽和します。**メトリクスが 0.95 に速く達し、そこにとどまる場合、サブスコアは寛大すぎます。rubrics を厳しくします。オプティマイザにヘッドルームがあるように、最大バーを上げることを検討してください (たとえば、部分クレジットが 1 ではなく 0 になります）。
+ **サブオブジェクトは直接競合します。**「簡潔」と「完全性」は実際のトレードオフです。加重和パターンは、そのフロンティア上の操作ポイントを選択します。好きでない場合は、重みを変更します。
### 起動前チェックリスト
+ データセット全体で最初のプロンプトのメトリクスを計算し、スカラーだけでなく、ディメンションごとの平均を検査します。1 つのディメンションがすでに飽和している場合は、バンドルから削除することを検討してください。
+ 5 つのサンプルをスポットチェックします。メトリクスの判定は判断と一致していますか? そうでない場合は、プロンプトを最適化する前にメトリクスを修正します。
## マルチターンプロンプトとステージングプロンプトの最適化
高度なプロンプト最適化は、サンプルごとの評価に対して単一のプロンプトテンプレートを最適化します。ネイティブにターンアウェアではありません。ダイアログを反復したり、特定のターンで動作を最適化したりすることはできません。*ステージングされたプロンプト*は、複数ターンの会話またはワークフローが同じプロンプトをターン間で再利用し、プロンプト自体にワークフローの各ステージ、ステップ、またはフェーズの手順が含まれるプロンプトテンプレートです。これらのプロンプトを最適化するには、ダイアログの状態をテンプレートの入力変数にフラット化し、 に絞り込むシステム指示をベイクし`promptTemplate`、サンプルごとのリファレンスレスポンスで実際に注意するターンを調べます。
このパターンは垂直に依存しません。これは、カスタマーサービスフロー、エージェントツール使用ループ、マルチステップ推論、チュートリアル、コードアシストターン、ドキュメントベースの QA、トリアージワークフローなど、増大するコンテキストでモデルが繰り返し呼び出されるあらゆる場所に適用されます。
### 高度なプロンプト最適化が実際に最適化するもの
+ **入力:** `{{placeholder}}`変数を含む`promptTemplate`文字列。
+ **サンプルあたり:** 各 `evaluationSamples[i]`は、これらの変数と の値を提供します`referenceResponse`。オプティマイザは、推論、評価、フィードバック、書き換えをサンプルごとに個別に実行し、サンプル間でメトリクスを集約します。
+ **出力:** 絞り込まれた `promptTemplate`。変数、データセット、メトリクスは固定入力であり、テンプレートのみが変更されます。
最適化が必要なものは、それ`promptTemplate`自体の内部に存在する必要があります。サンプルごとに異なるモノ (会話履歴、現在のユーザークエリ、取得されたコンテキスト) は です`{{variables}}`。絞り込むシステム指示はテンプレートの一部です。入力変数ではないか、サービスに書き換えるものはありません。
サービスでターン N 時の動作を改善したい場合は、ターン N を 1 つのサンプルのレンダリングされた prompt-plus-input-variables として表現し、それを目的のターン N モデル出力`referenceResponse`にします。
### パターン A — Stage-at-a-time (推奨スターター)
ダイアログの 1 つのフェーズを一度に最適化します。各評価サンプルは、そのフェーズ内の単一の決定ポイントを表します。
ここで「ステージ」とは、一貫した一連の成功基準で説明できるものです。垂直方向の例:
+ **エージェント/ツールの使用:** 計画形成ターン、ツール選択ターン、tool-result-interpretationターン、最終回答ターン。
+ **カスタマーサポート:** インテーク、検証、アクション、確認、クローズアウト。
+ **チュートリアル/教育:** 評価に関する知識、説明概念、チェック理解、要約。
+ **ドキュメント QA:** 検索に基づく回答、フォローアップの明確化、引用ターン。
+ **コーディングアシスタント:** spec-clarification、code generation、code-review/fix、test-write。
#### パターン A を使用するタイミング
+ 個別の成功基準を使用して、個別のフェーズに名前を付けることができます。
+ 1 つのフェーズは品質をドラッグダウンすることであり、他のユーザーを邪魔することなく修正したいと考えています。
+ 高速反復と、デバッグ可能な厳密なフィードバックシグナルが必要です。
#### テンプレートシェイプ
ステージ固有のシステム手順がテンプレートにベイクされます (これはサービスが書き換えるものです）。会話履歴と現在のターンのみが変数です。以下の構造は説明用であり、規定されていません。モデルが最適に処理する区切り文字またはレイアウトを使用します。唯一の要件は、(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 を使用するタイミング
+ 本番プロンプトは既にモノリシックであり、分割したくありません。
+ オプティマイザで、より前のターンが後のターンをどのように設定するかを確認し、書き換えによってステージ間のフローが保持されるようにします。
+ プローブターンの正確性は、複数のステージにまたがって構築されたコンテキストによって異なります (たとえば、「ターン N、正しい事実が既に参照されている必要があります」、「適切なツールが既に呼び出されている必要があります」など）。
#### テンプレートシェイプ
完全なモノリシック多相システムプロンプトは、文字通りテンプレート内に配置されます。サービスは、最適化中にこの本文を書き換えます。履歴と現在のターンは変数のままです。モデルが適切に処理するレイアウトを選択します。要件は、最適化する手順がテンプレートの一部であり、サンプルごとのデータが を介して参照されることのみです`{{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 よりもうまく機能する理由
+ オプティマイザは でステージの進行状況を表示するため`conversation_so_far`、最適化のフィードバックはステージ全体で一度に推論できます。
+ 単一の最適化されたプロンプトは、複数の最適化されたステージプロンプトを結合せずにデプロイするため、後処理が軽減されます。
#### パターン B の注意事項
+ **前のターンでの確率。**本番アシスタントのターンは、常に既定と`conversation_so_far`正確に一致しない場合があります。既定履歴を予想される軌道として扱います。本番稼働では、早めにドリフトすると最適化が無効になる可能性があります。合成されたハッピーパスではなく、代表的な実際の会話キャプチャを使用します。
+ **トークンのコスト。**長い履歴、トライアルごとの推論コスト。このサービスは、多くの候補 × サンプル × 反復を実行します。それに応じて予算を立て、コストがボトルネックである場合は、最新の K ターンと概要への切り捨てを検討してください。
+ **リファレンスレスポンスバイアス。** `referenceResponse` は、その履歴を考えると正しいアシスタントが言うべきことです。リファレンスレスポンスが狭すぎる場合 (許容されるフレーズが 1 つだけ）、オプティマイザはそのレスポンスに過剰適合します。可能な場合は、表面形式の一致よりも結果 (ツール名、スロット値、決定) をランク付けするメトリクスを優先します。
### 特定のターンでのツールコールの検証
サービスにはアシスタントのテキスト出力が表示されます。「モデル呼び出しツール X を右の引数で N 番にランク付けした」には、いずれかを選択します。
+ **出力の規則:** Lambda メトリクスの正規表現/JSON 解析を使用して、アシスタントに `X(arg=...)`や のような構造化トークンを出力させます。最も安く、最も信頼性が高い。
+ **LLM-as-a-Judge カスタム条件:** 「(a) ツールに名前を付け`X`、(b) 引数 を含め`arg`、(c) 必要な語句と一致するか」と判事`customLLMJPrompt`に尋ねる を指定します`Y`。各サブチェックは \+1; 集計です。作成が簡単で、分散性が高くなります。
+ **ダウンストリームシミュレーションを使用した Lambda メトリクス:** ツール実行ハーネスがある場合は、そのハーネスを通じてモデル出力を実行し、観察された副作用をスコアリングします。最高の忠実度、ほとんどのセットアップ。
多くのターンまたは多くのサブチェック (ツールの正確性とトーンと完全性) にわたる複合基準については、[マルチオブジェクト最適化](#advanced-prompt-optimization-multi-objective)「」セクションを参照してください。
### 推奨パス
+ 最も品質を害しているステージの**パターン A から始めます**。作業メトリクス、20～50 個のサンプルデータセット、1 つの最適化をend-to-end。これにより、より大きなパターン B の実行に投資する前に、データセットとメトリクスが検証されます。
+ **次に、完全なモノリシックプロンプトとマルチオブジェクト複合メトリクスを使用してパターン B を 1 回実行**し、パターン A が見逃す可能性のあるクロスステージ回帰をキャッチします。
+ **プロンプトを繰り返す前にデータセットを反復します。**サービスの がメトリクスを hill-climb に書き換えても、本番稼働動作が改善されない場合、メトリクスまたはデータセットが問題になることがあります。
### マルチターンに高度なプロンプト最適化を使用しない場合
+ **ダイアログポリシー/ステートマシンのバグ** (誤ったステージ移行ロジック): フラットプロンプトの書き換えではこれを修正できません。最初にオーケストレーションレイヤーを修正します。
+ **ツールスキーマが間違っている:** サービスはツール定義を変更しません。モデルにそれらを使用するように求めるプロンプトのみ変更できます。
+ **既定履歴とライブ履歴のずれ:** 実際の会話が数ターン後に評価サンプルから大きく逸脱すると、パターン B の最適化シグナルは弱くなります。最適化実行の実際の許容可能な本番トレースをキャプチャすると、理想的な状態に加えて、ここでも役立ちます。
+ **必要な動作は、オプティマイザが表示しないプライベート状態 (たとえば、モデルがツール呼び出しを介してのみ学習するユーザーアカウントデータ) によって異なります**。プローブサンプル`conversation_so_far`に対して でその状態を明示的にするか、サービスが表面動作のみを調整できることを受け入れます。
### スターターチェックリスト
+ 関心のあるプローブターンを選択します。それぞれが 1 つ以上のサンプルになります。
+ パターン A または B (または両方 — A が最初、B) を決定します。
+ リアルでクリーンな`referenceResponse`値で 20 以上の代表的なサンプルを構築`conversation_so_far`します。