はじめに

ChatGPTやGPT-4をはじめとする大規模言語モデル(LLM)の能力が大幅に向上し、自然言語処理の分野で多くの注目を集めています。これらのLLMは、さまざまな自然言語処理タスクにおいて、タスクに固有な学習データを用いてモデルをファインチューニングすることなく、推論時にタスクの説明といくつかの例を見せるだけでさまざまなタスクを解くことができます。タスクに関する指示だけを与える場合をZero-shot、いくつかの事例も与える場合をFew-shotと呼びます。

Zero-shotとFew-shotの例。「英語から日本語に翻訳してください。」と指示している。Few-shotでは、事例も与える。

ChatGPTのようなモデルは、メールの文面の生成や文書要約といったテキスト生成系のタスクで使われている例を多く見かけますが、実は自然言語理解のタスクでも高い性能を発揮することが知られています。たとえば、[1]では英語での自然言語理解ベンチマークであるGLUE[2]に対して、ChatGPTがBERTやRoBERTaなどの事前学習済みモデルを訓練した場合に匹敵する性能を出しうることを報告しています。以下の表を見ると、平均スコアでBERT-baseと同程度だとわかりますが、指示の与え方を工夫することで、RoBERTa-large並の性能に達することも示されています。

ChatGPTをGLUEで評価した結果[1]。

ChatGPTが英語での自然言語理解能力が高いことはいくつかの研究で示されていますが、日本語に対する理解能力がどの程度あるのかは明らかではありません。そこで、本記事では、日本語に対する言語理解能力を測るベンチマークであるJGLUE[3]を用いて、ChatGPTの日本語に対する言語理解能力を定量的に評価してみます。そして、その結果をBERTやRoBERTaなどのモデルを訓練した場合と比べることで、どの程度の能力があるのか明らかにします。記事の構成は以下のとおりです。

  • JGLUEとは
  • 評価の設定
  • 評価結果
  • 高度なプロンプトを使った性能改善

JGLUEとは

JGLUEは日本語の一般的な言語理解能力を測るためのベンチマーク(データセット群)です。このようなベンチマークを使うことで、言語理解モデルの能力をさまざまな観点から評価することが可能になります。JGLUEはGLUEと呼ばれる英語の言語理解ベンチマークにならって構築されており、日本語理解の能力を評価するための6つのデータセットが含まれています。データセットは大きく分けると文章分類、文ペア分類、質問応答の3種類のタスクに対応しています。以下の表に、JGLUEに含まれるデータセットと学習・検証・テスト用のデータ数を示します。

タスク データセット 学習 検証 テスト
文章分類 MARC-ja 187,528 5,654 5,639
JCoLA
文ペア分類 JSTS 12,463 1,457 1,589
JNLI 20,117 2,434 2,508
質問応答 JSQuAD 63,870 4,475 4,470
JCommonSenseQA 9,012 1,126 1,126

MARC-jaはAmazonレビューをまとめたコーパスであるMARC(Multilingual Amazon Reviews Corpus)をもとに構築されているデータセットです。MARCは、商品レビューと対応する5段階の評価(1〜5)から構成された多言語のコーパスです。MARC-jaでは、このうちの日本語部分を使用し、5段階の評価のうち3を除く1と2を「negative」、4と5を「positive」というラベルに変換し、2値分類用のデータセットを構築しています。以下にデータの例を示します。

MARC-jaの例。

JSTSは、日本語の文ペアの意味がどのくらい近いかを測定するためのデータセットです。JSTSは、日本語の画像キャプションデータセットであるYJ Captionsから抽出された文とクラウドワーカーが作成した文に類似度スコアを付与することで作成されています。正解の類似度は、0〜5までの間の値が付与されており、0に近いほど文ペアの意味が異なり、5に近いほど文ペアの意味が似ていることを表しています。以下にデータの例を示します。

JSTSの例。

JNLIは、日本語の前提文と仮説文の文ペアが与えられたときに、前提文の仮説文に対する関係を分類するタスクの性能を測定するためのデータセットです。JNLIもJSTSと同様、YJ Captionsから抽出された文とクラウドワーカーが作成した文にアノテーションすることで作成されています。関係には「含意(entailment)」「矛盾 (contradiction)」「中立(neutral)」の3つがあります。以下にデータの例を示します。

JNLIの例。sentence1が前提文、sentence2が仮説文。

JSQuADは日本語の機械読解用のデータセットです。Wikipediaから選んだ高品質な記事を段落に分割してクラウドワーカーに提示し、段落を読めば答えられる質問文とその答えを書いてもらうことで作成されています。以下にデータの例を示します。質問と対応する答えが書かれていることがわかりますが、答えは自由記述ではなく、段落中から抜き出せるものに限るという制約があります。

JSQuADの例[3]。

JCommonSenseQAは常識的な推論能力を評価するための5択の質問応答から構成されるデータセットです。ConceptNetをもとに、クラウドソーシングによって作成されています。以下にデータの例を示します。「question」に質問文、「choice0〜4」に選択肢、「label」に回答となる選択肢の番号が格納されています。

JCommonSenseQAの例。

評価の設定

本節では、評価用タスクやデータセット、評価指標、ベースライン、プロンプト、ChatGPTのパラメーターなどの評価設定について紹介します。

モデルの評価にはこれまでに説明してきたJGLUE(JCoLAを除く)を使います。現時点では、JGLUEは学習用と検証用のデータセットが公開されているため、学習用データセットの一部をプロンプトやモデルのパラメーターをチューニングするために使い、検証用データセットをテスト用に使用します。また、一部のデータセット(JSQuAD)は全件評価ではなく、検証用データセットをランダムにサンプリングしてテストします。以下の表に、データセットとテスト用の件数を示します。

タスク データセット テスト
文章分類 MARC-ja 5,654
文ペア分類 JSTS 1,457
JNLI 2,434
質問応答 JSQuAD 440
JCommonSenseQA 1,126

評価指標としては、MARC-ja、JNLI、およびJCommonSenseQAについては正解率を使って評価します。JSTSについてはPearsonおよびSpearman相関係数を用い、JSQuADについてはExact Match(EM)とF1で評価します。なお、F1の評価については、単語単位で評価すると、採用する形態素解析器によって値が異なってしまうため、今回は文字単位で計算します。

言語理解力を評価するためのベースラインとしてはBERTが一般的に用いられていることから、ChatGPT(Azureのgpt-3.5-turbo バージョン0301)、text-embedding-ada-002とBERTなどの6つのモデル(以下、BERT系モデル)を比較します。具体的には、東北大学により公開されている2つのBERT(Tohoku BERT)[[5]、早稲田大学により公開されている3つのRoBERTa[7][[9][10]の値を参照しています。

各タスクに対して、ChatGPTでタスクを解くために、タスク固有のプロンプトを設計します。プロンプトとしては、Zero-shot用とFew-shot用を用意します。このうち、Few-shot用のプロンプトに与える事例については、各タスクの学習用データセットから取得しています。事例数としては、MARC-jaは6(各クラス3ずつ)、JNLIは15(各クラス5ずつ)、JSQuADは5、JCommonSenseQAは6となっています。実際のプロンプトについては付録を参照してください。なお、JSTSのみ、text-embedding-ada-002を用いるほうが自然だと考えたため、ChatGPTは使っていません。

ChatGPTのパラメーターについては、すべての実験において、temperatureは0で固定しています。これは実験の再現性を高めるためですが、0で固定しても、毎回同じ出力になるとは限らないことに注意する必要があります[12]。また、無駄な出力を生成しないようにするため、タスクごとにmax_tokensを設定しています。その値は、MARC-jaとJCommonSenseQAでは1、JNLIでは3、JSQuADでは100としています。

テキスト生成で問題を解いているため、ときには想定していない文字列を出力してくることがあります(指定したラベル以外など)。そういった出力に対しては、次の後処理をしています。

  • MARC-ja: positiveに置き換え
  • JCommonSenseQA: 0に置き換え
  • JNLI: 小文字化
  • JSQuAD: 先頭と末尾の「」『』ペアおよび末尾の。を除去後、NFKCで正規化

評価結果

JGLUEに対する各モデルの評価結果を以下の表に示します。MARC-jaやJCommonSenseQAのようにBERT系モデルより優れた性能を示すタスクがある一方、JNLIではBERT系のモデルに大きく差をつけられています。先行研究[1]ではNLIのような自然言語推論系のタスクはBERT系のモデルより高性能であることが報告されていたのですが、今回のJNLIではそれは成り立ちませんでした。

モデル MARC-ja JSTS JNLI JSQuAD(EM/F1) JCommonSenseQA
ChatGPT(few-shot) 0.980 0.633 0.818/0.926 0.929
ChatGPT(zero-shot) 0.958 0.608 0.823/0.915 0.910
text-embedding-ada-002 0.8372/0.7902
LUKE Japanese large 0.965 0.932/0.902 0.927 0.893
Tohoku BERT base 0.958 0.909/0.868 0.899 0.871/0.941 0.808
Tohoku BERT large 0.955 0.913/0.872 0.900 0.880/0.946 0.816
Waseda RoBERTa base 0.962 0.913/0.873 0.895 0.864/0.927 0.840
Waseda RoBERTa large (s128) 0.954 0.930/0.896 0.924 0.884/0.940 0.907
Waseda RoBERTa large (s512) 0.961 0.926/0.892 0.926 0.918/0.963 0.891
参考:人間 0.989 0.899/0.861 0.925 0.871/0.944 0.986

JSQuADを題材に、ChatGPTの出力が正解に一致しない場合について分析してみましょう。不正解な事例を確認すると、以下の図に示すように、内容としては正解であるものの、余計な文字列を付与する等の形式違反により不正解となっているケースが見られました。とくに質問文中の文字列を付け足して答える傾向があります。たとえば、以下の例では、質問に対する正解は「印刷」ですが、「に使用される。」と付け足して答えているため、正解とは一致しなくなります。このあたりは、プロンプトエンジニアリングやファインチューニングによる改善の余地がありそうです。

JSQuADでの不正解例。

どのようなタイプの誤りが多いのかを明らかにするために、正解に一致しなかった82件について、「形式違反」「部分的に正解」「不正解」の3つのタイプに人手で分類してみます。その結果を以下の図に示します。図を見ると、正解に一致しなかったうちの50%弱は形式違反によるものであることがわかります。仮に、形式違反を正解とみなして評価指標(EM)を計算し直すと0.902という値になります。この値は、RoBERTa large (s512)には及ばないものの、その他のモデルを上回る結果となります。

正解に一致しなかった回答のタイプ分類。

高度なプロンプトを使った性能改善

評価結果を見てわかるように、JNLIにおいてはChatGPTとファインチューニングしたBERTやRoBERTaモデルとの間に大きな差があります。一方、大規模言語モデルの能力を活用するために、いくつかの高度なプロンプト手法が提案されています。そこで、本節では高度なプロンプト手法を用いてChatGPTの能力を改善し、BERTなどのモデルとの性能差をどの程度小さくできるか調査します。

今回は高度なプロンプト手法としてzero-shot CoT(Chain of Thought)を用いて、性能の改善を試みます。CoT(few-shot CoT)[13]では、中間的な推論過程を明示的に与えることで、複雑な推論を可能にします。その一方、zero-shot CoT[14]では、元のプロンプトに「一歩ずつ順番に考えてください」のような文言を追加することで、過程を明示的に与えることなく、言語モデル自身に考えてもらいます。

zero-shot CoTとfew-shot CoTの例。

実験の設定についてですが、検証対象はJNLIの検証データセットからサンプリングした100件のデータとします。これは、CoTは生成するトークン数が多く、全件を用いると検証に時間(とお金)がかかるためです。また、推論時の言語によって性能に変化があるかを検証するため、タスクへの指示は日本語と英語で行った結果を載せます。

JNLIに対する各設定の評価結果を以下の表に示します。指示を英語でした場合は、CoTを入れることにより性能の改善につながっていますが、日本語の場合は逆に性能が低下しています。この結果をもって、英語で指示したほうが良いということは言えませんが、日本語のタスクだからといって、必ずしも日本語で指示するほうが良いとは限らないようです。推論の結果を見ると、英語の場合と比べて、日本語の場合はステップで考えていない(指示に従っていない)ケースが散見されたので、そのあたりが今回の結果につながっている可能性があります。

モデル JNLI
Zero-shot(英語) 0.650
Zero-shot CoT(英語) 0.700
Zero-shot(日本語) 0.660
Zero-shot CoT(日本語) 0.600

おわりに

本記事では、日本語に対する言語理解能力を測るベンチマークであるJGLUEを用いて、ChatGPTの日本語に対する理解能力を定量的に評価してみました。その結果をBERTやRoBERTaなどのモデルをファインチューニングした場合と比べると、タスクによってはそれらのモデルを上回る性能を示すことがわかりました。また、高度なプロンプトを使うことで、性能改善の余地がありそうなこともわかりました。

ただし、今回の検証にはいくつかの限界があります。まず、一部のデータセットは、サンプリングして評価をしています。とくに、CoTの検証では、100件のデータを対象に評価しているため、選択するデータによる分散は大きいと考えられます。また、JGLUEのみを実験に用いているため、タスクが限定されている点も挙げられます。今回、高性能だったタスク(MARC-ja)は比較的単純な分類であったため、より難しいタスクでの性能も気になるところです。

今後は、より多くの自然言語理解タスクでChatGPTを評価し、詳細な分析と考察を行いたいと考えています。

以下の記事にも、OpenAIのモデルに関する検証結果を載せているため、本記事と合わせてご覧ください。

付録(プロンプト)

以下に、実験で使ったZero-shot用のプロンプトを示します。

MARC-ja

製品レビューをnegativeかpositiveのいずれかのセンチメントに分類してください。出力は小文字化してください。 

製品レビュー:{text}
センチメント:

JNLI

前提と仮説の関係をentailment、contradiction、neutralの中から回答してください。 

制約:
- 前提から仮説が、論理的知識や常識的知識を用いて導出可能である場合はentailmentと出力
- 前提と仮説が両立しえない場合はcontradictionと出力
- そのいずれでもない場合はneutralと出力

前提:{premise}
仮説:{hypothesis}
関係:

JSQuAD

質問に対する回答を文章から一言で抽出してください。回答は名詞で答えてください。 

文章:{context}
質問:{question}
回答:

※実際のところ、回答は名詞だけではないが、事前検証の結果、名詞で答えるように指示したほうが性能が良かったため、このようにしている。

JCommonSenseQA

質問と回答の選択肢を入力として受け取り、選択肢から回答を選択してください。なお、回答は選択肢の番号(例:0)でするものとします。 

質問:{question}
選択肢:{choices} # 例:0.社長,1.教師,2.部長,3.バイト,4.部下
回答:

※例は選択肢の形式を説明するために入れている。

参考資料

  1. Can ChatGPT Understand Too? A Comparative Study on ChatGPT and Fine-tuned BERT
  2. GLUE: A Multi-Task Benchmark and Analysis Platform for Natural Language Understanding
  3. JGLUE: 日本語言語理解ベンチマーク
  4. cl-tohoku/bert-base-japanese-v2
  5. cl-tohoku/bert-large-japanese
  6. nlp-waseda/roberta-base-japanese
  7. nlp-waseda/roberta-large-japanese
  8. nlp-waseda/roberta-large-japanese-seq512
  9. studio-ousia/luke-japanese-large-lite
  10. yahoojapan/JGLUE | GitHub
  11. Text completion | OpenAI Documentation
  12. Create chat completion | OpenAI API Reference
  13. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
  14. Large Language Models are Zero-Shot Reasoners