Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

エキスパートジャッジを構築する

判定モデルを本番環境に対応させる。

Maud Nalpas

基本的な判定モデルをセットアップするのパート 1とパート 2で構築した基本的な判定モデルは、自己ラベリングされたデータに基づいていました。これは、テストのベースラインを確立するのに最適な方法です。ただし、本番環境レベルの品質を得るには、ドメインの専門家のように考える判定モデルが必要です。また、大規模なスケールで信頼できる堅牢な統計指標も必要です。ここでは、その方法について説明します。

専門家とアライメントデータセットを作成する

アライメントデータセットのラベリングに人間の専門家を使用することは、信頼性の高い LLM 判定モデルを構築するうえで重要です。量よりも質を優先してください。ドメインの専門家による 30 個の高品質なラベルは、専門家以外による 300 個のラベルよりもはるかに優れています。

ラベリング担当者を探す

ブランドアライメントには、社内のデザイナーとブランドの専門家を使用します。有害性については、同じラベリング担当者に依頼するか、チームからラベルをクラウドソーシングして、ラベリング担当者が同じグレーディング基準を共有できるように、中央のルーブリックに基づいてラベルをクラウドソーシングします。

専門のラベリング担当者の人数

1 人の専門家: これは迅速で、開始するには問題ありませんが、判定モデルは担当者のバイアスを受け継ぎます。
2 人の専門家: これは予算の面で最適な選択肢です。意見が分かれた場合、解決することはできませんが、意見の不一致を特定できます。
3 人以上: これはゴールドスタンダードです。奇数を使用すると、例のようにバイナリの PASS と FAIL の評価で自動的に意見が分かれるため、多数派の評価を採用できます。

ThemeBuilder の場合、社内に 3 人のブランドデザイナーがいて、専門のラベリング担当者になることに同意しているとします。

専門家がルーブリックを作成する

ラベリングを行う前に、専門家に厳格なルーブリックを定義してもらい、PASSの具体的な基準を定めます。これにより、専門家は個別に、また集団で一貫した判断を下すことができます。

次に例を示します。

Criteria:
• Psychological association: Do the colors evoke the emotions associated with the desired tone?
• Harmony: Do the colors work together to create the right atmosphere?
• Appropriateness: Is the palette suitable for the company's industry?

専門家がデータにラベルを付ける

専門家に 30 ～ 50 個のサンプルを確認してもらい、ルーブリックに基づいて PASS または FAIL のラベルを割り当て、判断の理由を説明する rationale を記述してもらいます。判定モデルと専門家の間のアライメントのずれをトラブルシューティングして修正するために使用するため、理由は重要です。

専門家がテーマを判断するのに役立つスプレッドシートインターフェース。 — 専門のラベリング担当者向けのウェブアプリケーション。この UI は、Eugene Yan のAlignEvalsに基づいています。

効率的なラベリングのヒント

手動ラベリングには費用がかかります。専門家の効率を最適化するには、次の手法を試してください。

検証のみ: LLM を使用して最初のラベルと理由を生成し、専門家に監査と修正を依頼します。判断をゼロから作成するよりも検証する方が速くなります。
選択的ラベリング: 2 人目の専門家に、1 人目の専門家の作業の小さなサブセットを監査してもらいます。意見が分かれた場合は、ラベリングを停止し、ルーブリックを修正してから続行します。
LLM をセカンドオピニオンとして使用: 1 人の専門家と 1 つの LLM 判定モデルに同じ項目にラベルを付けてもらいます。一致率が低い場合、LLM はルーブリックを異なる方法で理解しています。一致するまでルーブリックを繰り返します。
ラベリング担当者内チェック: 専門家が 1 人しかいない場合は、1 週間後にデータの 10% をランダムに再ラベリングしてもらいます。過去の自分と意見が一致しない場合、ルーブリックは安定していません。

専門家がラベル付けしたデータセットエントリの JSON スニペットを次に示します。これには、専門家の PASS ラベルと FAIL ラベル、および詳細な理由が含まれています。

{
  "id": "sample-001",
  "userInput": {
    "companyName": "Kinetica",
    // Company description, audience and tone
  },
  "appOutput": {
    "motto": "Unlock your kinetic potential.",
    // ... Color palette
  },
  "humanEvaluation": {
    "mottoBrandFit": {
      "label": "PASS",
      "rationale": "This motto powerfully aligns the brand's technical
        engineering with the ambitious goals of its elite athletic audience.
        Relevance: Leverages 'kinetic' to expertly link the brand to physical
        energy. Audience appeal: 'Unlock your potential' resonates perfectly
        with competitive runners. Tone consistency: Nails the required
        aggressive, high-performance marks."
    },
    // ... Human evals for colorBrandFit and mottoToxicity:
  }
}

専門家の合意に達して測定する

ルーブリックはモデルの手順として機能するため、時間をかけて改善することが重要です。あるデザイナーが「遊び心がある」を「クリエイティブな言語」と定義し、別のデザイナーが「明るい色」と解釈した場合、LLM も混乱します。判定モデルにフィードする前に、ルーブリックを強化して、このような曖昧さを解消する必要があります。ラベリング担当者間の信頼性または 評価者間の合意と呼ばれる、合意率が高いほど、判定モデルは信頼性の高い高品質のラベルを提供します。

人間の意見の不一致は、スコアリングルーブリックの改善が必要な箇所を示す有用なシグナルです。専門家が PASS と FAIL のケースについて合意するまで、繰り返します。

判定モデルは、構築した人間よりもアライメントを調整できません。

Booking.com

基本的な合意

人間の合意を測定する方法の 1 つは、基本的な判定モデルの人間と判定モデルの合意スコアにも使用されている、専門家が合意する頻度の割合です。

// total = all test cases
// aligned = test cases where human1Eval.label === human2Eval.label
// (for example PASS and PASS)
const alignment = (aligned / total) * 100;

運以上の合意: カッパ

基本的な割合の合意は簡単ですが、誤解を招く可能性があります。データセットの半分が PASS で、半分が FAIL であるとします。2 人の専門家がコインを投げても、運だけで 50% の確率で合意します。これは運の底と呼ばれます。

合意を正確に計算するには、純粋な偶然を超えた信頼性を測定する統計指標を使用します。

2 人のラベリング担当者の場合は**コーエンのカッパ係数**。
3 人以上のラベリング担当者の場合はフレイスのカッパ係数。
テスト: カッパ係数のスコアを 0.61 以上にすることを目指します。これは、実質的な合意の標準です。スコアが 0 の場合はランダムな推測と変わらず、そして 1.0 は完全な合意です。
修正: カッパ係数のスコアが 0.61 未満の場合、ルーブリックが曖昧すぎます。専門家の意見が分かれたサンプルをグループ化し、理由を確認して、特定のエッジケースをカバーするようにルーブリックを更新し、0.61 に達するまで繰り返します。専門家の意見が一致した場合にのみ、次のステップに進みます。

カッパ係数のスコア	アクション
`0.60` 未満: 不良	専門家の意見が異なる理由を特定します。ルーブリックが曖昧すぎる可能性があるため、改善します。
`0.61`～`0.80`: 良好	ベースラインは信頼できます。このルーブリックで続行します。
`0.81`～`1.00` ほぼ完璧	話がうますぎるように思えます。タスクが簡単すぎるか、専門家が単純化しすぎているかを確認します。

専門家のラベルを折りたたむ

3 人以上の人間の専門家を使用してデータにラベルを付けた場合は、各サンプルの投票を 1 つの多数派の評価に折りたたみます。このリストがグラウンドトゥルースになります。

判定モデルを構成する

基本的な判定モデルと同様に、モデルパラメータを構成してプロンプトを作成する必要があります。システムの手順を厳格な専門家ペルソナに設定し、一貫性を最大限に高めるために温度を 0 に保ちます。プロンプトで、人間の専門家がデータのグレーディングに使用した正確なルーブリックを指定します。専門家がラベル付けしたサンプルを少数ショットの例としていくつか追加して、判定モデルに推論方法を正確に示します。

判定モデルのアライメントを調整してテストする

人間の専門家の意見が一致したら、LLM 判定モデルが同意するかどうかを確認します。

基本的なセットアップでは、未加工のアライメント（精度）を確認しました。しかし、その数値だけでは誤解を招く可能性があります。テストデータの 90% が PASS であるとします。判定モデルが毎回 PASS を出力し、有害なモットーを 1 つも検出できなくても、90% の精度を達成できます。

ポジティブクラスを定義する

ポジティブクラスを定義します。ポジティブクラス（ターゲット条件または対象イベントとも呼ばれます）は、検出、測定、フラグ設定しようとしている特定の成果です。評価パイプラインはゲートキーパーとして機能します。主な目標は、不正な出力を検出してブロックすることです。

ThemeBuilder は通常、ブランドに合ったスローガンとパレットを生成するのが得意で、有害なモットーはまれであると仮定すると、すべての評価基準のポジティブクラスは FAIL です。

これらを踏まえると以下のようになります。

偽陽性は、FAIL として誤ってフラグが設定された良好な出力です。
偽陰性は、見逃された FAIL です。
真陽性は、正しく識別された FAIL です。

適合率と再現率

ポジティブクラスを考慮して、未加工のアライメントよりも優れた指標である適合率と再現率を使用できます。

適合率: LLM 判定モデルが FAIL と判定した場合、正しかった頻度はどのくらいですか？例: 判定モデルがモットーを有害としてフラグ設定した場合、実際に正しかった頻度はどのくらいですか？
再現率: 人間が FAIL と判定した場合、LLM 判定モデルが検出した頻度はどのくらいですか？例: 実際に有害な出力、実際にブランドに合わないモットーとパレットのうち、判定モデルが検出した数はどのくらいですか？

間違いのコストを把握する + 目標スコアを設定する

アプリケーションにとってどちらの間違いが悪いか自問してください。

有害性: 有害性は安全上の問題です。判定モデルが厳しすぎて安全なモットーにフラグを設定することがあっても、有害なモットーをすべて検出したい（偽陰性を最小限に抑えたい）と考えています。安全なモットーにフラグを設定する（偽陽性）と、わずかな遅延や人間のレビューが必要になります。そのため、100% の再現率 を目指します。適合率は低くてもかまいません。
ブランド適合性: バランスが必要です。悪いデザインを見逃すことも、良いデザインを拒否することも、同じくらいコストがかかります。そのため、適合率と再現率の両方を高くする必要があります。

F1 スコア

再現率が上がると、適合率が低下することがよくあります。有害性については、再現率のみに関心があるため、問題ありません。

ブランド適合性については、再現率と適合率の両方が重要です。この重要性のバランスを取るには、新しい指標である F₁ を使用します。F₁ スコアは、適合率と再現率を 1 つのバランスの取れた指標にまとめたものです。

アライメントに達する

専門家がラベル付けしたデータセットに対して判定モデルを実行し、各基準の精度、適合率、再現率、F₁ スコアを計算します。目標を達成しているかどうかを評価します。

達成していない場合は、失敗したケースをグループ化して、LLM の理由を読みます。指標が目標に達するまで、判定モデルのシステム手順とスコアリングルーブリックを更新してギャップを埋めます。

判定モデルが目標に達すると、判定モデルのアライメントが調整されます。

最終検証

次に、基本的な判定モデルのセットアップで説明したのと同じ手順で判定モデルを検証しますが、新しい高度な指標を適用します。

ブートストラップによるストレステスト: データセットを 10 回反復してランダムに再サンプリングします。これらの実行における適合率、再現率、F₁ スコア の分散を計算して、高いスコアが単なる偶然ではないことを数学的に証明します。
自己整合性をテストする: 判定モデルに同じ入力を複数回実行して、判定が 100% 安定していることを確認します。すべての反復で分散がゼロ になるようにします。
判定モデルの最終試験を実施する: 判定モデルを、これまで見たことのない 15 ～ 20 個の新しい専門家がラベル付けしたサンプルのホールドアウトセットでテストします。この非表示のセットでコーエンのカッパ係数、適合率、再現率、F₁ スコア を計算します。これらの指標が近いままであれば、判定モデルがアライメントデータに過適合しておらず、現実世界に汎化できることを証明できます。

判定モデルのアライメントを再調整する

完了したら、おめでとうございます。信頼性の高い評価パイプラインを構築しました。

判定モデルが依存する基盤となる LLM を更新する場合や、アプリケーションの機能セットが根本的に変更された場合は、必ず判定モデルのアライメントを再調整してください。

評価を実行する

まとめ