mcpField
A
advanced-evaluation

advanced-evaluation

github.com/shipshitdevテスト・品質38184 回インストール1 日前に更新
リポジトリ

advanced-evaluation について

advanced-evaluation は、LLM-as-a-Judge の評価、ルーブリック、バイアス対策を設計するスキルです。直接採点とペア比較の選択を支援し、人間の判断との一貫性を評価します。

主な機能

  1. 01直接採点とペア比較の選択
  2. 02位置・長さバイアスの軽減
  3. 03構造化されたルーブリックの作成
  4. 04タスク別の指標選定
  5. 05確信度の調整と同点処理
  6. 06人間の判断との照合

活用シーン

  1. 01好みに基づくモデル応答の比較
  2. 02客観基準に沿った出力の採点
  3. 03評価結果の不一致の調査
  4. 04プロンプトやモデル変更のテスト

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/shipshitdev/skills --skill advanced-evaluation

インストール後、Claude Code で/advanced-evaluationを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

plugin.json
README.md
references/
bias-mitigation.md
evaluation-pipeline.md
examples.md
implementation-patterns.md
metrics-guide.md
scripts/
evaluation_example.py

詳細

高度な評価

重要な洞察:LLM-as-a-Judge は単一の手法ではなく、評価の状況に応じて使い分ける複数のアプローチの総称です。適切なアプローチを選び、既知のバイアスを軽減することが、このスキルで身につける中核的な能力です。

有効化するタイミング

  • LLM の出力を評価する LLM-as-a-Judge システムを構築するとき
  • 複数のモデル応答を比較して最適なものを選ぶとき
  • 評価チーム全体で一貫した品質基準を確立するとき
  • 結果に一貫性がない評価システムをデバッグするとき
  • プロンプトやモデルの変更に対する A/B テストを設計するとき
  • LLM または人間と LLM のハイブリッド判定者専用のルーブリックを作成するとき
  • 自動判定と人間による判定の相関を分析するとき

他のスキルが担当する関連作業には、このスキルを有効化しないでください。

  • 一般的な決定論的チェック、回帰テストスイート、本番環境の品質ゲート、結果指標:evaluation。
  • 評価ツールのツール API コントラクト:tool-design。

コアコンセプト

評価の分類

正解データが存在するかどうかに基づいて、主な 2 つのアプローチから選択します。

直接スコアリング — 事実の正確性、指示への準拠、有害性など、客観的な基準が存在する場合に使用します。単一の LLM が、定義された尺度で 1 つの応答を評価します。基準が明確であれば、中程度から高い信頼性を実現できます。スコアのキャリブレーションのずれや、尺度の解釈の不一致に注意してください。

ペアワイズ比較 — トーン、スタイル、説得力など、主観的な好みを評価する場合に使用します。LLM が 2 つの応答を比較し、より優れた方を選択します。主観的なタスクでは、ペアワイズ手法は自由形式の直接スコアリングよりも人間の好みと高い相関を示すことがよくあります(claim-advanced-evaluation-position-swap)。位置バイアスと長さバイアスに注意してください。

バイアスの全体像

あらゆる評価システムで、次の体系的なバイアスを軽減してください。

位置バイアス:最初の位置にある応答が優先的に評価されます。位置を入れ替えて 2 回評価し、多数決または一貫性チェックを適用して軽減します。

長さバイアス:品質に関係なく、長い応答ほど高く評価されます。長さを無視するよう明示的にプロンプトで指示し、長さで正規化したスコアリングを適用して軽減します。

自己評価バイアス:モデルは自らの出力を高く評価します。生成と評価に異なるモデルを使用して軽減します。

冗長性バイアス:不要な場合でも、過剰な詳細が高く評価されます。無関係な詳細を減点する、基準に特化したルーブリックを用いて軽減します。

権威バイアス:正確性に関係なく、自信に満ちた口調が高く評価されます。根拠の提示を必須とし、ファクトチェックの層を追加して軽減します。

指標選択のフレームワーク

評価タスクの構造に合わせて指標を選択します。

タスクの種類主な指標副次的な指標
二値分類(合格/不合格)再現率、適合率、F1Cohen のカッパ係数
順序尺度(1〜5 の評価)Spearman の順位相関係数、Kendall の順位相関係数Cohen のカッパ係数(重み付き)
ペアワイズの好み一致率、位置の一貫性信頼度のキャリブレーション
マルチラベルMacro-F1、Micro-F1ラベルごとの適合率/再現率

絶対的な一致率よりも、体系的な不一致のパターンを重視してください。特定の基準について一貫して人間と異なる判定をする判定者は、ランダムなノイズがある判定者よりも問題が大きいためです。

評価アプローチ

直接スコアリングの実装

明確な基準、キャリブレーション済みの尺度、構造化された出力形式の 3 つの要素を使って、直接スコアリングを構築します。

基準の定義パターン:

Criterion: [Name]
Description: [What this criterion measures]
Weight: [Relative importance, 0-1]

尺度のキャリブレーション — ルーブリックの詳細さに応じて、尺度の粒度を選択します。

  • 1〜3:中立の選択肢を含む二値評価。認知負荷が最も低い
  • 1〜5:標準的なリッカート尺度。粒度と信頼性のバランスが最適
  • 1〜10:キャリブレーションがより難しいため、レベルごとの詳細なルーブリックがある場合に限り使用

採点プロンプトではスコアを出す前に根拠を示すよう必須にしてください。これにより、判定者は数値を出す前に、観察可能な出力の特徴に基づいて判断する必要があります。完全なプロンプトについては、references/examples.md(§ Direct Scoring Prompt Template)を参照してください。

ペアワイズ比較の実装

すべてのペアワイズ評価で、位置バイアスの緩和を適用します。

  1. 最初に決定的な事前チェックを実行します。両方の候補が同じスキーマ、ソースエビデンスの要件、スコープの制約を満たしている必要があります。
  2. 1回目の判定:Response Aを1番目、Response Bを2番目に配置します。
  3. 2回目の判定:Response Bを1番目、Response Aを2番目に配置します。
  4. 一貫性チェック:判定が一致しない場合は、確信度を下げてTIEを返します。
  5. 最終判定:一貫して勝者となった候補を選び、確信度の平均値と、明示的なタイブレークの根拠を示します。

確信度のキャリブレーション — 確信度を位置の一貫性に対応させます。両方の判定が一致する場合 → 確信度 = 個々の確信度の平均値。不一致の場合 → 確信度 = 0.5、判定 = TIE。プロンプト全文については、references/examples.md(§ ペアワイズ比較プロンプトテンプレート)を参照してください。

ルーブリックの生成

自由形式の採点と比べて評価のばらつきを抑えるルーブリックを生成します。ばらつきがどの程度低減するかは、対象の評価セットで測定しない限り、ワークロードに依存するものとして扱います。

ルーブリックに含める要素:

  1. レベルの説明:各スコアレベルの明確な境界
  2. 特性:各レベルを定義する、観察可能な特徴
  3. 例:各レベルを代表するテキスト(任意ですが、あると役立ちます)
  4. エッジケース:曖昧な状況への指針
  5. 採点ガイドライン:一貫して適用するための一般原則

ユースケースに合わせて厳格さのキャリブレーションを設定します。

  • 緩やか:合格基準を低めに設定し、反復を促す用途に適しています
  • バランス型:一般的な本番環境での期待水準です
  • 厳格:安全性が重要な評価や、重大な結果を伴う評価での高い基準です

ルーブリックはドメインに合わせて調整し、ドメイン固有の用語を使用します。コードの可読性を評価するルーブリックでは、変数、関数、コメントに言及します。医療情報の正確性を評価するルーブリックでは、臨床用語とエビデンスの基準を参照します。

実践的なガイダンス

評価パイプラインの設計

本番環境の評価システムは、次のレイヤーで構築します:Criteria Loader(ルーブリック + 重み) -> Primary Scorer(直接採点またはペアワイズ) -> Bias Mitigation(位置の入れ替えなど) -> Confidence Scoring(キャリブレーション) -> Output(スコア + 根拠 + 確信度)。全体の図については、評価パイプライン図を参照してください。

判断フレームワーク:直接評価かペアワイズ評価か

次の判断ツリーを適用します。

Is there an objective ground truth?
+-- Yes -> Direct Scoring
|   Examples: factual accuracy, instruction following, format compliance
|
+-- No -> Is it a preference or quality judgment?
    +-- Yes -> Pairwise Comparison
    |   Examples: tone, style, persuasiveness, creativity
    |
    +-- No -> Consider reference-based evaluation
        Examples: summarization (compare to source), translation (compare to reference)
評価のスケーリング

大量の評価を行う場合は、次の戦略のいずれかを適用します。

  1. LLM のパネル(PoLL):複数のモデルを判定者として使用し、投票を集約することで、個々のモデルのバイアスを軽減します。コストは高くなりますが、重大な判断では信頼性が向上します。

  2. 階層型評価:スクリーニングには高速で低コストなモデルを使用し、エッジケースには高コストなモデルを使用します。スクリーニングのしきい値をキャリブレーションする必要があります。

  3. 人間参加型:明確なケースは自動化し、確信度の低い判断は人間によるレビューに回します。時間の経過とともに自動評価を改善できるよう、フィードバックループを設計します。

例

事実の正確性に対する直接採点、位置を入れ替えるペアワイズ比較、ルーブリック生成の3つの実例については、references/examples.md(§ 例1~3)を参照してください。

ガイドライン

  1. スコアを付ける前に、必ず根拠を求める - 根拠を先に示すプロンプトは、判断を監査しやすくし、根拠のない数値評価を減らします

  2. ペアワイズ比較では、必ず提示順を入れ替える - 1回だけの比較では、提示順によるバイアスで結果が歪みます

  3. 評価基準の具体性に合わせて尺度の細かさを調整する - 各レベルの詳細な説明なしに1~10の尺度を使わないでください

  4. 客観的な基準と主観的な基準を分ける - 客観的な基準には直接評価を、主観的な基準にはペアワイズ比較を使います

  5. 確信度スコアを含める - 提示順を入れ替えたときの一貫性と根拠の強さに基づいて調整します

  6. エッジケースを明確に定義する - 評価のばらつきは、曖昧な状況で最も大きくなります

  7. ドメイン固有の評価基準を使う - 汎用的な評価基準では、評価も汎用的になります

  8. 人間の判断と照らし合わせて検証する - 自動評価に価値があるのは、人間による評価と相関する場合に限られます

  9. 体系的なバイアスを監視する - 評価基準、回答の種類、モデルごとに不一致のパターンを追跡します

  10. 反復を前提に設計する - 評価システムはフィードバックループによって改善されます

注意点

  1. 根拠のないスコアリング:スコアに根拠がなく、問題のデバッグが困難になります。スコアの前に、必ず根拠に基づく説明を求めてください。

  2. 1回だけのペアワイズ比較:提示順を入れ替えないと、提示順によるバイアスで結果が歪みます。必ず提示順を入れ替えて2回評価し、一貫性を確認してください。

  3. 基準の詰め込みすぎ:一度に複数の項目を測る基準では、信頼性の低いスコアが生じます。1つの基準につき、測定可能な側面を1つにしてください。

  4. エッジケースに関する指針の不足:明示的な指示がないと、評価者は曖昧なケースを一貫性なく処理します。明確な解決ルールとともに、エッジケースを評価基準に含めてください。

  5. 確信度の調整を軽視する:確信度の高い誤った判断は、確信度の低い判断よりも深刻です。提示順を入れ替えたときの一貫性と根拠の強さに基づいて、確信度を調整してください。

  6. 評価基準のずれ:品質基準の変化やモデルの能力向上に伴い、評価基準の調整がずれていきます。定期的に評価基準を見直し、新たに人手でアノテーションした例を使ってスコアの各レベルを再調整してください。

  7. 評価プロンプトの表現に対する敏感さ:評価プロンプトのわずかな表現変更でも、スコアが大きく変動することがあります。評価プロンプトをバージョン管理し、変更を適用する前に回帰テストを実施してください。

  8. 制御されていない長さのバイアス:簡潔さが望ましい場合でも、長い回答のほうが体系的に高く評価されます。評価プロンプトに長さを評価に影響させないよう明示し、長さを揃えたテストペアで検証してください。

統合

このスキルは、評価者の設計とバイアスの軽減を担当します。隣接するスキルは、より広範な品質ゲートとインフラストラクチャを担当します。

  • evaluation:一般的な決定論的チェック、回帰スイート、品質ゲート、本番環境の監視。
  • context-optimization (references/fundamentals.md):評価者プロンプトのコンテキスト構成。
  • tool-design:評価ツールのスキーマとエラー処理。
  • context-optimization:大量の評価におけるトークン効率とレイテンシー効率。

参考資料

内部資料:

  • LLM-as-Judge 実装パターン - 次の場合に参照してください:評価パイプラインを一から構築する場合、または LLM ジャッジを CI/CD に統合する場合
  • バイアス軽減手法 - 次の場合に参照してください:評価結果に一貫性のない、または疑わしいスコアリングパターンが見られる場合
  • メトリクス選定ガイド - 次の場合に参照してください:評価の信頼性を検証する統計メトリクスを選ぶ場合
  • 評価パイプライン図 - 次の場合に参照してください:多段階評価システムのアーキテクチャを設計する場合
  • プロンプトテンプレートと実例 - 次の場合に参照してください:直接スコアリングやペアワイズ比較のプロンプトを作成する場合、または実例全体を確認する場合

外部調査資料:

このコレクションの関連スキル:

  • evaluation - 評価の基礎概念
  • context-optimization(基礎リファレンス) - 評価プロンプトのコンテキスト構造
  • tool-design - 評価ツールの構築

コメント