その「精度」、あなたが選んだ定義ですよね

「精度を上げる」と言うとき、その”精度”は物理法則ではなく、誰かが選んだ定義でしかない。

合否だけを返す採点に最適化すると、その定義が拾う軸だけが磨かれ、拾わない軸は置き去りにされる。しかも数字は上がり続けるので、置き去りにされていること自体が見えない——貧しい定義に向かって全力で最適化すると、“正しいが平板”に綺麗に収束する（Goodhartの法則）。

だから改善が止まったとき、問いは2つある。「モデルは限界か？」は誰でも問う。飛ばされるのは、「私の”精度”の定義は、本当に測りたい良さを捉えているか？」のほうだ。私の場合、天井はモデルではなく定義にあった。

「精度を上げてくれ」。会議で最もよく飛ぶ指示のひとつだ。誰も反対しない。精度は高いほうがいい——当たり前に見える。

でも一度立ち止まってほしい。その「精度」とは、具体的に何のことか。 翻訳なら「意味が合っている率」か。要約なら「要点の網羅率」か。回答なら「事実誤認のなさ」か。どれも「精度」と呼べる。そして——どれを”精度”と呼ぶかは、あなたが選んでいる。 物理法則が決めた唯一の数字ではない。選ばれた定義だ。

私がこれに気づいたのは、数字が頭打ちになったからではない。対象読者の一言からだった。

思い込み：精度は一本の数字、上げ続ければいいと思っていた

翻訳品質を、私は一本の数字で管理していた。合否を返す採点者（judge＝AIの採点者）に訳を渡し、その合格率を「精度」と呼ぶ。judge は100件でも1000件でも「合格・不合格」を量産してくれる。この採点器は三つの軸——意味は合っているか、言語は正しいか、崩れていないか——をまとめて一つの「総合OK（overall_ok）」に畳んで返す。数字が一本なら、上がった・下がったで即断できる。運用としては綺麗だ。

そして私は、この数字を上げる算段だけを考えていた。良い訳を選び直し（best-of-N）、その選好でモデルを微調整する（CPO ＝良い例と悪い例の差からモデルに好みを教える手法）。総合OKを押し上げていく。もしこの数字がいずれ頭打ちになったら、それはモデルの容量が限界に達したサインだろう——そう読むつもりでいた。改善曲線が寝たら容量律速、というのは技術的には筋の通った推論に見える。私は、その推論を実行に移す前に足を止めることになった。

気づき：きっかけは、読者の一言だった——「正しいのに、良くなかった」

足を止めさせたのは、数字ではない。対象読者からのフィードバックだった。 「意味は正しい。言語も正しい。なのに、読んでも響かない」。正しいのに良くない、という指摘だ。

その声を手に、総合OKで合格になった訳を、原文と並べて読み直した。言われてみれば、そのとおりだった。合格の訳は、確かにどれも「間違っていない」。意味は合っている。言語も正しい。崩れてもいない。だが、良くはなかった。 正しいのに、平板だった。人が読んで心が動く訳と、条件を満たしただけの訳が、同じ「合格」の箱に入っていた。

からくりはこうだ。私の採点器は三軸を見ていた。だが本当に価値を分ける軸——読者にとっての”良さ”の核——は、その三軸に入っていなかった。 意味が合っていれば総合OKは yes を返す。だから採点器から見れば、平板な訳と生きた訳の区別がつかない。両方 yes だ。

ここで初めて、さっきの推論の危うさが見えた。もしあのまま数字だけを追って best-of-N と CPO を回し続けていたら、どうなっていたか。 総合OKは上がり、やがて寝る。私はそれを「モデルの限界」と読み、サイズを上げにいっただろう。だが天井はモデルにではなく、定義にあったはずだ。 採点器が拾わない価値の上では、改善が起きても数字に映らない。貧しい定義へ向かって最適化すれば、“正しいが平板”という一点に綺麗に収束していく——これは観測を待つまでもなく、構造からの必然だ。 読者の一言は、その袋小路に入る前に私を止めてくれた。

指標が目標になると、指標でなくなる（Goodhartの法則）

これは Goodhartの法則（ある指標を目標にした瞬間、その指標は良い指標でなくなる、という経験則。Strathern による定式化）が待ち構える、教科書どおりの罠だった。

総合OKは、もともと品質の代理指標（proxy ＝本当に測りたいものの代わりに測る、測りやすい近い量）にすぎなかった。本当に測りたいのは「読者が良いと感じるか」。それは測りにくい。だから測りやすい三軸の合否で代理した。ここまでは正しい。

問題は、その proxy を最適化の目標そのものに据えた瞬間に起きる。best-of-N も CPO も、賢く働けば働くほど「総合OKが上がる訳」に寄せていく。すると起きるのは、proxy が拾う軸だけが磨かれ、proxy が拾わない軸は置き去りにされることだ。しかも数字は上がり続けるから、置き去りにされていること自体が見えない。貧しい定義に向かって全力で最適化すると、“正しいが平板”という一点に、綺麗に収束していく。

だから「改善が止まった」ように見えたとき、問いは二つある。ほとんどの人は片方しか問わない。

• 「モデルは限界か？」——こちらは誰でも問う。そして、しばしばここで誤る。
• 「私の”精度”の定義は、本当に測りたい良さを捉えているか？」——こちらは問われないまま飛ばされる。

私の場合、答えは後者にあった。天井はモデルにではなく、定義にあった。

教訓

1. “精度”は選ばれた定義であって、与えられた事実ではない。 何を精度と呼ぶかを決めた時点で、拾わない価値を決めている。
2. 指標を目標に据えた瞬間、それは指標でなくなる。 賢い最適化ほど、代理指標が拾う軸だけを磨き、拾わない軸を平板に取り残す。
3. 改善が止まったら、モデルの前に定義を疑う。 真の定義は少数の人手較正セットに置き、採点器はそれとの一致で検証する。人＝定義、採点器＝量産。

だから、運用はこう変えた

一行にすると——「精度を上げる」の前に、「何を精度と呼ぶか」を設計する。 定義は測定の下流にある道具ではない。定義こそが、最上流の設計判断だ。具体的には四つに落ちた。

1. 最適化の前に、定義を疑う。 best-of-N や CPO を回す前に、まず「この採点器が拾っていない価値はないか」を現物で確かめる。貧しい定義の上で最適化を回すのは、間違った的に向かって全力で走ることだ。速く走るほど遠ざかる。

2. 一本の総合OKに畳まない。 総合OKは、価値の異なる軸を一つの箱に潰す。潰した瞬間、どの軸で負けているかが見えなくなる。本当に効く軸は、独立した軸として残して別々に見る。何を一本化し、何を分けて持つかは、「どっちが速い？」がそもそも愚問になるときで扱った、軸を畳まず分けて見るという骨格と同じだ。

3. 真の定義は人に置き、採点器は量産に使う。 究極の「良さ」の定義は、対象読者が自然だと感じるかどうかにある。それを少数の人手較正セットに刻み、それを ground truth として採点器を検証する。採点器が yes、人が「これは良くない」——このズレが出たら、直すのは訳ではなく採点器の定義のほう。 人＝定義、採点器＝量産、という分業にする。

4. 採点器を、そのまま信じない。 そもそも採点器は proxy であり、proxy には固有の癖とブレがある。合格・不合格の数字を意思決定に使う前に、採点器そのものを校正する——これはAIに採点させるなら、その採点を疑うところからで詳しく扱った。総合OKが proxy にすぎないという本記事の問題は、その実害の一形態だ。

改善が止まったら、それはしばしば限界の合図ではなく、定義が貧しいという合図だ。数字が動かなくなったとき、モデルを大きくする前に、自分が選んだ”精度”の定義を疑う。計測ファーストは「たくさん測れ」ではない。まず、正しいものを正しく測れ——そして”正しいもの”を決めているのは、いつだって、あなたが選んだ定義だ。

付録：生データ

本記事の核は定量値ではなく、定義の設計判断にある。裏づけとして残せる事実は次のとおり。