LLM Advent Calendar 2023について
こんにちは、LLM Advent Calendar 2023を企画しましたkunishouです。今年も気づけばあっという間に12月ですが皆さんいかがお過ごしでしょうか？ちょうど1年と1日前の2022年11月30日にChatGPTが世界に公開されたのは記憶に新しいですが、それを皮切りに世の中の機械学習／自然言語処理周りの技術トレンドも大きく変化した1年だったと感じました。私はちょうど1年ほど前に「オープンソースAIを用いた音声対話ロボットの作成」というBERTと音声対話する内容の記事を投稿しましたが1年経ち改めて読み返すとかなり陳腐な内容に見えてしまい、技術の進歩の速さに非常に驚いています。実際、技術の進歩は早く、この1年はLLM（Large Language Model）に関連する新しい技術や日本語対応したLLMが日々公開され、常に驚きと興奮を感じる毎日だったと思います。今回企画したこのLLM Advent Calendar 2023では皆さんがこの1年の間に見てきたLLMの技術に関するワクワクを共有し、知識を広げ、これからのLLMの可能性について考える場になれば幸いです。
※ まだまだ参加枠がたくさんありますので今からの参加も大歓迎です！
本記事について
LLM Advent Calendar 2023 1日目の記事になります。本記事はLLMのファインチューニングで使用されるInstructionデータセットの品質の定量化にチャレンジした記事になります。
モチベーション
高品質なデータセットの重要性
LLMには大きくベースモデルを作る事前学習フェーズと、ベースモデルを様々な指示に応答できるように調整するファインチューニングフェーズがあります（場合によってはファインチューニングの後に強化学習フェーズもあります）。LLMでのファインチューニング（SFT）は指示文と応答文をペアにしたInstructionデータセットを用いてチューニングをしますが、このチューニングに使用するデータセット次第でLLMの性能は大きく影響を受けると言われており、高品質なデータセットであれば数千程度のデータでもかなり高い性能が出ることが知られています。例えば、先日、ストックマーク社から公開された stockmark-13b-instruct では、理研にて作成した高品質な1,003レコードだけのデータセットを用いてファインチューニングすることで oasst1-89k-ja（88,838データ）や dolly-15k-ja（15,015データ）などのデータセットでチューニングするよりも高い性能が出ることが報告されています。
高品質とは？
さて、Instruction データセットにおける「高品質」については諸説ありますが、以下のようなものであることが望ましいと言われています（当然これだけがすべてではないです）。
- データの文章が自然な日本語になっていること（日本語翻訳による不自然さがない）
- データの内容が日本文化に沿ったものであること
- 指示の内容が複雑であること
- データセットに含まれる指示タスク（QA、要約、翻訳、…）が豊富であること
ただ、上記のように高品質なデータがどういうものなのかについては定性的に言われてはいるものの、品質が定量的に示されているわけではないため、データセットの中でどのデータが良いデータで悪いデータなのかを判別することはできません。もし仮に、 データに定量的な品質スコアを付与することができれば、公開されているデータセットを盲目的にすべて使用するのではなく、そのデータセットの中から高品質なデータのみをピックアップして使用する、といったより柔軟なファインチューニングができるようになる と考えています。
そこで、 今回の記事ではこの Instruction データセットの品質を定量化すること（品質スコアリング）にチャレンジ してみました。
目次
１．品質スコアリング方法の概要
２．LLM 48個のファインチューニングと評価の実施
３．品質スコアリング（回帰予測）
４．品質スコアリング（ルールベース）
５．選定したデータセットによるファインチューニングと評価
６．最適な閾値の探索
７．最適閾値データでのファインチューニングと評価
８．テキストデータと品質スコアを用いた品質予測モデルの検討
９．他の Instruction データセットでの品質スコアリング
１０．まとめ
１１．今後の展望
１２．おわりに
※ 記事内での言葉の定義
データセット：Instruction データセットを指す
ファインチューニング：Instruction データセットを用いたInstruction Tuningを指す
品質スコア：データの評価指標への寄与度の大きさを示す
１．品質スコアリング方法の概要
さっそくInstructionデータセットの品質を定量化する流れを説明します。なお、本記事内における「品質」とは「評価指標に対してプラスに作用するかどうか」を指し、「品質スコア」は「評価指標への寄与度の大きさを表す数値」の意味で使わせていただきます。
データの品質に関する仮説
私はプライベートでは、商用利用可能なLLMをファインチューニングすることがよく良くありますが、その中で実験的に特定のデータセットを分割、サンプリングしてファインチューニングするようなこともしてきました。以下はあるデータセットを3Foldで分割し、それぞれのデータでファインチューニングし、JGLUE （ JcommonsenseQA 、MAARC-ja､ JSQuAD ）で評価した結果の一例になります。
同じデータセットでも3つに分割することで評価結果が大きく異なっており、Fold 0 のように JcommonsenseQA はとても高いけども、JSQuAD は低かったり、 Fold 2 のように JSQuAD のみ突出していたりと、ひとつの評価指標が良ければ、他の評価指標も良いわけではないことにも気づきました。
このような結果を見て、以下のような仮説を立てました。
- データの品質は単純に1つの指標で表せるものではなく、いろいろな軸を持っている。
- データによってある評価指標に対してプラスに作用するデータもあればマイナスに作用するデータもある。
- データによってある評価指標Xではプラスに作用していも、評価指標Yではマイナスに作用するデータもある。
- すべての軸でプラスに作用するデータ（下図のデータC、こういうデータがいわゆる高品質なデータなのかもしれない）だけをピックアップしてファインチューニングすれば LLM の性能を格段に上げることができる（マイナスに作用するデータが一切含まれないため）。
本記事ではこの仮説の是非を確認するべく、 データごとに複数の品質スコア（例えば、JcommonsenseQAへの寄与度、MARC-jaへの寄与度、…）を算出し、最後はすべての品質スコアが高いものに絞ったデータでファインチューニングし、評価を行います。
品質スコアリングの流れ
ステップ１：評価指標の決定
本記事の品質スコアリングはデータが評価指標へどれくらい寄与するのかを算出する方法になります。そのため、まずは寄与度を知りたい評価指標を決めます。例えば、各データのコード生成性能への寄与度を見たいのであればコード生成ベンチマークを評価指標に設定すると良いと思います。ここでは説明を分かりやすくするために、仮で JGLUE の MARC-ja への寄与度を算出する体で話を進めます。
ステップ２：ランダムに分割したデータでモデルをファインチューニング、評価
特定のデータセットを特定シードでランダムに3Foldに分割し、分割した各データでモデルをファインチューニングし、評価指標を算出する。シードを変えてこれをひたすら繰り返す（シードは後で必要になるため控えておく）。すると以下のようなデータが蓄積されます。
ステップ３：評価指標予測モデルの作成
ステップ２で蓄積したデータに、そのモデルをファインチューニングしたときにどのデータを使用したかの情報をマルチホットな形式でマージする（0：データ未使用 1：データ使用）。各モデルでのデータ使用有無はステップ２で控えたシードを元に作成する。データの使用状況をマージしたデータを用いて評価指標を回帰予測するモデルを作成する。
ステップ４：求めた回帰係数を品質スコアとしてデータセットにマージ
ステップ３の予測モデル作成で求めた回帰係数を品質スコアとしてデータセットにマージする。回帰係数がプラスのものは評価指標に対してプラスに寄与し、マイナスのものはマイナスに寄与するものとする。品質スコアの高いデータのみに絞ってファインチューニングをすれば高い評価値を得ることができると推定。
(最終的に以下のようなアウトプットを得たい)
２．LLM 48個のファインチューニングと評価の実施
前章で述べた流れで実際に検証を進めます。
実施内容
以下の内容で検証を実施しました。
使用データセット： oasst1-89k-ja（データ数 55,359）
ファインチューニングメソッド： QLoRA
作成モデル数： 48個（16シード×3Fold）
使用モデル： cyberagent/open-calm-1b
評価指標： JGLUE（ JcommonsenseQA 、MARC-ja 、JSQuAD ）
評価コード： Stability-AI/lm-evaluation-harness
今回使用するデータセットの oasst1-89k-ja (以降、oasst1 )はOpenAssistantという海外の有志コミュニティで作成されたデータセットを私が個人で日本語に翻訳して公開したデータセットになります（指示、応答の形式に変換すると55,359レコードになります）。モデル数については100個以上を作成、評価したかったのですが時間がかかる関係でひとまず48個までの作成としました。使用モデルは CyberAgent 社から公開されている OpenCALM-1B を利用しました。モデル作成が短時間で済む1Bクラスのモデルであること、かつモデルのアーキテクチャが LoRA ファインチューニングに対応している GPT-NeoX であることから選定しました（rinna 社や LINEヤフー社、LLM-jp から公開されている1Bクラスのモデルはすべて GPT-2 ）。評価指標は JGLUE の JcommonsenseQA 、MARC-ja 、JSQuAD の3つでやることにします（ JNLI はなぜか自分の環境だと評価時にエラーがでてしまうため除外）。なお、JGLUE については以下の記事を参考にして下さい。評価には StabilityAI 社が公開している lm-evaluation-harness のコードを使用しました。
評価結果
上記の条件で 48個の LLM の作成、評価を実施しました。画像の結果は一部のみですが以下のようになりました。参考にファインチューニングは QLoRA で 1モデル 3エポック 45 分、評価（JcommonsenseQA、MARC-ja、JSQuAD）には1モデル 30 分程度の時間がかかりました。ファインチューニングは A100 80GB 2台で行い（ Paperspace を利用）、評価は Google Colab 上の V100 で行いました（正直なところ何回もやりたくなるような作業ではないです）。
各指標の相関
参考に、評価で得たモデル48個の各指標の相関を確認しました。各指標同士の相関はあまり高くないですが、「 validation loss と JcommonsenseQA 」や「 JcommonsenseQA と MARC-ja 」は他と比較して相関が高いように見えます。このことから validation loss が良い（低い）と JcommonsenseAQ の値は良かったりするけども、その他の指標に関しては validation loss の値を見てもあまり参考にはならなそうです（実際、「 validation loss が悪くても（高くても）、 MARC-ja はとても高い」といったモデルもありました）。
３．品質スコアリング（回帰予測）
次に、48個の評価結果に、各モデルでどのデータを使用したかのマルチホットな特徴量をマージし、このデータを用いて回帰予測を実施しました。LightGBM Regressor で予測モデルの作成を行い、作成したモデルで、テストデータに対して推論を行いました。予測値と正解値の関係を可視化したのが以下のグラフになります。
予測結果
ここでは48個のデータのうち38個を学習データ、10個をテストデータとしました。
なんということでしょうか。 予測値と正解値の相関が取れておらず、まったく目的変数を予測することができていません （惜しいというレベルではないです）。原因としては、マルチホットな特徴量が5万個ほど（ oasst1 のレコード数分）あるのに対して学習データ数が極端に少ないことが原因だと思われます（なお、最初からこの懸念自体は分かっていました）。作成する LLM の数を 48 個から増やせばどうにかなるレベルではないので、ここで当初のやり方から アプローチ方法を変えることにしました。
４．品質スコアリング（ルールベース）
先ほどのやり方は、評価指標の評価値を予測するモデルを作成し、各データの回帰係数を品質スコアとするアプローチでしたが、ここではルールベースで品質スコアを算出できないかを試してみることにします。
方法としては非常に単純で、48 個の LLM の評価指標と各モデルでどのデータを使用したかが分かっています。ここでデータごとに、そのデータを使用してファインチューニングした LLM の評価値の平均値を計算し、その平均値をそのデータの品質スコアと見なす方法です。
ちょっと言葉だけだと説明しづらいですが、晴れ男、雨男をイメージしてもらうと分かりやすいかもしれません。「データAがいるといつもLLMの評価指標が高いからデータAは寄与度が高いだろう」みたいな感じです。
下図は、 index 2 のデータの品質スコアを集計するイメージですが、 index 2 のデータの数値が 1 のもの、すなわちモデルで index 2 のデータが使用されたものの評価指標の値（ 0.827 , 0.823 , … ）の平均を算出します。
品質スコアの集計実施
上記のルールに則り、oasst1 の55,359 レコードすべてのデータに対して品質スコアを算出しました。以下は結果の一部になります。なお、数値は min-max スケール済みの値になります。
各評価指標の品質スコア分布
3つの評価指標の品質スコアを算出しましたが、それぞれの分布がどうなっているのかも確認してみたところ、どの品質スコアの分布も正規分布に近い形になっていました（何となく良さそうな感触を得ました）。
縦軸がデータ頻度、横軸が各評価指標の品質スコア（数値は min-max スケール済み）
５．選定したデータセットによるファインチューニングと評価
次に、先ほどルールベースで集計した品質スコアが妥当なのかを確認するために、品質スコアが以下の3つの条件すべてに当てはまるデータのみでLLMをファインチューニングし、評価指標がどうなるかを確認しました。
データ選定条件
- JcommonsenseQA 品質スコアが上位1万位以内、かつ
- MARC-ja 品質スコアが上位1万位以内、かつ
- JSQuAD 品質スコアが上位1万位以内
※ 55,359 レコードのうち 763 個のデータが該当
評価結果
品質スコアの高いデータ763個でファインチューニングし、評価した結果は以下の通りになりました。なお、比較のために oasst1 をフルデータ使用した場合の評価値も載せています。
使用モデル： line-corporation/japanese-large-lm-3.6b※
チューニングメソッド： QLoRA
※ LLM Advent Calendarの別日の記事でLINEモデルを使って検証をしている関係でここでもLINEモデルを使用
いかがでしょうか？ oasst1 の55,359レコードすべてを使用する場合と比較して品質スコアをもとに選定した763個のデータでファインチューニングしたモデルのほうが JcommonsenseQA 、MARC-ja 、JSQuAD のスコアが良いという結果になりました。すごい粗々なルールベースでの品質スコア集計でしたが一応機能はしていそうです。
６．最適な閾値の探索
５章での結果からルールベースで集計した品質スコアが上手く機能している可能性が高そうです。先ほどは各評価指標の品質スコアが上位1万位以内のデータを選定しましたが、品質スコアがいくつまでのデータを選定すると良いのかを確認するために データ選定する際の品質スコアの値を可変させてファインチューニングと評価を行い、各評価指標ごとにデータ選定する際の最適な閾値を確認していきます。
JcommonsenseQA 品質スコア
縦軸が JcommonsenseQA の評価値、横軸がデータ選定の品質スコア閾値（ 例えば「0.525」のときには品質スコア（横軸）が 0.525以上のデータをファインチューニングに使用。 数値は min-max スケール済み）
閾値探索の結果から JcommonsenseQA に関しては品質スコア（横軸）が 0.525 以上のデータを選定するのが良さそうです。グラフの見方ですが品質スコアが 0.525 以上のデータは JcommonsenseQA へプラスに寄与するデータと想定され、データ選定の閾値を0.525へ下げていく（データ数が増える）とファインチューニングで使用されるプラス寄与のデータ数が増えていくので、JcommonsenseQA の値も上がっていきます。 0.525 以下のデータは JcommonsenseQA へマイナスに寄与するデータと想定され、データ選定の閾値を0.525よりも下げていくと マイナス寄与のデータが増えていくので JcommonsenseQA の値は低下していく、と解釈することができそうです。
MARC-ja 品質スコア
縦軸が MARC-ja の評価値、横軸がデータ選定の品質スコア閾値（数値は min-max スケール済み）
閾値探索の結果から MARC-ja に関しては品質スコア（横軸）が 0.800 以上のデータを選定するのが良さそうです。
JSQuAD 品質スコア
縦軸が JSQuAD の評価値、横軸がデータ選定の品質スコア閾値（数値は min-max スケール済み）
閾値探索の結果から JSQuAD に関しては品質スコア（横軸）が 0.725 以上のデータを選定するのが良さそうです。
７．最適閾値データでのファインチューニングと評価
6章で求めたデータから各評価指標の品質スコアが以下の条件であると良いことが分かったので、ここではこの条件に当てはまるデータを用いて、ファインチューニングと評価を実施します。なお、選定条件1の各条件はあくまでも単一条件の場合にその評価指標が最適となる閾値ですが、3つの条件すべてに当てはまる制約が付くことで単一条件の場合と比較してデータ数が少なくことが想定されます。そこで、選定条件2ではデータ数が少なくなることによる評価指標への影響も考慮して、条件1の各閾値にマージンを設けたデータ選定もしてみます（閾値を少し下げてデータ数を増やす）。
選定条件1
- JcommonsenseQA 品質スコアが 0.525 以上、かつ
- MARC-ja 品質スコアが 0.800 以上、かつ
- JSQuAD 品質スコアが 0.725 以上
※ 55,359 レコードのうち 1,107 個のデータが該当
選定条件2（閾値を少し下げてデータ数を増やす）
- JcommonsenseQA 品質スコアが 0.500 以上、かつ
- MARC-ja 品質スコアが 0.790 以上、かつ
- JSQuAD 品質スコアが 0.700 以上
※ 55,359 レコードのうち 4,204 個のデータが該当
評価結果
使用モデル： line-corporation/japanese-large-lm-3.6b
チューニングメソッド： QLoRA
評価結果は最適な閾値を条件にした選定条件1（表のNo.3）よりも、選定条件2（表のNo.4）のほうがいずれの評価指標も高くなりました。また、763個のデータを用いたモデルの評価値と比較すると選定条件2は JcommonsenseQA と JSQuAD は高い値になりましたが、MARC-ja は 763 個のデータを用いたモデルの評価値のほうが高くなりました。選定条件2において MARC-ja 品質スコアの選定閾値をもう少し高め（ 例えば 0.820 くらい）に設定すると MARC-ja の評価値ももっと高くできると思います。
データ選定方法によるデータセットのカスタム
上記の結果から、データを選定する閾値を調整することでデータセットの品質を調整できることが分かりました。先ほどの選定条件では3つの評価指標の値が良いバランスになることを意図してデータ選定しましたが、特に重要視したい評価指標があるのであれば、その指標に比重を置いたデータ選定をすることも可能で、以下の一例のように JcommonsenseQA 重視、MARC-ja 重視、 JSQuAD 重視なデータセットを作ることも可能です。
８．テキストデータと品質スコアを用いた品質予測モデルの検討
ここまでの検証の結果から、当初の狙い通り各データにある程度信頼できる品質スコア（データの評価指標への寄与度）を付与することができていると考えています。 この品質スコアはLLMのファインチューニングを48回行うプロセスを経て得ることができましたが、今回品質スコアリングを実施したデータセット oasst1 以外のデータセットにも品質スコアを付与したいとなったときにこのプロセスが毎回発生するのは非効率です。 そこで oasst1 のテキストデータと今回算出した品質スコアから、指示文と応答文がペアになったテキストデータを与えると品質スコアを予測してくれるモデルを作れないかを検討しました。
ここでは先ほどと同様、テキストデータをembeddingして得たベクトルデータを特徴量、品質スコアを目的変数としてLightGBM Regressorで回帰予測を行いました。
予測結果
（ここでは3つの品質スコアの平均値を目的変数としました）
なんということでしょうか。 予測値と正解値の相関が取れておらず、まったく目的変数を予測することができていません （本記事2回目）。何となく今回は上手くいくかもと思っていましたが、自分のやり方が悪いのか現時点では精度の良い品質予測モデルを作ることはできませんでした。これはまた時間のある時にリトライしてみたいです（ LightGBM などではなく BERT で直接回帰する方法なら上手くいくかも？）。
９．他の Instruction データセットでの品質スコアリング
ここまで oasst1 に対して品質スコアリングを試みてきましたが、検証結果から今回提案した品質スコアリングが手法としてある程度有効そうであることを確認できました。次に databricks-dolly-15k-ja （以降、dolly ）や hh-rlhf-49k-ja （以降、hh-rlhf ）※ に対しても品質スコアリングを実施してみます。
※ databricks-dolly-15k-ja 、hh-rlhf-49k-ja はどちらもオリジナルの英語データセットを私が個人で日本語に翻訳し公開したデータセットになります。
dolly , hh-rlhf に対しても品質スコアを付与し、oasst1 , dolly , hh-rlhf の3つのデータセットの中で品質の良いデータのみを選定してファインチューニングをすれば JGLUE の値がより高くなると推定されます。
というわけで、
もう一度 LLM のファインチューニングとJGLUEの評価を48回行いました。
oasst1 でやったときは「この作業、最悪全部無駄になるかも…」と思いながら検証をしていたので若干の辛さを感じましたが、今回はある程度良い結果が出そうな見通しがある中で実施したのでさほど辛さはありませんでした。
品質スコアの分布
oasst1 における品質スコアの最適な閾値は以下の値が目安になるので、dolly , hh-rlhf においても品質スコアがこの値以上のデータを選定すると良さそうです。
- oasst1 における品質スコアの最適な閾値条件
| JcommonsenseQA 品質スコア |
MARC-ja 品質スコア |
JSQuAD 品質スコア |
|
|---|---|---|---|
| min-max scaled vale | 0.525 以上 | 0.800 以上 | 0.725 以上 |
| raw value | 0.285 以上 | 0.797 以上 | 16.954 以上 |
このことを踏まえて dolly , hh-rlhf の品質スコアの分布を確認してみます。なお、分布図は dolly と hh-rlhf の2つのデータセットをマージして表示しており、赤い破線は oasst1 で求めた、各品質スコアでデータ選定する際の最適な閾値になります。
横軸は品質スコアの 生値（ mix-max スケール前）、赤い破線はデータ選定の最適な閾値
なんということでしょうか（本記事3回目）。品質スコアの分布を見ると dolly , hh-rlhf の品質スコアは JcommonsenseQA 、MARC-ja についてはかなり低く、逆に JSQuAD だけは oasst1 と比較してもかなり品質スコアが高いようです。この分布の結果から、dolly , hh-rlhf において oasst1 で求めた3つの品質スコアの最適閾値の条件すべてに該当するデータは存在しないことが分かります。
この場合、dolly , hh-rlhf には選定できるデータはないのか？という話になりますが、JSQuAD についてはかなり品質スコアが高いので dolly , hh-rlhf における3つの品質スコアが高いデータを oasst1 の高品質データに上手い塩梅でマージすれば、JcommonsenseQA 、MARC-ja の評価値は多少下がるものの、 JSQuADの評価値を大幅に高めることができる と予想できます。
次にこの予想が正しいかを確認してみます。
選定したデータでのファインチューニングと評価
oasst1 と dolly , hh-rlhf に対して以下の条件でデータ選定を行い、そのデータでファインチューニング、JGLUE での評価を行いました。
oasst1 選定条件
閾値は生値、カッコ内はmin-maxスケール後の数値
- JcommonsenseQA 品質スコアが 0.284（0.500）以上、かつ
- MARC-ja 品質スコアが 0.796（0.790） 以上、かつ
- JSQuAD 品質スコアが 16.866（0.700） 以上
※ 55,359 レコードのうち 4,204 個のデータが該当
※ 7章における選定条件2と同じ条件
dolly , hh-rlhf 選定条件
閾値は生値（min-maxスケール前の数値）
- JcommonsenseQA 品質スコアが 0.240 以上、かつ
- MARC-ja 品質スコアが 0.720 以上、かつ
- JSQuAD 品質スコアが 18.250 以上
※ 61,439 レコードのうち 1,191 個のデータが該当
（oasst1 と dolly , hh-rlhf で min-max スケール時の最大、最小値が異なるため、横並びに閾値を見るため生値表記にしています）
評価結果
評価結果（表の No.5 ）は、No.4 の結果と比較し、JcommonsenseQA が若干下がり、MARC-ja は若干向上、 JSQuAD は大幅に向上しており、MARC-ja 以外は前述の予想通りになりました。
oasst1 フルデータを使った場合の結果（表の No.1 ）と比較すると、品質スコアでデータ選定した高品質なデータを使用することで少数データながらも各評価指標の値を向上させることができ、今回のケースでは、特に MARC-ja , JSQuAD で大幅な評価値の向上を確認することができました。
なお、参考に dolly , hh-rlhf のJSQuADのデータ選定閾値を 18.250 以外にも 18.100（表の No.6 ）と 18.400（表の No.7）にも変更して評価値を確認してみました。JSQuADのデータ選定閾値が 18.250（表の No.5 ）の場合が一番良さそうです。
応答の比較
最後に参考程度ですが oasst1 のデータをすべて使用したモデル（表の No.1 ）と高品質なデータのみを使用したモデル（表の No.5 ）における任意の指示に対する応答の一例を載せておきます。
- 指示：東京タワーについて教えて下さい。
| モデル | 応答 |
|---|---|
| model 1 | 1958年3月に完成した東京タワーは、東京のランドマークであり、日本の近代建築の傑作です。その高さは333メートルで、60年間東京のランドマークでした。東京タワーは日本の近代的なデザインと建築の遺産であり、そのユニークな形と構造は、日本の建築とエンジニアリングの傑作であり、現代の都市の景観の重要な構成要素でもあります。 |
| model 5 | 1958年に完成した東京タワーは、東京のシンボルであり、333メートルの高さがあります。東京タワーの頂上には、有名な赤いアンテナがあり、これはテレビやラジオの送信に使用されています。また、展望台やレストランもあります。また、東京タワーは東京の観光スポットの一つであり、多くの人々が訪れています。 |
- 指示：資本主義について教えて下さい。
| モデル | 応答 |
|---|---|
| model 1 | 社会主義は、労働者の利益を最優先にし、彼らのニーズを満たすために社会を変革する政治形態です。労働者の賃金やその他の労働条件を改善するために使用されるため、資本主義は労働の報酬として賃金を支払うために使用され、労働者の利益の最大化を達成します。資本主義は、競争、市場、および利益の最大化された企業を奨励する自由市場システムに基づいています。資本主義は多くの欠点を持っていますが、それは最も人気のある政治形態の1つです。 |
| model 5 | 現代の資本主義は、個人が資本を所有し、資本を投資して生産能力を拡張し、利益を最大化しようとする経済システムである。資本主義経済は、生産手段を独占する資本家が、労働者を搾取するシステムとして批判されてきた。しかし、資本の蓄積が雇用や需要を創出し、経済を成長させるという側面も持つ。資本主義経済の歴史的発展には、産業革命や大恐慌など、様々な要因が複雑に絡み合っている。 |
１０．まとめ
とても長くなりましたが記事のまとめです。
- 今回、Instructionデータセットの品質スコアリング方法を提案し一定の有効性を確認
- LLMに対してサンプリングするデータを変更して48回ファインチューニングと評価を実施。その評価結果をもとにルールベースで各データの品質スコアを集計（なお、回帰予測するアプローチは失敗）
- 各評価指標（JcommonsenseQA , MARC-ja , JSQuAD）の品質スコアの最適閾値を探索し、その値を目安に高品質なデータを選定することで、少ないデータ数でもデータセットすべてのデータを使用する場合よりも評価指標の値が高くなることを確認
- 他のデータセットでの品質スコアリングを簡易化する目的でデータの品質予測モデルの作成（ LightGBM ）を試行したが上手くいかず
- dolly , hh-rlhf でも oasst1 と同様に品質スコアリングを実施（ JcommonsenseQA , MARC-ja の品質は低く、JSQuAD の品質は非常に高い）。品質スコアの高いデータを選定し使用することで特に JSQuAD の評価値が大幅に向上することを確認
１１．今後の展望
今回は時間の都合上できなかったことも多々あるため、時間があれば今後以下のようなこともできればと思っています。
- 高品質、低品質なデータのテキストの傾向確認
今回、品質スコアの高いデータ、低いデータの具体的なテキスト内容の傾向確認まではできませんでした。これらの傾向を言語化できればオリジナルのInstructionデータセットを作成する際に意識して質の高いデータセットを作ることができるようになると思われます。 - 他の評価指標への影響確認
今回はあくまでも JGLUE の3つの評価指標が高くなるようなデータ選定をしたのでこれ以外の評価指標（例えば、MT-Bench など）の値が下がっているものもあると考えられます。このあたりがどうなっているのかも確認してみたいです。 - 他の評価指標での品質スコアリング
今回は JGLUE を評価指標として品質スコアリングをしましたが、その他のベンチマークを評価指標として設定した品質スコアリングも時間があればやってみたいです（ただし、評価を48回しなくてはいけないので GPT-4 に自動評価させるタイプの実施はコスト的に難しい）。 - 品質スコアリング時の LLM 作成数を増やす
今回は 48個の LLM の評価結果だけで品質スコアリングをしたため、本当はデータの品質は低いけども、たまたま品質の高いデータと一緒にファインチューニングに使用されることが多かったために品質が高くスコア付けされてしまっているデータもあると推定されます。品質スコアリングに使用するモデル数を96個なり、144個なり増やすことで品質スコアの精度が向上すると思われます。 - テキストから品質を予測するモデルの作成
やはりデータセットごとに都度都度48回ファインチューニング、評価をするのは非効率なので品質予測モデルが作れると嬉しいです（ BERT で直接、回帰予測するパターンはまだ試していない）。 - 高品質なデータの収集
今回提案した品質スコアリング方法を活用して、他の高品質なデータも収集し、高品質なデータだけのInstructionデータセットを作成したいです。 - 高品質なデータを対象にした日本語翻訳の修正
英語から日本語に自動翻訳したデータセットでは、翻訳の不自然さを解消することにより品質が向上すると言われています。ただ、これまで私が公開してきたデータセットはレコード数が数万オーダーであるため、人力で翻訳内容を修正するのは困難です。ただ、今回行った、JGLUE 観点で品質の高いものに絞り込んだ数百、数千のデータであれば人力で修正するのも可能かもしません（評価指標への寄与度の高いデータのみ翻訳修正）。
１２．おわりに
本記事では Instruction データセットに品質スコアを付与することにチャレンジし、一定の有効性を確認することができました。あくまでも私の足りない頭で思いついたジャストアイディアから始めた検証なので他にももっと良い方法もあるかとは思いますが（ LLM を開発している研究組織、企業ではもっと高度なデータセットの特性分析をしているものと想像していますが）、この記事が高品質な Instruction データセットを入手したいと考えている人や Instruction チューニングをもっと工夫したいと考えている人の検討のヒントになれば幸いです。
また、あくまでも実験的なデータセットですが今回、oasst1 , dolly , hh-rlhf のデータセットから JGLUE という観点で 高品質なデータのみを選定して作成したデータセット 『 JP-Effective-Instructions 』 を公開したいと思います。 今後も高品質なデータを見つけ次第、順次こちらのデータセットに追加していきたいと思います。
最後に簡単な感想になりますが、今回、 oasst1 と dolly , hh-rlhf の品質スコアリングや最適な閾値探索を合わせると LLM のファインチューニングと JGLUE での評価を 100 回以上行ったためだいぶ疲れました。しばらく JGLUE は見ないようにしたいです（爆）
その他
参考の話（というか布教に近い）ですが、今回の検証での Instruction チューニング時は kunishou/hh-rlhf-49k-ja からランダム抽出した 3,000 データを評価用データセットとして固定して使用しました。通常の Instruction チューニングでは、使用するデータセットや、データセットを train , test にスプリットする仕方により評価データが変わるので validation loss の比較ができませんが、Instruction チューニングに使用するデータセットによらず常に共通の評価用データセットを使用することで validation loss を横並びに比較できるようになります（同じ評価用データセットを使用しているのであれば他者の検証結果の validation loss との比較もできます）。以下に今回使用した評価用データセットを置いておくのでもしよければ皆さんも共通の評価用データセットとして使ってみて下さい。
記事の宣伝
自分の投稿予定の記事も宣伝させて下さい。今回企画した LLM Advent Calendar 2023 ではあと3つ記事を投稿予定なのでこちらも興味があれば是非ご覧ください。最終日の12/25の記事では、私が独自に収集した Instruction データを活用してデータセットを作成する取り組みの状況についても紹介する予定です。