Eval 入門

Transcript

1. Eval 入門 計測から意思決定へ LLM に何かを判定させるとき、その判定が信用できるかをどう測り、測 った数字をどう使うか。 統計の予備知識がない人が、最初に一度だけ通しで読むための資料です。 → ← はじめに で移動、O で目次。全 37 枚。 01 / 37
2. はじめに 「精度 90%」では、何も決められない LLM に判定をさせる仕組みを作ると、必ず precision と recall という2つの数字が出てきます。多くの人がここで止まります。 数字は出たが、それが良いのか悪いのか、次に何をすればいいのか が分からない。 はじめに この資料のゴール 数字を見て、次に何をすべきかが言えるようになること。モデルを直すの か、閾値を動かすのか、判定基準を書き直すのか、予算を増やすのか。 前提知識 不要です。用語は出てきた場所で説明し、数字はすべて共通の一つの例 （次ページ）で計算します。数式は3つだけ、いずれも足し算と割り算です。 02 / 37
3. はじめに 2つの数字は、それ自体が目標ではない precision と recall は測定器の目盛りであって、目的地ではありません。目的地を決めずに目盛り だけ眺めていても、進む方向は決まりません。 Eval のダッシュボードを眺めて悩む時間の多くは、 「何を最適としたいのか」を言葉にしていないことから来ています。 この資料は、目盛りの読み方（第1〜2部）と、目的地の決め方（第3部）の両方を扱います。後者の ほうが重要です。 はじめに 03 / 37
4. 全体像 この順に進みます 第 1 部 第 2 部 第 3 部 4つのマス、2つの分母、そして必ずはまる3つ の落とし穴。 1つの数字ではなく曲線で見る。閾値、PR、 ROC、AUC。 どういう型の問題として解くかを決め、曲線 上のどこに立つかを選ぶ。 数字を読む 曲線を見る 第 4 部 第 5 部 Eval の品質は正解データの品質を 超えません。 どこまで良くできるのか。努力が報わ れない場合の見分け方。 正解データを作る はじめに 意思決定に使う 天井を見極める 04 / 37
5. はじめに この資料を通して使う一つの例 抽象的な話が続くと分かりにくいので、以降に出てくる数字はすべて次の一つの例で計算しています。自分の業務に置き換えながら読んでく ださい。 例 — チェックリスト業務の自動化 提出物 1件につき 100 項目を人がチェックしている 1項目の確認に 1分 → 1件あたり 100分 項目の 1% に不備がある（1件あたり平均1個） 不備が1つでも残るとやり直しや問い合わせになる この作業を LLM の判定で減らしたい はじめに 当てはまる業務 書類の不備チェック、契約書レビュー、生成物の品質確認、入力データの検証、コンテ ンツの規約チェック——小さな判定を多数まとめて人が見ている業務すべてに同じ 構造があります。 用語 項目 = 判定の最小単位／件 = 人が1つと数えるまとまり（この例では100項目）／不 備 = 見つけたいもの（陽性） 05 / 37
6. 第 1 部 — 数字を読む Eval は結局のところ二値分類器 「この出力は合格か不合格か」「この回答に不備はある か」。Eval がやっているのは、各ケースに Yes / No を付け る作業です。 そこに正解ラベルを突き合わせると、結果は必ず4通りの どれかに落ちます。 呼び方の規則: 1文字目 True / False は予測が当たったか、2文字目 Positive / Negative は予測したラベル。だから FP は「陽性と予測して 外れた」。 数字を読む 予測: 陽性 予測: 陰性 実際: 陽性 実際: 陰性 TP FP 拾えた正解 空振り FN TN 見逃し 正しく除外 この4つの数だけで、以降すべての指標が作れる 06 / 37
7. 第 1 部 — 数字を読む すべては分母に何が入っているか PRECISION — 適合率 RECALL — 再現率 TP TP TP + FP TP + FN 分母は自分が「陽性だ」と言った数。自分の挙動なので、判定を厳しくすれ ば減らせます。 「私の言うことをどれだけ信じてよいか」 分母は実際に陽性である数。データ側の性質で、こちらの挙動では1ミリも 動きません。 「私に任せて漏れがないか」 この2つは違う質問に答えています。だから片方だけ見ても意味がありません。この資料でいちばん大事な1枚です。 数字を読む 07 / 37
8. 第 1 部 — 数字を読む どちらも、単独なら簡単に満点にできる recall を 100% にする方法 全ケースを「陽性」と判定する。取りこぼしゼロで recall は 1.0。何の役に も立ちません。 precision を 100% にする方法 いちばん自信のある1件だけを陽性にする。99件の見逃しは precision の 分母に入りません。 数字を読む 片方だけを目標にすると、システムは自動的にもう片方を捨てる方 向に最適化されます。 片方だけの改善報告を見たら、 もう片方がいくつだったかを必ず聞く。 報告のたびに分数で書く習慣をつけると安全です。「precision 0.83」ではなく 「0.83 (99/119)」。分母が見えるだけで多くの誤解が防げます。 08 / 37
9. 第 1 部 — 数字を読む F1 は要約であって、目的ではない 2つを1つにまとめたいときに使うのが F1。調和平均なので、片方が 極端に低いと厳しく罰します。 P=1.0, R=0.02 単純平均 → 0.51 F1 のとき → 0.039 おかげで「全件陽性」の逃げ道が塞がれます。 数字を読む ただし、前提がある F1 は「見逃しと空振りは同じコスト」という主張を勝手に置いています。現 実にそれが正しいことは、ほとんどありません。 見逃しが致命的なら 本番に流出する不備、顧客クレーム → recall を重く 空振りが高くつくなら 人のレビュー時間、警告の無視 → precision を重く 09 / 37
10. 第 1 部 — 落とし穴 ① 探しものが珍しいと、precision は崩壊する 検出率 99%、誤検出率 5%。優秀に見える判定器を、例の 100 件分 = 10,000 項目に流します。不備率 1% なので不 備は 100 個です。 全 10,000 項目 実際に不備あり 100 TP 99 検出成功 問題なし 9,900 FN 1 見逃し FP 495 空振り 陽性と判定したのは 99 + 495 = 594 項目 当たりはそのうち 99 件しかない 落とし穴 recall TN 9,405 正しく除外 = 99.0% precision = 16.7% アラート6件に5件が空振り。判定器は何も変わっていな いのに、対象データの不備率が下がっただけで崩れまし た。 10 / 37
11. 第 1 部 — 落とし穴 ① だから accuracy は、ほぼ常に無意味 前ページと同じデータで、「全件を問題なしと判定する」だけの判定 器を考えます。何もしないのと同じです。 99% ACCURACY 不備を1件も見つけていないのに。 落とし穴 実務で効いてくること 開発用データと本番で不備率が違えば、precision は再現しま せん。不備を50%混ぜたテストの数字は、本番の1%環境では通 用しない precision が低いのを見て「モデルが悪い」と結論する前に、探し ているものが希少すぎないかを疑う recall は不備率に影響されません。環境が変わっても持ち運べ る指標です 11 / 37
12. 第 1 部 — 落とし穴 ② その差は、本当に差ですか これらはすべて推定値です。推定値には誤差があります。 recall = 45/50 = 0.90 0.79 〜 0.96。かなり広い。 のとき、真の値がある範囲はおよそ 別のプロンプトが 42/50 = 0.84 を出しても、範囲が大きく重なる ので「悪化した」とは言えません。 誤差は 1 ÷ √件数 に比例します。件数を4倍にして、はじめて誤差が半分。 いちばん大事な注意 誤差を決めるのは総件数ではなく、その指標の分母の件数。全体で200ケ ース回していても、実際の不備が20件なら recall の実効サンプル数は 20 です。 件数 全問正解が意味すること 真の誤り率は 6% 以下 100 3% 以下 1,000 0.3% 以下 50 precision 1.000 落とし穴 は「完璧」ではなく「この件数では区別がつかない」の意味。 12 / 37
13. 第 1 部 — 落とし穴 ③ 困る単位と、測る単位は違う 例の業務で困るのは項目単位ではありません。100項目のうち1つで も不備が残れば、その1件がやり直しになる。 項目の見逃しは掛け算で効きます。項目 recall が 0.90 でも—— 9.5% 件単位の見逃し率 落とし穴 項目 RECALL 件単位の見逃し率 0.80 18.1% 0.90 9.5% 0.95 4.9% 0.99 1.0% 1件=100項目・不備率1%。1−(1−π(1−R))^100 「項目 recall 0.9 は良さそう」という感覚は、この表で崩れます。最 初に決めるべきは「誰がどの単位で困るのか」。 13 / 37
14. 第 2 部 — 曲線を見る 1つの数字は、曲線上の一点にすぎない 1.0 つまり「precision 0.95 / recall 0.60」は判定器の性質ではなく、判 定器 × 閾値の性質です。 閾値を書かずに (P, R) だけを比べるのは、車の性能を「時 速60kmで走ります」とだけ言って比べるようなもの。 noisicerp 閾値を下げると陽性判定が増え、当たりも空振りも増えます。結果、 recall は上がり precision は下がる。逆も同じ。 .75 .50 基準線 30% .25 0 基準線 1% 0 .25 不備率 1%（例と同じ）AP 0.63 .50 .75 recall 不備率 30% AP 0.95 1.0 同じ判定器です。データの不備率だけを変えました。ROC で見れば AUC 0.976 の まま動きません。 曲線を見る 14 / 37
15. 第 2 部 — 曲線を見る 曲線は2種類ある PR 曲線 — 横 R E C A L L / 縦 P R E C I S I O N 1.0 ROC .50 .50 llacer .75 noisicerp .75 .25 .25 0 0 .25 .50 recall .75 1.0 precision の分母が両クラスをまたぐので、不備率に強く影響される 使い分け 陽性が珍しく空振りが問題 → PR。環境をまたいでモデルの素の能力を比 べる → ROC。 曲線を見る 曲線 — 横 空振り率 / 縦 R E C A L L 1.0 0 0 .25 .50 空振り率 .75 1.0 両軸ともクラス内で分母が閉じるので、不備率を変えても動かない（2本が完全に 重なる） 必ず確認すること PR 曲線の基準線は不備率の水平線。precision 0.4 は、不備率30%なら 凡庸、1%なら40倍の改善です。 15 / 37
16. 第 2 部 — 曲線を見る AUC とは、順位付けの正しさ AUC = ランダムに選んだ「不備あり」1件のスコアが、 ランダムに選んだ「問題なし」1件より高い確率 0.5 が当てずっぽう、1.0 が完全。ROC 曲線の下の面積ですが、この確率としての意味のほうが本質 的です。 閾値を決める前に使える 全閾値にわたる要約なので、動作点が決まってい なくても比較できます。 曲線を見る スコアを2乗しても動かない 順位しか見ていないから。裏を返すと「その数字が 確率として正しいか」は何も語りません。 16 / 37
17. 第 2 部 — 曲線を見る いちばんの使いどころ — 問題の切り分け AUC 動作点の P/R 高い 悪い 低い 悪い 診断と、次にやること 識別はできている。閾値・校正・コスト設定の問題。まず閾値を振ってみる 本当に見分けられていない。どの閾値でも救えない。プロンプトやモデルを変える この判別をせずに「モデルを改善しよう」と動くと、まるごと無駄打ち になります。 曲線を見る この後の第3部で見るように、AUC が 0.976 でも precision が 0.16 にな ることがあります。それはモデルの失敗ではなく、不備率とコスト構造がそ うさせている。 17 / 37
18. 第 2 部 — 曲線を見る AUC を主指標にしてはいけないとき 陽性が珍しいとき 空振り率の分母は巨大な TN に支配され、 ROC は楽観的に見えます。→ PR と AP を見 る 極端な動作点のとき 全閾値の平均なので、絶対に使わない領域 の性能まで足し込んでいます。→ 使う範囲だ け見る 曲線が交差するとき A が高 recall 側、B が高 precision 側で優れ るなら、AUC の大小に意味はありません。 数字の直感が効かない例 見逃し率 9.8% / AUC 0.998 → 見逃し率 2.1% 例の業務で1件あたり3分だけレビューする条件です。AUC の差はわずか 0.008 ですが、実際の結果は約5倍違います。 AUC 0.990 → 曲線を見る 18 / 37
19. 第 3 部 — 意思決定に使う 最大化すべきは precision でも recall でもなく、損失の小ささ 目的関数はこれだけです。難しい記号は使っていません。 損失 = 見逃した件数 × 見逃し1件のコスト + 空振りした件数 × 空振り1件のコスト 閾値を動かすと、上の項と下の項が逆方向に動きます。この合計が 最小になる場所が、立つべき動作点。 意思決定 precision と recall は、この計算の途中に出てくる中間値にすぎま せん。 19 / 37
20. 第 3 部 — どういう問題として解くか まず、3つの型のどれかを選ぶ ここを決めずに指標を並べても、precision と recall のどちらを上げるべきかは永遠に決まりません。Eval 設計の本体はこの選択です。 型 A. 期待コスト最小化 B. 予算制約付き C. 暫定 A が使えるなら A 成立条件 見逃しと空振りのコスト比が言える 使えるレビュー工数に上限がある どちらも言えない 必要なのはコストの絶対額ではなく比だけ。しかも比を10倍見誤っても最 適点は2〜3倍しかずれません。桁が合っていれば十分です。 意思決定 決めるもの 閾値 予算内での recall — 主指標 期待コスト、校正 recall@予算、順位 F1 / Fβ C を選んだら、そう明言する F1 は「見逃しと空振りが同コスト」という主張であって、中立ではありませ ん。「まだコストを考えていません」という表明だと理解しておく。 20 / 37
21. 第 3 部 — どういう問題として解くか 選び方は、2つの質問で決まる Q1. 使えるレビュー工数に はっきりした上限があるか YES 型 B — 予算制約付き 上位 k 件をどう選ぶか コスト比を聞き出すコツ NO Q2. 見逃しと空振りの コスト比が言えるか YES 型 A — 期待コスト NO 閾値を計算で出す 型 C — 暫定 後で A か B に移す 実務では B がいちばん多い 意思決定 抽象的に「いくらですか」と聞くと止まります。共通の単位に翻訳する。 「空振り1件の確認に何分？」→ 空振りコスト 「見逃し1件の事後対応に何分？」→ 見逃しコスト 型 B が合意しやすい理由 「レビュワーは1日2時間しか使えない」「1件3分以内」といった制約は、抽象的なコス ト比よりはるかに合意が取りやすい。 21 / 37
22. 第 3 部 — どういう問題として解くか 型が変わると、見るべき指標も入れ替わる 同じ判定器でも、型が違えば評価軸が変わります。ここを取り違えると、良いモデルを落としたり、使えないモデルを選んだりします。 問い 必要なもの 主指標 precision は 配分 型 B — 予算が固定 この予算で足りるか（可否の判定） 順位だけ。上位 k 件を取るので、スコアが確率として正しいかは無関 係 recall@予算、使う範囲の AUC 予算で決まる従属変数。目標に置かない 型 A — 予算が可変 いくら払うのが正しいか（最適化） どこで打ち切るかを決めるため、確率として正しいこと（校正）が必須 期待コスト、校正の良さ 閾値の結果として決まる 閾値を超えたものを全部。荒れた単位からは多く、きれいな単位からは0 件 順位は完璧だが確信度が全部 0.9 に張り付いている判定器は、型 B では満点、型 A では使い物になりません。 意思決定 どの単位からも一律 k 件 22 / 37
23. 第 3 部 — 型 A の解き方 コスト比が決まれば、閾値は計算で出る 逆算 — 今の運用が主張しているコスト比 各ケースの「不備である確率 p」が手に入っているなら、陽性と判定 すべき条件はこうなります。 p> 空振りのコスト 空振り + 見逃し 見逃しが空振りの9倍高くつくなら閾値は 0.1、49倍なら 0.02。 意思決定 今の閾値 見逃し : 空振り 0.5 1 : 1 0.3 2.3 : 1 0.1 9 : 1 0.02 49 : 1 「precision 0.7 が欲しい」は、「見逃しは空振りの2.3倍しか痛くない」と宣言する ことと等価。「見逃しは絶対に許されない」と言いながら閾値 0.5 で運用している、 という矛盾がここで出ます。 23 / 37
24. 第 3 部 — 型 A の解き方 見栄えの悪い行が、いちばん安いことがある 3600 例の 10,000 項目。見逃し1件のコスト=50、空振り1件=1 とした場合 3000 失損のりたあ目項000,01 閾値 2400 1800 RECALL 損失 PREC. 0.02 0.869 0.155 1,131 0.10 0.705 0.396 1,584 0.30 0.540 0.669 2,325 0.50 0.436 0.810 2,830 最適点の precision は 0.16。ダッシュボードで最も見栄 えの悪い行が、損失では最良です。F1 で選ぶと閾値 0.3 付 0 0.2 0.4 0.6 閾値 谷は平ら。最小の5%以内に入る閾値は 0.012〜0.034 と幅があります。小数第3位まで詰めた 近になり、損失は 2 倍を超えます。 1200 最小 t=0.02 「最適値」に意味はなく、平らな谷の真ん中を取るほうが安全です。 意思決定 24 / 37
25. 第 3 部 — 型 A の解き方 precision 0.16 が許される場合と、許されない場合 実際に採用されている例 低い precision の判定器は単独では使われず、必ず後段がありま す。 がん検診 — 陽性適中率は数%。陽性者が精密検査に進む 検索の候補生成 — 数億件から1000件を引く段階。後段が絞る 不正検知の一次判定 —「止める」ではなく「追加認証」なら空振 りは極小 共通点は、空振りの処理コストが本当に安いこと。 違和感があるなら、モデルではなく式を疑う コストが線形でない 500件目の誤アラートは1件目と同じコストではありません。ある量を超え ると人は警告を読まなくなります そもそも実行できない 1日100件しか捌けないなら560件は「高い」のではなく不可能。→ 型 B へ 信頼という項が抜けている precision 0.16 のツールはアンインストールされます 意思決定 25 / 37
26. 第 3 部 — 型 B の解き方 完璧な判定器でも届かない上限がある 枠 k・不備が平均 d 件のとき、完璧な判定器でも recall はおよそ k/d で頭打ちになります。判定器の性能とは無関係な、算数の上限 です。 まずこれを計算する 上限が目標に届かないなら、判定器の改善では絶対に解決しません。こ の見極めは数日で終わります。3か月開発してから気づくのが最悪です。 意思決定 例 0.98 .75 限上の llacer 例の業務で「1件あたり3分まで」と決めると、人に見せられるのは 100項目のうち3項目。問いは「閾値をどこに置くか」ではなく「どの3 項目を選ぶか」、つまり順位付けの問題になります。 1.0 .50 0.37 .25 0 0 3 レビュー枠 3 件 5件 6 9 1提出あたりの平均不備件数 10 件 12 15 例（平均1件）なら枠3件でも上限 0.98 で余裕があります。しかし不備が平均8件あ る業務なら、上位3件が全部当たりでも上限は 0.37。 26 / 37
27. 第 3 部 — 型 B の解き方 上限が足りないときの4つの打ち手 ① 規則で書けるものを規則に落とす 「日付の形式」「開始日 < 終了日」「必須項目の記入」——こうした判定は precision も recall も厳密に 1.0。限界費用ゼロで recall を買える唯一 の手段で、優先度は常に最上位です。 ② レビュー1件あたりの時間を下げる 「1分/件」は白紙から読む場合の数字。判定根拠を添えれば20〜30秒。モ デル改善より安く効くことが多い。 意思決定 ③ 予算を増やす 曲線は左端で急峻。3分→5分の効果は10分→20分より大きい。この事実 を持って交渉する。 ④ 不備そのものを減らす 入力フォームの改善など上流の対策。判定の話ではなくなりますが、いち ばん効くことがあります。 ①〜④はどれも「LLM をどう良くするか」の話ではありません。型 B で行き詰まった とき、答えはたいてい判定器の外にあります。 27 / 37
28. 第 3 部 — 意思決定に使う 意思決定者に渡すのは、自分たちの単位の曲線 50% 現行の人手 4.9% PR 曲線をそのまま見せないでください。横軸を「1件あた りのレビュー時間」、縦軸を「残る見逃し率」に描き替える。 これが意思決定の単位です。 左端が急峻 — 予算の議論はこの曲線の上でやる 良い判定器の価値は「同じ recall を安く買える」こと 現行の人手に線を引く — 合格ラインはここ 0% 0.5 1 判定器 AUC 0.955 0.990 現行の人手 recall は 1.0 ではありません。0.95 なら、100分かけても 4.9% の見逃しが出ています。比べる相手は「完璧」ではなく「今の人」。 ）位単件（率し逃見る残 40% 30% 20% 10% 意思決定 2 3 5 10 1件あたりの平均レビュー時間（分） 0.998 現行の人手 100分 = 4.9% 20 28 / 37
29. 第 3 部 — 意思決定に使う 「わからない」を第三の選択肢にする 合格/不合格の二択をやめ、「判断できないものは人に回す」を加え ます。3つの行動のコストを比べ、いちばん安いものを選ぶ。 二値 → 見逃し 45 / 誤ブロック 29 三値 → 見逃し 23 / 誤ブロック 1 判定器は一切変えていません。二値ではトレードオフだった2つが同時に 改善します。 例の 10,000 項目で、見逃し=50・誤ブロック=20・レビュー=3 とした場合。注意 — 確率の軸では帯が広く見えますが、実データは左端に集中するので実際に人に回 るのは 2.3%（230項目）。帯の幅と件数は別物です。 意思決定 40 トスコのりたあ件1 効果 50 30 20 10 0 止める この帯を人に回す 0 .25 通す 人に回す .50 不備である確率 .75 1.0 29 / 37
30. 第 4 部 — 正解データを作る 過去のレビュー記録は、そのままでは使えない 代わりにやること — 二重レビュー なぜ使えないか 記録に残るのは「人が見つけたもの」だけ。人の見逃しは「問題なし」とし て記録されています。 LLM がそれを見つけると空振りに数えられる。良い判定器ほど悪く見え る、という逆転が起きます。 この罠は Eval を作る前に必ず共有してください。気づかないまま数か月進むこと があります。 正解データ 200〜300件を選び、2名が独立に精査します。2つのものが手に入り ます。 信頼できる正解データ 現行の人手 recall の推定値 — 2人の結果の重なり具合から、見 逃しの総数まで推定できる 2つ目が決定的です。これがないと、達成不可能な基準と永遠に戦う ことになります。 30 / 37
31. 第 4 部 — 正解データを作る 規模を決めるのは、総件数ではなく不備の件数 recall を ±6ポイントで測るには、不備が約100件必要です。ここか ら逆算します。 不備率 1% → 約 10,000 項目 1件=100項目 → 約 100 件 二重レビュー → 約 330 人時 不備率が10倍違えば必要件数も10倍。先に20〜30件を粗く数えて桁を掴んでくだ さい。 正解データ 正解データは 3 つに分ける 用途 開発用 閾値決定用 報告用 役割と注意 改善のたびに見る。必ず過学習する 閾値の選択も学習です 締切まで開けない ラベル作りが工数の大半を占めます。判定器の開発は実は最小。これを 最初に言わないと、開発が終わってから「正解データがない」で止まりま す。 31 / 37
32. 第 5 部 — 天井を見極める 1.0 に届かない理由は、3種類ある 1.00 理論上限 — 完全な判定 ③ モデルの能力 — 判定器そのものの限界 0.95 0.90 0.85 0.80 天井 ② 情報の十分性 — 入力に答えが含まれていない ① 定義の一貫性 — 人間同士が一致しない 実際に到達できる範囲 最も低い天井が、すべてを決める まず前提。規則で書き下せる判定なら 1.0 は厳密に達成で きます。 だから「1.0 を目指せるか」という問いは、多くの場合「この 判断は規則に書けるか」と同じ問いです。 書き下せない判断には3つの天井があり、いちばん低い天井が すべてを決めます。多くのチームが ③ を上げようと努力してい て、実際に効いているのは ① というのが典型的な失敗です。 32 / 37
33. 第 5 部 — 天井を見極める 見分け方は1つの実験で足りる 判定器が間違えた事例を30〜50件抜き出し、熟練者2名に独立にラベルを付けさせる。それだけです。 結果 2人が割れる 一致するが根拠が入力の外 即座に一致し根拠も入力内 当たっている天井 ① 定義の一貫性 ② 情報の十分性 ③ モデルの能力 打ち手 ルーブリック（判定基準）を書き直す。天井そのものが上がる 文脈を足す／その判定を諦めて人に回す プロンプト改善、モデル変更、few-shot 追加 打ち手がまったく違うので、混ぜてはいけません。仕分けずに「judge の誤り」と一括りにすると、プロンプト改善に投資し続けて何も改善しない、という失敗に直 行します。 天井 33 / 37
34. 第 5 部 — 天井を見極める 人の一致率が、そのまま判定器の上限 一致度（ Κ ）の読み方 意味 Κ 逆向きのチェックにも使える 報告された一致率が人間同士の一致率を上回っていたら、測定が壊れて います。片方の担当者に寄っているか、正解データが judge の出力から作 られている（循環している）か。 言い方にも注意を。「Aさんの精度が低い」ではなく「この観点は解釈が2通りある」 と言う。事実は同じでも、後者は基準を直す方向に議論が向かいます。 天井 < 0.2 0.2 – 0.4 0.4 – 0.6 0.6 – 0.8 > 0.8 ほぼ偶然。定義が共有されていない 低い。基準の再設計が必要 中程度。境界事例の整備で改善余地が大きい 実用範囲。判定器の上限もこの水準 高い。定義の天井は問題になりにくい 全体の κ だけを見ない。観点ごとに割ると「形式チェック 1.00 / 表 現の適切さ 0.57」のように壊れた場所が特定できます。 34 / 37
35. 第 5 部 — 天井を見極める LLM に判定させるとき特有の注意 Yes/No しか返させない 合否だけの judge では曲線が引けません。 点が1つしか得られず閾値も選べない。 対処は連続スコアを取ること。同じ judge を 10回サンプリングして賛成票の割合を使う のが手軽で、順位と確率の両方が改善しま す。 自己申告の確信度を信じる 「0〜1で確信度を」に返る数字はまず確率と して正しくありません。閾値の公式はそのまま では使えない。 対処は、補正をかけるか、検証データ上で損 失を直接測って最小点を探す。後者が手軽で 頑健です。 judge を検証していない judge が正解ラベルを付けているなら、Eval の数字は「judge との一致度」でしかありませ ん。 judge 自身の精度が全体の上限になります。 人間との一致率を別途必ず測る。 おまけ — Eval セットで満点が出たら それは「解けた」のではなく測定器の寿命です。全員が満点なら候補に順位が付かず、改善のループが止まります。難しい事例を足す合図。 天井 35 / 37
36. まとめ 数字を渡されたときの7つの確認 陽性を何と定義したか。定義が反転すると解釈が全部反転しま す 分母は何件か。比率だけの報告は信用しない 測ったデータの不備率は、本番と一致しているか どの動作点の話か。閾値の違うもの同士を点で比べていないか どの型の問題として解いているか。A / B / C のどれか、言えるか 正解データは信用できるか。judge が付けたなら、誰が検証した か カテゴリ別に割ったらどうか。全体 0.85 が、ある観点では 0.4 か もしれない そして最後に。precision と recall は判定器を評価する目盛りであって、意思決定そのものではありません。決めるべきは「見逃し1件は空振り1件の何倍痛い か」、あるいは「使える予算はいくらか」。それが決まれば、あとは計算です。 まとめ 36 / 37
37. 付録 この先を深掘りするための文献 まず 1 冊 統計的な手法比較 高柳慎一・長田怜士『評価指標入門 — データサイエンスとビジネスをつなぐ架 け橋』技術評論社, 2023 この資料とほぼ同じ範囲を、日本語で体系的に扱っています Japkowicz & Shah, Evaluating Learning Algorithms, Cambridge, 2011 意思決定としての分類 Provost & Fawcett, Data Science for Business, O'Reilly, 2013（邦訳『戦略的 データサイエンス入門』）第7〜8章 Fawcett, "An Introduction to ROC Analysis", 2006 曲線と校正 Davis & Goadrich (2006) / Saito & Rehmsmeier (2015) Guo et al. (2017) "On Calibration of Modern Neural Networks" まとめ 一致率・アノテーション Artstein & Poesio (2008) "Inter-Coder Agreement for Computational Linguistics" Pustejovsky & Stubbs, Natural Language Annotation for ML, 2012 Kahneman et al., Noise, 2021（邦訳『NOISE』） 測定の妥当性 / L L M J U D G E の実務 Jacobs & Wallach (2021) "Measurement and Fairness" Shankar et al. (2024) "Who Validates the Validators?" Hamel Husain のブログ（hamel.dev/notes/llm/evals/） 37 / 37