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

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

Maud Nalpas

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

このモジュールでは、自分で、またはチームと協力してデータにラベルを付ける ことと、基本的な統計指標 を使用して、最初の判定を作成する方法について説明します。

最初の判定モデルを作成する手順

モデルのカスタマイズ方法を選択する 。ファインチューニングするか、プロンプトエンジニアリングを行うかを決定します。
モデルを選択する。基盤モデルまたはドメインの専門知識のない別の LLM を選択できます。
スコアリング方法を選択する。判定で、ThemeBuilder で生成されたテーマのスコアリングにバイナリスケールと数値スケールのどちらを使用するかを決定します。
判定を構成する。モデルの設定（Temperature や構造化出力など）を変更して、判定タスクに適するようにします。
最初のプロンプトを作成する。スコアリングルーブリックと例を含む、判定システムの指示とプロンプトの最初のバージョンを設計します。
アライメントデータセットを作成する 。ThemeBuilder の出力の良し悪しを多様かつ高品質なセットで作成または収集し、それらにラベルを付けます（例: 良いモットー、有害なモットー、ブランドに合わないカラーパレット）。
判定を調整してテストする。アライメントデータセットを使用して、判定プロンプト（システム指示とメインプロンプト）を反復的に改善します。判定の結果が人間の結果と一貫して一致するまで、このプロセスを繰り返します。最後に、判定をテストして、信頼性が高く、新しい入力に対してアプローチを一般化できることを確認します。

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

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

ほとんどの基盤モデルは汎用型です。判定モデルはドメインの専門家のように考える必要があります。

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

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

このコースの ThemeBuilder の評価では、プロンプトエンジニアリング をおすすめします。プロンプトエンジニアリングを使用すると、他の方法よりも開発作業を減らしながら優れた結果を得ることができます。

モデルを選択する

判定のモデルを選択する際は、強力な推論能力 を備えたモデルを選択してください。CI/CD パイプラインで評価を実行するため、速度とコスト も重要です。

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

より大規模で強力なモデルから始めて高い基準を設定し、徐々にスケールダウン して小規模なモデルに移行します。またはその逆を行います。
組み合わせる: 毎日の PR チェックには高速で費用対効果の高いモデルを使用し、最終リリーステストにはより強力なモデルを使用します。または、一般的な LLM と小規模な特殊モデルを組み合わせて、有害性検出などの特定のタスクを高速化します。

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

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

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

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

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

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

判定を構成する

パラメータと指示を使用して、判定で一貫した構造化された出力を作成できるようにします。

システム指示を設定する: 判定に厳格な専門家のペルソナを与えます。

温度または思考レベルを設定する: 判定は一貫している必要があります。Gemini Flash などの推論モデルを使用している場合は、論理ステップ間を移動するためにわずかなランダム性が必要になるため、温度をデフォルトに保ち、thinking_levelを HIGH に設定します。別のモデルを使用している場合は、 Temperature を 0 または 0 に近い値に設定します。いずれの場合も、Chain-of-Thought 手法を使用して、モデルが判断を下す前に考えるようにします。
判定の出力を構造化する: 予測可能な JSON オブジェクトは、コードベースの他の部分で再利用しやすくなります。label（PASS または 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"
}

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

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

**重要な用語:** 判定で判定を評価して決定するために使用されるメインプロンプトは、採点プロンプト、スコアリングプロンプト、判定プロンプトと呼ばれます。

システム指示を構成したので、メインの判定プロンプトを設計します。この段階では、このプロンプトの最初のバージョン のみを作成します。次のステップで判定を調整する際に、反復的に改善します。

判定の有効性は、判定に与える指示によって決まります。「このモットーは良いですか？」など、`good` が定義されていない一般的な質問は避けてください。代わりに、明確で一貫した出力を得るための構造を提供します。

ルーブリックを定義する: 判定に詳細なスコアリングガイドラインを提供します。理想的な出力に期待されるトーンを説明するものは何ですか？LLM にルーブリックの作成を依頼できます。
**少数ショットプロンプトを使用する**: PASS と FAIL の例を含めます。
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 (e.g. 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）を読んで、調整とテストで判定の作成を完了してください。

ルールベースの評価

パート 2