HTLM: Hyper-Text Pre-Training and Prompting of Language Models

1 はじめに

言語モデルの事前学習に使用されるテキストの大部分は，ウェブページから抽出され，その中に含まれるマークアップはすべて捨てられている（Liu et al. , 2019 ; Brown et al. , 2020 ; Raffel et al. , 2019 ; Lewis et al. , 2019）。私たちは、このHTMLを無視すべきではないと主張します。 HTMLは、構造化されたドキュメントレベルの監視による、非常に効果的な言語モデルの事前学習とプロンプトの新しい形を可能にします。 Common Crawl 1に見られるHTMLのようなハイパーテキストは、プレインテキストに比べて事前学習には多くの利点があります。ハイパーテキストには、テキストだけでは推論が困難な、ドキュメントのさまざまな部分の高レベルなプロパティがコード化されていることがよくあります。例えば、要素は、ドキュメントの<body>の優れた要約となり得ますし、要素のclassやid属性は、ドキュメントのカテゴリー的なプロパティをエンコードすることができます。このような監視は、ウェブサイトの作成者が何を提示するかに応じて非常に多様であり、後に解決することを目指す多くのNLPタスクのための緊密なプロキシを提供します。ハイパーテキストをモデル化することで、言語モデルの構造化プロンプトを導入することができます。望ましいモデルの出力をよりよく制御するために、HTMLの確立されたセマンティクスを組み込んだプロンプトを設計します。例えば、ウェブページの<title>タグを埋めるようにモデルに指示することで、ゼロショット要約を行うことができます。</p> <p>また、テキストとハイパーテキストのフォーマットを共同でモデル化することで、効果的な自動プロンプトを実現しています。新しいタスクのための例がいくつかあれば、それをHTMLでフォーマットするようにモデルに直接依頼し、その結果をテンプレート化して新しいプロンプトを定義することができます。我々のハイパーテキスト言語モデル（HTLM）は、一般的なクロールダンプ（セクション§2.1参照）から自動的に抽出された23TBの簡略化されたHTMLで学習されています。我々は、ハイパーテキストのスパンをランダムにマスクし、元の入力を再構築することを目的とした修正BARTノイズ除去目的（Lewis et al.、2019）を使用する。我々はオリジナルのマスキングを新しいサイズヒントスキームで拡張し、各マスクはマスクされたテキストのサイズのためのノイズのあるヒントを提供する整数と関連付けられ、最終モデルを促すときに、より細かい粒度のタスク固有の長さのプライアを可能にする（セクション§2.3参照）。図1は、約12トークンを含むフレーズで再構成されるべきマスクの例を示しています。</p> <p>広範な実験を通して、我々のHTLMは幅広いエンドタスクと監督レベルで非常に効果的な転送を達成することを示した。 HTLMは、GLUEにおけるゼロショットプロンプトとフルファインチューニングにおいて、比較可能なサイズのテキストオンリーのLMと同等かそれ以上の性能を示し、また、ゼロショットサマリーにおいては、最大8 ROUGE-1ポイントのゲインを得て、最先端の性能レベルを設定した。また、テーブルからテキスト生成までのように、テキストのみの入力に還元することが容易ではない問題に対しても、数ショットの学習が可能です。 Le Scao and Rush (2021)によって導入された方法論に従うと、ハイパーテキストプロンプトは、既存のLMに対してプレーンテキストプロンプトが提供するよりも、HTLMモデルに対してより多くのデータ効率を提供し、事実上、1,000個の余分な学習例を持つことと同等であることが分かった。最後に、HTLMモデルは自動プロンプトに非常に効果的であり、場合によっては手動で作られたプロンプトの性能に匹敵することが分かった。要約すると、我々の貢献は以下の通りです。</p> <ul> <li>初のハイパーテキスト言語モデル(HTLM)を発表し、一般的なクロールから得られた23TBの簡略化されたHTMLデータで学習した。</li> <li>我々の新しいハイパーテキストプロンプティングスキームは、HTMLの確立されたセマンティクスとプロンプトマスクの新しいサイズヒントの両方を使用して、新しいタスク仕様をより細かく制御します。</li> <li>我々は、様々なレベルのタスクに対して、HTLMから一貫して強力な移行を実証した。その中には、最もよく知られているゼロショット要約数を最大8ROUGE-1ポイント改善するものも含まれる。</li> <li>Le Scao and Rush (2021)に続き、我々のデータ効率分析では、ハイパーテキストプロンプトはHTLMモデルにとって、既存のLMにとってのプレーンテキストプロンプトよりも価値があり、事実上、1000個の追加の学習例を持つことと同等である。</li> <li>我々は、HTLMが新しいタスクのための自動プロンプトを直接サポートしていることを実証する。それは、利用可能な例をHTMLでフォーマットするようにHTLMに求めるだけで、しばしば以前の手動で作られたプロンプトに匹敵するかそれ以上のものである。</li> <li>今後のHTLMの研究を支援するために、すべてのコードとモデルを公開します。</li> </ul> <p><img src="https://user-images.githubusercontent.com/44970465/125901340-6a405e6a-e495-4276-9199-6d8ad550587d.png" alt="image" /></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/e4exp"><img src="https://avatars.githubusercontent.com/u/44970465?v=4" />e4exp</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <h2>2 HyperText Language Model (HTLM)</h2> <p>HTLMは、一般的なクロールから自動的に抽出された簡略化されたHTMLの大規模なコーパスで学習される(セクション§2.1)。我々は、BARTスタイルのノイズ除去オートエンコーダーとスパンマスキング(セクション§2.2)を使用し、原文の再構成の際にサイズヒントが得られるように拡張した(セクション§2.3)。</p> <h3>2.1 最小限のHTML</h3> <p>HTMLには自然言語への監視信号が含まれていますが、最近のWebページのHTMLの大部分は、事前学習のための重要な監視信号を提供していません。例えば、ウェブページの大部分は、JavaScriptコードやCSSであり、ドキュメントレベルの情報ではなく、ページの美観を提供しています。このことと、非常に長い配列長の変換器をトレーニングするという課題（Choromanski et al.2020; Wang et al.2020; Beltagy et al.2020）を組み合わせることで、ウェブページを以下に定義するMinimalHTML（MHTML）と呼ぶ簡略化された形式に自動的に変換することが重要でした。</p> <p>HTML DOM2のサブツリーのうち，一定の文字サイズ（標準的なテキスト要素では128，リスト／テーブル／スパンでは64）のテキスト要素を含まないものをすべて削除します。また、すべてのヘッダ、フッタ、著作権、フォーム、iFrameを除外します。連続した<div>要素を、統合された属性を持つ単一の<div>要素に折りたたみます。また、class属性やid属性ではないすべての属性を削除します。最後に、HTMLに対するテキストの割合が0.46より大きくないMHTMLドキュメントをすべてスキップします。特に、HTMLに対するテキストの比率が低いMHTMLドキュメントは、ドキュメントの平均的な品質も低くなる傾向があることに気づきました。これらの数値は、前述の変換を適用した後のCommon Crawl (CC)ドキュメントのセットを視覚的に検査することで得られたもので、ドキュメントの品質を高く保ちつつ、大量のデータをフィルタリングしないようにしています。さらに、enに設定されていないlang属性を持つすべてのドキュメントをフィルタリングします。これらの決定論的な変換を適用することで、ドキュメントの一般的なマークアップを維持しながら、生のウェブページから平均94％の文字を削除することができました。さらに、BARTやその他多くの既存の言語モデルの最大トークン長である1024BPEトークンに、MHTMLドキュメントの85%近くを収めることができました。この種のフィルタリングの副産物として、デフォルトで高品質な文書も生成されてしまうことが挙げられます3；そのため、CC-100（Conneau et al.、2019）などの文書のモデルベースのフィルタリングは行わないことにしました。我々はCommon Crawlの2021年1月のスナップショットを使用し、フィルタリング後の23テラバイトのMHTMLテキストを提供しました。</p> <h3>2.2 モデル</h3> <p>いくつかの理由から、BARTスタイルのデノイジングオートエンコーダ（Lewis et al.2019）を採用する。我々は、文書の残りの部分を条件として、MHTML内の任意の部分文字列を予測したい。これにより、（1）プロンプト中にマスクを使用して、Webページ内のモデル出力に関連するテキストを生成する場所をマークすることと、（2）プレーンテキストのトレーニング例をマスクで包み、モデルがMHTMLフォーマットを生成することでマークアップできるようにすることで、プロンプトを自動的に生成することを同じように簡単に行うことができます。また、それぞれのケースでどの程度のテキストを生成する必要があるかを事前に正確に知ることができないため、より伝統的なマスクされた言語モデルを使用することはできません。すべての実験において、BART-Largeと同じアーキテクチャを採用し、BART-Largeのチェックポイントでモデルを初期化しました。このモデルは、およそ4億個のパラメータを持っています。拡張BARTモデルは，256個のGPUを用いて，8192個の有効なバッチサイズで，合計330,000ステップの学習を行いました． BART-Largeモデルでモデルを初期化しました。 Adam optimizer (Kingma and Ba, 2014) と多項式減衰学習率スケジューラを用いて、ピーク学習率を4e-5とし、10,000ウォームアップステップで学習します。 BARTの目的である文のシャッフルは使用せず，マスキングのためのスパン長のサンプリングにはPoisson λを3.5に設定した．注意のドロップアウトは、最初の17万ステップでは0.1に設定し、その後は0.0にしました。また，FastText (Joulin et al., 2016)を用いて，170kステップ後に英語（en）のみにデータをフィルタリングしました． 17万ステップ付近で困惑度がプラトーになっていることに気づいたので、ドロップアウトを除去し、英語のフィルタリングを強く適用することで、学習プロセスを単純化しています。</p> <h3>2.3 サイズヒント</h3> <p>BARTでは、再構築時に各マスクを複数のトークンで置き換えることができます。事前学習の際、BARTはポアソン分布からサンプリングされた長さのスパンをマスクします。したがって、モデルはマスクされたテキストの長さを暗黙的に予測することを学習しなければなりません。標準的なBARTをゼロショット生成プロンプトに使用しようとしたときに遭遇した基本的な問題は、長さペナルティのような様々なデコーディング戦略を使用する場合でも、各マスクの生成テキストの長さを制御することができないということです。そこで、BARTのマスキング・スキームにサイズ・ヒントを導入することで、よりコントロールしやすくしました。具体的には、スパンの長さのノイジーな推定値を直接トークン化し、スパンマスクトークンの直後に挿入します。ここで、nはmax (1, ⌊N (m, m ∗ǫ)⌋であり、ǫは、これらのサイズヒントがどれだけノイズになるかを表すハイパーパラメータです。また、サイズヒントを注入しないことで、マスクサイズを暗黙的にモデル化することができます。サイズヒントのノイズ性をǫ=0.1として、80%のマスクにサイズヒントを与えます。表1にサイズヒントの利点の例を示します。</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/e4exp"><img src="https://avatars.githubusercontent.com/u/44970465?v=4" />e4exp</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <h2>3 HTMLベースのプロンプティング</h2> <p>HTMLベースのプロンプティングスキームは、さまざまな生成および分類タスクに使用されています。大まかには、手動で選択するか、モデル自身が自動プロンプトで生成したHTMLテンプレートを使用して、タスクのHTML構造を指定します。このテンプレートは、タスクの入力と出力用のプレースホルダー・マスク・トークンでインスタンス化されます。モデルは、このインスタンス化されたテンプレートをプロンプトとして使用します。 BARTモデルは完全な入力を再構成するので、我々は単純なヒューリスティックに頼って、マスクの周りの接頭辞/接尾辞をマッチさせ、最終的な出力を抽出します。</p> <h3>3.1 プロンプトの生成方針</h3> <p>マスクのサイズヒントがオプションであることを考えると、1つのプロンプトで多様なテキストを生成することができますので、プロンプトの結果を選択するための複数の方針について議論します。サイズヒントを全く利用しないことにして、ポリシーを使用する必要をなくすことができますが、これはテンプレートの堅牢性を犠牲にすることになります。サイズヒントがない場合、テンプレートはタスクのセマンティクスを表現しなければならないだけでなく、ターゲットの平均的な長さにも一致させる必要があります。しかし、ヒントを使用することで、世代の長さをプロンプトから切り離すことができ、関連するタスク間でのテンプレートの再利用を大幅に改善することができます。また、あるプロンプトとデータの特定のサブセットに対して、HTLMが生成されたマスクをプログラムで抽出できるような出力を生成しない可能性もある。したがって、サイズヒントのポリシーはこの問題を軽減するものである。全ての生成タスクに対して、まず意味的に正しいテキストを生成できるプロンプトを作成し、次に学習セットのサブセットの平均目標値s¯に等しいサイズヒントを提供する。ある入力に対して値を抽出できなかった場合、同じプロンプトに対してHTLMを実行するが、サイズヒントをs¯± iǫs¯に設定し、その中から最もパープレキシティの低い出力を選択し、このプロセスを最大で5回続ける。それでも有効な答えが見つからない場合は、次のセクションで説明する自動テンプレートにフォールバックする。</p> <p>実験では、HTLM-Manual-NS (not sized)をサイズヒントのない手動で作成されたプロンプトとし、HTLM-Manual-S はすべての生成ベンチマークにおいてここで定義されたポリシーを使用する。ハイパーテキストを学習することで、HTLMはハイレベルな文書のセマンティクスを学ぶことができ、それをプロンプトの生成に利用する。我々は、モデルに文書のマークアップを復元させることにより、プロンプトのテンプレートを生成する。具体的には、独立したデータブロック(例：要約/記事)の周囲に hmaski トークンを配置する。Gigaword summarization dataset (Napoles et al., 2012) のサンプルに対する自動プロンプトの例を，それぞれのマスキングとともに図2に示す．本実験では、HTLM-Auto-NS (not-size) をサイズヒントを使用しない自動プロンプトとし、HTLM-Auto-S は前節で説明したサイズヒントに基づくポリシーを使用するものとした。これは、ジェネレーティブ・ターゲットが単純なバイナリ・ターゲット・トークンよりもかなり多くの情報を持っているためであると考えられる。</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/e4exp"><img src="https://avatars.githubusercontent.com/u/44970465?v=4" />e4exp</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <h2>4 Zero/One-Shot Prompting</h2> <p>Perezら(2021)は、プロンプトが大量の開発データのチューニングによって作成された場合、ゼロ/フューショット学習は起こらないと主張している。この問題を軽減するために、我々の実験で使用される全ての手動プロンプトは、関連論文から得られたものか、訓練セットから最大50個のサンプルを用いて開発されたものである。</p> <h3>4.1 生成</h3> <p>典型的な生成タスクである要約について、HTLM を評価する。全ての要約ベンチマークにおいて、他の文献(Lin, 2004)との一貫性を保つために、ROUGE-1/2/L を主要なメトリクスとして使用する。さらに、3つの標準的な自然言語生成タスクでHTLMをベンチマークする。 BLEU (Papineni et al., 2002)、NIST (Belz and Reiter, 2006)、METEOR (Lavie and Agarwal, 2007)、ROUGE-L (Lin, 2004)、CIDEr (Vedantam et al., 2015)、TER (Snover et al., 2005)を報告する公式のベンチマークスクリプトを利用している。ベースラインにはLi and Liang (2021)を使用し，同様に0.1%のパラメータを用いたプレフィックスチューニングの結果を提示している．</p> <h4>Gigaword</h4> <p>は、ニュース記事のヘッドラインから構成されている(Napoles et al., 2012)。対象となる要約は比較的短く、おおよそ平均して10個のBPEトークンで構成されている。</p> <h4>CNN/Dailymail (Hermann et al., 2015)</h4> <p>は、3センテンスに近い複数センテンスのターゲットサマリーを提供しており、およそ50トークンで構成されている。</p> <h4>Reddit TIFU (Kim et al., 2018)</h4> <p>は、Redditの投稿のサマリーを含んでいます。具体的には、データの短いサブセットを使用します。私たちの他の要約データセットと比較して、このデータセットは抽象度が高く、ニュース記事に基づいていません。</p> <h4>XSum (Narayan et al., 2018)</h4> <p>は、ニュース記事の抽象的な単文サマリーを提供しています。</p> <h4>E2E (Novikova et al., 2017)</h4> <p>は、レストランのドメインから8つのユニークなフィールドを持つ約50Kのサンプルを含むtable-to-text生成データセットです。</p> <h4>WebNLG（Gardent et al., 2017）は、DBPediaから15種類のドメインを含む構造化生成データセットです。</h4> <p>データのSeen（S）、Unseen（U）、All（A）のサブセットの数値を報告します。</p> <h4>DART (Nan et al., 2020)</h4> <p>は、Wikipediaのテーブルを含むオープンドメインの構造化生成データセットです。</p> <p>これらのデータセットのそれぞれについて，訓練セットから最大50個のデータポイントを用いてプロンプトを手動で検索し，プロンプトを評価した．ベースラインについては、ゼロショット要約の現状であるPEGASUS（Zhang et al.、2019）と比較する。 PEGASUSは、ニュース記事から顕著なギャップセンテンスをマスキングして生成することで、要約のために明示的に事前学習されました。その結果を表2に示します。HTLM-Manual(手動プロンプト)とサイズヒントを用いたHTLMは、4つのデータセット全てにおいて、事前学習なしで、最新のゼロショット要約の結果を大幅に改善した。特に、Gigawordデータセットでは、ROUGE-L F1を8以上も向上させることができた。さらに、サイズヒントに基づく自動プロンプト(HTLMAuto-S)は、4つのデータセットのうち3つのデータセットでPEGASUSを上回った。特にGigawordデータセットでは、PEGASUSのゼロショットの結果を約6 ROUGE-Lポイント上回りました。 HTLMの改善は、HTMLベースのプロンプトによって、長さやスタイルなどのデータセット固有の属性をよりよく制御できるようになったことに起因する。 NLGタスクでは、プロンプティングが十分に機能するためには、1つの学習例を使用する必要がありました。表3では、これらのワンショット数を報告する。これらのタスクは、構造化された表形式の入力を必要とするため、他のテキストベースの事前学習モデルをどのように促すかは明らかではありません。 Gardentら（2017）の文法ベースのパイプラインアプローチ（TILB/UIT-VNU）のような、他の学習不可能なベースラインを報告します。我々の知る限り、これらは最初のワンショットテーブルからテキスト、自然言語生成の結果です。無料版のDeepL翻訳（www.DeepL.com/Translator）で翻訳しました。</p> <p><img src="https://user-images.githubusercontent.com/44970465/125904368-1b4edc05-7063-4af4-b301-4d7d64c29906.png" alt="image" /></p> <p><img src="https://user-images.githubusercontent.com/44970465/125904521-966d0692-12fa-4849-8f65-7a0bd4fabbd9.png" alt="image" /></p> <p><img src="https://user-images.githubusercontent.com/44970465/125905041-2b43e769-1de1-4403-b68c-6f57e7cd6ddb.png" alt="image" /></p> <h3>4.2 分類</h3> <p>分類設定でのプロンプティングでは、4つのデータセットを選択して作業を行う。正しいクラスを示すターゲット・トークンを生成する生成型プロンプトに頼る代わりに，正しいクラスを選択するために，すべてのターゲットのセットに対するパープレキシティ測定に頼ります．言い換えれば、対応するインスタンス化されたテンプレートの錯乱度が最小となるクラスを選択します。</p> <h4>RTE (Bentivogli et al., 2009)</h4> <p>は，バイナリ分類として定式化されたテキストの関連付けタスクです． class属性をcandidateに設定した<div>要素に候補を配置し，それぞれの仮説についても同様の処理を行います． 3番目の要素には、Brownら（2020）のプロンプトをクラス属性をanswerに設定して利用します。</p> <h4>BoolQ(Clark et al., 2019)</h4> <p>はYes/Noの質問応答タスクで、質問、通路、答えのトリプレットの2値分類としても定式化されています。質問は、itempropをhttps://schema.org/Question に設定した<div>要素、通路はclass属性のpassageを持つdiv要素、答えはitempropをhttps://schema.org/Answer に設定したdiv要素として表現します。</p> <h4>Winogrande (Levesque et al., 2012)</h4> <p>は、敵対的に収集されたWinograd Schema Challenge (Levesque et al., 2011) のデータから構成されています。GPT-3と同じテンプレートを利用していますが、BoolQに似たQAスタイルのテンプレートに配置されています。正確なテンプレートは付録を参照してください。 HellaSwag 最後に評価するデータセットは、常識的な自然言語推論タスクであるHellaSwagで、その敵対的な性質から、複雑であると考えられています(Zellers et al., 2019) ゼロショット分類に関する結果を表4に示します。分類データセットのHTLMプロンプトは、大部分のタスクで、最も比較可能な（パラメータ数の点で）GPT-3 Mediumサイズのモデルを上回り、一方で、HTLMの約2倍のパラメータ量で構成されるGPT-3 Largeモデルに近づき、RTEでは上回っています。</p> <p><img src="https://user-images.githubusercontent.com/44970465/125905093-d2ebca55-8c7f-4c90-b18f-60c12fe3e002.png" alt="image" /></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/e4exp"><img src="https://avatars.githubusercontent.com/u/44970465?v=4" />e4exp</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <h2>5 Fine-tuning実験</h2> <p>これまでのプロンプトの結果に加えて、HTLMが学習した表現が完全なFine-tuningの設定で有用であることを示すことも目的としています。 GLUEベンチマーク(Wang et al., 2018)でのファインチューニングにより、RoBERTa(Liu et al., 2019)、オリジナルのBART(Lewis et al., 2019)、T5(Raffel et al., 2019)などの他の事前学習型MLMモデルと比較します。 finetuningの際には、訓練セットからの単純な文章の連結ではなく、Le Scao and Rush (2021)から派生したプロンプトに例文を配置します。正確なプロンプトについては付録を参照してください。</p> <p>最近の微調整の進歩を考慮して、最近提案された微調整のためのR3F法（Aghajanyan et al.、2020a）をRoBERTaとHTLMの両方に使用した結果も報告する。その結果を表5に示す。全体的にHTLMは既存の事前学習法よりも向上しています。また、例をプロンプトに配置し、分類ヘッドを微調整することで、微調整性能を向上させることができることにも注目しています。プロンプトに関して見られる改善は、微調整に悪影響を及ぼさず、むしろ肯定的であり、構造化された事前訓練という提案されたアプローチが、微調整においても他の事前訓練の方法に代わる実行可能な方法であることをさらに証明している。また、表からテキストを生成するデータセットに対する微調整の結果を表3に示します。 GLUEの微調整と同様に、微調整中は全てのNLGサンプルをプロンプトに配置します。 HTLMのファインチューニングは、GPT-2モデルの両バージョンを一貫して上回ることができました。</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/e4exp"><img src="https://avatars.githubusercontent.com/u/44970465?v=4" />e4exp</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <h2>6 プロンプトデータの効率性</h2> <p>HTMLベースのプレトレーニングとプロンプティングのスキームは、プレーンテキストをベースにしたものに比べて何を提供するのでしょうか？ Le ScaoとRush(2021)は、1つのプロンプトにどれだけのデータポイントの価値があるかを定量化することを検討しました。具体的には、パターン（入力を入れる構造）とバーバライザー（パターンに対するイエス／ノーの答え）が与えられた場合の、3つの異なるタスク固有の設定を分析しました。</p> <p>(1)分類ヘッドを微調整する(H)、 (2)タスクの意味をコード化したプロンプトの動詞を微調整する(P)、 (3)プロンプトを微調整するが、動詞は無意味なものにする(N)です。</p> <p>それぞれの設定において、最終的な微調整のパフォーマンスに合わせて、トレーニング時に使用するデータポイント数を慎重に選択することで、プロンプトの有効性をデータポイント数で経験的に測定することができます。 Schick and Sch¨utze (2020)で提供されたのと同じPETプロンプトを用いて、BART、T5-Large、HTLMに拡張した同じ分析を提供する。 HTLMでは、すべてのPETプロンプトをHTML要素で囲んでいる。実験には、原著論文で使用されたのと同じデータセットを選択します；MNLI（Williams et al., 2018）、BoolQ（Clark et al., 2019）、CB（De Marneffe et al., 2019）、RTE（Bentivogli et al., 2009）、WiC（Pilehvar and Camacho-Collados, 2019）。</p> <p>まず、表6で分類ヘッド（H）に対するプロンプト（P）の微調整の平均的な優位性を見ます。全体的に、HTLMプロンプト、すなわちHTLMに適用されたハイパーテキストプロンプトは、他の様々な事前学習済みモデルに対する自然言語プロンプトよりも価値があることがわかります。小さいデータセットではRoBERTa-Largeと比較して、HTLMの優位性はCBでは3倍、RTEでは2倍に近い。さらに、WiCでは、HTLMはプロンプトを使用したときに正のトレーニングアドバンテージを持つことができる唯一の事前学習モデルである。これは、構造化されたデータに対する事前学習が、事前学習されたモデルのプロンプトに対して有益であることを示す追加的な証拠であると考えられる。また、意味のある動詞（P）でプロンプトを微調整した場合と、動詞をランダムな名字（N）に変更してプロンプトを微調整した場合の平均的な優位性を比較しました。これは、データをそれぞれのパターンで表現したことによるメリットなのか、パターンと動詞の結合によるメリットなのかを把握するために重要である。その結果を表7に示します。以前のP対Hの設定と比較すると、(Le Scao and Rush, 2021)で同様に見られたように、大きな利点を失っている。興味深いことに、CBのような小さなデータセットでは、プロンプトの学習上の優位性はすべてHTLMのパターンに由来する。これは、前処理とプロンプトの両方に、構造化されたドキュメントレベルのアプローチが、純粋な自然言語のアプローチに代わる実行可能な方法であることを示す、さらなる証拠であると考えている。</p> <p><img src="https://user-images.githubusercontent.com/44970465/125905501-b8ab7e7a-3f0c-4e99-9cfd-18af3e399cb5.png" alt="image" /></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/e4exp"><img src="https://avatars.githubusercontent.com/u/44970465?v=4" />e4exp</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <h2>7 Related Work</h2> <p>GPT-2 (Radford et al., 2019) は、大規模な言語モデルは、教師付きベースラインと比較した場合、NLPタスクにおいて様々なレベルのゼロショット性能を示すことを示しました（例えば、要約では初歩的な性能を示しますが、読解ではより競争力のある結果を示します）。 Brownら（2020）は、GPT3モデルを通じて、インターネットの大規模なサブセットで言語モデルをさらにスケールアップすることで、プロンプティングが標準的な微調整に代わる実行可能な手段となりうることを示しました。 GPT3の成功は、大規模なサイズと計算負荷の高い事前トレーニングによるところが大きいと考えられます。 Schick and Sch¨utze (2020)は、NLPタスクをclozeスタイルの質問に再構成することで、勾配ベースの微調整をタスク固有のラベルなしデータと組み合わせることで、GPT3が示したプロンプト機能が、はるかに小さなスケールの言語モデルでも発生することを示しています。その後の研究（Tam et al.2021）では、ラベルなしデータに頼らずにこれらの結果を改善しています。 GPT-3や他のモデルが従来の自然言語テキストベースのプロンプトを使用するのとは異なり、我々はHTML上で直接事前学習された生成的なマスクされた言語モデルを使用する新しいハイパーテキストベースのプロンプトスキームに焦点を当てています。タスクに特化したゼロショット性能を実現するために、カスタムの事前学習やデータ補強スキームが開発されています。例えば、PEGASUS（Zhang et al., 2019）は、大規模なニュースコーパスから顕著なギャップセンテンスをマスキングして生成する、要約に合わせた新しい事前トレーニングスキームを提案しています。 PEGASUSはゼロショット要約を行うことができるが、長さやスタイルなど、異なる要約データセットで変化する要約属性をほとんど制御できない。 WikiTransfer (Fabbri et al., 2021) は、一般的なWikipediaデータから生成された、長さや抽象度などのターゲットデータセットの特徴を含む擬似的な要約に対して、事前に学習されたモデルを微調整します。提案モデルでは、マスクの大きさを指定することで、生成されるテキストの長さを細かく制御することができます。さらに、異なるプロンプトを使用することで、HTLMはデータセット固有の補強や微調整を行うことなく、スタイル的に多様なサマリーを生成することができる。別の研究では、最終的なタスクを解決するために非常に少数のパラメータを最適化しようとするプロンプトのハイブリッド形式を検討している。例えば、Li and Liang (2021)は、連続的なプロンプト空間での最適化がプロンプト検索の効果的なソリューションであると主張し、Aghajanyanら (2020b)は、完全なパラメータ空間の低ランク投影を最適化する。簡単にするために、本稿では、フルフィネッティングまたはゼロショットプロンプトのいずれかにのみ焦点を当てる。構造化された入力に対するアーキテクチャプライアを変換器に符号化する試みもなされている。具体的には、Ainslieら(2020)は、入力の構造を符号化する能力だけでなく、入力長のスケーラビリティを可能にする新しいタイプのモデルを議論している。我々は、HTLMがモデル自体に構造プライアをエンコードすることなく、HTMLで利用可能な構造を直接学習することを選択した。</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/e4exp"><img src="https://avatars.githubusercontent.com/u/44970465?v=4" />e4exp</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <h2>8 まとめ</h2> <p>本稿では，大規模なWebクロールから得られた簡略化されたHTML文書を用いて学習したハイパーテキスト言語モデルであるHTLMを提案した．我々は、BARTのような目的語を通してHTMLを直接モデル化することで、タスクをHTMLで表現し、構造化されたゼロショット・プロンプトを行うことができることを示した。具体的には、各要約データセットの基本的なセマンティクスを捉えたプロンプトを作成することで、要約のためのゼロショット・プロンプトに関する過去の最良の結果を大差で上回ることができた。さらに、構造化データを用いた事前学習により、自然言語のみをモデル化した他の事前学習モデルと比較して、完全微調整の性能が向上することを示した。また、ハイパーテキストをモデル化することで、精度の向上以外にも利点があることを示した。 HTLMは、学習サンプルから文書構造を復元するようにモデルに要求するだけで、自動プロンプトに使用することができます。 GigawordやCNN/DMなどのデータセットにおけるこれらの自動プロンプトは、これまでの最先端のゼロショット・アプローチよりも優れています。最後に、HTLMが他の事前学習アプローチと比較して、データ効率の面で学習上の優位性があるかどうかを詳しく比較しました。これは、構造化されたデータを事前に学習することの有効性を示すものである。将来的には、構造化された事前学習とプロンプトのスケーリング法則に焦点を当てることができる。 GPT-3で見られたように、モデルのサイズと使用する計算機の量は、プロンプトのパフォーマンスに大きな影響を与える。</p> </div> </div> <div class="page-bar-simple"> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>

e4exp / paper_manager_abstract

HTLM: Hyper-Text Pre-Training and Prompting of Language Models #576

1 はじめに