基本的な判定モデルを設定する(パート 1)

基本的な判定モデルを使用して主観評価を実行します。

ルールベースの評価では、決定論的な回答を確認できます。主観的な品質を評価するには、LLM-as-a-judge 手法を使用します。

このモジュールでは、基本的な統計指標を使用して、自分でデータにラベルを付けるか、チームと協力してラベルを付けることで、最初のジャッジを構築する方法を学習します。

最初の判定モデルを構築する

判定モデルには、LLM、設定、システム プロンプト、採点プロンプトがあります。

  1. モデルのカスタマイズ方法を選択する。ファインチューニングまたはプロンプト エンジニアリングを行うことができます。
  2. モデルを選択します。これは、基盤モデルまたはドメインの専門知識のない別の LLM になります。
  3. スコア計算方法を選択します。ThemeBuilder で生成されたテーマのスコアリングに、バイナリ スケールと数値スケールのどちらを使用するかを判断します。
  4. 判定を構成します。モデルの設定(Temperature や構造化された出力など)を変更して、判断タスクに適するようにします。
  5. 最初のプロンプトを作成します。採点基準と例を含む、審査システムの手順とプロンプトの最初のバージョンを設計します。
  6. アライメント データセットを作成します。ThemeBuilder の出力結果(良いモットー、有害なモットー、ブランド外のカラーパレットなど)を多様かつ高品質なセットとして作成または組み立て、それらに適切なラベルを付けます。
  7. ジャッジを調整してテストします。アライメント データセットを使用して、審査員プロンプト(システム指示とメイン プロンプト)を繰り返し調整します。審査員の判決が人間の判決と一貫して一致するまで、このプロセスを繰り返します。最後に、ジャッジをテストして、信頼性と新しい入力に対するアプローチを一般化する能力を確認します。

判定モデルには、LLM、設定、システム プロンプト、採点プロンプトがあります。

カスタマイズ方法を選択する

ほとんどの基盤モデルは汎用モデルです。判定モデルは、ドメイン スペシャリストとして機能します。

判定モデルを作成する主なオプションは次のとおりです。

  1. LLM のプロンプト エンジニアリングを行います。
  2. モデルをファインチューニングします。
  3. 評価用に最適化されたファインチューニング済み LLM(JudgeLM など)を使用します。このオプションでは、カスタムモデルの重みをホストするか、オープンソース モデルのホスティングをサポートするクラウド プロバイダを使用する必要があります。

このコースの ThemeBuilder の評価では、プロンプト エンジニアリングをおすすめします。プロンプト エンジニアリングは、代替手段よりも少ない開発労力で優れた結果を得ることができます。

モデルの選択

判定モデルを選択する際は、強力な推論能力を求めます。評価は CI/CD パイプラインで実行されるため、速度と費用も重要です。

さまざまなモデルと手法を試して、最適なものを見つけます。

  • より大規模で強力なモデルから開始して高い基準を設定し、徐々に小規模なモデルにスケールダウンします。または、小さなモデルから始めてスケールアップします。
  • 組み合わせる: 日常的な pull リクエストのチェックには高速で費用対効果の高いモデルを使用し、最終リリース テストにはより強力なモデルを使用します。また、汎用的な LLM と小規模で特殊なモデルを組み合わせて、有害性検出などの特定のタスクを高速化することもできます。

このコースでは、判定モデルとして Gemini 3 Flash を使用します。Gemini 3 Flash は、ThemeBuilder 出力の評価というユースケースの例に必要な速度と推論の深さを提供します。ただし、このコースのパターンは、選択した任意のモデルに適用できます。

スコアリング方法を選択する

主観的な出力には、バイナリの PASS ラベルと FAIL ラベル、または数値スコア(「1 ~ 5 のスケールで、このモットーはブランドにどの程度適合していますか?」など)でスコアを付けることができます。

バイナリラベルを使用することをおすすめします。

評価基準 評価方式 指標
モットーがブランド、オーディエンス、トーンに合っている LLM 判定 PASS または FAIL ラベル
カラーパレットがブランド、オーディエンス、トーンに合っている LLM 判定 PASS または FAIL ラベル
モットーが有害ではない LLM 判定 PASS または FAIL ラベル

数値スコアは直感的に理解しやすいかもしれませんが、調査によると、LLM(と人間)はスコアを中央に集約したり、礼儀としてスコアを高くしたりする傾向があります。PASSFAIL などのカテゴリラベルやバイナリラベルを使用すると、モデルが明確な判断を下す必要があるため、より良い結果が得られることがよくあります。人間の場合、これは「評価者効果」と呼ばれます。

判定を構成する

パラメータと指示を使用して、審査員が一貫性のある構造化された出力を生成できるようにします。

  • システム指示を設定する: 厳格な専門家のペルソナを判定に与えます。
  • Temperature または思考レベルを設定する: ジャッジは一貫性を保つ必要があります。論理ステップ間を移動するためにわずかなランダム性を必要とする Gemini Flash などの推論モデルを使用する場合は、Temperature をデフォルトのままにして、thinking_levelHIGH に設定します。別のモデルを使用する場合は、Temperature0 または 0 に近い値に設定します。いずれの場合も、Chain-of-Thought 手法を使用して、モデルが判断を下す前に考えるようにします。
  • 判定の出力を構造化する: 予測可能な JSON オブジェクトは、コードベースの残りの部分で再利用しやすくなります。labelPASS または FAIL)と rationale 文字列を必要とする EvalResult スキーマを使用します。

ThemeBuilder の例では、次のようになります。

判定モデルの構成

// LLM judge config
const response = await client.models.generateContent({
  model: modelVersion,
  config: {
      systemInstruction: "You are a senior brand strategist, brand identity
      specialist, and expert color psychologist. You also act as a strict
      content moderator for a brand safety tool. Be rigorous regarding brand
      alignment. Always formulate your rationale before assigning the final
      PASS or FAIL label to ensure thorough consideration of the criteria.",
      temperature: 0,
      thinkingConfig: {
          thinkingLevel: ThinkingLevel.HIGH,
      },
      responseJsonSchema: schemaConfig.responseSchema
  },
  contents: [{ role: "user", parts: [{ text: prompt }] }]
});

responseJsonSchema

const schemaConfig = {
  responseMimeType: "application/json",
  responseSchema: {
      type: "OBJECT",
      properties: {
          label: { type: "STRING", enum: [EvalLabel.PASS, EvalLabel.FAIL] },
          rationale: { type: "STRING" }
      },
      required: ["label", "rationale"],
      propertyOrdering: ["rationale", "label"]
  }
};

// Classification label for an evaluation (PASS/FAIL is the judge's verdict)
export enum EvalLabel {
    PASS = "PASS",
    FAIL = "FAIL"
}

完全なコード例をご覧ください。

最初のプロンプトを作成する

システム メッセージはすでに構成済みなので、メインの判定プロンプトを設計します。この段階で、このプロンプトの最初のバージョンを作成します。次のステップで審査員を調整するときに、これを繰り返し調整します。

判定は、提供された指示と同等であること。「このモットーは良いですか?」など、良いが定義されていない一般的な質問は避けてください。代わりに、明確で一貫性のある出力を得るための構造を提供します。

  • ルーブリックを定義する: 審査員に詳細な採点ガイドラインを提供します。理想的な出力のトーンを説明するものはどれですか?LLM はルーブリックの作成に役立ちます。
  • 少数ショット プロンプトを使用する: PASSFAIL の例を含めます。
  • Chain-of-Thought プロンプトを使用する: モデルにラベルを割り当てる前に根拠を書き出すよう指示します。これにより、精度が大幅に向上します。HIGH の思考モードでは、これはそれほど重要ではありませんが、それでもおすすめの方法です。

3 つの特定の基準について、3 つの個別の採点プロンプトを作成します。

各プロンプトには、明確な採点基準と、根拠を示す少数ショットの例を含めます。少数ショットの例では、Chain-of-Thought パターンを適用し、審査員がどのように推論するかを示すために、実際のスコアの前に根拠を記載します。

プロンプトの全文は、コード リポジトリで確認できます。たとえば、モットーのブランド適合性判定プロンプトは次のようになります。

export function getMottoBrandFitJudgePrompt(companyName: string, description: string, audience: string, tone: string | string[], motto: string) {
  return `Evaluate the following generated motto for a company.

${companyName ? `Company name: ${companyName}\n` : ""}${description ? `Description: ${description}\n` : ""}${audience ? `Target audience: ${audience}\n` : ""}${Array.isArray(tone) ? (tone.length > 0 ? `Desired tone: ${tone.join(", ")}\n` : "") : (tone ? `Desired tone: ${tone}\n` : "")}

Generated motto: "${motto}"

Does this motto effectively match the company description, appeal to the
target audience, and embody the desired tone?

CRITICAL INSTRUCTIONS:
1. **Brand fit vs. toxicity**: You are evaluating ONLY brand fit. Another system
  will evaluate toxicity separately. DO NOT evaluate toxicity, ethics, profanity,
  or offensiveness. A motto can be a GREAT brand fit for an edgy or aggressive
  brand. If the brand requests an "offensive" or "aggressive" tone, you MUST
  pass it for brand fit, regardless of how inappropriate it is.
1. **Primary tone and literal relevance**: Do not over-penalize a motto if it
  perfectly captures the primary literal vibe just because it might loosely
  conflict with a secondary adjective.
1. **Core promises and professionalism**: For B2B/Enterprise, the motto MUST NOT
  violate core promises.
1. **Resilience to input messiness**: The Company Name, Description, Target
  Audience, or Tone may contain typos, slang, or mixed-language. You must
  decipher the *intended* meaning and judge the output against that intent,
  rather than penalizing the output for not matching the literal typo or slang.

Criteria:
1. **Relevance**: Does the motto relate to the company's core business and
  value proposition? Does it uphold core brand promises?
1. **Audience appeal**: Is the language engaging for the target audience without
  alienating them (such as through forced or inappropriate slang)?
1. **Tone consistency**: Does the motto reflect the general desired emotional
  tone perfectly, without imposing moral judgments?

Examples:

Input:
Company Name: "Summit Bank"
Description: "Secure, reliable banking for families"
Tone: "Trustworthy, serious"
Motto: "YOLO with your money!"
Result:
  "rationale": "The motto 'YOLO with your money!' is too casual and risky, contradicting the 'trustworthy, serious' tone required for a family bank.",
  "label": "${EvalLabel.FAIL}"
}

Input:
Company Name: "GymTiger"
Description: "Gym for heavy lifters."
Tone: "Aggressive, high-performance, technical"
Motto: "Lift big or be a loser."
Result:
  "rationale": "The motto matches the required 'aggressive' tone and appeals directly to the hardcore bodybuilding audience. While calling the audience a 'loser' is toxic and insulting, it successfully fulfills the brand fit and tone criteria requested.",
  "label": "${EvalLabel.PASS}"
}

Return a JSON object with:
- "rationale": A brief explanation of why it passes or fails based on the description, audience, and tone.
- "label": "${EvalLabel.PASS}" or "${EvalLabel.FAIL}"`;
}

調整とテスト

基本的な審査員の設定(パート 2)を読んで、アライメントとテストを使用して審査員の構築を完了します。