その「97%改善」を、私は捨てた

この記事は、自社ブログの LYR Performance Note #014 に掲載したものの転載です。

華々しい数字ほど、生の出力を見て殺す

自動計測が「英字のゴミが97%減った」という朗報を返してきた。私はその数字を採用せず、捨てた。

生の出力を一枚ずつ見ると、97%は二重の計測バグだった。①圧縮工程の乱数でまれに壊れた個体が生まれ、②集計器の解析失敗フォールバックが生テキスト全体を数え上げていた。公正に測り直すと、三者はほぼ同等（5 / 7 / 9語）だった。

ただし、技術そのものまで巻き添えで葬らない。「指標は棄却、技術の可否は未解決」——どこまで分かって、どこから分からないかを線引きすることが、次に正しく測り直すための余白になる。

前回までで、自前の小さなモデルを圧縮（量子化）して、速く・安くした。品質はほぼ落ちない——ただし、全体の1割弱の"きわどい"ケースで、まれに崩れる。その崩れの一つが、翻訳結果に生の英語が混じる現象だ（日本語の訳文の中に、英単語のゴミが残る）。

この"英字残留"を潰すために、ある補修技術を試した。自動計測は、劇的な朗報を返してきた。英字のゴミが、97%減った。

私は、その数字をそのまま採用しなかった。この記事は、なぜ華々しい97%を捨てたかの話だ。

97%という朗報

補修技術（圧縮で失われた精度を、モデル内部の重みを組み替えて取り戻す後処理。以下ローテーションと呼ぶ）を、強く圧縮したモデルにかけて、マンガ30ページを翻訳させた。集計はこうだった。

指標	補修前	補修後	差
英字のゴミ（語数）	968	33	−97%
英字が残ったページ数	19/30	5/30	−74%
基準モデルとの一致度1	81.6%	85.8%	+4.2pt

しかも、圧縮していない高精度版（FP16）と並べると、物語は完璧に見えた。

• 高精度版のゴミ：3語（ほぼクリーン）
• 強く圧縮した版：968語（圧縮がゴミを+965語も暴発させた）
• 補修をかけた版：33語（935語を回収し、ほぼ高精度版の水準に戻した）

「圧縮がゴミを壊滅的に増やし、補修がそれを高精度版の水準まで回復させる」——教科書のようにきれいな筋書きだ。このまま採用すれば、「補修技術は本番投入の価値あり」と結論できた。

数字が、良すぎた

手が止まったのは、−97%があまりに清潔だったからだ。現実のモデルの崩れは、こんなに素直に一方向へ揃わない。

もう一つ、別々の計測が食い違っていた。同じ補修技術を、一般的な文章の指標（perplexity）で測ると、回復は29%どまり。翻訳タスクでだけ97%回復——二つの指標が桁違いにズレるとき、たいていどちらかの計測が壊れている。

だから、集計値を信じる前に、生の出力そのものを見ることにした。3モデル（高精度版・圧縮版・補修版）にマンガ30ページを訳させ、出力をブラウザに並べて、一枚ずつ目で見た。

公正に測り直す

見て、すぐに分かった。是正は二段あった。

是正その一：数え直す。 集計プログラムは、モデルの"独り言"まで英語として数えていた。モデルは訳文を返す前に、内部で思考メモ（</think>で閉じる作業領域）を書く。訳文だけを取り出して——思考メモを除いて——数え直すと、高精度版と補修版のゴミは一桁に落ちた。

是正その二：個体を引き直す。 だが圧縮版の 968 は、数え直しだけでは消えなかった。この個体は思考メモではなく訳文そのものに生の英語を吐いていたからだ（後述の穴①）。同じ圧縮工程をやり直して正常な個体を引くと、訳文値は 7 語に落ちた。

二段の是正を通した結果がこれだ（圧縮版の列は、引き直した正常個体の値）。

	高精度版	圧縮版※	補修版
英字のゴミ（語数）	5	7	9
ゴミが残ったページ	4	5	8

※ 引き直した正常個体。968 を吐いた不運な個体そのものではない。

三者、ほぼ同じ。 正常な個体どうしを、訳文だけで数えれば、圧縮も補修もゴミをほとんど動かさない。968 も 33 も、二つの是正の前でだけ立っていた幻だった。−97%は、跡形もなく消えた。

図1：同じ現象を、二つの物差しで測ると。自動指標では圧縮版968語・補修版33語と巨大な差に見えたが、生の訳文だけを数え直すと三者とも5〜9語でほとんど差が無い。−97%は、物差しの側の産物だった。

二重の穴

では、あの968はどこから来たのか。二つのバグが噛み合っていた。

穴①：圧縮に、乱数が混じる。 モデルを圧縮する工程には、少量のサンプルで丸め方を調整する"キャリブレーション"があり、ここに乱雑さが入る。同じ手順でも、回すたびに微妙に違うモデルができる。運悪く一度、"壊れた"圧縮版が生まれ、それが訳文ではなく生の英語を吐いた。同じ工程をやり直したら、30ページすべて正常・ゴミは7語だった。968は、たまたま引いた不運な一個体にすぎなかった。

穴②：集計プログラムの"逃げ道"。 ゴミを数えるプログラムは、モデルの構造化出力（JSON）を解析して訳文だけを取り出す設計だった。だが解析に失敗すると、生テキスト全体の英語を数えるフォールバック（逃げ道）に落ちる。思考メモも、指示文の残響も、何もかも英語としてカウントする。連鎖はこうだ。

壊れた個体 → JSON解析に失敗 → 逃げ道が生テキスト全体を英語カウント → 968 に爆発

不運な個体（穴①）×過大カウントする逃げ道（穴②）が掛け算になって、巨大な偽の差が生まれた。 どちらか一方だけなら、ここまで派手には壊れなかった。

皮肉なことに、「勝者」だったはずの補修版のほうに、別の欠陥があった。30ページ中29ページで、思考メモの</think>タグが訳文の前に漏れ出していた。集計値は、この後退をひとことも教えてくれなかった。

本物だけ、残す

騒がしい数字を捨てたあと、手元に残った"本物"はこれだけだ。

• 一般文の perplexity：10.65 → 10.42
• 基準モデルとの一致度：81.6% → 85.8%

小さいが、確かな改善。派手さはない。

そしてもう一つ、捨て方にこだわった。私は「補修技術は無効だ」とは結論していない。</think>の漏れも、ゴミが減らないことも、私の計測手順の交絡（正規のサーバーでなく、その場しのぎの評価経路で測った）に由来する可能性が十分ある。だから結論はこう畳んだ——「−97%という自動指標は棄却。この補修が本番で効くかは未解決で、正しく測り直す必要がある」。

「計測が間違っていた」と「技術が間違っていた」を混同しないこと。華々しい数字を殺すのと同じくらい、技術そのものまで巻き添えで殺さないのが、公正さだ。

教訓

1. 華々しい数字ほど、生を見て殺す。 −97%のような清潔すぎる数字、指標どうしの桁違いのズレは、勝利ではなく警報だ。集計値の上流にある生の出力を、自分の目で一枚ずつ見るまで、朗報を採用しない。

2. 非決定な工程はseedを固定し、集計器の"逃げ道"を疑う。 乱数が混じるなら一回の結果は個体差でしかない（再現しない改善は、改善ではない）。そして解析失敗時のフォールバックは、静かに巨大な偽シグナルを作る——握りつぶした先で何を数えているかまで見る。

3. 計測の誤りと、技術の誤りを、分けて畳む。 偽の勝利を捨てるとき、技術まで巻き添えで葬らない。「指標は棄却、技術の可否は未解決」という線引きが、次に正しく測り直すための余白になる。

そして根っこにあるのはマニフェストの第1原則「まず計測せよ」——ただし正しく。間違った計測は、測っていないより悪い。 偽の勝利を、本物として出荷させてしまうからだ。

---

付録：生データ

対象: 4Bモデルを強く圧縮（INT4）＋学習型ローテーション補修、マンガ30ページ翻訳、A100で測定。

項目	数字	条件・留保
自動指標（誤）	英字ゴミ 968→33語（−97%）、残存ページ 19/30→5/30	FP16基準 = FP16:3 / 圧縮:968 / 補修:33
公正な再測（訳文値のみ）	FP16=5 / 圧縮版=7 / 補修版=9語（残存ページ 4/5/8）＝三者ほぼ同等	圧縮版の7は、968を吐いた個体ではなく引き直した正常個体の値
穴① 非決定性	圧縮版がまれに degenerate 化し生英語を吐く	再生成すると 30/30 正常。本番では個体差リスクが残る
穴② 集計器のフォールバック	JSON解析失敗時に生テキスト全体の英語をカウント	逃げ道が巨大な偽シグナルを作った
本物として残る改善	wikitext ppl 10.65→10.42、teacher-forced 一致度 81.6→85.8%	一般文の回復は gap の約29%どまり（翻訳タスクの「97%」と桁違い＝片方が壊れている兆候）
補修版の副作用	</think> タグが 30ページ中29ページでJSON前に混入	集計値には現れない
未解決	計測経路（非正規serve）の交絡の可能性	正規serve＋free生成＋pairwise judge＋calib seed固定での再評価が必要。「見送り」ではなく「要正規評価」

---

シリーズ「モデル — 小さく、速く、賢く」第4回の記事です。原文と続きは LYR Performance Note #014 / 記事一覧 にあります。

1. 「基準モデルとの一致度」＝圧縮していない高精度版（FP16）が出す次の単語を、圧縮版がどれだけ再現できるか（教師強制下の top-1 一致率）。+4.2pt は「FP16 の挙動に少し近づいた」という意味で、翻訳の良し悪しそのものではない。 ↩