LLM音韻理解の研究調査：Phun-Bench論文を読む

はじめに

自作している日本語の音韻類似検索を評価するためのベンチマークの研究的な位置づけを整理するために、LLMの音韻理解能力評価に関する研究を調査している。

今回は、中国語LLMの音韻理解能力を評価する「Phun-Bench: Evaluating LLMs on Phonological Understanding in Chinese」という論文についてまとめる。

• 論文情報: Xing Yue, Yongliang Shen, Weiming Lu. (2026). Phun-Bench: Evaluating LLMs on Phonological Understanding in Chinese. arXiv:2606.07300. Accepted to ACL 2026 Main Conference.

論文解説

Phun-Benchとは

Phun-Bench は、中国語における LLM の音韻理解能力を評価するために提案されたベンチマークである。

既存の音韻能力評価には、単に発音を暗記していれば解けるものや、意味理解など他の能力と混ざってしまうものが多い。そこで Phun-Bench では、LLM が音韻知識を単に記憶しているかではなく、音韻情報を柔軟に利用できるかを評価しようとしている。

具体的には、ベンチマーク設計において以下の2点が重視されている。

1. Memorization-Proof
   事前学習データ中の表現を暗記しているだけでは解きにくいようにする。

2. Solve with Sounds, not with Meaning
   意味ではなく音に基づいて解く必要があるようにする。

Phun-Benchは、中国語における以下の3つの観点を評価する。

1. 同音性 Homophony
2. 押韻 Rhyme
3. 音韻類似性 Phonetic Similarity

それぞれ、同じ発音を持つ語の対応を扱う能力、韻を踏む文を生成する能力、語同士の音韻的な近さを比較する能力を評価する。

データサンプルは論文のFigure 2に示されている。

以下、各タスクについて深堀りする。

タスク1：同音性に基づく理解

Homophone Recall

タスク説明

Homophone Recall は、意味的には不自然だが、音としてはターゲット語と同じになる表現を入力し、元のターゲット語を復元するタスクである。

具体的には中国の成語（chengyu; チェンユィ）を対象とする。ターゲットとなる成語に対して、同音だが意味的にはおかしい文字列を作り、それを入力として元の成語を答えさせる。

日本語で例を作ると以下のような感じになると思われる。

• Q. 「逸積煮長」と発音が同じ四字熟語は？
• A. 「一石二鳥」

評価指標には Exact Match が用いられる。

データセット作成

データセットは、chinese-idiom-db から取得した成語のうち、4文字のものだけを対象に構築されている。さらに news2016zh コーパス中の頻度で並べ、頻度 10 以上の 2,857 件をターゲット成語として採用する。

そこから、各文字を同音の常用漢字で置き換えることで、元の成語と同音だが意味的には不自然な参照列を自動生成する。各文字について置換候補が見つかった成語だけを残し、最終的に 1,098 件の (w_ref, w_target) ペアが作られている。

Contextual Homophone Recognition

タスク説明

Contextual Homophone Recognition は、文中に含まれるダジャレ的な表現を検出し、その背後にある元の語を復元するタスクである。

このタスクでは、モデルは以下の2つを行う必要がある。

1. 文中のどの語が同音に基づく pun word なのかを検出する
2. その pun word に対応する本来の target word を復元する

日本語で例を作ると以下のような感じになると思われる。

• Q. 次のダジャレ「怪我がなくても大分県」において、ダジャレ語と、それのもとになるターゲット語はなんですか？
• A. ダジャレ語: 「大分」, ターゲット語「おお痛」

補足として、井上ら2022でいう「重畳型」のダジャレが対象となっていると思われる。上記も同論文から重畳型ダジャレの例を拝借した。

評価では、検出率と復元率が計算される。

データセット作成

データセットは、Rohn (2024) の中国語同音ダジャレデータセット DuanzAI から収集された pun sentence を元に構築されている。ここから、pun word が 3 文字未満の事例や、ポップカルチャーのようなニッチな背景知識を必要とする事例を除外する。

そのうえで jieba と pypinyin を用いて pun word と target word をピンインへ変換し、必要な箇所は手修正する。そして、pun word と target word のピンインが完全一致する、厳密な同音関係の事例だけを残し、最終的に 1,684 件の (s, w_pun, w_target) タプルを得ている。

タスク2：押韻に基づく理解

Rhyming Sentence Generation

タスク説明

Rhyming Sentence Generation は、参照文と韻のルールを入力として、参照文と韻を踏む文を生成するタスクである。

中国語の押韻では、ピンインの final や tone などが重要になる。Phun-Bench では、音節を18個の Rhyme Group に分類し、生成文の対象音節が参照文と同じ Rhyme Group に属するかを評価する。

タスク設定には以下の2種類がある。

1. 1-rhyme
   末尾1音節で韻を踏む設定

2. 2-rhyme
   末尾2音節で韻を踏む設定

1-rhyme は比較的解きやすい一方、2-rhyme では、最後の2音節を正しく特定し、それぞれの韻グループを一致させる必要があるため、難易度が高くなる。

日本語で例を作ると以下のような感じになると思われる。

• Q. 参照文「今日は空があおい」に対して、末尾1音節で韻を踏む文を作ってください。

• A. 「庭先の花がしろい」

• Q. 参照文「窓辺で眠るねこ」に対して、末尾2音節で韻を踏む文を作ってください。

• A. 「光るあなたのデコ」

評価は、参照文と生成文の Rhyme Group が一致するかどうかで行われる。

データセット作成

まず著者らが中国語の全音節を 18 個の Rhyme Group に手作業で分類し、押韻規則を定義している。そのうえで ChineseLyrics の歌詞文を参照文 s_ref として利用し、非歌詞的な注記、非漢字や英数字を含む文、6文字未満の短い文を除外する。

通過した文は jieba と pypinyin でピンイン列に変換し、末尾音節の Rhyme Group G_refを付与する。そこから約 3,000 文をランダムにサンプルし、重複除去と手作業のフィルタを経て、最終的に 1,000 件の (s_ref, G_ref) タプルを作成している。この同一集合に対して、末尾 1 音節を合わせる 1-rhyme と、末尾 2 音節をそれぞれ合わせる 2-rhyme の 2 設定で評価する。

タスク3：音韻類似性に基づく理解

Similarity Comparison

タスク説明

Similarity Comparison は、参照語と4つの候補語が与えられ、その中から最も音韻的に類似した語を選択するタスクである。

入力形式には、漢字表記の語を提示する設定と、ピンイン表記で提示する設定がある。

このタスクでは、中国語の音節を構成する以下の要素が重要になる。

• initial
• final
• tone

論文では、これらの一致・不一致の組み合わせに基づいて複数の類似タイプを定義し、音韻的な近さを比較する問題を作成している。

日本語で例を作ると以下のような感じになると思われる。

• Q. 「カラス」に最も音が近い語を、次の4つから選んでください。
  候補: 「ガラス」「クラス」「カレー」「からすま」
• A. 「ガラス」

上記はあくまでも日本語で無理に雰囲気を移した例であり、実際の Phun-Bench では中国語の2文字語を対象に、initial・final・tone の一致関係を制御した4択問題が作られている。

データセット作成

データセットは、中国語の常用 2 文字語を集めた List of Frequently Used Words in Modern Chinese を出発点として構築されている。各語を news2016zh コーパス中の頻度で並べ、頻度 100 以上の 13,741 語を参照語候補として残す。

そこから論文で定義された perturbation type に従って候補語を自動生成する。ここで perturbation type とは、参照語の各文字に対して、候補語の各文字がどの程度音韻的に近いかを、文字ごとの類似タイプで指定するルールである。

正解候補と distractor の作り方は、各 perturbation type ごとに固定されている。たとえば pert_1 では、2文字のうち1文字は参照語と完全同音で、もう1文字はかなり近い候補を正解にし、同じく1文字は完全同音だが、もう1文字はもっと遠い候補を distractor にする。pert_2 と pert_3 も同じ枠組みだが、正解側の「もう1文字」の近さが段階的に変わる。pert_4 では2文字とも完全同音ではなく、2文字ともある程度近い語を正解にし、2文字ともより遠い語を distractor にする。

言い換えると、pert_1 から pert_3 は「片方は同じ音、もう片方の近さだけで見分けさせる」設定であり、pert_4 は「2文字とも完全一致なしで、全体としてどちらがより近いかを比べさせる」設定である。各参照語について、こうした条件を満たす正解候補を 1 語、distractor を 3 語集め、シャッフルして 4 択問題にする。最終的なデータ数は設定ごとに異なり、pert_1 が 945 件、pert_2 が 880 件、pert_3 が 431 件、pert_4 が 2,013 件である。

Phun-Benchの主な結果

評価対象モデル

論文では、主にテキスト入力の LLM を対象として評価している。non-thinking モデルとしては Llama-3.2-3B-Instruct、Qwen3-8B、GLM-4-9B-Chat、Qwen2.5-72B-Instruct-AWQ、DeepSeek-V3、GPT-4o が使われている。thinking モデルとしては Qwen3-8B-think、QwQ-32B-AWQ、DeepSeek-R1 が使われている。

このうち Qwen3-8B は non-thinking と thinking の両方で評価されている。また、比較対象として中国語母語話者の人間評価も用意されている。

タスクごとの結果

同音性

主要な結果はFigure 3に示されている。

同音性のタスクでは、人間はほぼ 100% に近い性能を示す一方、LLM はかなり苦戦する。Homophone Recall は特に難しく、non-thinking モデルでは DeepSeek-V3 が 0.664、GPT-4o が 0.618 と比較的高いが、Qwen3-8B は 0.152、Llama-3.2-3B は 0.007 にとどまる。thinking モデルでは改善が見られ、QwQ-32B が 0.807、DeepSeek-R1 が 0.977 まで到達する。

Contextual Homophone Recognition では、pun word の検出率 DR はほとんどのモデルで 0.90 を超える一方、元の語を復元する recovery rate RR はかなり低い。たとえば Qwen3-8B は DR が 0.957 だが RR は 0.345 であり、DeepSeek-V3 でも DR は 0.980 に対して RR は 0.782 である。つまり、文脈から「ここがダジャレらしい」と見抜くことは比較的できても、その背後の語を音に基づいて復元するのは難しいことが分かる。

5.2.2 の考察では、この弱さがどこから来るのかを調べるために、HR と CHR を「文字列から直接 target を当てる」問題としてだけでなく、「まずピンインに変換し、そのピンインから target を復元する」という二段階に分解して分析している（Table 2）

論文の仮説は、LLM は homophone 同士を直接結び付けているというより、いったん pronunciation、つまり sound layer に写してから処理しているのではないか、というものである。

この分析では、HR については P(pinyin | ref) と P(target | pinyin) が direct な P(target | ref) よりかなり高いことが示されている。たとえば Qwen3-8B では、参照語からピンインへの変換は 0.956、ピンインから target 成語の復元は 0.826 なのに、参照語から直接 target を当てる HR は 0.152 にとどまる。DeepSeek-V3 でも同様に 1.000、0.996、0.664 であり、「ピンインにしてから復元する方が簡単」という関係が成り立つ。CHR でも同じ傾向があり、Qwen3-8B では pun word の検出 0.957、pun word からピンインへの変換 0.869、ピンインから target 復元 0.591 に対して、文全体から直接 target を復元する RR は 0.345 である。

推論トレースの具体例（論文のFigure 12, 13。中国語事例のため転載略）もこの仮説を支持している。DeepSeek-R1 の HR 正答例では、まず 呻鳞骑竟 を shēn lín qí jìng に変換し、その音列から 身临其境 を復元している。逆に Qwen3-8B-think の誤答例では、案怖臼颁 から an bu jiu ban まではたどれているが、そこから正解の 按部就班 ではなく 安步就班 を出してしまう。つまり、thinking モデルでも「音への変換」はかなりできる一方で、その音列に対応する正しい語を最終的に選び切れない場合がある。

押韻生成

主要な結果はTable 3に示されている。

押韻生成では、1-rhyme と 2-rhyme の難易度差が非常に大きい。1-rhyme では DeepSeek-V3 が 0.816、GPT-4o が 0.827、QwQ-32B が 0.830、DeepSeek-R1 が 0.970 とかなり高い性能を示す。一方、2-rhyme になると non-thinking モデルはほぼ崩れ、DeepSeek-V3 が 0.083、GPT-4o が 0.072、Qwen2.5-72B でも 0.053 にとどまる。thinking モデルでは改善が大きく、QwQ-32B が 0.437、DeepSeek-R1 が 0.848 まで伸びるので、複雑な押韻制約では reasoning の有無がかなり効いているといえる。

ただし thinking なら常に良いわけではなく、Qwen3-8B-think はこのタスクでかなり不安定で、1-rhyme が 0.126、2-rhyme が 0.022 と低い。論文では、これは意味のない反復をしがちな挙動によるものだと分析している。

5.3.2 の考察では、thinking モデルの誤答トレースを読むことで、RSG の失敗要因がさらに分析されている。大きくは 2 種類で、1 つは indexing error であり、参照文や生成文の末尾文字・末尾2文字を正しく取り出せない。もう 1 つは misgrouping で、文字を誤った rhyme group に割り当ててしまう誤りである。論文では具体例として、DeepSeek-R1 が 去 と 古 をどちらも u 系だと見て韻を踏むと判断してしまうケースを挙げているが、実際には 去 は ü 系で group が異なる。また付録では、1-rhyme を求められているのに 2-rhyme 的な処理をしたり、その逆をしたりする instruction-following error も報告されている。

音韻類似性比較

主要な結果はFigure 5に示されている。

Similarity Comparison でも、全体として non-thinking モデルは弱く、thinking モデルで改善する傾向がある。特に語の差が主に声調にある Pert_3 では性能が高く、Qwen3-8B-think は 0.97、DeepSeek-R1 は 0.99 に達する。一方で、initial の違いが効く Pert_1 では難しく、thinking モデルでも 0.4 台にとどまる。論文では、人間は直感的に音の近さを判断しているのに対し、LLM はピンインへ変換し、initial / final / tone に分解して比較するような明示的推論に依存している可能性を指摘している。

5.4.2 の考察では、この「明示的推論」の中身も推論トレースから確認されている（Figure 13, 14。転載略）。たとえば DeepSeek-R1 の正答例では、まず参照語 摊位 を tān wèi に、候補語をそれぞれ huán wèi, tiáo wèi, yīn wèi, dān wèi に変換し、そのうえで「後半の wèi は同じ」「前半は tān と dān が最も近く、t と d は近い子音だ」と段階的に比較して、单位 を選んでいる。逆に Qwen3-8B-think の誤答例では、今生 と 晋升 の比較で、本来は jīn と jìn が声調違いだけでかなり近いにもかかわらず、「韻母が違う」と誤って分析してしまい、寄生 を選んでいる。つまり、thinking は有効ではあるが、推論過程そのものが正しく音韻分析できているとは限らない。

また、Similarity Comparison は漢字表記だけでなくピンイン表記でも評価されており（全体平均: Figure 8, pertごと: Figure 11）、LLM はピンイン表記の方が性能が上がる傾向を示す。これは、モデルが文字列をいったん音表記へ写してから比較している、という論文の仮説とも整合的である。

5.4.3 で音声入力に対応したマルチモーダルモデルについても追加分析している（Figure 6）。

設定としては、Similarity Comparison の各 perturbation type から 50 件ずつサンプルし、Qwen-TTS で音声化したうえで、Qwen-Omni-Turbo と Qwen3-Omni-Flash に入力している。Qwen3-Omni-Flash は thinking モードでも評価されている。

結果として、音声入力は全体に有効であり、とくに reasoning ありの Qwen3-Omni-Flash は平均性能で text-only モデルを上回る場合がある。論文では、約 30B 規模の Qwen3-Omni-Flash が、条件によっては GPT-4o より高い性能を示し、Pert_4 では DeepSeek-R1 を上回ることもあると報告している。一方で、すべての設定で一様に強いわけではなく、text-only LLM が得意な Pert_3 と、audio model が相対的に強い Pert_4 では傾向が異なる。論文では、Pert_3 は声調差をトークン上で扱いやすいため text-only 側に有利であり、Pert_4 は音響的に比較しやすいため audio 側に有利なのではないかと考察している。

推論トレースについては、多くの trace では、モデルはまず音声をテキストに書き起こし、その途中で似た音の聞き間違いを起こすこともある。その後、書き起こした語をさらにピンインに変換し、initial / final / tone を比較するという流れで推論しており、しばしば英語に code-switch しながら reasoning するという。つまり、少なくとも現状のマルチモーダルモデルは、音声をそのまま音響表現として比較しているというより、結局はいったんテキスト化・ピンイン化してから比較している可能性が高い、というのが論文の見立てである。

まとめ

以上をまとめると、Phun-Bench は「発音知識を知っていること」と「その知識を柔軟に使って音韻的な関係を扱えること」は別であることを示している。特に難しい設定では、モデル規模の大きさに加えて reasoning の有無が強く効くが、それでも人間的な直感的処理とはかなり異なる仕方で解いているように見える。

音韻検索ベンチマークとの関係

筆者が構築した音韻検索ベンチマーク（soramimi-phonetic-search）は、替え歌歌詞から取得された元歌詞と置換後表現の音韻ペアを正解として、候補語集合から正解語を検索・ランキングするタスクである。

Phun-Benchの特に Similarity Comparison は、自作ベンチマークと関心が近い。参照語と複数候補の中から最も音韻的に近い語を選ぶという点では、音韻類似検索の評価に近い形式になっている。「意味ではなく音で解かせる」「暗記だけでは解けないようにする」といったPhun-Benchの設計思想は、soramimi-phonetic-search にも通じる部分がある。

違いとしては、Phun-Bench の Similarity Comparison は4択問題であるのに対し、soramimi-phonetic-search は候補語集合全体（100件）に対するランキング課題である。候補語が多いことは多少難易度を高める作用があるかもしれない。

またPhun-Benchでは正解や候補語はある程度人為的に作成されているが、soramimi-phonetic-searchでは実際の替え歌歌詞に登場した単語ペアを正解としており、より人間の主観が反映されたデータセットとなっている可能性がある。

おわりに

自作の音韻検索ベンチマークの研究的な位置づけを整理するために、中国語LLMの音韻理解能力を評価する Phun-Bench の論文を読んでみた。課題意識やタスク設計はかなり通ずるものがあり、また推論モデルや音声対応モデルであることの効果など、興味深い分析も多かった。2026年6月公開と、記事執筆時点からみて非常に最近の論文であるため、1~2年前の論文では考慮されていなかったところが順当にカバーされている用に感じた。ACL 2026 Main Conferenceに受理されており、音韻理解の評価の論文の書き方としても参考になる部分が多かった。