author-calibrated-eval git:20260924.b3b0c67A

Immutable. This exact content never changes and is served at /api/v1/blob/31c55562a8ab0ef2.

---
name: author-calibrated-eval
description: LLM が書く読み物（本文・要約・解説文）を、著者の読みを正解にして磨くループの組み方と回し方。材料の固定、難所セット、著者の blind 読み比べ、強いモデルの参照稿で天井を測る、LLM 判定役は忠実さの足切り専任。/author-calibrated-eval で呼ぶ。NOT for — 判定役のプロンプト・判定形式の設計（→ llm-as-judge）、測定値・閾値の妥当性（→ measurement-discipline）、README の改稿（→ readme-writer）。
user-invocable: true
disable-model-invocation: true
origin: shimo4228
---

# Author-Calibrated Eval

生成された文章の「読む価値」の正解は、その文章を読む人（著者）の目にある。ループはこの前提で
組む。役割は三つに分ける。

| 何を見るか | 誰が見るか |
|---|---|
| 読みやすさ・読む価値（好み） | **著者**の blind 読み比べ |
| 忠実さ（材料に無いこと・比較の相手・限定・対象のすり替え） | **LLM 判定役**。二値チェックの足切り |
| 形式（引用記号の位置、印の有無、字数） | **コード** |

LLM 判定役は、読みやすさを総合判断させても著者の代わりにならない。実測（2026-09-23、
jev-research-pipeline）: 「情報量が多いことは勝つ理由にならない」と明記したルーブリックでも、
Opus の判定役は両方の順番で情報の多い版を「わかりやすい」と選び、著者は短い版を「すごくわかりやすい」、
情報の多い版を「読みにくい」とした。一方で判定役は、著者が読んで気づかなかった比較相手のすり替えを
両方の順番で拾った。

## 1. 材料を固定する

- 実際の出力を作ったときの入力（その日の材料一式）を 1 件ずつ固定する。材料に第三者の原文が
  含まれるなら、公開 repo ではなく非公開の置き場に置く
- 1 件を dev か holdout に割り当てる。割り当ては件の id だけから決める（後で件数が増えても
  件が dev と holdout の間を移らない）
- 書き手に渡すものと、判定役・著者に見せる材料は同じにする。判定役にだけ短く切った抜粋を見せると、
  書き手が正当に使った事実を「材料に無い」と誤判定する

## 2. 最初に著者の読み比べをする（判定役を回す前）

判定役のループを回す前に、著者に 1 回読んでもらう。これを飛ばすと、判定役の基準と著者の基準の
ずれに気づかないまま、プロンプトを判定役に合わせて磨き続ける。

- 1 件につき 3 本を並べる: 今の出力 / 候補 / **強いモデルの参照稿**（同じ指示・同じ材料）。
  どれがどれかは伏せ、並び順は件ごとに変え、対応表は別ファイルに置く
- 著者に聞くのは 2 つだけ: 「一番良いのはどれか」「なぜか（一言）」。「全部ダメ」も答えとして受け取る
- 参照稿の読まれ方で、原因を切り分ける
  - 強いモデルでも同じ不満が出る → 原因は書かせ方（指示の枠組み・材料の渡し方）。モデルを
    替えても直らない
  - 強いモデルだけ良い → 原因はモデル。プロンプトを磨く前に、使うモデルを決める
- 著者の一言は、そのまま次の指示とルーブリックの材料になる（例: 「目が滑る」「前提の説明を
  省略している」「変な断り書きが微妙」）

## 3. 難所セットで回し、節目で広げる

- dev から、**失敗の型ごとに 1 件**を選んで難所セットにする（例: 解釈の言い切り / 別々の結果を
  因果でつなぐ / 引用番号のずれ）。1 周はこの数件だけで回す
- 候補ができるたびに難所セットで確かめる: 判定役の足切り → 著者が 1 件 1 本を読む
  （聞くのは「読めるか」「どこで止まったか」）
- 難所セットで著者と足切りの両方を通ったら、**holdout から型の違う数件**を書かせ、足切りと著者の
  読みで確かめる。難所に合わせた磨き込みが、見ていない材料でも通るかを見る段
- 変種の軸は、指示 × モデル × 材料（厚さ）× 自己点検の 2 段目。磨く作業は、本番とは別の無料枠を
  持つモデルで回してよい

## 4. 足切りの判定役

判定役の中身は skill: llm-as-judge の型で作る（二値のチェック、根拠 1 行、致命的な No が一つで
不合格、数値の採点と集計を持たない）。ここでは、この用途で効いた点だけを置く。

- **チェックの中身**: 数値の中身（何の数値か）と比較の相手 / 原文の限定（「〜しうる」「多くの場合」）の
  保持 / 設計の意図を結果として書いていないか / 研究の対象のすり替え / 引用先に無い内容
- **判定の前にコードで確かめる**: 引用記号の位置、印の有無、字数。判定役にはその結果を事実の行として
  見せる。コードの検査が誤判定すると判定役の足切りも引きずられるので、検査を直したら既存の草稿にも
  掛け直してから判定役に渡す
- **1 本ずつ判定する**: 足切りは合否なので、草稿 1 本ごとに判定すればよい
- **判定役は軽くする**: Read / Write だけを持つ専用 agent を定義する。汎用の subagent は起動のたびに
  全ツール定義と常駐ルールを読むため、1 回の判定が約 8.5 万トークン、専用 agent なら約 2.5 万
  トークンだった（2026-09-23 実測）。書き出し先は、そのセッションが書ける場所（scratchpad など）にする

## 5. 著者の読みから、書き方の原則を取り出す

著者の一言を、指示の原則に翻訳する。2026-09-23 のループで効いた翻訳の例:

| 著者の一言 | 指示に入れた原則 |
|---|---|
| 目が滑る / 前提の説明を省略している | 論文を読んでいない読者への説明として書く。研究ごとに「取り組んだ問題 → やったこと → わかったこと」。専門用語は初出で言い換える |
| 情報量は多いが読みにくい | 持ち帰る事実を研究 1 本につき 1〜2 個に絞る（文の長さではなく、事実と固有名の数が効いていた） |
| 変な断り書きが微妙 | 「直接扱った研究ではない」のような断り書きをやめ、研究の対象を説明の中で示す |
| 短すぎて中身を拾えているか不安 | 研究ごとの 3 要素を最低 1 文ずつ、全体の字数に下限を置く |

原則を足したら、足切りで新しい型の崩れが出ていないかを必ず見る。平易に言い換えるほど、限定が落ちて
断定に寄る（「〜しうる」→「〜する」）。読みやすい文章の中の事実の崩れは、読む人には見えない。

## 6. トリビアルな評価を見分ける

次の比較は、改善を測っていない。

- **弱い基準線に勝つ**: 短い言い換えの羅列と、説明を尽くした版を比べれば後者が勝つ。どんな書き直しでも
  勝つ相手との比較は、良くなったかを示さない
- **自分で書いたルールへの遵守**: 足切りの合格率が上がったことは、指示に従えるようになったことを示すが、
  読む価値が上がったことは示さない
- **差が出ない比較**: 軸のほとんどが tie なら、その比較から学べることは少ない
- **判定のばらつきと同じ大きさの差**: 同じ草稿が順番や回で合否を変えるなら、版の差として読まない

迷ったら、著者に 1 件読んでもらう方が、判定役を何十回回すより速く正解に近づく。

## 参照例

jev-research-pipeline（2026-09-23）: `src/jev_research_pipeline/pipeline/prose_bench.py`
（`jrp prose export|bench|read|gate` — 材料の固定 / 草稿 / 著者向けの blind 読み比べ / 1 本ずつの
足切り）、足切りのチェック `docs/prose-rubric.md`、判定役 `.claude/agents/prose-judge.md`、
プロンプトの変遷 `bench/prose/prompts/`、手順は同 repo の `AGENTS.md`「本文を磨く」節、経緯は
`docs/design/pipeline-design.md`「Prose bench」節。