見出し画像

最近公開された日本語LLMを要約生成タスクで検証してみる

朝日新聞社 メディア研究開発センター

こんにちは。メディア研究開発センター（M研）の田口です。

最近、大規模言語モデル（以下、LLM）に関するニュースが毎日のように出ています。直近約1ヶ月の間にもOpenAIのAPIのアップデートが発表されたり、日本語のLLMが公開されたりしました。

少し前（といっても4月末）に「ChatGPT/OpenAI API/LLM活用事例～NewsPicksと朝日新聞の合同勉強会を公開」でLTをしました。このときはChatGPTの見出し生成の簡単な性能検証をしただけなので、この記事では最近公開されたLLMモデルの検証をしてみました。
※この記事では社内データでなく公開データされているデータセットで実験しています

LTの資料はこちらになります。

日本語LLMを要約タスクで検証する

さっそく本題に入りましょう。今回は5月以降に発表された以下の日本語LLMを要約タスクで評価してみようと思います。

上記のモデルはそのまま使うのではなく、要約タスクのデータを使ってLoRAチューニングという手法でモデルの学習を行います。

通常のファインチューニングと異なり、LoRAチューニングではモデルのパラメータは訓練時に更新せず、低ランクのパラメータを設けてそちらのみを更新します。これにより学習パラメータ数を大幅に削減することができます。
LoRAについては以下の資料がとてもわかりやすいのでオススメです。

日本語LLMのLoRAチューニングについては、今年の言語処理学会で王らが「日本語の大規模な基盤モデルに対するLoRAチューニング」（以下、王ら2023）で詳しく検証しています。利用しているLLMはLINE社が開発しているGPT言語モデルです。1B（10億パラメータ）と6.7B（67億パラメータ）のLLMをファインチューニングとLoRAチューニングそれぞれで学習し、QAタスクや含意関係認識、要約タスクで評価を行っています。その中で10億パラメータモデルの場合は、ファインチューニングではうまくいったが、LoRAチューニングではうまく動かなかったという報告がされています。

JCommonsenseQAでは, 1B-FTはほぼ全ての入力に対して解答候補のいずれかを生成したが, 1B-LoRAでは解答候補が出力されることはなかった.
（中略）
また, 6.7B FT について, XLSumをのぞいて, 6.7B LoRAとほぼ同程度の精度であったが, GPUメモリの使用量や訓練の計算時間が膨大であった.

日本語の大規模な基盤モデルに対するLoRAチューニングより引用

今回の実験では、日本語LLMのファインチューニングは行いませんが、このあたりも念頭においた上で読み進めてもらえると嬉しいです。

LLMの検証実験

LLMやLoRAチューニングについての簡単な紹介も終わったので、さっそく実験していきましょう。

利用するデータセット（XLSUM）について

実験では上述の王ら2023の論文と同じくXLSUMの日本語セクションを使います。こちらにデータセット一覧があり、「Japanese」のダウンロードリンクからデータは入手可能です。

XLSUMについて簡単に説明しておくと、日本語BBCの記事で構成されるデータセットです。中身は、
・ID
・URL
・見出し
・要約
・本文
から構成されています。今回は「本文」と「見出し」を利用します。当初は「要約」を使って実験しようと思ったのですが、中身を見てみるとこの記事では「タイ北部のタムルアン洞窟で10日夜…（以下略）」というきちんとした要約が付与されていますが、こちらの記事では要約が「1月」の2文字しかありません。一方、記事の見出しは問題なさそうだったので「見出し」を使って実験しています。というわけで記事タイトルでは「要約生成タスク」と書いていましたが、厳密には「見出し生成タスク」となります。

データセットの内訳
訓練データ：7,113記事
開発データ：889記事
テストデータ：889記事

訓練データの記事本文と見出しの平均文字数（カッコ内は文字数の下限と上限）は以下のとおりです。
記事本文の平均文字数：1681.96文字（102〜27,504文字）
見出しの平均文字数：27.93文字（11〜53文字）

例えば「ブレグジットについて知っておくべき全て」という記事は27,504文字もあるため、そのままモデルに入力するのは難しいです。そこで、記事の先頭1,000文字を入力として使います。モデルによってはもう少し長い入力でも大丈夫なのですが、実験設定を揃えるために全モデル統一で1,000文字としています。

実験に用いるLLM

実験では以下のLLMを使用しました。

  1. cyberagent/open-calm-7b

  2. cyberagent/open-calm-3b

  3. rinna/japanese-gpt-neox-3.6b

  4. retrieva-jp/t5-xl

OpenCALMについてはパラメータ数68億の7Bモデルの他に28億パラメータのcyberagent/open-calm-3bでも実験を行っています。Stability AIが公開している日本語LLMの評価リーダーボードでは、3Bモデルの方が7Bモデルより優れているという報告がされているため、確認も兼ねてこれらの2モデルを使用します。
また、上述の日本語LLMに加えてレトリバ社がT5-XLと同時に公開したretrieva-jp/t5-large-long（パラメータ数7.8億）をファインチューニングしたモデルをベースラインとして使用します。

DecoderのみのLLMを学習する際のプロンプト

レトリバ社のT5の場合はEncoder-Decoder型なので、入力（Encoder側）に「記事本文」を、出力（Decoder側）が「見出し」のように明確に区分できます。しかし、OpenCALMやrinnaのGPTの場合はDecoderのみで構成されるので、入力と出力を合わせて一つの系列として扱う必要があります。そこで、実験では以下のプロンプトで学習を行います。

# intruction:
以下のニュース記事を読んで見出しを書いてください。

# input:
記事本文の先頭1,000文字

# output:
見出し<各モデルのEOSトークン>

実験設定

上記の1〜4のLLMをLoRAチューニングする際には、PEFTライブラリを使用し、以下のパラメータで学習しました。T5-XLのみEncoder-Decoder型なのでtask_typeやtarget_modulesが異なります。

peft_config = peft.LoraConfig(
    task_type=peft.TaskType.CAUSAL_LM,
    # T5-XLの場合は以下
    # task_type=peft.TaskType.SEQ_2_SEQ_LM,
    r=8,
    lora_alpha=32,
    lora_dropout=2e-5,
    target_modules=["query_key_value"],
    # T5-XLの場合は以下
    # target_modules=["q", "v"]
)

モデル訓練時のハイパーパラメータとしては、バッチサイズは64、エポック数は10、さらにfp16オプションによる混合精度による学習を有効にして実験を行いました。レトリバ社のT5-XLのLoRAチューニングの際には混合精度による学習は有効にしていません。レトリバ社のnote記事で紹介されているモデルのハイパーパラメータを見ると、bf16で訓練されており、そのままfp16で訓練を行うとlossがnanになってしまうためです（transformersのissueでもこのような報告がいくつかされています）。

モデル評価時には、開発データ上でのlossが最も小さいチェックポイントを用いてモデルを評価しました。推論時にはビーム探索（幅5）でデコードしています。rinna3.6BおよびOpenCALMのDecoderのみで構成されるLLMでは、学習時のプロンプトを踏襲し、以下の入力から見出しを生成します。

# intruction:
以下のニュース記事を読んで見出しを書いてください。

# input:
記事本文の先頭1,000文字

# output:

評価指標には、要約タスクで一般的に用いられるROUGEスコアと、BERTScoreを使いました。ROUGEスコアはsumevalライブラリを使用してROUGE-1、ROUGE-2、ROUGE-Lを計算しています。また、BERTScoreはライブラリのデフォルト設定に従って、多言語BERTモデルで評価しています。

比較対象としてのGPT-3.5

日本語LLMの比較だけではなく、GPT-3.5モデルでどのくらいできるのか気になる人も多いと思います。そこでGPT-3.5の2つのモデル（gpt-3.5-turbo、text-davinci-003）でも評価してみました。両方ともGPT-3.5という括りになりますが、区別がつきづらいので以下ではChatGPT（gpt-3.5-turbo）とGPT-3.5（text-davinci-003）とします。

この2つのモデルはXLSUMデータセットでファインチューニングをするわけではないため、設定としてはZero-shotになります。モデルの入力となるプロンプトは以下のとおりです。基本は日本語LLMの箇所で紹介したテンプレートですが、出力の形式を指定するプロンプトを追加で書いています。

# intruction:
以下のニュース記事を読んで見出しを書いてください。出力は<headline>見出し</headline>の形式で出力してください。

# input:
記事本文の先頭1,000文字

また、モデルの出力を良くする方法として、プロンプトに事例を含めるFew-shot Learningがあります。ここでは、1-shot（事例1つ）の設定で行っています。1-shotの事例には、訓練データからランダムで選択したこちらの記事を用います。プロンプトの入力サイズの都合上、記事本文の先頭10文を利用しました。実際のプロンプトはこのようになります。

# intruction:
以下のニュース記事を読んで見出しを書いてください。出力は<headline>見出し</headline>の形式で出力してください。

# example1:
1-shot用の記事本文の先頭10文

<headline>ポルシェ、英でEU離脱後に値上げも 追加関税を上乗せ</headline>

# input:
記事本文の先頭1,000文字

ChatGPT・GPT-3.5については、Azure OpenAI Service内に構築したエンドポイント（gpt-35-turbo、text-davinci-003）を利用して実験しました。生成時のパラメータは、temperature=0.0, max_tokens=1024を使用し、それ以外はデフォルトのパラメータで生成しました。ChatGPTによる生成時にはsystemのロールは盛り込まず、以下のものだけで生成を行っています。

{"role": "user", "content": 上述のプロンプト}

ファインチューニング・LoRAチューニングの実験結果

実験設定についての説明が長くなってしましたが、さっそく実験結果を見ていきましょう。以下のテーブルではファインチューニングおよびLoRAチューニングしたモデルのみまとめています。ChatGPT、GPT-3.5の結果についてはあとで紹介します。

実験の結果、すべてのスコアにおいて最もスコアが高かったのはファインチューニングをしたT5-Large-FT（retrieva-jp/t5-large-long）でした。LoRAチューニングしたモデルの中ではrinna/japanese-gpt-neox-3.6bが最も良かったです。

OpenCALMについては、Stability AIが公開している日本語LLMの評価リーダーボードの報告と同じく、7Bモデルよりも3Bモデルの方が良いという結果になりました。スコアが低い要因として、見出しが生成されないケースが多かったことが挙げられます。上述のプロンプトを入力してビーム探索（幅5）すると、次のトークンにEOS（終端記号）が予測されてしまうケースが散見されました。7Bモデルではそのような出力（見出しが空文字）になるケースが889記事中200件、3Bモデルでは80件ありました。一方でrinna3.6B-LoRAでは見出しが空文字になるケースは0件でした。7Bモデルの生成結果の中できちんと見出しが生成されている689件だけに絞って確認してみると、ROUGE-1で39.17というスコアでした。以下は生成された見出しの一例です。直後にEOSが予測されずに生成できている場合は、見出しらしい出力ができています。

【解説】 ブレグジット2度目の国民投票は可能なのか
【ラグビーW杯】 イングランド、3大会ぶりの準決勝進出
新型ウイルスワクチン、英で臨床試験開始
トランプ米大統領、北朝鮮の金委員長と会談へ
【米大統領選2016】トランプ氏、マティス氏を称賛

ChatGPT、GPT-3.5の実験結果

ファインチューニングおよびLoRAチューニングの結果について書いたので、次はChatGPTおよびGPT-3.5のZero-shot、1-shotの結果を見ていきましょう。

結果としては、1-shotのChatGPTの場合、各指標でrinna3.6B-LoRA相当のスコアを記録しています。気になるのはGPT-3.5と比較してzero-shotから1-shot時の性能の伸び幅がかなり大きいことです。試しに1-shotの事例を別の記事にして再度検証してみましたが、ROUGE-1の結果を見るとChatGPTは40.15、GPT-3.5が36.73とほぼ同じ傾向になりました。

おわりに

最近発表された日本語LLMを使ってXLSUMの見出し生成タスクでの性能検証を行いました。一番スコアが高かったのはT5-Largeのファインチューニングという結果になりました。今回使用したデータセットの訓練データは約7,000件なので、このくらいの規模の学習データがあればLLMモデルをLoRAチューニングするよりも、事前学習済みモデルのファインチューニングをする方が良さそうです。要約タスクに携わっている方やLLMの利用を検討している方の参考になれば幸いです。

また、ChatGPTの検証も行いましたが、プロンプトに1つ事例を入れるだけで相当スコアが向上しているのは興味深いですね。要約タスクの場合、入力トークンの制限もあるのでFew-shotの事例数が増やせないのは悩みですが、1つあるだけでもスコア上はかなり機能するということがわかりました。

今回の検証結果を踏まえて要約モデルの研究開発（M研では「TSUNA」という要約APIを開発しています）や、社内のLLM応用を頑張っていきたいと思います。

（メディア研究開発センター・田口雄哉）