LLMを使ったかな漢字変換
こんにちは。メディア研究開発センターの山野です。私は普段は音声処理や自然言語処理やそれらの技術を使ったプロダクト開発などに従事しています。
さて今回は朝日新聞記事データを使ったニューラル仮名漢字変換について簡易な実験をしたのでその結果を共有します。
はじめに
多くの問題を解くことができるLLMですが、ひらがな列Xをかな漢字混じり文Yへ変換する仮名漢字変換については、単語の読み方とその表記の関連性を学習する必要があり、現時点(2024年7月8日)ではLLMでもうまく解くことができません。
(ちなみに私はiPhoneのキーボードをazooKeyに変更してしばらく経ちますがとても使い勝手/心地が良いのでオススメです。)
そこで、最近公開されたLlama-3-swallowでひらがな文に変換したいくつかの記事に対して仮名漢字変換を実施したところ、以下のような結果となりました。
例1:
例2:
この二つの例を見ても分かる通り、正確な仮名漢字変換はやはり難しそうだということが分かります。事実とは異なる情報を生成してしまったりなど、仮名と漢字の対応関係がうまく取れていないように思います。
そこで、本記事では最近公開されたLLMはどの程度仮名漢字変換ができるのかの検証と、朝日新聞記事を学習データとしたニューラル仮名漢字変換モデルの構築と性能検証をしていきたいと思います。
なお、今回は仮名漢字変換をLLMが解けるかという点に焦点を当てた記事となっており、n-gramやRNNなどとの性能比較は実施しません。
評価データ
2022年10月以降の朝日新聞記事の中から50~500文字以内でかつ紙面の面名から以下のリストに該当する記事を抽出しました。
上記のプロセスで抽出したサンプルから読みと漢字のペアを作り、それを評価データセットとしました。
また、仮名漢字変換タスクの評価指標は文字誤り率(以下CER)とBLEUを採用することにしました。CERは文字単位の正解率が評価結果に反映されるため細かい誤りを捉えられること、BLEUは仮名漢字変換タスクは一種の機械翻訳として見ることができると考えたからです。なお、CERは値が低ければ性能が良く、下限は0、BLEUは値が高ければ性能が良く、上限は1です。
なお、2022年10月以降、50-500文字以内などの抽出条件に特別な意図はありません。
学習データ
仮名漢字変換モデル構築のためのデータを作っていきます。今回の実験では朝日新聞記事コーパスからランダムに記事を抽出し、その記事の仮名をSudachiを使って推定していきます。
Sudachiは継続的に辞書がアップデートされ、290万語以上の語彙を収録していますが、一方で、うまく推定できない語彙も存在します。例えば以下のような通りです。(自分の実行環境かバージョンなどの都合でこれらの語彙の読み推定ができるのであればご指摘いただけると幸いです。)
礦山(こうざん)
花咲徳栄(はなさきとくはる)
掃苔(そうたい)
似鱚(にぎす)
専門用語や地名、難読漢字などが該当します。そのような語彙に対しては、朝日新聞が保有している辞書や独自で収集した地名データ等をもとにカバーしていきます。最終的にSudachiには収録されていない約14万件からなるデータを作成しました。なお今回の実験においてはその漢字に対する読みのみを必要としているので以下のようなデータを作成し、カスタム辞書を作成しました。
また、数量表現の読みもある程度推定できるようなルールベースの関数を以下の資料を参考に作成しました。
現代日本語の数詞の形態, 成田徹男https://ncu.repo.nii.ac.jp/record/1536/files/B421-19980331-41.pdf
「数詞+助数詞」の発音とアクセント, 滝島雅子
https://www.nhk.or.jp/bunken/research/kotoba/pdf/20160901_5.pdf。
ルール適用前後の読みは以下の通りです。
上記のようにデフォルトのSudachiよりは発音に忠実な読みが推定できているように思います。
ただし数量表現の読み推定は想像以上に大変で、あらゆる助数詞から数詞の読みを類推する必要があります。
このルールを絶賛作っている途中なのですが全てをカバーしているわけではないので、漢字から仮名に変換する際に多少の誤りは含まれています。例えばこんな例です。
このように2本を”にぽん”としてしまっていたりします。学習データとしてどうなの?という指摘もあると思いますがそれは今後改めて本腰入れて作っていくとして、まずは先に進むことにします。
LoRAチューニング
パラメータや実験設定は以下の通りです。
per_device_train_batch_size 4
gradient_accumulation_steps 16
weight_decay=0.01
learning_rate 1e-5
optim adamw_torch
use_peft
lora_r 64
lora_alpha 16
lora_dropout 0.1
load_in_4bit
また、AccelerateとDeepSpeed(stage2)を使って、A100 80GB x 2台で3epoch学習しました。1万件(swallow_instruct_8b_sample10000)と10万件(swallow_instruct_8b_sample100000)で学習した際のtrain時のlossカーブはこんな感じでした。
なおLoRAチューニング時のインストラクションは以下の通りです。
[
{
"role": "system",
"content": "あなたはひらがなのみで構成された文章を漢字仮名交じり文に変換するAIアシスタントです。",
},
{"role": "user", "content": <ひらがな文>},
{"role": "assistant", "content": <漢字かな混じり文>},
]
実験結果
LoRAチューニングによる効果
まずはデフォルトのモデル(tokyotech-llm/Llama-3-Swallow-8B-Instruct-v0.1)と、1万件のデータでLoRAチューニングしたモデルの比較を行っていきます。
BLEUは0.35から0.73と、LoRAチューニングによって性能が大幅に向上することがわかりました。CERは1.465から0.20へとこれも大幅に向上することがわかりました。
また、BLEUにおいては、これまで偏っていた性能も全てのジャンルで0.6を下回ることなくバランスのよい結果を得ています。
学習データ量を増やすと
続いて学習データ量の違いを見たいと思います。1万件と10万件のデータで学習したモデルを比較した結果は以下の通りです。
学習データを増やすと性能がさらに向上することがわかりました。一方で、”教育1”の性能向上幅が大きいですが、”文化”はあまり向上していないのは少し気になるところです。
vs Claude 3.5 Sonnet
続いて10万件でLoRAチューニングしたモデルとClaude 3.5 Sonnetの性能比較を行います。Claude 3.5 Sonnetの実行時のプロンプトは以下の通りでZero-shotで実行しました。
{"role": "user", "content": f"以下に与えるひらがなのみで構成されている文を漢字仮名交じり文に変換してください。出力結果のみ返却してください。\n{kana}"}]
Claude 3.5 SonnetのBLEUは0.81、CERは0.09でした。一方で、LoRAチューニングしたSwallowモデルはBLEUは0.86、CERは0.08となりました。やはりタスクに特化したモデルは強いですね。
最後に
いかがだったでしょうか。オープンな大規模言語モデルは仮名漢字変換タスクを解けない可能性があることを示しました。次に、LoRAチューニングによって性能向上が見込めること、学習データ量を増やせば商用のAPIにも引けを取らない性能を持つモデルを作れる可能性があることを示しました。今後は学習データの量を増やしたり、記事以外のドメインのデータに対する振る舞いを観察していければなと思います。
最後まで読んでいただきありがとうございました。
(メディア研究開発センター・山野陽祐)