OCR を導入するとき、三段のモデルが並んでいると、まず「一番大きいのが一番正確」と反射的に思う。でも各段の説明を読むと、容量の 20 倍差が買っているものは一つではない。
ImgIng は PP-OCRv6 を三段で使う。段を分けているのはここだ。
| 段 | 容量 | 言語 |
|---|---|---|
| 高速 | 約 6.0 MB | 中国語・英語＋ラテン系（独西葡仏） |
| 専門（既定） | 約 31.2 MB | 上記＋日本語 |
| 極致 | 約 138.8 MB | 上記＋日本語 |
まず言語の列を見る。高速は中国語・英語とラテン系、専門と極致はそこに日本語が加わる。つまり 6 MB → 31 MB で増えた 25 MB の大きな一部は「日本語の文字集合とその認識」だ。日本語は数千の漢字に二種類の仮名、丸ごと一クラスの文字を覚えるのだから、容量は小さくできない。
次に 31 MB → 138 MB。言語は増えず、同じ集合のままだ。増えた百数十 MB が買うのは、同じ言語での難しいサンプルの精度——極致の位置づけがそのまま言っている。デスクトップ、複雑、小さな文字。同じ中国語の一行でも、大きく鮮明に印刷されていれば三段とも正しく読めるだろう。ぼやけた小さな文字の表スクショに縮めれば、そこで差が開く。だからこの区間は「より多くの文字を読む」ではなく「読みにくい文字を正しく読む」だ。
結論はこうだ。容量は「大きいほど正確」という単調な目盛りではなく、まず言語の対応範囲を、次に難例の精度を買う。「どの言語か」に答えてから「画像がどれだけ難しいか」に答える。中英だけ・画像も鮮明なら、6 MB の高速で足りる。138 MB を引っ張ってくる理由はない。
実際に一枚動かした。情報の詰まった中国語 UI のスクショ、専門段で 69 行・605 文字を認識、デスクトップ Chromium で約 20.9 秒、バックエンドは WebGPU。
境界について、私が実際に触っている層から。OCR モデル自体は私のものではなく、PP-OCRv6 は統合したもので、私が担当するのはそのダウンロード検証と Worker でのスケジューリングだ。そこから言えるのは、三段とも固定のモデル名・容量・SHA-256 を使い、実行時に黙って差し替えない。「極致を使っているつもりが別物だった」に対する硬い保証だ。数十〜数百 MB、途中で一塊壊れれば結果は使い物にならない。止めた方がいい。
もう二つ、段を選ぶ前に知っておくべき境界。一つ、現在の統一モデルは韓国語を読まない——韓国語 UI はそれを正直に示す。大きな段にすれば直るものではない、これは対応範囲であって精度ではない。二つ、手書き、数式の意味、任意の複雑な表の関係は現バージョンの範囲外——「段が小さい」のではなく OCR そのものの境界だ。だから順序は直感と逆になる。容量が先ではなく、まず自分の言語がこの段の範囲にあるか、次に画像がどれだけ難しいか。モバイルでは選べもしない。WeChat や Safari がメモリ圧で落ちないよう、高速段だけが開放されている。使ったのは ImgIng（imging.ai）。