eval-design は何をしますか？
あなたは製品ではなく、計測を設計している。このスキルのアウトプットは、誰かが会議の場で擁護できる意思決定であり、単なる数値ではない。
ほとんどの場合、その意思決定とは次に何を修正するかです。システムをランク付けするだけの評価は報告書に過ぎません。しかし、最もコストがかかっている2つのことを特定し、再実行したときに修正が効いたことを証明してくれる評価は、開発ループとなります。後者を目指して構築しましょう。つまり、総合スコアよりも、失敗分類と基準ごとの内訳の方が重要です。それこそが、誰かが行動に移せる部分だからです。
スタンス
4つのルール。これらは意見であり、このスキルの要点です。
1. バイブスは禁止。 「感触が良くなった」は結果ではありません。変更が、固定されたセットで測定された明確な基準上の変化として表現できないのであれば、それは評価されていません。好きなら出荷しても構いません。ただし、テストされたと主張してはいけません。
2. すべての基準は反論可能でなければならない。 慎重なレビュアー2人が反対の立場に立てない基準は、何も測定していません。「アウトプットは役に立つか？」は基準ではありません。「返信は返金期間を日数で明示しているか？」は基準です。ルーブリック内のすべての基準は、それが解決するために書かれた特定の不一致を内包しています。→ references/rubric-design.md を参照。
3. デフォルトではLLMを判定機として使わない。 判定機はそれ自体がエラーレートを持つシステムであり、検証されていない判定機はそのエラーを総合スコアに紛れ込ませます。人間が最初にラベルを付け、そのラベルに対して判定機がキャリブレーションされ、一致度は判定機が生成したすべての結果の横に公開されます。→ references/judges.md を参照。
4. ベースラインを報告するか、さもなくば評価はマーケティング資料だ。 正規表現、キーワードルール、現在の本番システム、何もしないこと。出荷されたAI機能の約3分の1は、少なくとも1つの基準において、コストがかからない何かに負けます。そして、あなたはそれを、採用担当マネージャーやVPが見つける前に知っておきたいのです。
これらから派生する2つの構造ルール:
- ゲートは重みではなく、フロアである。 安全性、法的、または信頼性に関する基準は、平均的なパフォーマンスとトレードオフされてはいけません。フロアを下回るシステムは、いかなる価格でも候補になりません。加重平均はまさにこれを隠蔽します。
- 信頼区間がないならランキングはするな。 n=150の場合、3ポイントの差はノイズです。ノイズの範囲内でシステムをランク付けすることは、評価作業が読者を誤解させる最も一般的な方法です。
ワークフロー
この順序で作業してください。スコアリングにスキップしてはいけません。評価の失敗はすべて、その上のステップをスキップしたことに起因します。
- 意思決定を見つける。 結果によって何が変わるのか？「どのモデルを出荷するか」「これは無人運用できるか」「プロンプトの変更でリグレッションが発生したか」。何も変わらないなら、そこで止めてその旨を伝えてください。これこそがプロセス全体の中で最も価値のある瞬間であり、時に正直な答えは「評価は必要ない」です。
- 最初に失敗分類を書く。 基準よりも先に。実際の出力を30～50件収集し、すべてを読み、何が問題だったかをクラスタリングします。観察された失敗から導き出された基準は、想像から導き出された基準に常に勝ります。
→
references/failure-taxonomy.md - 分類を基準に変換する。 各基準に重み、不一致、そしてオプションでゲートを設定します。→
references/rubric-design.md - ゴールデンセットを構築する。 層別化され、敵対的で、バージョン管理され、人間が実際にラベル付けできる程度に小さいセットにします。→
references/golden-sets.md - 人間でラベル付けし、一致度を測定する。 2人のラベラーが同意できない場合、ルーブリックが壊れているのであって、ラベラーが悪いのではありません。ルーブリックを修正して再ラベル付けしてください。→
references/statistics.md - ここでのみ判定機の検討を許可する、そしてそれはキャリブレーションされたものに限ります。→
references/judges.md - AI以外のベースラインを含むすべてのシステムを実行し、
results.jsonを書き込み、レンダリングします。→references/scorecard-spec.md - 評価結果の文章は自分で書く。 スコアカードは数値を示します。人間が、行われているトレードオフと、その決定を覆す条件を記述します。
レンダリング
python3 skills/eval-design/scripts/render_scorecard.py results.json --md
これにより、自己完結型の scorecard.html（外部リクエストなし、ライト/ダーク対応）と、リポジトリ内で読むための SUMMARY.md が書き出されます。スキーマ: references/scorecard-spec.md。
python3 skills/eval-design/scripts/validate_rubric.py results.json
スコアカードを不誠実にするミスを検出して失敗します：重みの合計が1にならない、不一致が明記されていない基準、正当性のないゲート、ベースラインの欠落、または信頼区間内でのランキングの主張。
これを使うべきでない場合
- 意思決定を伴わない、一回限りのプロンプト調整。 出力を直接見れば十分です。
- ユーザーもサンプルも存在しない場合。 最初に30件の実際の入力を入手してください。想像上の入力で作られた評価は、あなたの想像力を測定しているに過ぎません。
- プログラムでチェックできる正解がタスクにある場合 — 算術、有効なJSON、コンパイル可能なビルドなど。ルーブリックではなく、チェックを書いてください。
- 誰かが既に下した決定を正当化するための数値を欲しがっている場合。 評価を構築する代わりに、そのことを声に出して伝えてください。
リファレンスファイル
必要に応じて読み込んでください。最初にすべてを読む必要はありません。
| ファイル | 読むタイミング |
|---|---|
references/rubric-design.md | 基準の作成または修正時 |
references/failure-taxonomy.md | 実際の出力から始める場合 |
references/golden-sets.md | ケースの選択と層別化時 |
references/judges.md | 誰かがLLM-as-Judgeを提案した場合 |
references/statistics.md | サンプルサイズ、信頼区間、一致度、ドリフト |
references/scorecard-spec.md | results.json の作成時 |
references/antipatterns.md | 誰かの評価をレビューする場合 |