大規模モデルで長いテキストを評価する方法: 4 つの主要な評価データセットのタスク設計とデータセット構築ソリューション

大規模言語モデル (LLM) は、さまざまな言語タスクで優れたパフォーマンスを発揮するにもかかわらず、通常はコンテキスト ウィンドウのサイズ内でのテキストの処理に制限されています。

LLM の長文理解能力をテストするために提案されるベンチマークはますます増えています。

現在、代表的な長文テキスト評価としては、主にZero-SCROLLS、L-Eval、LongBench、Loogleなどがあります。

この記事では、タスクの設計やタスク データ セットの構築スキームなど、非常に有益なこれらのデータ セットを参考用に整理します。

1. ZeroSCROLLS評価データセット

ZeroSCROLLS は、さまざまなソースからのデータセットを平均 10,000 語の統一された入力形式に自動的に処理します。

アドレス: https://arxiv.org/pdf/2305.14196.pdf

ZeroSCROLLS は、10 個の自然言語タスクのテスト セットを含むゼロ テスト ベンチマークです。各タスクでは、さまざまな種類の長いテキストでの推論が必要であり、各タスクでは最大 500 個の例しか使用できません。

で：

6 つのデータセットは Shaham らの研究成果を基にしており、他の 4 つは新しいタスクです。

写真

1. 要約タスク

この研究では、SCROLLS の 3 つのサマリー データセット (GovReport、SummScreenFD、QM-Sum) を採用し、4 番目のデータセット (SQuALITY) を追加します。

GovReport と SummScreenFD は完全なドキュメント要約タスクですが、QMSum と SQuALITY はクエリに重点を置いたタスクです。

で：

GovReport: 議会調査局と米国政府監査院からの長いレポートと、専門家による要約が掲載されています。

SummScreenFD: Wikipedia と TVMaze から収集された TV 番組のエピソード スクリプトとその概要が含まれています。

QMSum: クエリベースの会議議事録要約データセット。このデータセットには、学術会議、工業製品会議、ウェールズ議会およびカナダ議会の議事録が含まれています。会議の記録に加えて、各インスタンスには、特定のトピックの要約に焦点を当てることを目的としたクエリも含まれています。

SQuALITY: 質問中心の要約データセット。プロジェクト・グーテンベルクのストーリーを与えられた場合、ガイドとなる質問に基づいてストーリーまたはそのいくつかの側面の要約を生成することがタスクです。

サマリータスクに対応するプロンプトは次のとおりです。

写真

2. 質問応答

この研究では、SCROLLS の 3 つの質問応答データセット (Qasper、NarrativeQA、QuAL-ITY) を採用し、マルチホップの質問応答に重点を置いた MuSiQue を追加しました。

で：

Qasper: Semantic Sc​​holar Open Research Corpus (S2ORC) からの NLP 論文が含まれています。 NLP 実践者は要約に基づいて質問し、別の実践者グループが記事の内容に基づいて回答しました。

NarrativeQA: Project Gutenberg の書籍やさまざまな Web サイトの映画の脚本に関する質問と回答が含まれています。質問と回答を作成するために、注釈者は Wikipedia から書籍と映画の要約を入手しました。 各質問には 1 人以上の注釈者が回答します。

品質: Project Gutenberg、Open American National Corpus などからの物語や記事が含まれています。各文章には物語と多肢選択式の質問が含まれており、質問作成者は、正しく回答するために物語の大部分を読む必要がある質問を作成するように指導されます。

MuSiQue: 20 個の Wikipedia 段落と、異なる段落間で複数のジャンプを必要とする質問を入力とするマルチホップの質問応答データセット。元のデータセットでは、各質問には回答できない双子の質問があり、つまり、文章内に正しい答えが存在しません。この作品は、ZeroSCROLLS に対して、回答不可能な質問 100 件と回答可能な質問 400 件をランダムに選択しました。

3. 集約

この作業により、構造的に入力情報のさまざまな部分の文脈的関連付けと情報集約を必要とする 2 つの新しいタスクが作成されます。で：

SpaceDigest: 新しい感情集約タスク。 Space データセットに 50 件のホテルレビュー (評価なし) が含まれている場合、タスクは肯定的なレビューの割合を決定することです。

この作業では、元のデータセットの最高評価のホテル 500 軒から各ホテルの例 (50 件のレビュー) を作成し、厳密に肯定的なレビュー (評価 5 または 4) または否定的なレビュー (評価 2 または 1) のみを保持し、評価 3 の矛盾するレビューを削除します。

人間がこのタスクをうまく実行できるかどうかを確認するために、この研究では 5 人の注釈者に例の短縮版 (それぞれ 10 件のレビューを含む) を与え、肯定的なレビューの割合を記入するように依頼しました。

各注釈者に 10 個の例 (注釈者 1 人あたり 100 件のコメント、合計 500 件) が割り当てられました。

BookSumSort: さまざまなソースからの小説、演劇、長編詩の章 (または部分) の要約を含む Book-Sum データセットに基づく新しいタスク。

章の要約のリストが与えられた場合、タスクは BookSum で元の順序に従ってそれらを並べ替えることです。この作業では、BookSum から 125 冊の本の要約を手動で選択し、高品質のインスタンスのみを保持することでタスクを作成します。この作業では、各要約を手動で編集し、序文、前書き、概要、および要約の正確な場所を示す可能性のあるその他の情報などのコンテンツを削除しました。

たとえば、「第 8 章は...の簡単な説明で始まります」は「この章は...の簡単な説明で始まります」に置き換えられ、「劇が始まると、ヒッポリュトスは...と発表します」は「ヒッポリュトスは...と発表します」に置き換えられます。各抄録リストには 3 ～ 86 章の抄録が含まれており、インスタンスあたり中央値は 15、平均は 18.8 章でした。

ジョブは各リストから 4 つの順列をランダムに選択し、500 個のインスタンスを作成します。

対応するプロンプトは次のとおりです。

写真

2. L-Eval評価データセット

L-Eval (L-EVAL: 長いコンテキストの言語モデルのための標準化された評価の導入) は、小規模で類似した公開データセットからのデータと指示を再注釈付けして、品質を保証します。さらに、評価手順とベースラインを最適化して、より正確な結論を導き出します。

アドレス: https://arxiv.org/pdf/2307.11088.pdf

表1はL-Evalの統計を示している。

写真

L-Eval には、次のようなさまざまな質問タイプが含まれています。

多肢選択問題（TOEFL、QuALITY、Coursera）

真偽の質問（SF）

数学の問題 (GSM)

コード理解 (CodeU)

マルチドキュメント2ダイヤル

抽出QA（CUAD、NQ）

概要 QA (LongFQA、NarrativeQA、Qasper)

単一ドキュメントの要約 (GovReport、BigPatent、SummScreen、QMSum)

複数文書の要約（マルチニュース、SPACE）

リサーチライティング（OpenReview）

データ分布の点では、L-Eval の長い文書は、法律、金融、学術論文、講義、長い会話、ニュース、有名な Python コードベース、小説、会議など、多くの分野をカバーしています。

長さに関して言えば、L-Eval の平均入力長は 4k から 60k の範囲で、最大のサンプルには約 200,000 トークンが含まれています。この多様性は、さまざまなタスクで異なる長さのコンテキストと指示が必要になる可能性があり、参照の長さがタスク間で大きく異なるという現実世界の状況を表しています。

1. ゼロからのデータラベリング

L-Eval には、Coursera、SFcition、CodeU、LongFQA の合計 4 つの再注釈付きデータセットがあります。

元のリソースは、Coursera のビデオ、以前のオープンソース データセット、有名な Python ライブラリのソース コード、公開通話録音です。

注釈付けの難易度を軽減するために、本研究ではビッグデータと機械学習に関連する 4 つの公開コースを選択しました。入力された長いドキュメントはビデオの字幕です。質問と実際の回答は著者によってマークされています。 Coursera の教授法は多肢選択式の質問です。タスクの難易度を上げるために、ジョブには複数の正しいオプションがあります。

CodeU は、長い Python プログラムの出力を推測するために LLM を必要とするコード理解データセットです。この作業では主にNumpyのソースコードを使用し、文字列処理コードベースを構築しました。

LLM が引数の知識に基づいて質問に答えるのを防ぐために、この作業では元の関数名を置き換えます。 LLM はまず関数が呼び出される場所を見つけ、どの関数が呼び出されるかを判断する必要があります。

LongFQA この研究では、金融分野には長いコンテキストの質問応答データセットが不足していることにも注目し、6 つの企業 Web サイトの投資家向け広報セクションにある公開収益報告電話会議のトランスクリプトに基づいて QA ペアに注釈を付けました。

2. 公開データセットからデータを再注釈する

この研究では、5 つの公開データセットを L-Eval で再注釈しました。

で：

GSM(16ショット)はGSM8kデータセットから派生したものです。 LCLM がより長いコンテキストで推論能力を維持できる場合、より高品質の例を使用すると、数学の問題解決にプラスの影響を与えると考えられます。この研究では、より長い Chain-of-Thought を使用して 16 個のコンテキスト例を作成しました。そのうち 8 個は Chain-of-Thought ハブから取得され、8 個はこの研究自体によって作成されました。

「この作品の中で最も長い文から、作品は何を推測できるか？」や「この物語にはいくつの単語があるか？」など、グローバルコンテキストモデリングをテストするために、新しい合成指示が QuALITY に注入されました。

Openreview データセットには、openreview.net から収集された論文が含まれています。この作業では、モデルが要約セクションを記述し、関連する作業を要約し、最後に貴重な提案や著者への質問などのフィードバックを提供する必要があります。

3. データのフィルタリングと修正

残りの 12 個のタスクは既存のデータセットから派生したものです。しかし、この研究では、以前の長いシーケンス データセットの注釈の品質が大きく変動し、コンテキストとは無関係な回答できない質問が多数あることが判明したため、L-Eval ではデータ収集後にさらに多くの人手が必要になります。これらのエラーは、以前の研究で自動前処理スクリプトを通じて修正することは困難です。

L-Eval では、データ収集後にすべてのサンプルが手動でフィルタリングされ、修正されました。具体的には、この研究では、Claude-100k をアシスタントとして使用して、誤った QA や回答できない質問をフィルタリングします。

まず、ジョブは長いドキュメントを Claude に入力し、回答と説明を提供するように要求します。 clsude によって与えられた回答が真実と著しく矛盾している場合、または作業が文脈から回答を推測できない場合は、再度注釈が付けられるか、直接削除されます。

3. LongBench評価データセット

LongBench: 長いコンテキストを理解するためのバイリンガル、マルチタスク ベンチマークは、長いコンテキスト理解能力を包括的に評価するための、さまざまな長さ、分布、モード、言語、ドメインのシーケンスを含むバイリンガルおよびマルチタスク データセットを提供します。

写真

アドレス: https://arxiv.org/abs/2308.14508

1. シングルドキュメントQA

単一ドキュメントの QA の場合、この作業は主に長いドキュメントのインスタンスに焦点を当てています。含まれるもの: 読解力をテストする長いストーリーと質問で構成されたデータセット NarrativeQA。この研究は、NLP 実践者によって注釈が付けられた NLP 論文の QA を特徴とするデータセットである Qasper からもサンプルを取得しています。

さまざまな分野の長いコンテキストを理解するモデルの能力をより適切にテストするために、この研究では中国語と英語の MultiFieldQA データセットを手動でコンパイルしました。

具体的には、まず法律文書、政府報告書、百科事典、学術論文など、複数のソースから文書や記事を収集します。この研究では、3 人の博士課程の学生に各記事の質問と回答に注釈を付けてもらいました。自動評価を容易にするために、注釈付けの際には可能な限り明確な回答が与えられました。

注釈付けのプロセスでは、回答が文書から推測できること、また、回答に関連する文が冒頭または末尾に頻繁に現れる場合など、偏りを避けるために証拠の位置がかなりランダムであることが確認されました。

2. マルチドキュメントQA

複数ドキュメントの質問応答では、モデルが複数のドキュメントから情報を抽出して組み合わせて回答を得る必要があり、これは通常、単一ドキュメントの質問応答よりも困難です。

英語のテスト サンプルは、HotpotQA、2WikiMultihopQA、MuSiQue という 3 つの Wikipedia ベースのマルチホップ QA データセットから取得されます。

HotpotQA には、関連する 2 つの段落に基づいて、ネイティブ スピーカーが直接書いた 2 ホップの質問がいくつか含まれています。

2WikiMultihopQA には最大 5 つのホップを含む質問が含まれており、これらの質問はショートカットで解決できないように手動で設計されたテンプレートを通じて合成されます。

MuSiQue の質問は、最大 4 回の推論ホップを含む単純な質問から慎重に構成され、その後、人間の注釈者によって解析され、近道を回避して言語の自然さを確保します。元のデータセットの各質問には、ワンステップの推論証拠を提供する 2 ～ 4 個の補足段落と、いくつかの補足段落が追加されています。

長いテキストの評価にデータを適応させるために、この研究では、コンテキストとしてサポート段落またはディストラクタ段落のいずれかを含む Wikipedia の完全な段落を利用します。まず、文脈内に補足段落を含め、次に合計の長さが最大長に達するまで、必要な数の補足段落を追加します。最後に、段落はランダムに並べ替えられ、複数のドキュメントのコンテキストが形成されます。

この研究では、これら 3 つの英語データセットに加えて、DuReader に基づく中国語データセットも構築しました。ロングコンテキスト機能の評価に適したものにするために、この研究では、各質問に関連するいくつかの文書を提供するだけでなく、各質問が 20 個の文書に関連付けられるまで、文書セット全体からいくつかの文書をランダムに選択して誤答として扱います。

3. 要約

通常、コンテキスト内のローカル情報を活用して解決できる品質保証タスクと比較して、要約ではコンテキスト全体をより包括的に理解する必要があります。

オリジナルの GovReport データセットは、米国会計検査院と議会調査局からの詳細なレポートの大規模なコレクションであり、それぞれに人間が書いた要約が付いており、さまざまな国家政策問題をカバーしています。

QMSum データセットには、製品会議、学術会議、委員会会議など、複数の分野をカバーする 232 の会議のクエリ要約注釈が含まれています。この研究では、クエリを入力 I、会議の内容をコンテキスト C、要約を回答 A と見なします。

MultiNews は、同じイベントまたはトピックについて議論する 2 ～ 10 件のニュース記事で構成される、複数のドキュメントの概要データセットです。各記事には、複数のソース記事からの主要な情報を要約した、手動で作成された概要が付属しています。 LongBenchでは、この作業により、i番目のニュース記事の前に「Documenti」が追加され、コンテキストCに連結されます。

VCSUM は、230 時間を超える 239 の実際の会議から構成される大規模な中国の会議要約データセットであり、さまざまな要約タスクをサポートできます。 LongBenchでは、VCSUM内の長いフラグメントが評価サンプルとして選択されます。

4. 少数ショット学習

タスクの多様性を確保するために、この研究では、分類、要約、読解のタスクを少数ショットの学習シナリオに組み込んでいます。この研究には、TREC と LSHT を含む、細粒度クラス ラベルを持つ 2 つの分類データセットが組み込まれています。前者は 50 の細粒度クラスを含む質問分類タスクであり、後者は 24 のクラスを含む中国語ニュース分類タスクです。

要約タスクでは、ラベル付きの要約を含むメッセンジャー形式の会話を含む SAMSum データセットを使用します。 TriviaQA には、証拠の文章でラベル付けされた質問と回答のペアが含まれており、この作品では読解課題として使用されます。この作業では、TriviaQA 内の 1,000 語未満の文章を潜在的な例としてフィルタリングします。

TREC、LSHT、SAMSum、TriviaQAの場合、範囲はそれぞれ[100,600]、[10,40]、[10,100]、[2,24]です。

5. 合成タスク

合成タスクは、特定のシナリオとパターンでモデルの機能をテストするために慎重に設計されています。この研究では、LongBench で 3 つの合成タスクを設計しました。

PassageRetrieval-en と PassageRetrieval-zh は、英語版 Wikipedia と C4 データセットに基づいて構築されています。この研究では、データ エントリごとに 30 段落をランダムに抽出し、GPT-3.5-Turbo を使用して要約用にそのうちの 1 つを選択します。このタスクでは、モデルが、慎重に作成された要約に対応する元の段落を識別する必要があります。

PassageCount テストでは、モデルが完全なコンテキストを活用してタスクを完了する必要があります。各データ項目について、英語版 Wikipedia からいくつかの段落がランダムに選択され、各段落がランダムに複数回繰り返され、最後に段落がシャッフルされ、モデルは指定されたセット内の一意の段落の数を決定する必要があります。具体的には、段落数の上限としてMをランダムに選択します。次に、[2,M]の範囲からN個の段落がランダムに選択され、N個の段落からランダムサンプリング（復元抽出）が実行され、最終的なM個の段落が取得されます。

6. コード補完

コード補完は自動補完システムの重要なタスクであり、ユーザーが以前のコード入力とコンテキストに基づいてコードを補完するのに役立ちます。

このタスクは、特に長いコード入力やリポジトリ レベルのデータを扱う場合、モデルにとって大きな課題となる可能性があります。これは主に、モデルがコード要素内の関係（クラスと関数定義の関係など）に基づいて長距離シーケンスで注意を確立する必要があるためです。したがって、この研究では、これが長いコンテキストをモデル化するモデルの能力を評価するのに適したタスクであると考えています。

で：

LCC データセットは、オリジナルの Long Code Completion データセットから取得されます。元のデータセットは、GitHub 上のファイル内のコードを長さに基づいてフィルタリングすることによって構築されました。データには、コンテキストとして最初の数行の長いコードと、回答として次のコード行が含まれます。

リポジトリ レベルでのコード補完設定を考慮すると、ファイル間でコード情報を集約する必要があります。この目的のために、本研究ではRepoBench-Pデータセットを採用しています。

RepoBench-P データセットは、Github コード リポジトリから収集されます。まず、モジュールのインポート ステートメントに基づいて、他のファイルから関連するコード スニペットが取得されます。これらのコード スニペットは、現在のファイル内の前のコード行とコンテキストとして連結され、次のコード行を予測するために使用されます。

この研究では、ファイル内コンテキストが予測に役立つモジュールの以前の使用状況を提供しない、元のデータセットから最も困難な XF-F (ファイル間優先) 設定を選択します。

この作業では、元のデータごとに、実際のファイル間コード スニペット (最適な予測コンテキストとして手動で注釈が付けられている) を含むファイル間コード スニペットをシャッフルし、コンテキスト C にマージします。

写真

4. LooGLE評価データセット

LooGLE には、イベント タイムラインの並べ替え、理解/推論、計算など、より困難な長期依存タスクが含まれています。これらのタスクでは、情報の検索だけでなく、テキスト全体の理解/推論も必要です。

写真

表 2 に示すように、データ ソースには 3 つの種類があります。

写真

LooGLE で生成されるタスクには、主に短い依存関係のタスクと長い依存関係のタスクの 2 種類があります。

短い依存関係タスクの場合、Wikipedia の記事とスクリプトから短い QA が生成されます。

長い依存関係のタスクの場合、これらには arXiv 論文の要約や、長いドキュメントを理解するための手動で設計された QA タスクが含まれます。

QA には、複数の情報の検索、タイムラインの並べ替え、計算、理解、推論という 4 つの主要なサブタスクがあります。この研究では、長文テキストの理解度をより適切に評価するために、タスク/質問の生成を微調整して各データ ソースの固有の特性をカスタマイズします。

論文アドレス: https://arxiv.org/pdf/2311.04939.pdf

プロジェクトアドレス: https://github.com/bigai-nlco/LooGLE。

1. データセットの選択と構築

LooGLE ベンチマークは、科学論文、Wikipedia の記事、映画やテレビの脚本の 3 つのデータ ソースで構成されており、それぞれ異なるトピックとカテゴリをカバーしています。すべてのドキュメントは 2022 年以降のもので、長さは 10k を超えています。

で、

arXiv 論文用。データは、arXiv ウェブサイト (https://arxiv.org/) の 10,000 件のエントリからランダムに選択されました。応募期間は2022年1月から2023年4月までです。その後、それらの要約が抽出され、この作業要約タスクの主なソースになります。この作業ではデータの品質確保に非常に厳格に取り組んだため、参考文献のセクションが削除され、数式の文字化けが修正され、10,000 語未満の文書は排除されました。徹底的な調査の結果、最終的に 516 件の信頼できる研究論文が収集されました。

Wikipedia の記事については、まず公式サイト (https://dumps.wikimedia.org/) から .bz ファイル形式の最新ページ記事をダウンロードして解析しました。次に、HuggingFace（https://huggingface.co/datasets/wikipedia）のオープンソースWikipediaデータセット（202203.en）のサブセットを使用して、2022年以降の1万語を超える記事を保持しました。ダンプ ファイル内の一部のページは存在しなくなり、関連ページにリダイレクトされている可能性があるため、リダイレクトされたページのみが保持されます (免責事項の概要、引用、および参照)。

映画やテレビの脚本については、2022年以降に公開される映画やテレビシリーズを含む、すべての脚本が3つのウェブサイト（https://www.scriptslug.com、https://thescriptlab.com/、https://8flix.com）から提供されています。

2. 長期依存タスク

要約: 各論文の要約を直接参照して要約を作成します。要約は、各論文の主な内容と重要な情報を効果的にまとめます。

各ドキュメントの平均語数は 10,000 ～ 20,000 語で、5 ～ 10 個の質問を生成する必要があります。さらに、参加者は、記事の読み取り、データ生成、注釈付けに ChatGPT などの大規模な言語モデルやツールを使用することはできません。

長い依存関係の QA: 約 1.1k の実際の長い依存関係の品質保証ペアを手動でコンパイルするのに多大な労力を費やしました。この研究では、図 2 に示すように、複数の情報の検索、タイムラインの並べ替え、計算、理解、推論という 4 つの長期依存タスクを手動で設計しました。

写真

a. 複数の情報の検索

従来の短期検索タスクとはまったく異なり、特定の答えに対しては通常、テキスト全体にわたって多様な証拠があります。このタスクでは、長くて広く配布されたテキストから大量の情報を抽出し、証拠を集約して最終的な答えを導き出す必要があります。証拠は非常に明白な方法で提示されており、元のテキストの文章または章の中で直接見つけることができます。

b. 計算

前のタスクと同様に、まず大量のテキストから複数の情報を取得する必要があります。テキスト内の証拠のほとんどは数値データの形で提供され、通常は量、頻度、期間、特定の数値などを尋ねる質問の形で提供されます。

正確な回答を提供するには、質問と、提供された数値データとの関係を深く理解する必要があります。このプロセスは、大量の背景情報を把握する能力に大きく依存しており、ある程度の数学的推論能力も必要とします。

c. タイムラインの並べ替え

このタスクは、より伝統的な形式をとっており、「次のイベントのタイムラインを並べ替えてください」という指示と、並べ替えられた順序で提示される一連のイベントで構成されていました。この課題の目的は、テキスト全体にわたってこれらのイベントを時系列順に並べることです。

これらのイベントは、元のテキストから直接取得され、抜粋または要約された事実情報である場合があります。このタスクを正常に完了するには、ドキュメントの中心的なストーリーラインを記憶または完全に理解し、モデルの時間認識能力を評価する必要があります。

d. 理解力と推論力

この作業には、問題に対する深い理解だけでなく、適切な証拠を見つけることの意味を判断するための複雑な推論も必要です。最も一般的な質問パターンは、さまざまなイベントに関連する因果関係、影響、貢献、態度、および基本属性の調査です。

この課題の答えは原文からは明らかではありません。多くの場合、固有の接続と依存関係をモデル化するために複数ステップの推論が必要となり、複雑な分析プロセスを通じて回答を得るのに役立ちます。

2. 短期的な依存タスク

短い依存関係タスクには、質問回答 (QA) タスクとクローズ タスクが含まれます。短い依存関係の質問と回答のペアを生成するために、この研究では GPT3.5-turbo-16k を活用します。これらの短い依存関係のある質問と回答のペアは、通常、広範な証拠の検索を必要とせず、ローカライズされたスニペットから抽出できます。

写真

この研究では、各記事を複数のセグメントに分割し、記事内の関連する裏付け証拠を含め、これらのセグメントに基づいて言語モデル (LLM) に QA ペアを生成するよう促す反復的なアプローチを採用しています。

その後、QA ペアは手動でレビューされ、不要なコンテキストをフィルタリングし、冗長な説明を削除することで、一部の回答が絞り込まれました。この厳格なキュレーション プロセスは、生成された QA ペアの高品質と関連性を保証するために設計されています。

2. クローズタスク

当初、この作業では各スクリプトをさまざまな長さのセグメントに分割しました。次に、この研究ではGPT3.5-turbo-16kを使用して、ソーススニペットとプロンプトに含まれるいくつかの制約と一致する事実の要約を生成します（付録Dを参照）。

その後、生成されたサマリーに対して BERT-large を使用して固有表現抽出 (NER) が実行され、種類が人、場所、組織に制限されます。

写真

最後に、サマリーから一定数 (5 個以下) のエンティティがランダムに選択され、マスキングのプレースホルダーとして「」としてマークされます。目標は、長いコンテキストに基づいてマスクされたエンティティを予測することです。

要約する

この記事では主に長文テキスト評価に焦点を当て、Zero-SCROLLS、L-Eval、LongBench、loge ベンチマークなど、現在の代表的な長文テキスト評価を整理します。

データ セットの選択、タスクの設計、既存のモデルの評価に関する優れたガイダンスを提供します。具体的な詳細については、参考文献を参照してください。

参考文献

1. https://arxiv.org/pdf/2311.04939.pdf

2. https://arxiv.org/abs/2308.14508

3. https://arxiv.org/pdf/2307.11088.pdf

4. https://arxiv.org/pdf/2305.14196.pdf

私たちについて

Lao Liu、Liu Huanyong、NLP オープンソース愛好家および実践者、ホームページ: https://liuhuanyong.github.io。