品質ゲートでは測れないこと

Stage 1 / Stage 2 の品質ゲートは「出力が最低条件を満たすか」「以前より悪くなっていないか」を OK/NG の二値で返します。しかし「プロンプトを変えたらどれだけ良くなったか」という問いには答えられません。

改善量を測るには、点数が要ります。品質ゲートのように「通過した／しなかった」だけでは、軽微な改善も大幅な改善も同じ「通過」にまとめられてしまうためです。

ここで quality-eval（品質評価採点）が登場します。

評価軸（rubric）の定義

採点の軸は機能ごとに設計します。たとえば LP コピー生成タスクなら「具体性」「訴求力」「論理の流れ」の 3 軸、Q&A 応答なら「正確性」「簡潔さ」「丁寧さ」の 3 軸、といった形です。

# quality_axes.py（例）
AXES = {
    "specificity":  "具体的な数値・固有名詞を使っているか（1–10）",
    "appeal":       "読者の購買意欲を喚起するか（1–10）",
    "logical_flow": "段落の流れに論理的な一貫性があるか（1–10）",
}

AI ジャッジには各軸を 1〜10 の整数で採点させ、採点理由も JSON で返させます。採点理由を記録しておくと、スコアが下がった原因を後から追えます。

2 つの採点モード

**絶対評価（absolute）**では、ゴールデンと生成結果を独立に採点します。それぞれのスコアを引き算した Δ（generated − golden）がプロンプト改善の正味の効果です。Δ > 0 なら改善、Δ < 0 なら悪化です。

ペアワイズ（pairwise）では、ゴールデンと生成結果を並べて「どちらが良いか」を AI に選ばせます。複数ケースで集計した勝率が改善の目安になります。ペアワイズは微妙な差を検出しやすい反面、どちらが「新しい」かが AI にわかると判定が偏る（Self-Preference Bias）リスクがあります。

繰り返し採点と信頼区間

1 回の採点で出た Δ や勝率は「偶然か、実力か」が区別できません。AI ジャッジは温度パラメータがある確率的なモデルなので、同じ入力でもスコアが揺れます。

--repeat N（N >= 2）を指定すると、各ケースを N 回採点して統計を取ります。温度を 0 にすると各回がほぼ同一になり意味がないため、未指定時は自動で 0.7 に引き上げます。

  • 絶対評価: Δ の正規近似 95% 信頼区間（CI）を計算する
  • ペアワイズ: 勝率の Wilson 95% CI を計算する

CI がゼロ差（絶対評価なら Δ=0、ペアワイズなら勝率 50%）を含まなければ 有意=✓ をレポートに付けます。有意マーカーのない改善は「誤差の範囲内かもしれない」と判断します。

Self-Preference Bias を避ける

生成モデルに自分の出力を採点させると、自分の回答に高い点を付けがちです（preference leakage）。これを避けるため、--judge-model オプションで生成モデルと異なるモデルを採点専用に指定します。

docker compose run --rm sim \
    --quality-eval \
    --repeat 5 \
    --judge-model claude-opus-4-5

出力成果物

実行後に 2 つのファイルが生成されます。

  • quality_eval.md ── 軸ごとの Δ・勝率・有意マーカーをまとめたレポート
  • quality_eval.csv ── 生スコア（repeat 列付き）

quality_eval.csv は後続のリリースゲートが「品質が有意に改善したか」を判定する第 3 シグナルとして読み込みます。

まとめ

  • 品質ゲートの OK/NG では「どれだけ改善したか」は測れない。量を測るには採点が必要
  • 絶対評価はΔで改善量を、ペアワイズは勝率で相対優位を見る
  • --repeat N で繰り返し採点し、信頼区間で「誤差か実差か」を判別する
  • --judge-model で採点者を生成モデルと分離し、Self-Preference Bias を防ぐ
  • 生成された quality_eval.csv はリリースゲートの第 3 シグナルとして使われる