はじめに
背景とモチベーション
- ニュースキュレーションサービスとしての自動要約技術の重要性
- 事前学習済み言語モデルの急速な発展
自動要約モデルの作成
推論の高速化
- ONNX とモデル量子化
- CPU を使用した推論速度と要約精度の評価
API 実装と slack bot 化
- API 化
- slack bot化
ChatGPT の登場
今後に向けて・おわりに

はじめに

こんにちは、 Gunosy Tech Lab (GTL) MediaML チームの大竹です。今回のブログでは、社内で運用されているニュース記事の自動要約システムについてご紹介したいと思います。

ニュース記事の本文から簡潔な要約を生成するシステムを作るため、データセットの収集から自動要約モデルの学習、サービスとして利用するための API 実装までを行いました。開発した API は現在、日々のニュース記事記事を要約して社内の Slack に投稿する bot に使用されており、現在も自動要約に関する様々な技術検証が進んでいます。

背景とモチベーション

ニュースキュレーションサービスとしての自動要約技術の重要性

弊社ではグノシー・ニュースパス・auサービスToday という3つのニュースキュレーションアプリを開発・運用しており、日々入稿される大量のニュース記事をパーソナライズ推薦モデル等を通してユーザーに配信しています。

もしこうしたニュース記事を適切な長さに要約したコンテンツを提供することができれば、記事を読むユーザーは短い時間でニュースの概要が把握でき、情報取得にかかるコストを小さくできると考えられます。

また社内向けにも、コンテンツを編成しているチーム等がニュースの概要を要約という形で把握することで、効率的に業務を行う手助けになることが期待できます。

事前学習済み言語モデルの急速な発展

近年では BERT*1 や GPT シリーズ*2に代表される、事前学習済み言語モデルを利用した手法が自動要約を含む様々な NLP タスクで顕著な成果を挙げており、工夫次第では自動要約技術が実用に耐えうるものになるという期待がありました。

また社内でもこうした技術に関する知見を継続的に溜めていきたいというモチベーションがあり、最初の取り組みとして社内向けにニュース記事を要約するシステムの開発に着手することになりました。

自動要約モデルの作成

タスク設定

ニュース記事の本文を入力に受け取り、その要約（最長でも3行程度の長さ）を出力するタスクに取り組みます。

これは自然言語処理において単一文書要約と呼ばれるタスクで、長い歴史の中で様々な手法が提案されてきています。それらの手法は大きく抽出型要約・抽象（生成）型要約の2つに分けられます。

抽出型要約は、入力された文書から、重要であると判別された文（や単語）を選択し、それらを繋ぎ合わせることで要約文を出力します。文を選択する場合は文単位で見ると破綻が起きず、後述する hallucination（幻覚）等のリスクがないというメリットがあります。一方で、文と文の繋ぎ目が不自然で要約としてまとまりのないものになってしまう可能性もあります。

抽象型要約は、入力文書にある内容を短く言い換えたり、入力文書にない表現を新たに生成したりすることで入力文書を要約します。抽出型要約よりもより自然で流暢な出力ができる傾向がある一方で、入力文書に書かれていない事実を出力に含めてしまう hallucination のリスクがあります。また、近年抽象型要約に頻繁に用いられている seq2seq のニューラルモデルにおいては、特定のフレーズを繰り返してしまうといった問題*3が知られています。

近年では、 T5*4 や BART*5 といった encoder-decoder 形式の Transformer を採用した事前学習済み言語モデルを要約タスクに fine-tune する抽象型要約の手法が、 CNN / Daily Mail*6 といった自動要約のベンチマークデータセットを使用した評価で高い性能を達成しています。

今回はざっくりと概要を掴めるような自然な要約を生成したいため、こうした抽象型要約の手法を採用することにしました。

モデル

事前学習済みの言語モデルを準備します。今回は Megagon Labs が公開している事前学習済みの T5*7 を使用します。

T5 は上述した encoder-decoder 型の Transformer をベースにした言語モデルで、様々な自然言語処理タスクを text-to-text の形式に変換して統一的に扱うことができます。文章中でランダムにマスクされた部分テキストを復元するようなタスク（denoising objective）で事前学習が行われ、各タスクへの fine-tune と組み合わせることで自動要約を含めた様々な自然言語処理タスクを高精度に解けることが報告されています。

データセット

T5 を自動要約タスクに fine-tune するため、本文とその要約のペアを収集しデータセットを準備します。今回は、web 上から著作権法上の問題がないニュース記事とその要約のペアデータを収集しました。作成したデータセットの（本文、要約）ペア数は以下のようになりました。

	記事数
train	101,775
dev	685
test	695

また、後述するマルチタスク学習に使用するため、各記事につけられているタイトルも（本文、要約）ペアと一緒に収集しました。

T5 の fine-tune

huggingface が提供する transformers ライブラリには T5 等の事前学習済み言語モデルを要約タスクに fine-tune するためのexample スクリプト*8が公開されています。今回はここで提供されているスクリプトを利用して学習済みモデルの fine-tune をおこないます。

学習には NVIDIA T4 GPU を搭載した g4dn タイプの AWS EC2 インスタンスを使用し、dev セットに対する loss が収束するまで学習を行いました。評価時には dev set に対する loss がもっとも小さくなった時点の checkpoint を使用します。

学習率等のハイパーパラメータは基本的にデフォルトの値を使用しましたが、今回学習に使用した GPU の場合、小さいバッチサイズでないとメモリが足りなくなってしまうため、 per_device_train_batch_size=2, gradient_accumulation_steps=8 とパラメータを変更しています。

gradient accumulation*9 はバッチサイズ分の gradient を gradient_accumulation_step 数分保持しておき、まとめて update するようにするテクニックで、実質的なバッチサイズを擬似的に増やすことが可能です。

評価

test set に対する要約生成結果を、自動評価・人手評価により評価しました。

自動評価

自動評価尺度には、要約タスクの評価に一般的に用いられる ROUGE*10 を使用しました。 ROUGE はモデルの生成結果と test set における正解の要約文（reference文）との語彙的な一致度を評価します。

ベースラインとして、記事冒頭の3文をそのまま要約とする Lead3 ベースラインと比較しています。ニュース記事では重要なことが記事冒頭に書かれる傾向があり、 Lead3 は単純ながらも強いベースライン手法として知られています。

評価時はビーム幅を 3 とするビームサーチでデコードを行ないました。繰り返し生成を抑制するシンプルな対処法として no_repeat_ngram_size=5 を指定しています。

また、要約タスクに加え、ニュース記事の本文からタイトルを生成するタスクをマルチタスクに学習したモデルの評価も行ないました。タイトル生成も一種の要約タスクとみなせるため、要約に関する一般的な能力をより獲得することで、通常の要約タスクの精度向上を狙います。

結果は以下のようになりました。

	ROUGE-1	ROUGE-2	ROUGE-L
Lead3	0.424	0.198	0.300
T5 fine-tune	0.540	0.308	0.427
T5 multi task	0.541	0.311	0.428

Lead3 と比較すると今回作成したモデルはいずれも ROUGE スコア上は大幅に参照要約に近い出力ができているようです。

また、タイトル生成と要約生成のマルチタスク学習をした場合、わずかですが ROUGE スコアの向上がみられました。

人手評価

今回作成したモデル（T5 fine-tune）の生成結果を人手により評価しました。1名の評価者がランダムにサンプルした生成例を 30 個観察し、① 日本語として自然 ② 記事内容を反映しており誤情報を含まない、という2観点から要約として許容できるか否かを判定しました。

結果として、許容できるものは 30 例中 17 例で全体の 57% 程度でした。*11 生成結果の半分以上は定性的に問題ない要約を生成できているようです。

推論の高速化

実験時の学習や評価は GPU インスタンス上で行いましたが、実際にこうしたモデルを何らかのサービスのために定常的に稼働させることを考えると、高額な GPU インスタンスよりもより安価な CPU インスタンス上で動作させることが望ましいです。しかしながら、 CPU を使用した推論は GPU を使用した場合に比べて非常に低速で、実応用上レスポンスタイムの問題が生じやすくなります。そこで、今回学習したモデルを CPU インスタンス上で高速に動作させる工夫を2通り検討します。1つは ONNX (Runtime)*12 の使用、もう一つはモデルの量子化です。

ONNX とモデル量子化

ONNX (Open Neural Network eXchange) は様々なフレームワーク（例：PyTorch, TensorFlow）を使用して書かれた機械学習モデルを統一的な形式で表現するためのフォーマットです。ONNX 形式に変換したモデルは ONNX Runtime で推論を行うことで、ハードウェアに対して実行が最適化されるため、高速な推論が期待できます。

ニューラルネットワークのモデルを軽量化する手法の一つに、量子化（Quantization）があります。これは、モデルのパラメータをよりメモリサイズが小さいデータ型に（例えば 32 bit 浮動小数点から 8 bit の符号付き整数に）変換してしまうという方法です。モデルファイルの容量が小さくなることに加え、推論時の計算も高速になることが期待できます。

CPU を使用した推論速度と要約精度の評価

先述の T5 fine-tune モデルをベースに、それぞれの工夫を適用した場合の要約タスクそのものの性能と、1サンプルの推論にかかる平均時間を算出しました。評価には今回作成した test set を使用し、ベースラインとして何の工夫もせずにそのまま CPU で推論を行った場合と比較します。

ONNX 形式への変換・ ONNX Runtime での推論、モデル量子化には fastT5*13 を使用しました。

以下の表ではベースラインを100%とした時の相対値で各手法の性能を示しています。

	ROUGE-1	ROUGE-2	ROUGE-L	1サンプルあたりの推論時間
ベースライン	100.00	100.00	100.00	100
+ onnx	99.68	99.71	100.05	67.55
+ onnx + quantization	98.67	96.89	98.42	50.36

ONNX のみを使用した場合、使用しないベースラインと比較して推論速度が 32% 程度速くなっていることが分かります。ROUGE スコアの低下も 1% 未満に抑えられています。

加えてモデル量子化を行った場合、推論時間は約半分と大幅に短くなっていますが、ROUGE スコアの低下が ONNX のみの場合と比較すると大きくなってしまっていることがわかります。

API 実装と slack bot 化

API 化

一定の精度で要約を行うことができるモデルを用意することができたので、実際にサービスとして使うことができるよう要約 API を実装しました。 API はリクエストに含まれる記事本文を受け取り、今回学習したモデルによる要約生成を行い、要約結果をレスポンスとして返します。web フレームワークとして fast API*14 を使用しました。また、弊社では様々なサービスが EKS クラスタ上で管理されているため、要約 API 用に kubernetes の deployment を作成し、社内の EKS クラスタ上にデプロイしました。

slack bot化

要約 API を利用する最初の検証用アプリケーションとして、入稿されてくるニュース記事を定期的に要約して社内の slack に投稿する bot を作成しました。以下の図ようなシンプルな構成です。

この slack bot は現在も稼働中で、実際にニュース記事の要約結果を定常的に観察できるようになったことで、コンテンツ編成チーム等からいくつも現状の技術に関する課題点を含めたフィードバック集めることができています。これらは今後の継続的なモデル改善・システム改善に生かしていきたいと考えています。

ChatGPT の登場

ここまででご紹介した自動要約システムの開発が始まってからしばらくして、ChatGPT*15 が発表されました。抽象型要約のような生成タスクは ChatGPT が非常に得意とするタスクの一つです。定性的で厳密な比較ではありませんが、今回作成したモデルとその要約結果を無作為に選んだ複数のサンプルで比較してみました。

ChatGPT による要約生成には次のようなプロンプトを使用しました。

あなたはプロの編集者です。
次のニュース記事を最長でも3文以内でわかりやすく簡潔に要約してください：
（以下本文）

実際のニュース記事を用いた比較のため本文や要約そのものを載せることはできないのですが、結果としてどの例においても、今回作成したモデルと ChatGPT ともに、本文の内容を反映した流暢な要約を生成することができていました。

強いて言えば ChatGPT の方は少し説明的で冗長な要約、今回作成したモデルの方は比較的簡潔な要約を生成する傾向にありました。

定量的な比較ではなく検証した際の印象を多分に含んだ私見ですが、現時点での ChatGPT と今回作成したモデルのメリット・デメリットをまとめると以下のようになりそうです。

観点	内製モデル	ChatGPT
要約性能	◯	◯
推論速度	◯	△
開発・運用コスト	△	◎
可用性	◯	△（不安定になる場合あり）

今回のモデル作成にはデータセット作成〜モデル学習まで、金銭的・人的なコストがかかっていますが、ChatGPT の方は API の利用料金のみでほぼ同じような目的を達成できるという点で非常に大きなメリットがありそうです。また、プロンプトには（今回も何通りか試して良いものを使っているものの）さらに改善の余地があると思われ、モデル自体も今後アップデートされていく可能性が高いという点もポジティブです。

ネガティブな点があるとすれば、API が何らかの要因（アクセス規制やモデルの公開停止など）で使用不可能になった場合、サービスが継続不可能になるというリスクは考慮する必要がありそうです。

こうした要約技術を実際にビジネスに応用していく段階では、上述したようなメリット・デメリットを考慮した総合的な意思決定が必要になると思われます。

今後に向けて・おわりに

今回のブログでは社内で開発・運用されている自動要約のシステムをご紹介しました。内製モデルの開発自体は過去の知見の積み上げやオープンになっているリソースが多いおかげで、スムーズに実現できたのではないかと思います。

最後のセクションで簡単に触れましたが、 ChatGPT をはじめとする LLM の技術発展はすさまじく、今後もどんどんできることの範囲が広がっていくと予想されます。個人的な印象ですが、今回試した範囲でも（特に抽象型要約のような ChatGPT が得意な生成タスクにおいては）自社でモデルを開発しなくとも ChatGPT を API として利用するだけで事足りるようになる可能性は十分高いと感じました。もちろんそれぞれにメリット・デメリットがあるので、実際にはビジネス上どういった観点を重視するのかによって意思決定していくことになるのだと思います。

一方で、ニュースキュレーションサービスにとっては、 ChatGPT を使うかモデルを内製するかという問題よりはむしろ、要約技術を使ってユーザーにどのような体験を届けるのか・それらをどうデザインするのかという問題が重要です。

さらに、要約コンテンツをユーザーに届けるような仕組みを考えると、現実問題として自動要約結果に対する人手のチェックが必須になります。こうした場合には、自動要約を行うコンポーネントそのものよりも確認・修正を行う人間との human-in-the-loop なシステムをどう構築していくべきか、継続的にシステムを改善していくにはどういった仕組みが備わっているべきかといった問題がより重要になると思われます。

先日行われた言語処理学会第29回年次大会のワークショップ、日本語言語資源の構築と利用性の向上*16においても、「システムの本体は LLM の外側にある」というメッセージを含む発表がありましたが、ここでも重要なのはむしろ LLM の外側、 LLM を要素として含むシステム全体であると言えそうです。

技術に対して近視眼的にならずに、全体像を把握しながら何にフォーカスするべきかを考えて取り組んでいくことが今後もますます重要になりそうです。

*1:Devlin+NAACL'19

*2:GPT, GPT-2, GPT-3, GPT-4

*3:Holtzman+ICLR'20

*4:Raffel+JMLR'20

*5:Lewis+ACL'20

*6:Nallapati+CoNLL'16

*7:https://huggingface.co/megagonlabs/t5-base-japanese-web

*8:https://github.com/huggingface/transformers/tree/main/examples/pytorch/summarization

*9:https://huggingface.co/docs/accelerate/usage_guides/gradient_accumulation

*10:Lin+'04