LLM-as-Judge プロンプトの設計

特定の失敗モード1つに対する二項判定（合格/不合格）の LLM-as-Judge 評価器を設計します。各判定器は厳密に1つの項目をチェックします。

前提条件

• エラー分析が完了している。失敗モードが特定されている。
• この失敗モードに対する人間がラベル付けしたトレース（最低20個の合格例と20個の不合格例）がある。
• コードベースの評価器ではこの失敗モードをチェックできない。判定器に頼る前に、コードベースのオプションを完全に検討してください。主観的に見える多くの失敗モードは、ドメインをよく理解することで、キーワードチェック、正規表現、またはAPI呼び出しに還元できます。例：AI インタビュー コーチが「一般的な」質問（典型的な行動について尋ねることと特定の過去の出来事を尋ねることの区別）を提案しているかどうかを検出することは、意味的理解が必要に見えますが、実際には「usually」、「typical」、「normally」などの単語に対するキーワードチェックがかなり有効に機能する可能性があります。

4つのコンポーネント

すべての判定器プロンプトには厳密に4つのコンポーネントが必要です。

1. タスク評価基準

判定器が評価する内容を述べます。判定器1つにつき失敗モード1つです。

You are an evaluator assessing whether a real estate assistant's email
uses the appropriate tone for the client's persona.

次のようではありません。「メールの品質を評価する」または「メールの品質を1～5で評価する」。

2. 合格/不合格の定義

結果は厳密に二項判定です。リッカートスケール、段階的評価、部分点はありません。合格と不合格を厳密に定義します。これらの定義はエラー分析の失敗モード説明から得られます。

## Definitions

PASS: The email matches the expected communication style for the client persona:
- Luxury Buyers: formal language, emphasis on exclusive features, premium
  market positioning, no casual slang
- First-Time Homebuyers: warm and encouraging tone, educational explanations,
  avoids jargon, patient and supportive
- Investors: data-driven language, ROI-focused, market analytics, concise
  and professional

FAIL: The email uses a tone mismatched to the client persona. Examples:
- Using casual slang ("hey, check out this pad!") for a luxury buyer
- Using heavy financial jargon for a first-time homebuyer
- Using overly emotional language for an investor

3. 少数ショット例

人間がラベル付けしたデータからラベル付けされた合格と不合格の例を含めます。

## Examples

### Example 1: PASS
Client Persona: Luxury Buyer
Email: "Dear Mr. Harrington, I am pleased to present an exclusive listing
at 1200 Pacific Heights Drive. This distinguished property features..."
Critique: The email opens with a formal salutation and uses language
consistent with luxury positioning — "exclusive listing," "distinguished
property." No casual slang or informal phrasing. The tone matches the
luxury buyer persona throughout.
Result: Pass

### Example 2: FAIL
Client Persona: Luxury Buyer
Email: "Hey! Just found this awesome place you might like. It's got a
pool and stuff, super cool neighborhood..."
Critique: The greeting "Hey!" is informal. Phrases like "awesome place,"
"got a pool and stuff," and "super cool" are casual slang inappropriate
for a luxury buyer. The email reads like a text message, not a
professional communication for a high-end client.
Result: Fail

### Example 3: PASS (borderline)
Client Persona: First-Time Homebuyer
Email: "Hi Sarah, I found a property that might be a great fit for your
first home. The neighborhood has good schools nearby, and the monthly
payment would be similar to what you're currently paying in rent..."
Critique: The greeting is warm but not overly casual. The email explains
the property in relatable terms — comparing mortgage to rent, mentioning
schools — which is educational without being condescending. It avoids
jargon like "amortization" or "LTV ratio." While not deeply technical,
this matches the supportive tone expected for a first-time buyer.
Result: Pass

例を選択するための規則：

• 少なくとも1つの明確な合格例、1つの明確な不合格例、1つのボーダーライン例を含めます。ボーダーライン例は最も価値があります。ニュアンスを教えます。
• トレーニングスプリット（この目的のために確保されたラベル付けデータセットの10～20%）から例を抽出します。
• 判定器プロンプトで使用される例はすべて、開発セットとテストセットから除外する必要があります。開発/テスト例の使用はデータリークです。
• 2～4個の例が典型的です。パフォーマンスは4～8個の後にプラトーに達します。

4. 構造化出力フォーマット

LLM プロバイダーのスキーマ強制（OpenAI の response_format やAnthropicのツール定義など）またはInstructorやOutlinesなどのライブラリを使用して、構造化出力を強制します。プロバイダーがスキーマ強制をサポートしていない場合は、プロンプトで JSON スキーマを指定します。

出力には、判定の前に評論が含まれている必要があります。評論を最初に配置することで、判定器は決定にコミットする前に評価を明確に述べることができます。

{
  "critique": "string — detailed assessment of the output against the criterion",
  "result": "Pass or Fail"
}

評論は、簡潔ではなく詳細である必要があります。優れた評論は、具体的に何が正しい、または正しくないのか、そして出力からの具体的な証拠を参照して説明します。少数ショット例の評論は、判定器が生成する詳細レベルのベンチマークを設定します。

判定器に渡す内容の選択

正確な判定に必要な情報のみを提供します。

失敗モード	判定器が必要とするもの
トーンの不一致	クライアント ペルソナ + 生成されたメール
回答の正確性	取得されたコンテキスト + 生成された回答
SQL の正確性	ユーザー クエリ + 生成された SQL + スキーマ
指示への従従性	システム プロンプト ルール + 生成された応答
ツール呼び出しの正当化	会話履歴 + ツール呼び出し + ツール結果

長いドキュメントの場合、ドキュメント全体ではなく、関連するスニペットのみを提供します。

モデル選択

利用可能な最も機能的なモデルから始めます。メイン タスクに使用されるのと同じモデルが判定器として機能します（判定器は異なるより狭いタスクを実行します）。整列が確認されたら、後でコストを最適化します。

アンチパターン

• 「これは役に立つか？」のような曖昧な基準。 エラー分析から特定の観察可能な失敗モードをターゲットにしてください。
• トレース全体に対する包括的判定器。 複数の側面をカバーする1つの判定器は、実行不可能な判定を生成します。
• 少数ショット例がない。 例がなければ、モデルはアプリケーションの失敗が何であるかを知りません。
• 少数ショットとして使用される開発/テスト例。 これはデータリークです。トレーニングスプリットのみを使用してください。
• リッカートスケール（1～5、段階的評価など）。 二項合格/不合格のみです。リッカート スケールは正確に見えるスコアを生成しますが、キャリブレーションできません。注釈者は3と4の違いについて不同意となり、判定器はそのノイズを継承します。二項判定は、事前に明確な決定境界を定義することを強制します。これにより、注釈者間の一致度が測定可能になり、判定器のエラーが実行可能になります。重大度をキャプチャする必要がある場合は、1つの順序付きスケールではなく複数の二項判定器を使用してください（例：「事実上間違っている」と「危険に間違っている」）。
• 検証をスキップする。 validate-evaluator を使用して、判定器を信頼する前に、人間ラベルとの整列を測定してください。
• プロンプトを最初に修正せずに仕様失敗のための判定器。 プロンプトが動作を要求しなかった場合は、評価器を構築する前に指示を追加してください。重大な要件の場合、判定器は回帰ガードとして機能できます。