LLMによる日本語タイポ修正ベンチマーク
こんにちは。メディア研究開発センター(通称M研)の田口です。
昨年6月末にこんな記事を書きました。このときはgpt-35-turbo、text-davinci-003を使っていて今読み返すと隔世の感ですね…
現在も要約関連のことをやっているのかというと、最近のメインの業務は「Typoless」という校正支援AIサービスの開発に従事しています。AI校正機能からその他解析API群の整備・運用まで幅広くやっています。Typolessについては昨年末にPdMがnoteを書いているのでぜひ読んでみてください。
さて、そろそろ本題に入りましょう。今回は要約生成とは別のタスクでLLMを評価します。
日本語のタイポ修正について
以前の記事でやった要約生成とは別に、今回はタイトルにあるようにLLMのタイポ修正の性能について検証していきます。
普段文章を書いていると誤字脱字などが混じってしまうことは避けられません。たとえば以下の文章を読んでどこがタイポしているかわかりますか?
助詞の誤りや、誤変換、文字の消し忘れ(衍字)などが混じっており、それらを直すと以下のような文章になります。
たとえば、これをLLMに修正させるとどうなるのでしょうか?試しにChatGPT(GPT-4o)に修正させてみましょう。
以下の文章を読んで、誤りがあれば修正してください。
カフェに本を読んでいる。
ぜひアンケートにご解答ください。
メールの内容を確認の上、至急変身ください。
これからスライドのをつくって、会議の準備をします。
こちらの入力の結果、生成されたのが下記の文章です。修正文の提示後に修正箇所についてのコメントも生成していますがそちらは省略しています。
完璧ですね。。
と、さすがにこれだと検証とは言えないので、もう少しちゃんとLLMの性能を確認していきましょう。今回の検証では京都大学が公開している日本語Wikipedia入力誤りデータセット(v2)を使用します。データセットの内訳は以下のとおりです。
日本語Wikipedia入力データセット(v2)の内訳
訓練データ(train): 696,189ペア
テストデータ(test):5,440ペア
入力誤り評価データ(gold):1,127ペア
データセットの構築方法などの詳細については「日本語Wikipediaの編集履歴に基づく入力誤りデータセットと訂正システムの改良」をご参照ください。今回はこのうち、入力誤り評価データを使ってLLMのタイポ修正性能を評価します。
上述のデータセットを使った他のブログ記事としては、リクルートさんやブレインパッドさんのものがあります。記事では系列ラベリングによる誤り箇所の検出や、BERTとGPT-4の比較をしています。
LLMの検証実験
それではさっそく検証実験をしていきましょう。
実験に用いるLLM
今回は以前の記事とは異なり、APIとして利用可能なものに絞って検証しました。
GPT-4o:モデルバージョンは2024-08-06
GPT-4o mini:モデルバージョンは2024-07-18
Claude 3.5 Sonnet
Gemini 1.5 Pro
Gemini 1.5 Flash
GPT-4oと4o miniはOpenAI API、Claude 3.5 SonnetはAWS Bedrockを、Gemini 1.5 ProとFlashはGemini APIを使って実験しました。生成時のパラメータはtemperature=0.0とし、それ以外はデフォルトのパラメータを使用しています。
プロンプトについて
上記のLLM APIの入力には全て同じシステムプロンプトとユーザープロンプトを使用しました。
システムプロンプト
入力された文章に含まれるタイポを修正してください。タイポの修正以外に文章は編集しないでください。また、出力は修正文のみを含め、<output>修正文</output>の形式で行ってください。
ユーザープロンプト
こちらは入力文をそのまま使います。
入力文
利用するデータセット
こちらは先ほど紹介した日本語Wikipedia入力誤りデータセット(v2)の入力評価誤りデータセットを使用します。ただし、元のデータをそのまま使うのではなくUnicode正規化をしてから各種LLMにタイポ修正をさせています。
理由としては、全角の英数字記号で入力しても半角で生成されてしまうためです。特にGeminiにおいては生成時に半角の英数字記号が生成されてしまうので、全角と半角が異なるだけでも評価時にスコアに差が出てしまいます。
そこで、今回は入力評価誤りデータセットの入力と出力(正解文)をUnicode正規化(NFKC)しています。
また、予備実験時にGemini APIでは以下のように安全フィルタリングのしきい値を設定したのですが、「ブロックなし」のしきい値にしても一部の入力ではエラーになってしまいました。
from google.generativeai.types import HarmBlockThreshold, HarmCategory
safety_settings = {
HarmCategory.HARM_CATEGORY_HATE_SPEECH: HarmBlockThreshold.BLOCK_NONE,
HarmCategory.HARM_CATEGORY_HARASSMENT: HarmBlockThreshold.BLOCK_NONE,
HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT: HarmBlockThreshold.BLOCK_NONE,
HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT: HarmBlockThreshold.BLOCK_NONE,
}
実際の例を確認してみると、性的な表現や暴力的な描写が含まれる事例だったため、問題のある4事例を外した1,123件を実験で使いました。
評価指標について
LLMの生成した修正文がどの程度うまく直せているのかを計測するためにERRANTというツールを使います。今回はこのERRANT内部で使われているspaCyのモデルを日本語モデル(ja_core_news_md)に切り替えて評価をしました。評価指標はPrecision(適合率)、Recall(再現率)、そしてF0.5です。
ERRANTは”ERRor ANnotation Toolkit”の略なので、GECのアノテーションにも使われています。今回は誤り種別のアノテーションは行わないため詳細は割愛します。気になる方は以下の記事をご参照ください。
また、LLMによっては一部生成結果に全角英数字記号が混じってしまうケースがあったため、ERRANTで評価する際には先ほどと同様にUnicode正規化を行いました。
実験結果
ようやく実験結果のセクションです。5つのLLMのベンチマーク結果は下記のとおりです。
結果としてはGPT-4oがPrecision、Recall、F0.5全てにおいて圧倒的に高いスコアを記録しています。逆にGemini 1.5 ProはF0.5で見るとFlashと同等程度のスコアとなっており、両者にNejumi LLMリーダーボード3ほどのスコア差はありません。また、Claude-3.5 Sonetの結果がGPT-4o miniより振るわなかったのは意外でした。
実際の修正例を見てみる
各モデルの出力結果に散見されたのが、一部記号等を削除してしまっているケースでした。たとえば、Wikipedia内で箇条書きとして使うアスタリスクを削除してしまっています。GPT-4o miniやGemini 1.5 Flashのような軽量なモデルの方は残している反面、4oを始めとする高性能なモデルの方が過剰に直してしまっていますね。
こちらはどのモデルもうまく直せている例です。ただ、Claude-3.5 Sonnetのみ「言う」を「いう」に開いてしまっています。
下記はGPT-4oやGemini 1.5 Proなどの高性能モデルがうまく直せている例です。「本体」を「本社」に直すのが正解ですが、これは「出世欲」や「上司」などのコンテキストを見ていないと直しづらい例かと思います。Gemini 1.5 Flashだけマークダウン記法で「出世欲」を強調しているのが目立ちます。
おわりに
今回はOpenAI、Google、(AWS経由ですが)Anthropicが提供するLLM を使って日本語のタイポ修正性能のベンチマークを実施しました。GPT-4oの性能には目を見張るものの、推論時間が長いのでリアルタイムで使うとなるとなかなか難しい印象でした。性能と速度のトレードオフがあるのは当然なので、うまく使えるシチュエーションを見つけるのが大事になりそうですね。
今回の検証をもとに引き続きTypolessの開発を頑張っていきたいと思います。ではまた。
(メディア研究開発センター・田口雄哉)