mcpField
D
design-ai-benchmarking

design-ai-benchmarking

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

design-ai-benchmarking について

design-ai-benchmarking は、AI ベンチマーク評価の設計を支援するスキルです。評価基準、レビュアー手順、信頼性指標、データスキーマを定め、記録に基づく評価を重視します。

主な機能

  1. 01評価課題と比較対象の定義
  2. 02尺度アンカー付き多次元ルーブリック
  3. 03校正プローブとレビュアーパネルの計画
  4. 04信頼性指標と評価者割り当ての指定
  5. 05構造化された評価データスキーマ
  6. 06情報漏洩と構成概念の独立性チェック

活用シーン

  1. 01専門家評価型 AI ベンチマークの設計
  2. 02大規模な評価項目のレビュアー割り当て
  3. 03ベンチマークのデータ収集と分析の準備

インストール

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

$npx skills add https://github.com/aperivue/medsci-skills --skill design-ai-benchmarking

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

同梱ファイル

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

skill.yml
references/
anchor_rotate_reader_allocation.md
benchmark_export_schema.json
elicitation_rubric_template.md
tests/
test_reader_allocation.py

詳細

Design-AI-Benchmarking スキル

標準出力

## AI-Benchmark Design Review
Evaluation question: ...
Arms / systems compared: ...
Reference (human-expert panel): ...
Unit of rating: (item / case / output)

### Rubric (decoupled dimensions)
- dimension -> construct -> anchors (1..k)

### Calibration probes (blinded, randomized)
- positive-control / known-bad / instability / mechanism-contradiction

### Reviewer panel
- n reviewers, metadata captured, per-reviewer randomized order

### Reliability plan
- IRR target on the anchor set of real items (ICC form + 95% CI) + control-item hit rate (a competence check, reported separately)

### Judge strategy
- human-as-judge / LLM-as-judge / both + adjudication rule

### Validity risks
1. ...

### Minimal fixes
- ...

### Decision
- Ready to collect / Needs rubric revision / Needs arm or judge redesign

レビュアー評価、参照ラベル、プローブの結果、評価者間一致度の統計は、収集した評価記録のみから得られます。決して捏造しないでください。裏付けとなる評価記録がないまま ICC、カッパ係数、またはスコアを報告することこそ、このスキルが防ごうとしている失敗です。参照文献を引用するのは、/search-litでDOIまたはPMIDを確認できた場合に限ってください。それ以外には [UNVERIFIED - NEEDS MANUAL CHECK] を付けてください。臨床上の定義、診断基準、またはガイドラインの推奨事項が未確認の場合は [VERIFY] を付け、ユーザーに確認を求めてください。


ワークフロー

フェーズ 1:評価の問いと比較対象を定義する

以下を書面で明確にします。

  • ベンチマークで裏付ける必要がある主張の正確な内容(例:「システム A の出力は専門家の出力と知覚上区別できない」であり、「システム A は本番環境への導入準備が整っている」ではありません)
  • すべての比較対象/システムと、それぞれが入力として受け取る内容(同一の項目、同一の情報へのアクセス、同一の出力形式)。どの比較対象にも隠れた優位性がないようにします。
  • 人間の専門家を参照基準とする場合、その専門家が誰で、正解ラベルを設定するのか、比較対象の一つとなるのか、またはその両方なのか
  • 評価単位(項目、ケース、出力)と、各レビュアーが評価する単位数

ゲート: ルーブリックを設計する前に、再構成した評価の問い、比較対象、参照基準をユーザーに提示し、確認を得てください。誤った再構成は、ベンチマーク全体の方向を誤らせます。

フェーズ 2:互いに独立した多次元ルーブリックを設計する
  • 評価軸を分離します。 各評価次元では、単一の構成概念を測定します。「出力が妥当/正確か」と、「新規性があるか」、「実現可能/測定可能か」、「既存のツールより価値があるか」、「行動を変えるか」を分けてください。候補は妥当性が高くても付加価値が低い場合があります(「実在するが冗長」)。単一の合算スコアでは、こうした違いが隠れてしまいます。
  • 尺度のすべての段階に短い言語的な説明を付け、確定前に少なくとも1名のレビュアーとアンカーを試験してください。
  • 弁別的妥当性を事前に規定します。 どの次元同士が相関し、どの次元同士が直交するかを仮定し、次元間の相関行列をすべて報告してください。
  • ${CLAUDE_SKILL_DIR}/references/elicitation_rubric_template.md から始めてください(次元、アンカー、プローブの種類)。
フェーズ 3:キャリブレーション用プローブを組み込み、ランダム化する

尺度の基準を示し、評価者のドリフトや疲労を測定し、ルーブリックとパイプラインを監査するため、意図的に用意した少数のコントロール項目を、評価者に伏せてランダムに配置します(どの評価者にどの項目を提示したかを probe_arm フラグで記録します)。種類は4つあります。

  • ポジティブコントロール/「良すぎる」項目 — ほぼ自明な項目です。評価者が「効果が最大である」ことを「最良である」ことと同一視しないか、また構成概念の独立性に関するゲート(フェーズ 7)が機能するかを検証します。
  • 既知の不良項目を使ったネガティブコントロール — 捏造された参照値や重要な統計量の欠落など、意図的に欠陥を設けた項目です。
  • 不安定性項目 — ホールドアウトで推定結果が逆転するか、再現されない項目です。
  • メカニズム矛盾項目 — 提案されたメカニズムに反する実証的な方向性を示す項目です。

プローブは、仮説に合うように捏造するのではなく、意図的に組み込むか、判定するものです。

フェーズ 4:レビュアーパネルを構成する
  • 想定する専門性の幅をカバーするレビュアーを採用し、層別化を行う場合は事前に規定します。
  • レビュアーのメタデータ(経験年数、過去のAI評価経験、サブスペシャリティ)を記録します。
  • 項目の順序をレビュアーごとにランダム化し(全体で共通のシードを一つ使うのではなく)、その順序を記録し、順序と疲労の影響を分析する計画を立てます。
  • 各項目を単独で評価するよう求めます。自由記述で項目間の参照が見られる場合は、評価が独立していないことを示します。

ゲート: 採用を確定する前に、パネルの構成、層別化、ランダム化の計画をユーザーに提示し、確認を得てください。

フェーズ 5:評価者間信頼性の目標を設定する
  • 信頼性の統計量とその形式を事前に指定します。評価者が複数いる場合は、モデルを明記した ICC(例:ICC(2,1):二元配置変量モデル、絶対一致、単一評価者)または Krippendorff の α(順序尺度)を使います。重み付き(Cohen の)κは評価者が 2 人の場合の統計量です。また、妥当な目標値を設定します。必要な信頼区間の幅に合わせて項目数を決めます。ICC の精度は主に項目数によって決まります(Koo & Li、J Chiropr Med 2016)。
  • 仕込み済みの対照項目は評価者の能力確認であり、信頼性の根拠ではありません。 正解が既知の対照と不正解が既知の対照について、正答率を報告します。対照項目で算出した ICC を、ルーブリックや尺度の妥当性の根拠として示してはいけません。ICC は項目間のばらつきに応じて変わり、対照項目は意図的に極端な値にしているため、実項目に対する評価者の信頼性がどうであれ ICC は高くなります(評価者 5 人、ノイズは同じでも、仕込み済み対照 4 項目では ICC(2,1) が 0.89、実項目 40 項目では 0.16)。また、少数の項目に依存しています。
  • 代表性のある実項目のアンカーセットで信頼性を報告します。形式を明記した ICC とその 95%信頼区間に加え、一致度の指標(完全一致率、SEM)も示します。信頼性は評価対象の項目の異質性に左右されるためです(de Vet et al., J Clin Epidemiol 2006)。対照項目の正答率が高いにもかかわらず実項目の ICC が低い場合、評価者の不注意ではなく、項目間に真のばらつきがほとんどないか、ルーブリックで項目を区別できていないことを示しています。
  • 安定した一致度の推定に必要な、項目あたりの最小評価数を計画します(計算方法は /analyze-stats を参照してください)。
フェーズ 5b:負担制約下での評価者の割り当て(アンカーとローテーション)

項目プールが 1 回のセッションで 1 人の評価者が評価できる数を超える場合、全員に全項目を評価させてはいけません(これでは項目プールが評価者 1 人あたりの上限に制限されます)。アンカーとローテーション(アンカーセットと、ローテーションする不完全ブロックを組み合わせる方法。評価者のペアが同じ頻度で共同評価するわけではないため、バランス型不完備ブロック計画ではありません)を使います。つまり、全評価者が実項目の共通のアンカーセット(評価者間信頼性を担うセット。仕込み済みの対照項目が担うのは能力確認のみです)を評価し、それぞれがローテーションする固有のブロックを評価します。通常、制約となるのは利用可能な専門評価者の人数なので、必要な評価セットの規模を決めるため、逆問題(評価者 R 人で扱える最大の項目プール)を解きます。評価を始める前に、アンカーの構成、項目あたりの評価者数、ローテーションのシードを事前に指定します。数式、トレードオフ、標準ライブラリのみを使った実装については ${CLAUDE_SKILL_DIR}/references/anchor_rotate_reader_allocation.md を参照してください。

フェーズ 6:判定者の戦略と裁定を選ぶ
  • 人間を判定者とするか、LLM を判定者とするか、または両方を使うかを決めます。LLM 判定者も追加の評価群の 1 つです。極端な対照項目だけでなく、実項目のアンカーセットで人間の評価パネルと照合して、その評価を検証する必要があります。
  • 意見が一致しない場合の裁定ルール(多数決、3 人目の上級レビュアー、合意形成のための協議)と、裁定者を事前に指定します。
  • 可能な限り、判定者に評価群の識別情報を伏せます。やむを得ず識別情報を開示した場合は記録します。
フェーズ 7:構成概念の独立性と情報漏えいの防止策
  • 結果の定義上の構成要素にあたる予測因子や入力は除外し、結果を定義する構成要素から作られた、ほぼ恒等的な複合指標にはフラグを付けます。このような指標は結果を過大評価し、ほぼ循環論法となるため、発見事項ではなく、明示的にラベル付けした検証用項目として扱います。
  • いずれかの評価群だけが、意思決定後または結果に由来する情報を得ていないことを確認します。
  • 基準ラベルが、評価対象の同じモデル出力から導出されたものではないことを確認します。
フェーズ 8:構造化エクスポートスキーマを確定する

${CLAUDE_SKILL_DIR}/references/benchmark_export_schema.json をベースに、機械可読な評価記録を JSON スキーマとして記述します。各評価項目について、すべてのルーブリックの次元の評価、自由記述の根拠、フォローアップフラグ、probe_arm フラグ、評価者 ID とメタデータ、項目の順序、所要時間を含めます。

ゲート: 最終的なルーブリック、プローブセット、パネル計画、判定戦略、エクスポートスキーマをまとめて提示します。評価が始まる前に、ユーザーから明示的な承認を得てください。収集開始後の変更は、比較の妥当性を損なうためです。


引き継ぎルール

  • ICC(明記された形式)/Krippendorff の α/カッパ(評価者 2 名)/DeLong、評価者間一致度のサンプルサイズ、ベンチマーク結果の効果量の実世界に即した解釈については、/analyze-stats に引き継ぎます
  • 設計確定後、STARD-AI、CLAIM、TRIPOD+AI の項目別報告については、/check-reporting に引き継ぎます
  • ベンチマークを取り巻く研究全体(コホートのロジック、分析単位、比較対象)についてもレビューが必要な場合は、/design-study に引き継ぎます
  • 評価結果があり、原稿を評価する場合に限り、/peer-review または /self-review に引き継ぎます

コメント