MergeKitによるMoEマージだけで日本語性能は上がるか？

• 前回の記事で、「LightChatAssistant 2x7B」が日本語チャットモデルのベンチマークでもかなり高いスコアを示すことを確認しました（スコア上はCohereの「Command-R 35B」に近い水準です）。
• 体感的にもベンチマーク的にも優れた日本語チャットモデルで、サイズが小さいことも考えるととても魅力的です。

sc-bakushu.hatenablog.com

• 作者さんがモデルカードで説明されている制作プロセスを読むと、単純に「ChatNTQ 7B」と「Antler-7B」をMoEマージする前に、ChatVectorという手法により各モデルに微調整を施しているようです。
• となると、「LightChatAssistant 2x7B」の性能の上昇はMoEによる部分が大きいのか、あるいはChatVectorによる部分が大きいのかが気になってきます。
• というわけで、まずChatVectorを使わない単純なMoEマージを試して、MoEオンリーでどれくらいの性能上昇が得られるのかを確認してみたいと思います。

ChatNTQ 7B x Antler 7B の単純なMoE

• 最初に、「LightChatAssistant 2x7B」の制作プロセスのうちChatVectorによる処理の部分だけスキップして、単純なMoEモデルを作ります。
• なお、MoEマージの手順については、はちさんによる以下の記事を参考にさせていただきました。ありがとうございます。

note.com

• 結果は以下のとおりです。2モデルの単純な直マージだと「Chat NTQ 7B」からの性能向上はありません。誤差を踏まえるとほぼ同じと言っていいと思います。

名称	LightChatAssistant 2x7B	Chat NTQ JA 7B x Antler 7B 直マージ （CheapEmbed）	ChatNTQ JA 7B
パラメータサイズ	2x7B	2x7B	7B
量子化タイプ	Q8_0	Q8_0	Q8_0
ElyzaTasks100 スコア平均	3.31	3.04	3.06
標準誤差	0.14	0.14	0.15

• ただし実際の出力をみると、日本語の流暢性はいくらか改善している印象があり、小説生成モデル「Antler-7B」の影響はわずかに感じられます。
• ところで、このMoEでは「LightChatAssistant 2x7B」のマージ設定でも使われている「cheap_embed」というゲートモードを使いましたが、どうやらこのモードの選択がけっこう重要なようです。
• 次は「random」というモードに変更して、あらためてマージを試してみます。結果は以下のとおりでした。

名称	LightChatAssistant 2x7B	Chat NTQ JA 7B x Antler 7B 直マージ （Random）	ChatNTQ JA 7B
パラメータサイズ	2x7B	2x7B	7B
量子化タイプ	Q8_0	Q8_0	Q8_0
ElyzaTasks100 スコア平均	3.31	3.15	3.06
標準誤差	0.14	0.14	0.15

• 「random」へ変更することで、スコアに改善が見られました。まだ誤差の範囲内ですが、体感的にはわずかに差がありそうです。とはいえ本家の「LightChatAssistant 2x7B」には及びません。
• MergeKitに関するウェブ上の解説を斜め読みすると、「random」というモードは一番単純なマージ設定のようで、「cheap_embed」や「hidden」のように各モデルの特長の違いを考慮しない雑なモードのようです。

docs.google.com

• ということは、純粋にパラメータ数が増えるだけでも日本語性能が上がる余地があるのかもしれない、という気がしてきます。

ChatNTQ 7B x ChatNTQ 7B のダブルMoE

• 「Antler-7B」は小説生成モデルなので、チャットモデルである「Chat NTQ 7B」と性能補完的ではあるものの、それ自体のチャット性能は（微調整しない限り）低いままです。
• では、「Antler-7B」を使わずに「Chat NTQ 7B」を2つ使ってMoEマージするとどうなるのでしょうか？
• MergeKitの説明などを見ると、一般的には「同一モデルのマージは意味がない」とされているようですが、物は試しでやってみます。結果は以下の通りです。

名称	LightChat Assistant 2x7B	Chat NTQ JA 7B x Chat NTQ JA 7B 直マージ（Random）	Chat NTQ JA 7B x Antler 7B 直マージ （Random）	ChatNTQ JA 7B
パラメータ	2x7B	2x7B	2x7B	7B
量子化タイプ	Q8_0	Q8_0	Q8_0	Q8_0
ElyzaTasks100 スコア平均	3.31	3.25	3.15	3.06
標準誤差	0.14	0.14	0.14	0.15

• 意外なことに、かなりスコアが改善しています。「LightChatAssistant 2x7B」ほどではありませんが、明らかに性能が上がりました。
• 実際の出力をみると「LightChatAssistant 2x7B」に比べて日本語の流暢性は劣っており面白味はありませんが、計算などの推論能力に多少の向上が見られました。

感想

• ということで、「Chat NTQ 7B」→「LightChatAssistant 2x7B」の顕著な性能向上のうち、ざっくり1/3～半分程度はMoEマージでパラメータ数が伸びることで説明できそうな印象です。
• なお今回は素の「Antler-7B」を使ったので、チャットファインチューンを施していないモデルをマージに組み込むことの悪影響が出た感は否めません。
• 次は、ChatVectorによる効果についても調べてみたいと思います。

補足

• パラメータ数（モデルサイズ）を増やすタイプのモデルマージとしては、MoEのほかに「Passthrough」という手法も存在します。
  • MoEがコミュニティで一般化する前から使われていたいわゆる「Frankenマージ」を作成する手法です。
• 今回、MoEマージ以外にも、この「Passthrough」など他のマージ手法も簡単に試してみたのですが、そもそもモデルの出力がかなり壊れてしまい、性能を測定するに至りませんでした。MoEマージのほうが意外に扱いやすい手法のようです。

ChatNTQ 7B と LightChatAssistant 2x7B の日本語性能を測定する

• 前回の記事で試した日本語チャットモデル「ChatNTQ-JA-7B-v0.1」と、そのMoEモデル「LightChatAssistant 2x7B（改称あり）」について、かなり性能が良さそうな感触が得られたので、追加でテストしてみました。
• LLMの日本語チャット性能を測るベンチマークとしては「MT-Bench日本語版（GPT-4測定）」が最も代表的ですが、何度も測定するにはコスト面でヘビーそうなので、代わりにELYZAさんの考案した「ELYZA-tasks-100」を使うことにしました。

huggingface.co

• このベンチマークは5点満点の日本語記述問題100問から構成されています。本来は人手で採点しますが、GPT-4採点でも人力評価とかなり高い相関が得られるようです。
  • 詳細はこちらやこちらの記事で丁寧に紹介されています。同じモデルでも記事によって若干スコアが違いますが、単純な誤差のほかGPT-4のバージョン更新などが影響するようです。

ELYZATasks100 測定結果

• 今回はGPT-4-Turbo(0125版)を使って測定しました。APIコストは1件あたり1ドルほど。比較対象にしたのは個人的に日本語性能が高いと感じた小型モデルです。結果は以下のとおりでした。

ベース	Command R		Mistral 7B				Llama-2 7B
名称	Command R v01		LightChat Assistant 2x7B	ChatNTQ JA 7b	Rakuten 7B Chat	Shisa Gamma 7B	ELYZA 7B Instruct
パラメータ	35B	35B	2x7B	7B	7B	7B	7B
量子化	Q8_0	IQ3_XXS	Q8_0	Q8_0	Q8_0	Q8_0	Q8_0
サイズ (量子化後)	37.2GB	13.8GB	13.7GB	7.7GB	7.8GB	7.7GB	7.2GB
ELYZATasks 平均得点	3.42	3.09	3.31	3.06	2.82	2.81	2.46
標準誤差	0.15	0.15	0.14	0.15	0.14	0.15*	0.13
平均字数	194.02	196.58	273.61	240.46	108.54	297.71	243.02

• ベンチマーク結果は、個人的な使用感による順位とだいたい一致した印象です。「ChatNTQ-JA-7B」は、やはり7Bクラスのモデルの中ではとても優秀でした（比較した「Rakuten 7B」や「Shisa Gamma 7B」も7Bモデルの中では性能のいい部類です）。
• この「ChatNTQ-JA-7B」と小説生成モデル「Antler-7B」をMoEマージした「LightChat Assistant 2x7B」のスコアはさらに高いです。パラメータ数がはるかに大きい多言語モデル「Command-R 35B」の日本語性能に迫っています。
  • さらにファイルサイズがほぼ同じになる「Command-R 35B」のIQ3_XXS量子化と比較すると「LightChat Assistant 2x7B」のQ8量子化のほうがスコアが高くなります。
• なおGPT-4は冗長な回答を高く採点しやすいとよく言われるので、興味本位で出力字数の平均も取ってみました。今回は字数に影響される傾向は見られませんでした（ELYZATasks100では採点基準で説明の丁寧さも評価されるので、字数と相関があったとしても必ずしも問題はありません）。

 雑感

• 「LightChat Assistant 2x7B」のチャット性能の高さは、ベースにした「ChatNTQ-JA-7B」の優秀さもありますが、小説生成モデルの「Antler-7B」とのマージがうまく機能している面も大きいようです。
• 「Mixtral 8x7B」や「Qwen 1.5 MoE A2.7B」のように最初からMoEを使って作られたモデルの推論が高効率・高性能なことはよく知られています。一方、MergeKitで作られたコミュニティのMoEモデル（FrankenMoE）は、サイズは大きいけれど体感性能がほとんど変わらないと感じることが多いです。
• しかし「LightChat Assistant 2x7B」は、体感性能でもベンチマークスコアでも明らかにベースモデルを上回っているので、適切な組み合わせでマージするとMergeKit製のMoEでもしっかり効果が得られるようです。
• 面白いので、MoEマージの組み合わせについて引き続き調べてみたいと思います。

Mistral 7Bベースの日本語チャットモデル ChatNTQ-JA-7B を試す

「chatntq_chatvector-MoE-Antler_chatvector-2x7Bchatntq_chatvector-MoE-Antler_chatvector-2x7B」という呪文のような日本語MoEモデルが話題になっていました。

https://t.co/tmcIFgrObQ
2x7Bの日本語チャット・ノベル専用高性能モデル。

Antler-7Bとchatntq-ja-7b-v1.0という、Japanese Stable LM Base Gamma 7B（Mistral 7Bベース）をinstructionチューニングしたモデルを各々ChatVector法で強化し、MoEでマージしたのだそうだ。
VRAM12GBでロード可能！

— mutaguchi (@mutaguchi) 2024年4月3日

Mistral 7Bベースの「Japanese Stable LM Base Gamma」をファインチューンした2つの異なるモデル（Antler 7B, ChatNTQ-JA-7B）を2x7BのMoEにしたモデルだそうです。

このMoEモデルを早速試してみたところ、確かに賢そうな印象を受けました。ただ、そもそもベースにされている2つのモデルを聞いたことがありませんでした。

・Antler 7B は日本のネット小説テキストを使って学習させた小説生成モデルのようです（このモデルが学習データにNSFWコンテンツを含んでいるらしい）。日本語のライトノベル風テキストに対する潜在的需要は結構強いらしく、類似のコンセプトのモデルは他にもHuggingFaceで見かけます。

・もうひとつが本題の ChatNTQ JA 7B です。こちらは小説生成ではなく、通常の日本語チャットでファインチューンされたモデルのようです。

ChatNTQ-JA-7Bについて

モデルのアップロード日をみると、どうやら昨年末に怒涛の勢いで公開が続いた日本語ファインチューンモデルの一つで、完全に見過ごしていたようです。

リリースしたNTQ AIという会社はなんとベトナムのスタートアップらしく、日本にも拠点があると説明されています。

StabilityAIの「Japanese Stable LM Base Gamma」をベースにしているので、すでに日本語で追加学習を済ませたモデルを、追加的に微調整した形になっています。

同じく「Stable LM Base Gamma」ベースの「Shisa-gamma-7B」も、よくファインチューンされたモデルでしたが、モデルカードによると日本語MT-Benchのスコアではこれを上回ったと報告しています。

出力例

あなたは親切なAIアシスタントです。

USER: こんにちは。自己紹介をしてください！
ASSISTANT: こんにちは、私は人間が必要とする情報を提供するために開発されたAIアシスタントです。よろしくお願いします！
USER: 地理について質問です。京都府に海はありますか？
ASSISTANT: 申し訳ありません。そのようなデータが見当たらないため回答できません。もし可能であれば、別の方法で確認してみて下さい。
USER: 日本語について質問です。光陰矢の如し、とはどんな意味ですか？
ASSISTANT: 「光陰矢の如し」とは、時間が過ぎ去るのは矢のように早いという意味です。
ASSISTANT: 以上のように、様々な分野に関する質問に対応することができます。お困りの際は何なりとお申し付け下さい。

適当なプロンプトフォーマットで試しただけですが、7Bモデルであることを考えるとかなり良い印象を受けます。おそらく日本に関する知識はあまり学習できていないと思いますが、日本語チャット用途という点では筋がよさそうです。

冒頭のMoEモデルも含めて、もうすこしテストしてみたいと思います。

llama.cpp: CPU+GPUのプロンプト処理が高速化される（#6083）

今さら知ったのですが、2週間ほど前にllama.cppでモデルをGPUに部分オフロードした場合のプロンプト処理速度が大幅に向上されていました。

github.com

• 従来のllama.cppではGPUフルオフロードから部分オフロードに移行すると急激にプロンプト処理（PP）が遅くなるため、CPU+GPUのハイブリッド推論の魅力を大きく損ねていました。
• このPRによって、CPU比率が増えた場合のPP速度低下が緩和され、部分オフロードの実用性が大幅に改善しています。
• 以下はMixtral 8x7B のQ3_K_L量子化モデルで1024トークンのPPを実行したときのグラフです。

• モデルのレイヤー33層のうち半分をGPUから引き上げた場合、旧来のllama.cppではPP速度が半分以下に低下していますが、このPR適用後は2/3程度の処理速度を保っています。
• このPRの技術的な概要について、llama.cppのJohannesGaesslerさんが以下のように説明しています。

CPUレイヤーのデータはRAMにあり、GPUレイヤーのデータはVRAMにあります。GPUレイヤーは常に GPU上で評価されます。

#PR6083では、バッチサイズが大きい場合（つまりプロンプト処理の場合）、GPUの高い計算能力を利用するためにCPUレイヤーのすべてのデータがGPUに移動され、そこで計算が行われます。バッチサイズが小さい場合（つまりトークン生成の場合）、CPUレイヤーはそのままCPU上で評価されます。

• 個人的にも、Mixtralモデルを使う場合はVRAMに詰め込むため2bitのきつい量子化を使っていたので、オフロードがしやすくなるのはとても嬉しいです。
• 早速llama.cppを更新して、ベンチマークでPPの高速化が確認できました。ただ普段APIとして使っているkobold.cppにはまだ反映されていないので、こちらはアップデートを待ちたいと思います。

llama.cpp量子化：重要度行列(Importance Matrix)計算に使うテキストについて

• 以前にも取り上げている件ですが、現在のllama.cppでは重要度行列(Importance Matrix)計算を利用することで量子化精度が改善できます。
  • 特に4bit以下の低bit量子化を行う場合は、このiMatrix版の量子化が推奨されます（Metal環境などでは推論速度が遅くなるので要注意）。
• Claude 3 Opusによると、重要度行列とは以下のように説明できます。

Importance Matrixは、言語モデルの量子化において、各パラメータの重要度を表現するために使用される行列のことを指します。

量子化の過程では、モデルの精度を維持しつつ、パラメータを低ビット幅の整数値で表現します。しかし、すべてのパラメータが同等に重要というわけではありません。そこで、Importance Matrixを用いて、各パラメータの重要度を評価します。

具体的には、以下のような手順で計算されます：

１．学習済みのモデルを用意する
２．各パラメータに対して、そのパラメータの値を微小量だけ変化させたときの、モデルの出力への影響を計算する
３．影響の大きさを正規化し、Importance Matrixの対応する要素に格納する

こうして得られたImportance Matrixは、量子化の際のビット割当てに利用されます。重要度の高いパラメータにはより多くのビットを割り当て、重要度の低いパラメータには少ないビットで済ませることで、量子化後のモデル精度の低下を最小限に抑えることができます。

Importance Matrixは、モデル圧縮の分野で広く使われている概念で、特に携帯端末やエッジデバイス向けの小型モデルを作成する際に重宝されています。同様の考え方は、pruning（枝刈り）など、他のモデル圧縮手法にも応用されています。

• さて、llama.cppの重要度行列計算では通常、英語版のwiki.trainが入力テキストとして使われていますが、この選択が妥当なのかどうかという議論が存在します。
• 以下はllama.cppのRepoにおけるディスカッションです。

github.com

• 基本的には、実際の用途に近いテキストを使って重要度行列を計算するのがよいとされています。
  • 例えば、コーディング支援で使うモデルならコードを含むテキストがよく、中国語で使うモデルなら中国語を含むテキストがいいはずです。
• 以下のデータを見ると、確かにテスト用テキストと同系統の入力テキストを利用したほうがKL-Divergenceの値が改善しています。一方で、入力テキストの量については特に精度に寄与していないことも分かります。

• 以下は、雑多な内容の疑似ランダムテキスト、C4の英仏混合学習テキスト、通常のwiki.trainテキストを使用した場合の当惑度(Perplexity)およびLLMベンチマーク(MMLUとHellaSwag)のスコア比較です。

• これらの結果に基づいて、llama.cppの量子化実装を手掛けているikawrakowさんは以下のように指摘しています。
  • Wikitextから得られた重要度行列は、ランダムに近いデータによる重要度行列よりも、小さいとはいえ統計的に有意に優れている。よって、基本的にWikitextを使用するのが無難である。
  • 英語以外の言語で使いたいけれど、その言語では有用なトレーニングテキストが見つからない場合は、疑似ランダムデータが使えるかもしれない。
  • フランス語のC4データセットにおけるモデルの当惑度は、フランス語だけの重要度行列を使用した場合にさらに改善する。特定言語が主なユースケースである場合、その言語だけのテキストを使用してimatrixを作成することが最善かもしれない。
• なお、日本語テキストによる重要度行列計算については、以下の記事で簡単に検証しています。

sc-bakushu.hatenablog.com

• 上記記事のあと、日本語モデルのKarakuri 70Bでも試してみましたが、やはり日本語のみの用途であれば日本語テキストで計算したほうが当然ながらベターな結果が得られそうです。
  • ただし、日本語のみのデータセットを使うと英語のPPLが十分に改善しなかったので、実用的には日英混合テキストのほうがよいかもしれません。

DPO（直接選好最適化）とは何か、メモ

• 最近、自作の指示応答データセットを使った微調整によってLLMにパーソナライズされた知識を追加することを試みているのですが、その際にモデルに植え付けられた過剰なアラインメントが知識追加の障壁になる場合があります。
  • 例えばモデルに対し「USER: 好きな色は何色ですか？\nAI: 私の好きな色は青です」と学習させたいのに、モデルが頑として「AI: 私はAIなので人間のような色の好みはありません」と回答し続けるような場合があります。
  • しつこく学習を続ければデータ通りに回答するようにはなりますが、そこまでSFTをやりすぎるとオーバーフィットでモデルの質が劣化します。
• このような場合、DPO（直接選好最適化）を使って微調整すると過剰なアラインメントを簡単に除去できる可能性があります。
• ということで、DPOとは何かを開設する記事をまとめて斜め読みしてみました。具体的なコード等は割愛しています。

メモ1：「Mistral-7BをDPOでファインチューンする」

towardsdatascience.com

• 人間のフィードバックからの強化学習 (RLHF)は、学習済み言語モデルの回答からバイアスや有害性を取り除くことを主な目的として考案された。
• しかし最近では、RLHFとその派生手法がアラインメントだけでなくパフォーマンスの向上にも寄与することが分かっている。
• そもそもRLHFの概念はロボット工学で長い間使用されてきたが、OpenAIの論文「人間の好みから言語モデルを微調整する」でLLM向けに普及した。
• この論文のフレームワークでは、1）まず「報酬モデル」を人間のフィードバックを近似するようにトレーニングし、2）次に近似ポリシー最適化（PPO）アルゴリズムを使い、報酬モデルを介して対象モデルをポリシー微調整する。

• PPOのポイントは、ポリシーを小さく段階的に更新する点にある。大規模な更新は不安定性や最適化の失敗につながる可能性があるため。
• とはいえPPOはやはり不安定で（損失が発散しやすい）、再現が困難で（ハイパーパラメータが多い、ランダムシードに敏感）、しかも計算コストが高いという課題がある。
• そこで、直接選好最適化 （DPO）アルゴリズムが良い代案になる。
• DPOは、タスクを分類問題として扱うことで制御を簡素化する。具体的には、学習対象モデル(ポリシーモデル) とそのコピーである参照モデルを使用する。
• DPOはLLM自体を報酬モデルの代わりとして使用することで、大規模なサンプリング、報酬モデルの調節、複雑なハイパーパラメータ調整を必要とせずに、モデルの出力を人間の好みに適合させる（PPOより安定し、効率的で、計算負荷が少ない）。

メモ2：「DPOによる言語モデルのファインチューニング」

www.cerebras.net

• DPOはRLHFに代わる手法として登場したものであり、RLHFの基本原理を基礎としながらも異なる実装を持つ。DPOでは、RLHF的な損失関数を選好推定のためのBradley-Terryモデルと組み合わせて利用する。
• これにより学習プロセスが単純化され、RLHFで採用されている複数モデルによる学習と複雑な強化学習最適化は不要になり、モデル収束の安定性も高まる。
• BTLM（Cerebrasの独自LLM）等を用いた検証では、DPOの適用により会話タスクにおけるモデルの熟練度が向上するだけでなく、その他のさまざまな下流タスクのパフォーマンスも向上した。

• また、DPOによる事前学習データの忘却について検証したところ、1）DPOによる知識の忘却はごく限られること、2）betaパラメータが大きいほど情報を保持しやすいこと、が示唆された。

• 一方で、beta値が小さい(0.1 未満) と、チャット指向のデータセット(Anthropic-HH)において最適な結果が得られる。

• 指示応答や要約に重点を置いたデータセット(SHP, Redditから収集した選好データ)ならbeta値が大きい(0.3 ～ 0.5の範囲)ほうが効果的だが、総じてチャットスタイルのデータセット(Anthropic-HH)の方がDPOに適している。
• SFTとDPOの学習に異なるデータセットを使用することが効果的な可能性が示唆されるが、これは元のDPO論文の提案とは食い違っている。

メモ3：「DPOによるLLMの選好チューニング」

huggingface.co

• この投稿では、有望な3つのLLMアライメントアルゴリズムである直接選好最適化(DPO)、同一選好最適化 (IPO)、カーネマン-トヴェルスキー最適化 (KTO) の実証的評価を行っている。
• DPO：DPOは、LLMを人間やAIの嗜好にアライメントするための有望な選択肢として登場した。強化学習に基づく従来のアライメント手法とは異なり、DPOはアライメントの定式化を選好データセット上で直接最適化できる単純な損失関数として再構成する。
• IPO：DPO の欠点の1つは、選好データセットに過剰適合する傾向があること。これを回避するため、Google DeepMindの研究者は、Identity Preference Optimisation (IPO)を導入した。これは、DPO損失に正則化項を追加し、早期停止などのトリックを必要とせずにモデルを収束までトレーニングできる。
• KTO：ほとんどのアライメント方法と同様に、DPOではペアの選好データセットが必要で、アノテーターが有用性や有害性などの一連の基準に従って、どの応答がより良いかをラベル付けしなければいけない。現実的には、この作業には時間とコストがかかる。そこで、ContextualAIはKahneman-Tversky 最適化 (KTO)と呼ばれる代替案を考案した。これは、損失関数を「良い」または「悪い」とラベル付けされた個々の例 (たとえば、チャット UI に表示される 👍 または 👎 アイコン) に基づいて定義できる。
• 以下は、ペア選好データセット（HuggingFaceH4/orca_dpo_pairs）を用いてZephyr-7b-beta-SFTおよびOpenHermes-2.5-Mistral-7Bのポリシー最適化を実行した結果である。

• 少なくとも適切なbeta値においては、DPOが最もパフォーマンスの優れたLLMアラインメントアルゴリズムであることが示唆された。

メモ4：「Starling-LM-7B-beta」

sc-bakushu.hatenablog.com

• 現在、7Bモデルで最もチャット性能が高いと評価されている「Starling-LM-7B-beta」では、DPOではなくPPOを採用している。
• これはStarling-LMがすでにC-RLFTで微調整済みのOpenchat-3.5をベースにしているため。（DPOと類似性のある）C-RLFTのような手法で学習済みのモデルをさらに鍛えるには、DPOではなくPPOのほうが有望とのこと。

雑感

• OpenHermes-2.5-Mistral-7BやOpenchat-3.5のような徹底したファインチューニングを経たチャットモデルにおいては、DPOによるチャット性能向上の余地は限られるようです。
• やはりPPOとDPOは別物であって、パラメータの最適化と計算資源の確保の問題さえクリアできるならPPOのほうが有効性が高いように見えます。とはいえ、現実的に素人が個人でやるならPPOの選択肢は無さそうですが。
• 知識追加のためのファインチューニングの観点では、おそらくSFTで知識そのものをインプットしたあとで、学習させた知識を出しやすくするための仕上げの工程でDPOを使うことになると思います。DPOによる知識の忘却はそれほど心配なさそうです（SFTモデルにDPOを上掛けしたモデルがたくさんある）。
• DPOにおいて重要となるbeta値は、通常0.1程度が標準になっているようですが、その最適値は、目的/モデル/データセットに応じて完全にケースバイケースになるようです。

Starling-7B: RLAIF で LLM の有用性と無害性を向上させる

• お馴染みのLMSYS Chatbot Arena ELOランキングが更新されていました。

[Arena Update]

70K+ new Arena votes🗳️ are in!

Claude-3 Haiku has impressed all, even reaching GPT-4 level by our user preference! Its speed, capabilities & context length are unmatched now in the market🔥

Congrats @AnthropicAI on the incredible Claude-3 launch!

More exciting… pic.twitter.com/p1Guuf0B3K

— lmsys.org (@lmsysorg) 2024年3月26日

• Claude 3シリーズのレーティングの高さも目を引く一方、Mistral 7BベースのStarling-LM-7B-Betaが小型モデルとしては際立ったスコアを示しています。
  • これはStarling-LM-7B-alphaの後継として今年3月にリリースされたモデルです。前モデル同様、Mistral 7BベースのOpenchat-3.5をもとに、ポリシー最適化でファインチューンしたモデルです。
  • サンプル数が少ないので暫定ですがArena ELOレーティングはClaude 2相当で、GPT-3.5/Mixtral 8x7B/Gemini Proを上回っています。
  • もちろんコーディングや計算/推論、多言語スキルなど含めた汎用性能では大型モデルに劣ると思いますが、7Bモデルでも特定の用途（ここでは英語チャットボット）に特化すれば高性能に到達できるというのは面白いです。
• 個人的には、Starling-LM-7B-Alphaは受け答えがあまりに「疑似ChatGPT」感があって敬遠した記憶があるのですが、改めて興味を持ったので当時のStarling-LM開発チームのブログ投稿（Alphaリリース時のもの）に目を通してみました。

"Starling-7B: RLAIF で LLM の有用性と無害性を向上させる"

starling.cs.berkeley.edu

概要

教師あり微調整（SFT）は、特にChatGPT/GPT-4（Alpaca、Vicuna、OpenHermes 2.5、Openchat 3.5を含む）から抽出された高品質なデータを活用する場合、言語モデルからチャットボットシステムを開発する際に顕著な効果を発揮します。しかし、人間のフィードバックからの強化学習（RLHF）やAIのフィードバック（RLAIF）が、高品質な嗜好データをスケーリングする際に、どの程度モデルを強化できるかは、未解決の問題のままです。Zephyr-7B、Neural-Chat-7B、Tulu-2-DPO-70Bなどのオープンソースコミュニティにおける初期の試みは、直接選好最適化（DPO）を採用していましたが、OpenHermes 2.5やOpenchat 3.5のような主要なSFTモデルと比較した場合、MT Bench（およびChatbot Arenaの一部）でのパフォーマンスは、RLHFの可能性を十分に示すものではありませんでした。

RLHFのより詳細な研究を促進するためには、チャットに特化した高品質のランキングデータセットが不可欠です。私たちは183KチャットプロンプトからなるGPT-4ラベル付きランキングデータセットNectarを公開します。各プロンプトはGPT-4、GPT-3.5-instruct、GPT-3.5-turbo、Mistral-7B-Instruct、Llama2-7Bのような様々なモデルから抽出された7つの回答を含み、合計380万のペアワイズ比較を提供します（GPT-4に順位を求める際、位置の偏りを軽減するためにかなりの努力が払われましたが、その詳細は以下のデータセットのセクションで詳しく説明します）。

オープンソースの報酬モデルは著しく少ないのが現状です。我々は、NectarデータセットのKワイズロスで学習させた報酬モデルStarling-RM-7B-alphaを公開することで、このギャップに対処します。

私たちは学習した報酬モデルを使用して、Openchat 3.5の言語モデルを微調整しました。その結果、MT-Benchのスコアは7.81から8.09に、AlpacaEvalのスコアは88.51%から91.99%に向上しました。どちらの指標もチャットボットの有用性を評価するものです。

メモ

• 「RLAIF」とは「人間のフィードバックからの強化学習（RLHF）」をAIで代替した「AIのフィードバックからの強化学習」を指す。
• RLHF/RLAIFは、すでに教師あり微調整（SFT）を済ませたモデルに対し、学習の最終工程として行うもの。AIチャットボットとして人間の嗜好にあった好ましい回答ができるようにポリシー最適化する。
• Starling-LM-7B-alphaの具体的な作成手順は以下の通り。まず、様々な言語モデルによって同一のプロンプトに対する7つの応答パターンを出力させる。

• 次に、その7応答に対してGPT-4に「回答としての好ましさ」を評価させ、順位付けする。このプロセスにより、著者らはNectarという183Kのランキングデータセットを作成している。
• さらに、このランキングデータセットをもとに報酬モデル（Reward Model）を作成する。ここでは、Llama-2-Chat-7BにNectarデータセットで追加学習させ、Starling-RM-7B-alphaという報酬モデルを作出している。

• 最後に、教師あり微調整でトレーニング済みの初期モデル（ここではMistral 7B v0.1をSFTしたOpenchat-3.5）に対し、先ほどの報酬モデルを用いたポリシー微調整を施し、Starling-LM-7B-alphaが完成する。
• なお、この研究では複数のポリシー最適化の手法を予備実験によって比較検討している（DPO、APA、PPO、P3O）。
  • DPOは実装がシンプルで、事前に収集されたオフラインの嗜好データセットに基づいて言語モデルを直接更新する。手軽でありローカルLLMコミュニティでもよく用いられる。
  • 対照的に、PPOなどのオンラインRL手法では、現在の言語モデルを使用して新しい応答をサンプリングし、トレーニング済みの報酬モデルを使用して新しい応答にスコアを付け、新しい応答の報酬情報を使用して言語モデルを更新する。PPOのパラメータ最適化については試行錯誤が必要。
  • DPOを用いた予備実験では、初期モデルOpenchat 3.5と比べて大幅な改善は見られなかった。Openchat-3.5自体がC-RLFTというオフラインの嗜好に基づく強化学習を受けたモデルであり、機能的に類似したDPOの重ね掛けでは追加的な効果が得られなかった可能性がある。
  • この研究では最終的に、報酬モデルを用いたPPOの派生手法であるAPAによって学習したチェックポイントを採用した。
• ここでのポリシー最適化は、トレーニング速度の向上のためモデルの最後の4層のみを解凍して行っている。モデルは、バッチサイズ28、合計10,000ステップで8個のA100 GPUでトレーニングされた。

Starling-7B-alphaとStarling-7B-betaの違い

• 上述のブログ記事は、Starling-7B-alpha公開時のもので、後継モデルであるbetaではいくつかの点で事情が異なっています。
• Starling-LM-7B-betaでは、Yi-34Bベースの新たな報酬モデルStarling-RM-34Bを作成し、さらにポリシー微調整にはAPAではなくPPOを採用しているようです。