日本語の文字化けを見つける検出器を、6つ作って比べていました。

比較用のテストデータは自分で作りました。正常な日本語を用意して、わざと壊して、正解ラベルを付ける。よくあるやり方だと思います。

その自作データでの結果です。

  検出器A   99.5%
  検出器B   34.4%

Aの圧勝でした。Bは捨てるつもりでいました。

そのあと、GitHubから実際に文字化けした状態でコミットされているファイルを集めて、同じ検出器を当て直しました。

  検出器B   89.6%
  検出器A   71.2%

順位が入れ替わっていました。

数字がずれるだけなら説明はつきます。合成データの方が簡単だった、で終わる話です。でもこれは順位が入れ替わっている。どれを選ぶべきかという結論そのものが変わっていました。

しかもこの状態は、自作データの中を見ている限り絶対に気づけません。検出器Aは何度測っても99.5%のままだからです。

そこで検出器の改良を止めて、「テストデータの作り方」の方を調べ直しました。

このレポートは、その全記録です。

中身

1   結論
2   なぜ普通のテストではダメだったのか
3   実データをどう集めて、どう「正解」を作ったか
4   実データの壊れ方を測ったら、合成と違っていた
5   目立つ特徴を追いかけて、採用しなかった話
6   見逃しを分類したら、次の版が決まった
7   敵対的正常系——弱点を狙って壊しにいった
8   最終評価——検証用データを1回だけ開けた
9   限界——これは書かないと嘘になる
10  これは誰の役に立つか

全文で約1万1千字。数値表は全部載せています。

このレポートに入っているもの

6つの検出器 × 4つの評価集合の、検出率と誤検出率の全数値
正解ラベルを、評価対象の検出器から独立に作る方法。そのラベラ自身の偽陽性・偽陰性
実データと合成データで「壊れ方」がどう違っていたか。その具体的な差
開発用と検証用を分ける単位の決め方と、凍結のやり方
検証用データを1回だけ開けたときの結果。型別・ファイル別・作者別まで
開発用データに合わせ込んでいた分が、どれくらいだったか
途中で立てて、測って捨てた仮説の全記録
測れなかったことの一覧

このレポートに入っていないもの

検出器のソースコード。これは商品に含みません
最終版の判定規則そのもの（どの条件で、どの閾値で撃つか）
実データの取得元リポジトリ名

理由を書いておきます。このレポートで売っているのは検出器ではなく、評価のやり方だからです。判定規則を出してしまうと「その規則が良いか悪いか」の話になり、本題がぼやけます。

価格

1,500円

一度払えば、あとから追記が入っても追加の費用はかかりません。

こんな人に向いています

異常検知やバリデーションを作っていて、異常データを自分で作ってテストしている人
「うちのテストデータ、そもそも現実を写しているのか？」が気になったことがある人
日本語のテキスト処理で、文字コードの事故を踏んだことがある人
個人開発で、精度の数字を人に見せる機会がある人

向いていない人

すぐ使えるツールが欲しい人（これは読み物です）
文字化けを直す方法を探している人（これは「見つける側」の話です）

日本語文字化け検出器を作ったら、テストデータが検出器の順位を逆転させた話