データセット

インストラクションチューニングには以下の5種類のデータを使用します．

databricks-dolly-15k は英語のインストラクションデータセットです．指示（＋入力）に対する応答が用意されたシングルターンのデータです．

databricks-dolly-15k-ja はこの databricks-dolly-15k を DeepL を用いて日本語に翻訳したものです．

oasst-21k-en は マルチターンのインストラクションデータセットです．オリジナルの oasst1 は 35 の言語を含んでいますが，その中から英語の対話のみを抽出しています．

oasst-21k-ja は oasst-21k-en を DeepL で日本語に翻訳したものです．翻訳の際にはマルチターン対話の発話間のつながりを考慮するため，発話を繋げて対話単位で翻訳し，後処理で再度発話に分割しています．

ichikara-instruction-003-001 は LLMのための日本語インストラクションデータ作成プロジェクトで作成されている，シングルターンの日本語インストラクションデータセットです．上記の翻訳したデータセットとは異なり，「いちから」日本語で作成されており，高品質であることが特徴です．

参考までに databricks-dolly-15k-ja と oasst-21k-ja の翻訳には計約10万円の費用がかかりました．

学習の際には，各データセットを学習データと開発データに9:1の割合で分割して使用します．

入力プロンプト

モデルへの入力プロンプトは Alpaca が採用しているプロンプトとその日本語訳を参考に以下の3パターンを使用します．

・シングルターンかつ「入力」フィールドあり（対象：databricks-dolly-15k と databricks-dolly-15k-ja の一部）

以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。

### 指示:
{instruction}

### 入力:
{input}

### 応答:
{output}

・シングルターンかつ「入力」フィールドなし（対象：databricks-dolly-15k と databricks-dolly-15k-ja の一部，ichikara-instruction-003-001）

以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。

### 指示:
{instruction}

### 入力:
{input}

### 応答:
{output}

・マルチターン（対象：oasst-21k-en と oasst-21k-ja）

以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。

### 指示:
{instruction}

### 入力:
{input}

### 応答:
{output}

事前学習では全てのトークンに対して損失を計算してモデルを訓練しますが，インストラクションチューニングでは指示（instruction）と入力（input）を与えた場合の応答（output）を学習させることが目的です．そのため，指示と入力の部分は損失を計算せず，応答の部分のみ損失を計算します．この実装には trl の DataCollatorForCompletionOnlyLM が便利です．

比較実験の設定

先行研究では英語と非英語言語のインストラクションデータを同時に使用してインストラクションチューニングを行った場合，非英語言語での質問応答（XQuAD）の精度が向上することが報告されています．これを踏まえ，英語と日本語の両方のインストラクションデータを同時に使用して学習します．

今回はモデルの学習パラメータと使用データセットの組み合わせを以下のように変えて比較実験を行います．

学習パラメータについては LoRA チューニング と フルパラメータチューニング を比較します．

使用データセットについては，dolly (databricks-dolly-15k と databricks-dolly-15k-ja)，ichikara (ichikara-instruction-003-001)，oasst (oasst-21k-en と oasst-21k-ja) の有無を比較します．

また最後の行の dolly-oasst->ichikara (full) は dolly と oasst でチューニングしたのち，ichikara でチューニングを行うという，2段階でチューニングを行う設定です．

ハイパーパラメータ

ハイパーパラメータは以下のように設定しています．

ichikara (full) と dolly-oasst->ichikara (full) の 2 段階目のチューニングでは 10 ステップごと，それ以外のモデルでは 100 ステップごとにチェックポイントを保存し，開発データに対して最も損失が小さいモデルを採用します．

学習

学習には A100 40GB の GPU を 8 枚使用しました． LoRA チューニングでは DeepSpeed Zero 2 を，フルパラメータチューニングでは DeepSpeed Zero 3 + parameter offload を使用することで，メモリ使用量を抑えています．フルパラメータチューニングでは学習の途中で過学習が起き，開発データに対する損失が増加していたため，学習を 2.5 epoch 程で打ち切っています．dolly, ichikara, oasst の 3 つのデータセットを使った設定で学習にかかった時間は LoRA が約 14 時間，フルパラメータが約 61 時間でした．

実装には trl ライブラリを使用しています．詳細は公開しているコードをご覧ください．

評価

評価には 日本語VicunaQAベンチマーク を使用します． このベンチマークは決まった回答が存在しない非定型的なタスクにおける LLM の性能評価を目的としたベンチマークです．日本語の質問に対する LLM の回答を GPT-4 (gpt-4-0613) を用いて評価します．質問は常識，数学，ロールプレイなどの8カテゴリからなる80問で構成されています．なお，GPT-4による自動評価は人的評価とある程度一致すると報告されているものの，情報の正確性を判断するのが難しいなど，課題も多く存在することに注意が必要です．

日本語VicunaQAベンチマークのリーダーボードにならい，GPT-3.5 (text-davinci-003) の出力と比較して，評価対象の LLM の出力の方が優れている割合である AdjustedWinRate （引き分けも考慮）を評価します．$$AdjustedWinRate=\frac{\#Win+0.5×\#Tie}{\#Win+\#Loss+\#Tie}$$

結果は以下のようになりました． 今回学習したモデルは 太字 で表示し，この記事執筆時点で 日本語VicunaQAベンチマークのリーダーボード に記載されている他モデルの結果も併記しています．

まずモデルの学習パラメータについては フルパラメータ の方が LoRA よりも優れている傾向が見て取れます．

次に使用データセットについては，dolly と oasst に加えて ichikara を使用することで性能が向上していることがわかります． ただ ichikara 単独でチューニングしたモデルは dolly と oasst でチューニングしたモデルより性能が低くなっています．これは ichikara のデータ数が 2,903 件と他のデータセットに比べて少ないことが原因と考えられます．

最後に， 2 段階のチューニングを行った dolly-oasst->ichikara (full) は dolly, ichikara, oasst を同時に使用した dolly-ichikara-oasst (full) に若干劣ってはいますがほぼ同等の性能を出しています．大規模なモデルになるとインストラクションチューニングですら多くの計算資源が必要になりますが，このような 2 段階のチューニングは計算資源を節約する上で有効な手法の一つであると考えられます． 実際 2 段階目のチューニングにかかった時間は約 2 時間とかなり短めで済みました．

データセット

DPO には hh-rlhf の一部を DeepL で日本語に翻訳した hh-rlhf-12k-ja を使用します． hh-rlhf は，人とエージェントとの対話と，それに続くエージェントの好ましい応答，好ましくない応答の3つがペアになったデータセットです． この「好ましい」や「好ましくない」という評価は，役に立つかどうか（helpfulness，有用性）と，害がないかどうか（harmlessness，無害性）の2つの基準で分けられており，それぞれに対してデータが用意されています．hh-rlhf は学習データだけでも約16万件のデータがありますが，今回は有用性について 9,000 件，無害性について 3,000 件をランダムサンプリングし，日本語に翻訳して使用します． この翻訳の際には oasst-21k-ja と同様，マルチターン対話の発話間のつながりを考慮するため，発話を繋げて対話単位で翻訳し，後処理で再度発話に分割しています．

学習の際には学習データと開発データに9:1の割合で分割して使用します．

入力プロンプト

入力プロンプトはインストラクションチューニングと同じものを使用します．

ハイパーパラメータ

ハイパーパラメータは以下のように設定しています．

学習率は DPO の元論文でも 1e-6 に設定されているように，比較的小さい値の方が上手く学習できる印象です．

学習

今回はインストラクションチューニングでも最も性能が良かった dolly-ichikara-oasst (full) をベースモデルとして DPO を行います． LoRA チューニングのみを行い，インストラクションチューニングと同様に DeepSpeed Zero 2 を使用しました． 学習には A100 40GB の GPU を 8 枚使用し，約 21 時間で学習が完了しました．

実装にはインストラクションチューニングと同じく trl ライブラリを使用しています．詳細は公開しているコードをご覧ください．

評価

評価には再び 日本語VicunaQAベンチマーク を使用します． 結果は以下のようになりました．

dolly-ichikara-oasst (full) + DPO は dolly-ichikara-oasst (full) よりも 8.750% スコアが向上しており，DPO が性能向上に寄与していることがわかります．

また，dolly-ichikara-oasst (full) と dolly-ichikara-oasst (full) + DPO の 2 つのモデルの出力した回答を比較したところ，dolly-ichikara-oasst (full) + DPO の方がより長い回答を出力する傾向が見受けられました．実際，回答の平均出力文字数は dolly-ichikara-oasst (full) が 446 文字，dolly-ichikara-oasst (full) + DPO が 509 文字となっており，10%ほど回答が長くなっていました．DPO によってモデルがより長い回答を出力するようになり回答の情報量が増えたことが，スコア向上に寄与していると考えられます．

最後に回答例を見ていきます．

「時間管理能力を向上させるにはどうしたらいいですか？」という質問に対して dolly-ichikara-oasst (full) と dolly-ichikara-oasst (full) + DPO はそれぞれ以下のような回答を生成しました．

dolly-ichikara-oasst (full):
時間管理のスキルを向上させたいなら、まず優先順位をつけることから始めましょう。ToDoリストを作り、緊急度と重要度に基づいて項目を整理しましょう。そして、最も重要な仕事からこなしていくようにしよう。さらに、生産性向上ツールを使ったり、スケジュールやToDoリストをデジタル化したりして、より効率的に時間を管理できるように工夫しましょう。

dolly-ichikara-oasst (full) + DPO:
時間管理のスキルを向上させたいなら、まず優先順位をつけることから始めましょう。やるべき仕事とやりたくない仕事のリストを作るんだ。そして、やるべき仕事が終わったら、リストにチェックを入れる。そして、その仕事を終わらせるために、自分が使える最も重要な時間帯（朝一番とか）にそれらの仕事をこなすようにスケジュールを調整するんだ。もしできたら、ボーナスポイントとして丸いシールを追加してください！

優先順位をつけたら、次のステップは、時間管理能力を向上させるために、タイマーを使って仕事の時間を測ることだ。タイマーを10分、20分、30分と1つずつ増やしていく。タイマーが切れるまで、できるだけ多くの仕事をこなしたほうがいい。タイマーを切った後、どれだけ仕事をこなせたかを見て、自分の進歩を確認しましょう。また、一日中、タイマーで何かを制限しながら作業するという実験もできます。

また、ToDoリストアプリを使うこともできる。この種のアプリは、あなたの進捗状況や、どのタスクにもっと時間をかけたほうがいいかを教えてくれます。また、これらのアプリは、各タスクに対して「完了」ボタンを与えるので、達成感を感じるのに役立ちます。

まとめると、時間管理能力を向上させる最善の方法は、優先順位をつけること、タイマーを使うこと、そして達成感を感じることだ。

どちらの回答も質問に対して適切なアドバイスが出力されていますが，dolly-ichikara-oasst (full) + DPO の方がより具体的なアドバイスを出力していることがわかります．

一方，両モデルに共通する課題として語尾（常体・敬体）の統一が挙げられます． インストラクションチューニングや DPO で使用したデータセットの一部は機械翻訳で作られており，そのデータ内での語尾の統一が不十分であったことが原因だと考えられます． この課題の解決には，機械翻訳の人手修正や，ichikara-instruction のような自然な日本語で作成されたデータセットをより多く使用することが有効ですが，こうしたデータセットの作成には多大なコストがかかります．LLM-jp でも今後取り組んでいければと考えています．