日本語入力システムSumibiの開発 part14: LLMはローマ字の読解が苦手という重要な発見

はじめに

LLMを使った日本語入力システムSumibiの開発で、日本語特化型LLMトークナイザーの理解から得た重要な発見がありました。

1. LLMのローマ字処理の課題: LLMはローマ字を直接処理するのが苦手
2. 効果的な入力方式: ベンチマーク結果から、ローマ字を一度ひらがなに変換してからLLMに送ることが効果的
3. 最適なローカルLLM: 現時点でSumibiに最も適したローカルLLMはgemma-3n-e4b-it (ただし実用にはまだ遠い)

以前はローカルLLMの変換精度が不十分で導入を見送りましたが、技術書を読むうちに改善に一歩近づきました。

LLMはローマ字を直接処理するのが苦手である

LLMを利用した日本語IMEの開発を始めてから2年経過しましたが、この問題に気付くことができませんでした。やはり日頃から技術書を読み、LLMの内部構造を把握しておくことが重要だと思い知りました。

どれくらい差があるか、ベンチマークを見てみましょう。
同じ文章を、ローマ字、カタカナ、ひらがなの3種類で入力し、LLMに漢字仮名混じりの文章を生成してもらいました。直感ではどれも変わらないのではないかと思っていましたが、予想に反して次のように大きな差が出ました。ローマ字に対して、ひらがなは約2倍の変換精度が出ます。
確かに人間もローマ字の羅列を見せられるのとひらがなの羅列を見せられるのでは、ひらがなの方が遥かに読みやすいので、そういう傾向があっても不思議ではありません。

使用したデータ

AJIMEE-Bench を使っています。日本語Wikipedia入力誤りデータセット (v2) を元に作成されたデータで、200件のテストデータが入っています。詳細は、GitHubのREADMEを確認してください。

ローマ字処理が苦手なことに気づいた経緯

Sumibiを改善しようという意図はなく、単純に日本語特化LLMについて興味があったので、技術書を読んでみました。グローバル向けのLLMと何が違うのか、なぜ日本語特化型を作るのかを知って、モデル選定の際の参考にしたかったのです。これが読んだ本です。

本:大規模言語モデル入門(Amazon)

この本には、Transformerのトークナイザーについても言及されており、日本語LLMではMeCabなどの形態素解析器が使われていることが分かりました。

次に、ClaudeのDeep Researchを使って日本語特化型LLMについて調査した結果、日本語特化型LLMでは、SentencePiece UnigramやMeCab+JumanDICなどを用いて日本語に対する最適化を行っていることが分かりました。以下の推定結果を出してきました。

訓練時にMeCab+JumanDICによる形態素解析を用いて事前トークナイズし、助詞・接辞・動詞活用などの形態素境界を制御することで、日本語の文法的な単位を適切に捉えています。これにより、BPE(Byte Pair Encoding)の貪欲なマージ手順が生成する不適切な境界を回避し、品詞や活用パターンに沿ったサブワード単位を学習できます。最終的なトークナイザーは標準的なSentencePieceとして動作し、推論時には形態素解析器への依存なしに高効率な処理を実現しています。

また、訓練データの偏りについて調べてみると、最も根本的な要因は、ローマ字が日本語LLMの訓練コーパスにほぼ存在しないという事実があります。
公開されているデータでは、大規模日本語コーパス（CC-100、mC4、OSCAR、Swallowコーパス等）の分析によると、日本語テキストの文字種分布は：ひらがな40-60%、漢字20-40%、カタカナ5-15%である一方、ローマ字は推定0.1%未満しか出現しないことが分かっているため、ローマ字が最も不利であることが明らかです。

これらの事から、ローマ字をLLMのプロンプトの入力に使うことは変換精度の面で最も不利だということが推測できたため、実際にベンチマークを取りました。

最後に

LLMをブラックボックスで使うのではなく、内部構造をよく知った上で使うことが大事でした。
この結果を受けて、sumibi.elにプロンプトの事前処理としてローマ字からひらがなへの変換を行う対応を入れ、この記事を書いていますが、非常に良好です。
Sumibi 4.0系にこの対応を入れてリリースする予定です。