Google ドキュメントでテキスト要約を自動的に生成できるようになりました。

私たちの多くは、毎日たくさんのファイルを処理する必要があります。新しい文書を受け取ったとき、通常は、ユーザーが文書の内容をできるだけ早く理解できるように、重要なポイントの簡単な要約が含まれていることを望みます。ただし、ドキュメントの要約を書くのは困難で時間のかかる作業です。

この問題に対処するため、Google は、Google ドキュメントでドキュメント作成者がコンテンツの要約を作成できるように、自動的に提案を生成できるようになったと発表しました。この機能は、テキストの内容を理解し、1～2 文の自然言語テキスト記述を生成できる機械学習モデルによって実現されます。ドキュメント作成者はドキュメントを完全に制御でき、モデルによって生成されたすべての提案を受け入れ、ドキュメントの概要をより適切に把握するために必要な編集を行うことも、完全に無視することもできます。

ユーザーはこの機能を使用して、ドキュメントをより深く理解し、ナビゲートすることもできます。すべてのユーザーがスニペットを追加できますが、現在のところ、自動生成の提案は、Google Workspace のエンタープライズ カスタマーのみが利用できます。Google Workspace は、Google がサブスクリプション ベースで提供するクラウドベースの生産性向上およびコラボレーション ソフトウェア ツールおよびソフトウェアのスイートです。 Google は、文法の提案、スマートライティング、自動修正に基づいて、これが職場での書面によるコミュニケーションを改善するためのもう 1 つの貴重な研究であると考えています。

次の図に示すように、ドキュメントの概要の提案が利用可能な場合は、左上隅に青い概要アイコンが表示されます。ドキュメント作成者は、提案されたドキュメントの概要を確認、編集、または無視することができます。

モデルの詳細

過去 5 年間、特に Transformer と Pegasus の導入により、ML は自然言語理解 (NLU) と自然言語生成 (NLG) に大きな影響を与えてきました。

ただし、抽象的なテキスト要約を生成するには、長いドキュメントの言語理解と生成のタスクを解決する必要があります。現在、より一般的に使用されている方法は、NLU と NLG を組み合わせることです。この方法では、シーケンスツーシーケンス学習を使用して ML モデルをトレーニングします。入力はドキュメントの単語で、出力は要約単語です。次に、ニューラル ネットワークは入力トークンを出力トークンにマッピングすることを学習します。シーケンスツーシーケンスパラダイムの初期のアプリケーションでは、エンコーダーとデコーダーの両方に RNN が使用されていました。

Transformer の導入により、ドキュメントで非常に重要な長い入力と出力の依存関係をより適切にモデル化するために自己注意を使用する RNN の有望な代替手段が提供されます。ただし、これらのモデルを完全にトレーニングするには、依然として大量の手動でラベル付けされたデータが必要であり、そのため、Transformer のみを使用するだけでは、ドキュメント要約の SOTA パフォーマンスを大幅に向上させるのに十分ではありません。

Pegasus の研究では、このアイデアをさらに一歩進めています。この方法は、抽象要約をカスタマイズするための事前トレーニング目標を導入することで、論文「PEGASUS: 抽象要約のための抽出されたギャップ文による事前トレーニング」で提案されました。 Pegasus 事前トレーニング (GSP (ギャップ文予測) とも呼ばれる) では、ラベル付けされていないニュース メッセージや Web ドキュメント内の完全な文が入力でマスクされ、モデルはマスクされていない文に基づいてそれらを再構築する必要があります。特に、GSP はさまざまなヒューリスティックを通じて、ドキュメントにとって重要な文をマスクしようとします。目標は、事前トレーニングを要約タスクにできるだけ近づけることです。 Pegasus は、多様な要約データセットで SOTA 結果を達成します。しかし、この研究の進歩を製品に実装するには、多くの課題が残っています。

PEGASUS インフラストラクチャは、標準の Transformer エンコーダー/デコーダーです。

最近の研究の進歩を Google ドキュメントに適用する

データ

自己教師あり事前トレーニングでは、一般的な言語理解と生成機能を備えた ML モデルが生成されますが、その後の微調整フェーズは、モデルをアプリケーション ドメインに適応させるために非常に重要です。 Google は、一般的なユースケースに合わせて手動で生成された要約を含むドキュメントのコーパスで、モデルの初期バージョンを微調整しました。しかし、コーパスの初期のバージョンには、多くの種類の文書や、学術要約は通常長くて詳細であるのに対し、行政要約は短くて簡潔であるなど、要約の書き方に対するさまざまなアプローチが含まれていたため、矛盾や大きな変更が見られました。これにより、モデルはさまざまな種類のドキュメントと要約でトレーニングされるため混乱しやすくなり、それらの間の関係を学習することが難しくなります。

幸いなことに、Google のオープンソース Pegasus ライブラリ (記事の要約を自動生成するライブラリ) から得られた重要な発見の 1 つは、効果的な事前トレーニング フェーズでは、微調整フェーズ中に必要とされる教師ありデータが少なくて済むということです。一部のサマリー生成ベンチマークでは、10,000 以上の教師ありサンプルを必要とする Transformer ベースラインのパフォーマンスに匹敵するために、Pegasus の微調整サンプルが 1,000 個しか必要ありません。これは、量ではなくモデルの品質に重点を置くことができることを示しています。

より一貫性があり、より一貫した要約を表すトレーニング例が含まれるように、微調整データを慎重にクリーンアップしてフィルタリングしました。トレーニングデータの量が削減されたにもかかわらず、より高品質のモデルが生成されました。データセットの蒸留などの他の分野での最近の研究と同様に、次の重要な教訓を引き出すことができます。つまり、小さくて高品質のデータセットの方が、大きくて変動の大きいデータセットよりも優れているということです。

仕える

高品質なモデルがトレーニングされると、Google はモデルを本番環境で提供するための課題の解決に取り組みました。エンコーダー/デコーダー アーキテクチャの Transformer バージョンは、要約生成などのシーケンス間タスクのモデルをトレーニングするための主流のアプローチですが、このアプローチは実際のアプリケーションで使用する場合、非効率的で実用的ではありません。効率が低いのは主に、自己回帰デコードを利用してトークンごとに出力サマリーを生成する Transformer デコーダーによるものです。ダイジェストが長くなると、デコーダーは各ステップで以前に生成されたすべてのトークンを処理する必要があるため、デコード処理が遅くなります。リカレント ニューラル ネットワーク (RNN) は、Transformer モデルのように以前のトークンに自己注意を適用しないため、より効率的なデコード アーキテクチャです。

Google は知識蒸留 (大規模なモデルからより小さく効率的なモデルに知識を転送するプロセス) を使用して、Pegasus モデルを Transformer エンコーダーと RNN デコーダーで構成されるハイブリッド アーキテクチャに改良しました。効率性を向上させるために、Google は RNN デコーダー レイヤーの数も削減しました。結果として得られるモデルは、元のモデルと同等の品質を維持しながら、レイテンシとメモリ使用量が大幅に改善されています。レイテンシとユーザー エクスペリエンスをさらに改善するために、Google は TPU を使用して要約生成モデルを提供します。これにより、大幅な高速化が実現され、単一のマシンでより多くのリクエストを処理できるようになります。

進行中の課題

これまでの進歩に私たちは満足していますが、まだ取り組むべき課題がいくつかあります。

ドキュメントの範囲: ドキュメント間に大きな違いがあるため、微調整フェーズ中にドキュメント セットを開発するのは困難です。推論段階でも同様の課題が存在します。さらに、Google ユーザーが作成したドキュメント (会議メモ、レシピ、授業計画、履歴書など) の中には、要約に適していないものや要約が難しいものもあります。

評価: 要約は文書の本質を捉え、流暢かつ文法的に正しいものでなければなりません。特定のドキュメントに対して正しいと考えられる要約が多数存在する可能性があり、ユーザーによって好まれる要約が異なる場合があります。このため、自動指標のみを使用して概要を評価することは困難であり、ユーザーからのフィードバックと使用状況の統計は、Google がモデルの品質を理解し、継続的に改善するために不可欠です。

長いドキュメント: 長いドキュメントは、すべての重要なポイントを捉えて 1 つの要約に抽象化 (要約) することが難しいため、モデルが要約を生成するのが最も困難です。さらに、長いドキュメントのトレーニングと提供中にメモリ使用量が大幅に増加します。ただし、モデルによって要約を自動的に生成するタスクには長いドキュメントが最も役立つ場合があります。これは、ドキュメント作成者がこの面倒なタスクを迅速に開始するのに役立つためです。 Google は、この課題にうまく対処するために、ML の最新の進歩を適用したいと考えています。