はじめに
LLM は音韻の類似度を推論無しでうまく扱えません。
これがなぜかを考えるにあたって、LLMは、そもそも文字の表層的な類似度(例えば編集距離)がうまく計算できるのかが気になったので調べてみました。
具体的には以下の問いを検証しました。
- LLM は 編集距離の計算自体 はできるのか
- もし精度が落ちるなら、それは 編集単位の切れ目が見えにくいから ではないか
結論
今回の観察を先にまとめると、だいたい次の流れです。
- LLM は編集距離をある程度暗算できる
- これは、編集単位をスペースで与えた場合に一致率がかなり高くなることから示唆された。
- 一方で、スペースで区切らないと一致率は下がった
- その理由のひとつとして、tokenization がカナ 1 文字と完全には一致しないことが考えられた。
- 実際、multi-char token を含むペアに絞ると、そうでないペアより精度は下がった。
- さらに、multi-char token を含むペアの中でも、token 距離と文字距離がズレるケースで特に精度が落ちた(ただし、ズレていても当たるケースはあるし、ズレていなくても外すケースもあるので、あくまで傾向)。
実験設定
- モデル:
gpt-5.4 -
reasoning_effort:none -
max_output_tokens:64 - データ: soramimi-phonetic-search-datasetの
small_dataset_for_llm - 評価対象: シード固定でランダムに取得した100 pair
- サンプリング seed: 7
比較に使った 2 条件は次の通りです。
-
kana_only: カタカナ文字列をそのまま与える -
kana_spaced: カタカナを 1文字ずつスペース区切り で与える
例:リ ャ オ
正解ラベルは、カタカナ文字列そのものに対して文字単位の Levenshtein distance を計算して作っています。
1. まず、カナ編集距離はどれくらい計算できるか
各条件での exact match rate (LLM の出力が正解と完全に一致する割合)は以下のとおりでした。
| 条件 | exact_match_rate |
|---|---|
kana_only |
0.72 |
kana_spaced |
0.95 |
kana_spacedの結果が高いことから、編集単位の区切りが明確であれば、数文字程度の単語ペアの編集距離は高い精度で計算(暗算?)できることが示唆されます。
一方で、スペースという区切り文字がなくなると、精度が下がっています。
2. tokenization の影響
区切り文字がないときに精度が下がる原因として、LLMが処理するトークンが必ずしもカナ1文字ずつに対応しないことが考えられます。複数のカナが1トークンとみなされると、カナを単位とした編集距離の計算は難しくなりそうです。
そこで、kana_only 条件のペアを、トークン化したときに
- 両方とも 1 文字ずつ token 化されるペア
- どちらかに multi-char token を含むペア
の 2 群に分けて、exact match rate を比較してみました。
multi-char tokenの判定には tiktoken の o200k_base を 用いました(これがgpt-5.4のtokenizerであるかどうかは公式には発表されていない気がしますが、傾向をみるには問題ないと思います)
3. multi-char token を含むペアは本当に不利か
100ペアの内訳は、
-
両方とも 1 文字ずつ token 化されるペア:
64 -
どちらかに multi-char token を含むペア:
35
でした。
この 2 群で exact match rate を比較すると、
| 条件 | pair数 | exact_match_rate |
|---|---|---|
| 1文字ずつ token 化される pair | 64 | 0.7969 |
| multi-char token を含む pair | 35 | 0.6000 |
となりました。
劇的な差ではありませんが、multi-char token を含むペアの方が精度が落ちる傾向は見られました。
4. さらに、token 距離と文字距離のズレで分ける
さらに、LLMがmulti-char tokenを含むペアに対しては、token 単位の編集距離を出しやすいのではないかという仮説も考えられます。
この仮説を検証するために、multi-char token を含む 35ペアの中で、token 距離と文字距離がズレるペアとズレないペアに分けて、exact match rate を比較してみました。
結果は以下です。
| 条件 | pair数 | exact_match_rate |
|---|---|---|
| token 距離 = 文字距離 | 21 | 0.7619 |
| token 距離 != 文字距離 | 14 | 0.3571 |
multi-char token を含むペアのなかでも、token 距離と文字距離がズレる場合に、特に精度が下がっていました。
この結果は、multi-char token を含む場合は、LLM が token 単位の編集距離を誤って出しやすいという仮説を支持すると考えられます。
5. 具体例
token 距離と文字距離が一致していて、exact match した例
-
アイvsアルー- query tokens:
["アイ"] - candidate tokens:
["アル", "ー"] - 文字距離:
2 - token 距離:
2
- query tokens:
-
アイvsタイ- query tokens:
["アイ"] - candidate tokens:
["タイ"] - 文字距離:
1 - token 距離:
1
- query tokens:
このような例では、tokenization はズレていても、token 距離が偶然正解と一致しています。
token 距離と文字距離がズレていて、外した例
-
アイvsイシイ- query tokens:
["アイ"] - candidate tokens:
["イ", "シ", "イ"] - 文字距離:
2 - token 距離:
3 - LLM 出力:
3
- query tokens:
-
アトvsナイト- query tokens:
["ア", "ト"] - candidate tokens:
["ナ", "イト"] - 文字距離:
2 - token 距離:
3 - LLM 出力:
3
- query tokens:
-
アレクルウvsデラクルス- query tokens:
["ア", "レ", "ク", "ル", "ウ"] - candidate tokens:
["デ", "ラク", "ル", "ス"] - 文字距離:
3 - token 距離:
4 - LLM 出力:
4
- query tokens:
token 距離と文字距離が一致していても外した例
-
アトvsナイト- query tokens:
["ア", "ト"] - candidate tokens:
["ナ", "イト"] - 文字距離:
2 - token 距離:
2 - LLM 出力:
3
- query tokens:
-
アレクルウvsアライ- query tokens:
["ア", "レ", "ク", "ル", "ウ"] - candidate tokens:
["ア", "ライ"] - 文字距離:
4 - token 距離:
4 - LLM 出力:
5
- query tokens:
おわりに
今回の結果からは、次のように整理するのが自然そうです。
- LLM は編集距離の計算自体はある程度できる
- それは、
kana_spacedで 0.95 まで上がることから示唆される - 一方で、
kana_onlyでは 0.72 まで落ちる - この落差は、tokenization と比較単位のズレでかなり説明できそう
- 特に、token 距離と文字距離がズレるペアで精度が大きく落ちる
過去の実験では、LLMの推論なしでの音韻検索性能はあまり高くありませんでしたが、今回の結果を踏まえると、クエリや候補語カナをスペースで区切って与えることで、少なくとも編集距離程度の精度は出せる可能性があると考えられます。この検証は今後の課題とします。