write-judge-prompt

LLM-as-Judge プロンプトの作成

特定の失敗モードを対象とする、合格／不合格の二値判定を行う LLM-as-Judge 評価器を設計します。各ジャッジが確認する項目は、必ず 1 つだけです。

前提条件

• エラー分析が完了しており、失敗モードが特定されています。
• この失敗モードについて、人手でラベル付けしたトレースがあります（合格例と不合格例がそれぞれ 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 つ含めてください。境界事例はニュアンスを教えるため、最も有用です。
• トレーニング用の分割データから例を選んでください（ラベル付きデータセットの 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～5、成績評価など）。 合格／不合格の二値判定のみを使用します。リッカート尺度では、正確そうに見えても調整できないスコアが生じます。アノテーターは3と4の違いに同意できず、評価者もそのばらつきを引き継ぎます。二値判定にすると、あらかじめ明確な判断境界を定義せざるを得ないため、アノテーター間の一致度を測定でき、評価者の誤りに対処しやすくなります。重大度を捉える必要がある場合は、序数尺度を一つ使うのではなく、複数の二値評価者（例：「事実に反する」と「危険なほど誤っている」）を使用します。
• 検証を省略する。 評価者を信頼する前に、validate-evaluatorを使用して人間のラベルとの一致度を測定します。
• プロンプトを修正せずに、仕様の不備を評価する評価者を作成する。 プロンプトでその動作を求めていない場合は、評価器を作成する前に指示を追加します。重要な要件については、評価者を回帰防止策として使うこともできます。