【LLM論文を読む】人間的なエピソード記憶を持つコンテキスト無限のLLM

• 言語モデルの「記憶」を管理する方法としては、１）追加学習や知識編集によってLLM自体の知識更新を試みる方法と、２）外部の記憶データから必要情報を適時検索してモデルに渡す方法、の2つの方向性があります。
• この論文は後者の系統に属する研究で、人間のエピソード記憶のあり方を参照し、外部データを効果的に整理・検索することを目指した研究のようです。
• タイトルは"Human-like Episodic Memory for Infinite Context LLMs"で、Huaweiの研究所とUCLの研究者らによって2024å¹´7月に投稿されています。

arxiv.org

要旨

大規模言語モデル（LLM）は目覚ましい能力を示しているが、広範なコンテキストの処理にはまだ苦戦しており、長いシーケンスにわたって一貫性と正確さを維持する能力には限界がある。これとは対照的に、人間の脳は、生涯にわたる膨大な時間スケールのエピソード経験を整理し、検索することに優れている。本研究では、人間のエピソード記憶と事象認知の主要な側面をLLMに統合し、計算効率を維持しながら実質的に無限のコンテキスト長を効果的に扱えるようにした新しいアプローチ「EM-LLM」を紹介する。EM-LLMは、ベイジアン・サプライズとグラフ理論に基づく境界精密化の組み合わせにより、トークンのシーケンスをオンライン方式で首尾一貫したエピソードイベントに整理する。必要に応じて、これらのイベントは、類似性に基づく検索と時間的に連続した検索を組み合わせた2段階の記憶プロセスによって検索され、関連情報への効率的で人間的なアクセスを実現する。LongBenchデータセットを用いた実験では、EM-LLMの優れた性能が実証され、様々なタスクにおいて、最新のInflLLMモデルを4.3%の相対的改善で上回った。さらに、我々の分析により、EM-LLMのイベントセグメンテーションと人間が認識するイベントとの間に強い相関があることが明らかになり、この人工的なシステムと生物学的な対応物との間の橋渡しを示唆している。本研究は、LLMの拡張文脈処理能力を向上させるだけでなく、人間の記憶メカニズムを探求するための計算フレームワークを提供し、AIと認知科学の学際的研究に新たな道を開くものである。

Claudeによる解説

Q.内容をわかりやすく説明して

この論文は、大規模言語モデル(LLM)のロングコンテキスト処理能力を向上させる新しいアプローチ「EM-LLM」を提案しています。主なポイントは以下の通りです:

1. 問題点:
   - 現在のLLMは長いコンテキストの処理に課題がある。
   - 学習時のコンテキスト長を超えると性能が低下する。

2. 提案手法 (EM-LLM):
   - 人間の認知科学、特に episodic memory(エピソード記憶) と event cognition(イベント認知) の知見を取り入れた。
   - 入力を意味のあるイベントに分割し、効率的に保存・検索する仕組みを導入。

3. 主な特徴:
   - Surprise-based segmentation: 予測困難な箇所でイベントを区切る。
   - Boundary refinement: グラフ理論を用いてイベント境界を最適化。
   - Two-stage retrieval: 類似性と時間的連続性に基づく記憶検索。

4. 結果:
   - LongBenchデータセットで既存の最高性能モデル(InfLLM)を上回る性能を達成。
   - 特に PassageRetrieval タスクで33%の性能向上。
   - 人間の知覚するイベント区切りとの高い相関を示した。

5. 意義:
   - 事実上無限の長さの文脈を扱えるLLMの可能性を示した。
   - 認知科学とAIを橋渡しし、人間の記憶メカニズムの計算モデルを提供。

6. 将来の展望:
   - より高度なイベント分割アルゴリズムの探求。
   - マルチモーダルタスクへの拡張。
   - 強化学習や継続学習への応用。

この研究は、LLMの長文脈処理能力を大幅に向上させただけでなく、人間の認知プロセスをAIに取り入れる新しいアプローチを示した点で重要です。

Q.コンテキスト処理方法を詳しく

EM-LLMのコンテキスト処理方法をもう少し詳しく説明しましょう：

1. コンテキストの分割:
   - コンテキストを「イベント」と呼ばれる意味のあるセグメントに分割します。
   - この分割は、まず「サプライズ」（モデルの予測誤差）に基づいて行われ、その後グラフ理論的な手法で最適化されます。

2. イベントの保存:
   - 分割されたイベントは、各イベント内のトークンのkey-valueペアとともに保存されます。

3. メモリ検索:
   - 新しいトークンを生成する際、関連するイベントを検索します。
   - 検索は2段階で行われます：
     a) 類似性バッファ: 現在のクエリと各イベントの代表トークンとの類似性に基づいてk_s個のイベントを選択します。
     b) 連続性バッファ: 選択されたイベントの前後のイベントもk_c個取得し、時間的な文脈を維持します。

4. コンテキスト構成:
   - 選択されたイベントは、LLMの拡張されたコンテキストウィンドウに追加されます。
   - このコンテキストは以下のように構成されます：
     - 初期トークン（128トークン）
     - 類似性バッファからのイベント
     - 連続性バッファからのイベント
     - ローカルコンテキスト（最新のトークン）

5. LLMの処理:
   - 拡張されたコンテキストを使用して、LLMが新しいトークンを生成します。

この方法により、EM-LLMは非常に長いコンテキストを効率的に処理し、関連性の高い情報を保持しながら、人間の記憶メカニズムに似た方法で情報を取り出すことができます。

Q.ベクトルデータベースは使ってないですね？

はい、その通りです。EM-LLMの手法では、ベクトルデータベースのような外部のデータ構造は使用していません。代わりに、情報は以下のような形で保持されています：

1. テキストベースの保存:
   - 情報は、元のテキスト形式で保存されます。具体的には、トークン化されたテキストの形で保持されています。

2. Key-Valueペア:
   - 各イベント（テキストセグメント）は、そのイベント内のトークンに対応するkey-valueペアとして保存されます。
   - これらのkey-valueペアは、Transformerモデルの注意機構で使用されるものと同じです。

3. イベント構造:
   - テキストは「イベント」と呼ばれる意味のあるセグメントに分割されます。
   - 各イベントは、そのイベントに含まれるトークンのkey-valueペアの集合として表現されます。

4. 内部メモリ:
   - これらのイベントとそれに対応するkey-valueペアは、モデルの内部メモリに保持されます。
   - 外部のデータベースやインデックスは使用せず、すべての情報はモデル内部で管理されます。

5. 検索メカニズム:
   - 関連イベントの検索は、保存されたkey-valueペアを直接使用して行われます。
   - 類似性の計算は、クエリと各イベントの代表トークンのkey間で行われます。

この方法の利点は、外部のデータ構造に依存せずに長いコンテキストを処理できること、およびTransformerモデルの既存のメカニズム（key-value注意機構）を直接利用できることです。これにより、モデルの既存の能力を最大限に活用しながら、長いコンテキストを効率的に処理することができます。

Q.この論文で使っているLongBenchデータセットについて教えて

はい、LongBenchデータセットについて説明します。

LongBenchは長文コンテキスト処理能力を評価するためのベンチマークデータセットです。論文の中で以下のような特徴が挙げられています:

1. 長文処理を必要とする多様なタスクが含まれています。具体的には以下のようなタスクが挙げられています:

- NarrativeQA: 長い物語文の質問応答
- MultiNews: 複数の記事の要約
- Qasper: 学術論文からの質問応答 
- TREC: 質問分類
- MultiFieldQA: 複数分野にまたがる質問応答
- TriviaQA: 雑学クイズ形式の質問応答
- HotpotQA: 複数文書を参照する必要のある質問応答
- SAMSum: 会話の要約
- 2WikiMQA: Wikipediaの複数記事にまたがる質問応答
- PassageRetrieval: 要約から元の段落を特定するタスク
- Musique: 複数のステップを要する質問応答
- LCC: 長文の分類
- GovReport: 政府報告書の要約
- RepoBench-P: プログラミング関連の質問応答
- QMSum: 会議録の要約

2. これらのタスクは、長い文脈の理解、複数文書間の関連付け、長文の要約など、長文処理の様々な側面を評価します。

3. 論文の実験では、このLongBenchを使ってEM-LLMの性能を評価し、特にPassageRetrievalタスクで33%以上の大幅な改善を示しています。

4. LongBenchは長文処理モデルの性能を包括的に評価するための標準的なベンチマークとして使用されており、EM-LLMの性能をInfLLMなど他のモデルと直接比較することができます。

このように、LongBenchは長文コンテキスト処理における言語モデルの能力を多角的に評価するための重要なデータセットとして位置づけられています。

Q.驚きベースの分割(Surprise-based segmentation)をもっと詳しく

Surprise-based segmentationは、EM-LLMの重要な要素の1つです。この手法は人間の認知プロセスにヒントを得ており、予測が困難な（つまり「驚き」のある）箇所でテキストを区切ることで、意味のあるイベントに分割します。以下にその詳細を説明します：

1. 基本概念:
   - LLMの予測確率を利用して、各トークンの「驚き」の度合いを計算します。
   - 「驚き」が一定のしきい値を超えた箇所をイベントの境界とみなします。

2. 数学的定義:
   - あるトークン x_t の驚きは、負の対数尤度で定義されます：
     - −log P(x_t | x_1, ..., x_t-1; θ)
   - ここで P は LLM によるトークンの予測確率、θ はモデルのパラメータです。

3. 境界の決定:
   - 動的なしきい値 T を使用：T = μ_t-τ + γσ_t-τ
   - μ_t-τ と σ_t-τ は、過去 τ トークンの驚きの平均と標準偏差
   - γ はスケーリング因子

4. アルゴリズム:
   - 各トークンの驚きを計算
   - 驚きがしきい値 T を超えるトークンを潜在的な境界として識別
   - これにより、初期のイベント分割が得られる

5. 利点:
   - コンテキストの変化に適応的
   - 人間の知覚するイベント境界と高い相関を示す
   - 計算コストが低い（既存のLLM出力を利用）

6. 補完的手法:
   - Boundary refinement と組み合わせることで、さらに洗練された分割が可能

7. 認知科学との関連:
   - 人間が予測誤差や驚きの大きな瞬間で経験を分割するという理論と一致
   - エピソード記憶の形成プロセスを模倣

このアプローチにより、EM-LLMは入力テキストを意味のある単位に効率的に分割し、後の検索や利用を容易にします。これは特に長い文脈を処理する際に重要で、LLMの性能向上に大きく貢献しています。

Q.境界精緻化(Boundary refinement)をもっと詳しく

Boundary refinementは、Surprise-based segmentationで得られた初期のイベント境界をさらに最適化するプロセスです。この手法はグラフ理論の概念を応用しており、イベント内の一貫性を高め、イベント間の区別を明確にすることを目的としています。以下にその詳細を説明します：

1. 目的:
   - イベント内の類似性（intra-event similarity）を最大化
   - イベント間の類似性（inter-event similarity）を最小化

2. グラフ理論的アプローチ:
   - 注意機構のキー（key）ベクトル間の類似度行列を隣接行列として扱う
   - 各トークンをグラフのノードとみなし、類似度をエッジの重みとする

3. 主要な評価指標:
   a. Modularity（モジュラリティ）:
      - コミュニティ（イベント）構造の質を測定
      - 高いモジュラリティは、イベント内の強い結合とイベント間の弱い結合を示す
   b. Conductance（コンダクタンス）:
      - コミュニティ間の接続の少なさを測定
      - 低いコンダクタンスは、より明確に区別されたイベントを示す

4. アルゴリズムの流れ:
   - Surprise-based segmentationで得られた初期境界を開始点とする
   - 隣接する境界間で、選択した評価指標（モジュラリティまたはコンダクタンス）を最適化する新しい境界位置を探索
   - この過程を全ての初期境界に対して繰り返す

5. 計算複雑性:
   - O(kn)、ここでkは初期境界の数、nはシーケンス長

6. 利点:
   - より一貫性のある、意味のあるイベント分割が可能
   - 後の検索プロセスの効率と精度を向上させる
   - グラフ理論の既存の知見を活用できる

7. 実験結果:
   - 単純なSurprise-based segmentationよりも高いパフォーマンスを示す
   - 人間の知覚するイベント境界との相関がさらに高まる

8. 将来の展望:
   - より高度なグラフクラスタリングアルゴリズムの探索
   - 階層的なイベント構造の形成への拡張の可能性

Boundary refinementは、EM-LLMの性能向上に大きく寄与しており、特に複雑な時間的推論を必要とするタスクで効果を発揮します。この手法により、LLMはより人間らしい方法で長い文脈を理解し、処理することが可能になっています。

Q.二段階検索(Two-stage retrieval)をもっと詳しく

EM-LLMの Two-stage retrieval プロセスは、人間の記憶検索メカニズムに着想を得た重要な特徴です。以下にその主な要素と特徴をまとめます：

1. 目的:
- 関連性の高いエピソードイベントを効率的に選択し、LLMのコンテキストウィンドウに組み込む
- 類似性と時間的関係の両方を考慮した検索を実現する

2. 第1段階: 類似性ベースの検索
- k-NN (k-Nearest Neighbors) 検索を使用
- 現在のクエリと各イベントの代表トークンとのドット積類似度に基づいて検索
- ks個のイベントを取得し、「類似性バッファ」を形成

3. 第2段階: 時間的連続性の維持
- 「連続性バッファ」を導入（サイズ kc のキュー構造）
- 検索されたイベントの近傍イベント（元のシーケンスで±n位置以内）をこのバッファにエンキュー
- 時間的文脈を維持し、LLMの「誘導」注意ヘッドが連続性と非対称性効果を示すことを可能に

4. 全体の構成:
- 合計 k = ks + kc + 2 個のイベントがコンテキストウィンドウに追加される
- 関連性と時間的関係のバランスを取る

5. 特徴:
- 人間の記憶検索パターンに類似（類似性ベースと時間的に連続した検索の組み合わせ）
- キュー構造により、新しいイベントが処理されるにつれて時間的文脈が自然に減衰

6. 効果:
- LLMが長期的な文脈を効果的に利用できるようになる
- 特に複雑な時間的推論を必要とするタスクでパフォーマンスが向上

7. 実装の詳細:
- 大規模なメモリストアに対しては、効率性を維持するために近似k-NNを利用

このTwo-stage retrievalプロセスは、EM-LLMが実質的に無限のコンテキスト長を扱えるようにする重要な要素であり、人間の記憶システムの特徴を模倣しつつ、LLMの性能を大幅に向上させることが示されています。

メモ

• 相変わらずテクニカルな部分は訳わかっていませんが、要は工夫を重ねたRAGだと理解しました。
  • コンテキストを全部読み込むのではなく、あらかじめイベント単位に整理しておき、入力されたプロンプトと類似性の高いイベント＋時間的連続性の高いイベントだけを残してモデルに渡す。
• 残念ながら実装は公開していないっぽいのですが、この論文で「既存のロングコンテキスト処理のSOTA」として言及されている「InfLLM」はGithubに公開されていました。試すならこっちでしょうか。

github.com

 

 

【LLM論文を読む】知識直接選好最適化（KDPO）によるLLMの知識編集

•  「直接選好最適化（DPO）」はいわゆるアラインメントの目的で使われているLLMの学習手法です。
  •  同一の指示に対する有益な回答例と有害な回答例の両方を提示することで、モデルが開発者にとって好ましい挙動をとるよう効率的に調整します。
  • 他のアラインメント手法よりも手軽に行えるので、ローカルLLMコミュニティでも追加学習の最終工程として積極的に採用されているようです。
• 以前「このDPOってLLMに対する知識の追加目的でも使えるのでは？」と思ったことがあり、実際に試したのですが、素人仕事では効果が得られずそれっきりになっていました。
• ただ、久しぶりに知識編集関連の情報を調べていたところ、DPOを応用した知識編集に関するarXiv論文が出ていたので、簡単に目を通してみた次第です。

arxiv.org

• タイトルは『Knowledge Editing in Language Models via Adapted Direct Preference Optimization（適応直接選好最適化による言語モデルの知識編集）』、2024å¹´6月にイスラエルのテルアビブ大学などの研究者によって投稿されています。

要旨

大規模言語モデル(LLM)の持つ知識は、時間の経過とともに古くなっていくことから、事実認識の誤りやギャップにつながる可能性がある。知識編集（Knowledge Editing: KE）は、高コストな再トレーニングを必要としない重み更新を用いて、この課題を克服することを目的としている。我々は知識編集をLLMアライメント問題として扱うことを提案する。この目標に向けて、知識の修正により効果的な直接選好最適化（DPO）のバリエーションである「知識直接選好最適化（KDPO）」を導入する。我々の手法は、モデルに格納された知識を継続的に更新するオンラインアプローチに基づいている。DPOと呼ばれるプロセスにおいて、現在の知識をネガティブサンプルとして、導入したい新しい知識をポジティブサンプルとして使用する。また、ネガティブサンプルの生成には教師強制を用い、ポジティブサンプルを用いて最適化を行うことで、局所的な変化を維持することができる。我々は様々なデータセットとモデルで我々の知識編集法をテストし、100回と500回の逐次編集を行い、いくつかの最先端手法と比較した。さらに、我々の方法を標準的なDPOアプローチと比較するアブレーション研究も行った。我々の実験結果は、我々の修正DPO法がより洗練された知識編集を可能にし、従来の方法と比較して同等以上の性能を達成することを示している。

メモ

• ここでは「好ましい回答(Chosen)」＝「新しい知識」、「好ましくない回答(Rejected)」＝「古い知識」として、DPO手法を知識編集に応用しています。
• そのうえで、KDPO手法では学習知識をトークン単位で細かくターゲッティングすることにより学習の質の改善を図っているようです。
• 以下の図はKDPO「メッシはアルゼンチンのロサリオ市で生まれた」という知識を「メッシはイタリアのミラン市で生まれた」に改変する場合の例です。
  • 通常のDPOのように「イタリアのミラン市 vs. アルゼンチンのロサリオ市」で学習させるのではなく「イタリア」を固定しておき「（イタリアの）ミラン vs. （イタリアの）ロサリオ」に絞って損失を学習させる。
  • 通常のDPOだと、LLMの知識の中で「メッシ」と「アルゼンチン」の関係を遠ざけるだけでなく「ロサリオ市」と「アルゼンチン」の関係性をも遠ざけてしまい、別の知識を歪める弊害がある。

• この論文で示されているKDPO手法のパフォーマンスを概観します。
• 以下の表は、MMLUなどの代表的なLLMベンチマークを利用したもので、左側は「100回の連続知識編集の結果」、右が「500回の連続知識編集の結果」を示しています。対象モデルはLlama-2-7Bです。

• OursとなっているのがKDPO手法、FT-Mは一般的なファインチューニングの派生手法、ROMEとMEMITは非ファインチューニングの代表的な知識編集手法です。
• まず、ほかの手法よりKDPO/DPOのほうが全般的に成功率が高いことが示されてます。
  • ただ、知識編集の研究では論文によって各手法の評価に大きなバラつきがあるので注意したいです。
• また、通常の知識編集ではKDPOよりも単純なDPO手法のほうが成功率が高く、500回程度まで編集回数を増やすとKDPOのメリットが出てくる、ということのようです。
• 以下は、別の方法による知識編集精度の評価です。

• この部分は、DPOとKDPO（Ours）の比較のみです。結果にムラがあり、やはり編集の反復回数を増やさないとKDPOの優位性は出にくいようです。
• なおデータセットはいずれも知識編集の評価用のもので、MetricのEdit Succ.は編集成功率、Portabilityは編集知識を応用できるかの評価、Localityは編集が他の周辺知識に悪影響を及ぼしていないかの評価、Fluencyは編集後のモデルが反復的な出力に陥らないかの評価、のようです。
• 最後に、DPO・KDPO（Ours）と、ファインチューンの派生手法（AdaLoRA, FT-L, FT-M）の比較表です。Qwen1.5-0.5Bという小規模な言語モデルを対象にしています。

• どうやら、超小型の言語モデルだとSDPOの優位性が出やすいということみたいです。

雑感

• この論文によれば、そもそもDPO自体が知識編集にかなり効果があると主張されています。ここで使われた具体的なDPOハイパーパラメータがよく分からなかったのですが、またDPOによる知識編集を試してみたくなりました。
• 「KDPO」については、たぶん期待したほどの結果は出なかったのかな、という雰囲気を感じます。
• 知識編集については、ファインチューンの派生手法もそれ以外の系統も、断続的に新手法が出続けているのですが、あまりローカルLLMコミュニティの関心が高くなく網羅的・実用的な評価がよく分からない難点があります...

 

ファインチューニングの終焉：全ては継続的な事前学習

• 少し古いですが「ファインチューニングの終焉（The End of Fine-tuning）」という記事が面白かったので、簡単なメモです。

www.latent.space

• この記事に登場するFast.aiのJeremy Howardさんは「事前学習→追加学習→RLHF」のように、フェーズごとにデータセットの種類・手法を完全に切り替えていく言語モデルの学習方法は「もはや正しくない」と主張しています。

「私は今では誰もが採用している 3 段階の学習アプローチを最初に考案しましたが、これは実は間違っており、使用すべきではないというのが私の今の見解です。正しい方法は、ファインチューニングという考えを捨て去ることです。そのようなものは存在しません。ただ事前学習を継続するだけです。

事前学習とは、最初から、関心のあるあらゆる種類のデータ、関心のあるあらゆる種類の問題、指示、演習、コード、汎用ドキュメントの完成などをすべて含めるようにすることです。そして、トレーニングするにつれて、徐々にそれをキュレートし、徐々に品質を高め、実行したいタスクの種類にますます特化していきます。ただし、データを捨てることはありません...

それが今の私の見解です。ULMFiT は間違ったアプローチだと思います。それが、いわゆるアライメント税（alignment tax）が数多く見られる理由です。実際には、人々が間違ったトレーニングをしているからだと思います。」

• このコメントで言及されている「アライメント税」は、LLMが有害な出力をしないように微調整するアラインメントによってモデル性能が低下してしまう現象を指しているのだと思います。
• そのほか、Llama-2にコーディング特化の学習を加えたCodeLlamaが一般タスクでの性能を落とした例にも言及しつつ、過去に獲得した知識を追加学習中に失ってしまう「壊滅的忘却」を防ぐためには常に学習データの多様性を維持し続けることが重要だ、というのが論旨みたいです。
  • 最終的な用途に合わせて重要なデータの構成比率を増やしていく必要はありつつも、それ以外のデータを完全に捨ててしまうと学習によって汎用性能が劣化してしまう。
• そういえば、以前にも似たような投稿をメモしていました。微調整中も1/4くらいは事前学習データを混ぜたほうがいいのでは？という内容です。

sc-bakushu.hatenablog.com

 

【LLM論文を読む＆試す】LLMの刈り込み(Pruning)：深いレイヤーの不合理な非効率性

 

• 先日「Llama-3-70Bを刈り込み（Pruning）で42Bに縮めたモデルが登場」というRedditの投稿が話題になっていました。
• 投稿者はおなじみのkindacognizant（kalomaze）さんですが、モデル作成者は別の方のようです。モデルのHuggFaceのRepoはこちら。

huggingface.co

• このモデルを実際に触ってみましたが、InstructモデルではなくBaseモデルを刈り込んだものなので正直なところ良し悪しはよくわかりませんでした。
  • 投稿によれば、Pruned-Llama3のMMLUスコアは76-77（4bitでテスト）で、元の79から若干低下しているものの、それでもMixtral 8x22Bと同等！の高いスコアを維持しているそうです。
• ちょっと面白そうなので、このモデル作成手順の元ネタとされている論文を斜め読みしたうえで、モデル刈り込みを試してみたいと思います。

arxiv.org

• これは2024å¹´3月にMeta FAIR関係の研究者が投稿したarXiv論文です。

要旨

我々は、オープンウェイトの事前学習済みLLMのための単純なレイヤー刈り込み戦略を経験的に研究した。その結果、モデルのレイヤーの大部分（最大で半分）を除去した後でも、様々な質問応答ベンチマークでの性能の劣化を最小限に留められることを発見した。これらのモデルに刈り込みを行うにあたり、レイヤー間の類似性を考慮することによって除去するレイヤーの最適なブロックを特定した。この際パラメータ効率の良いファインチューニング（PEFT）手法、QLoRAを使用し、各実験を単一のA100 GPUで実行している。実用的な観点からは、これらの結果は、レイヤー刈り込み手法が他のPEFT戦略を補完し、一方ではファインチューニングの計算資源をさらに削減でき、他方では推論のメモリとレイテンシを改善できることを示唆している。科学的な観点からは、これらのLLMが層の削除に対して頑健であることは、現在の事前学習手法がネットワークの深いレイヤーのパラメータを適切に活用していないか、浅いレイヤーが知識の保存において重要な役割を果たしていることを示唆している。

メモ

• Llama-2-70Bのようなベースモデルでは、最大で半分くらいのレイヤーを削除してもその性能の大部分を維持することができる。
• というのも、刈り込むレイヤーを増やしていくと（単調に性能が低下するのではなく）一定の水準でMMLUスコアが急低下する現象が観察される。

• これは、モデル性能にとって重要なパラメータが一部のレイヤーに偏っている（＝それ以外のレイヤーは削っても性能に影響しにくい）ことを示唆する。
• 具体的に検証すると、浅いレイヤーではレイヤー間の類似性が低く（無駄がなく）、より深いレイヤーで類似性が高く（冗長になる）ことがわかった。
• したがって、単純に刈り込む戦略をとるよりも、深いレイヤーを優先して刈り込む戦略をとることで、モデルの性能低下を抑えながらサイズを縮小する道が開ける。
• なおレイヤーを選択的に刈り込む場合も、モデルの損傷を修繕するための追加学習（Healing）を施すことで術後？の性能がより安定する。

PruneMe：論文の非公式実装

• さて、MergeKitを手がけるarcee-aiが「PruneMe」というこの論文の非公式な実装を提供していて、冒頭のモデルもこれを利用して作っているそうです。

github.com

• PruneMeのRepoには「Mistral-7B-instruct-v0.2」を例に実際にレイヤー間の類似性を検証したグラフが掲載されています。
• 元論文で主張されているとおり、前半の浅いレイヤーは類似性が低く、後半の深いレイヤーで類似性が高くなる様子がプロットされています。

PruneMeによるモデル刈り込みを試す

• ではGoogle Colabで簡単に試してみます。Repoをクローンし、依存関係をインストールします（TransformersはColabにプリインストール済み）。

# レポジトリのクローン
!git clone https://github.com/arcee-ai/PruneMe

# 依存関係
!pip install bitsandbytes datasets accelerate

• ここではMistral 7Bベースの日本語チャットモデルを使って、レイヤー類似性を測定します。
• とりあえずサンプルと同じ英語データセットを使って測定しています（レイヤーの類似性が判定できればよく日本語を使う必要はない気がするので）。
• 「--layers_to_skip」で、削除したいレイヤーの数を指定します。ここでは32レイヤーのうち1/4の8レイヤーを削除する想定です。
• なお計算時間の問題で、データセットサイズはサンプルより大幅に減らしています。

!python ./compute_block_similarity/layer_similarity.py --model_path "TFMC/Japanese-Starling-ChatV-7B" \
                      --dataset "arcee-ai/sec-data-mini" \
                      --dataset_column "text" \
                      --batch_size 8 \
                      --max_length 1024 \
                      --layers_to_skip 8 \
                      --dataset_size 200 \
                      --dataset_subset "train"

• 計算が終わると、CSVファイルで結果が出力されます（上記設定で、標準GPUで20分ほど）。測定結果は以下の通りでした。

• サンプルとよく似た結果が得られました。21-29のブロックが最も冗長なようです。同じMistral 7Bベースのモデルなので当然といえば当然かもしれません。
  • いずれにしてもレイヤーごとの冗長性は追加学習では特に変わらない（アーキテクチャが同じなら同じ）可能性がありそうです。
• あとは、この特定したレイヤーブロックを削除するため、MergeKitを導入します。

# MergeKitの導入
!git clone https://github.com/cg123/mergekit.git
%cd mergekit
!pip install -e .

• 次に「./PruneMe/slice_with_mergekit/slice.yaml」を適宜編集します。MergeKitのpassthorough手法（いわゆるフランケンマージを作る手法）を流用しているようです。

slice.yaml
--------------------------------------
slices:
  - sources:
      - model: TFMC/Japanese-Starling-ChatV-7B
        layer_range: [0, 21]
  - sources:
      - model: TFMC/Japanese-Starling-ChatV-7B
        layer_range: [29,32]
            
merge_method: passthrough
dtype: bfloat16

• 最後にスライスを実行すると、刈り込みモデルが出力されます。

# 刈り込みの実行
!python /content/PruneMe/slice_with_mergekit/merge_me.py

刈り込みモデルのテスト

• ということで、モデルの刈り込みができたので実際に出力してみます。以下が出力の一例です。

<s> [INST] <<SYS>>\nあなたは役立つアシスタントです。\n<</SYS>>\n\n空が青いのはどうして？ [/INST] 

空が青いのは、一般には空の中での色の相物が効嵑たぼいるにお効がて効ぼとしいともい職て効㩉効い〾くでいてのいい。も樾詖倴棧倴壯〾棧倴壬費塏壯〳ぞ度、度桴壯〷度眸竇疎ゾ度、度諷耡紐ゾお填ゾとしい度熱ぼこいでいてまい臦諓ぞ度、...

• 残念ながら、モデルの出力は途中から破綻してしまいます。
• よく考えてみると、冒頭のモデルも元論文で扱っている例もいずれもBaseモデルだけで、Instructモデルには触れていませんでした...
• 「刈り込みしても性能が落ちにくい」というのは、あくまで選択式のMMLUスコアで測定されるようなBaseモデルの単純性能の話で、Instructモデルはもっと繊細なようです。
  
  • あるいは、指示追従にとって重要なパラメータが実は冗長な深いレイヤーに存在していたりもするのでしょうか？
• ということで、基本的には「InstructモデルではなくBaseモデルに刈り込みして、あらためて指示追従の追加学習をやる」という手順が必要になりそうで、お手軽感はありません。
• 既成のモデルを単にサイズ圧縮するのが目的なら、量子化の質にこだわったほうが期待できそうです。
• とはいえ、例えばMoEモデルならもっと刈り込める余地がありそう？とか、色々と面白そうな手法ではあるので、有効な活用方法が見いだされてほしい気もします。

 

llama.cpp：iMatrix量子化は日本語性能にどう影響するか？

 

• 量子化時のモデル劣化を抑制する重要度行列（iMatrix; Importance Matrix）計算の話題です。
• 最近はHuggingFaceにアップされるGGUFも多くがiMatrix版となっていますが、これらの量子化でよく使われているiMatrix計算用データセットは以下の2種類のようです。 
  1. wiki.train.raw：Wikitext（英語版）のトレーニング用データセット。llama.cppのサンプルでもwiki.train.rawが使われている。iMatrix計算では、このうち10kトークンほど計算すれば実用的には十分な様子。
  2. groups_merged.txt：koboldcppにも関わっているkalomazeさんが作成した疑似ランダムデータセット。言語モデルで生成した雑多なテキストを中心とした200KBほどのデータ。
• となると、一体どちらのiMatrix版が良いのかが気になってきます。以下のllama.cppのRepoの議論に目を通すと「基本的にはwikitextでよいが、英語以外の言語で使うならばgroups_mergedなど他の選択肢を検討すべきかもしれない」という趣旨の話が展開されています。

github.com

iMatrixテキストによる日本語性能の差

• そこで、先日のChatVectorを使った7Bモデルを使ってそれぞれのiMatrix量子化による日本語性能の変化を調べてみました。ベンチマークはお馴染みのELYZA-tasks-100です。結果は以下の通りでした。

• 青がiMatrix無しの量子化、橙がwiki.trainによるiMatrix量子化、黄がgroups_mergedによるiMatrix量子化です（なおIQ3_XS以下では非iMatrixの量子化は不可）。
• "Q5_K_M"の時点ではiMatrixの有無による差はありませんが、4bitの量子化では"iMatrix"による効果がはっきりあらわれます。
• 同じiMatrix版でも差がみられ、"Q4_K_M"のgroups_merged版（3.52）は、"Q8_0"すら超えるスコア（3.42）を示していて驚きます。
  • かなり差が大きく、単なる誤差ではなさそうです。具体的に得点が上がった回答の一例を確認します。

ElyzerTasks100 設問68	Q：私の目は黒く、髪は明るい黄色で、足元はしっかりと地面に根ざしています。私は太陽の光を顔に浴びるのが好きです。私の正体は何でしょう？
Q8_0量子化 （×不正解）	あなたの特徴から推測すると、あなたはおそらく日本人である可能性が高いです。日本人の多くは黒い目を持ち、明るい黄色の髪色を持つ人は稀です。また、足元がしっかりと地面に根ざしているという表現から、安定感や地に足のついた人物像が浮かびます。太陽の光を好むということから、明るく前向きな性格を持っているのではないでしょうか。ただし、これらの特徴だけでは正確な正体を特定することはできません。もしかしたら、その他の要素も含めて自分自身のアイデンティティを表現してみると良いかもしれません。
Q4_K_M量子化 By groups_merged （〇正解）	この情報から推測すると、あなたの正体は「ヒマワリ」である可能性が高いです。以下の理由からです。 1. 目が黒い：ヒマワリの花弁には中心部に暗い部分があり、まるで目のように見えることがあります。 2. 髪は明るい黄色：ヒマワリの花弁の色は明るい黄色で、髪色が明るい黄色であることがヒマワリのイメージに一致しています。 3. 足元がしっかりと地面に根づいている：ヒマワリは背が高く、しっかりと地面に根を張っています。足元がしっかりと地面に根づいていることもヒマワリの特徴の一つです。 4. 太陽の光を顔に浴びるのが好き：ヒマワリは太陽の光を浴びることで元気に成長します。太陽の光を好む姿勢はヒマワリにピッタリです。 以上の点から、あなたはヒマワリである可能性が高いと推測されます。ただし、他の花や植物の可能性もあるため、確定するにはさらに詳しい情報が必要かもしれません。

• • この問題では、日本語の比喩表現が理解できるようになっています。ほかの設問も含め、総じて日本語の文章理解が若干向上している印象を受けます。
• "Q4_K_M"以外ではiMatrixデータの違いによる差は小さく、また必ずしもgroups_merged版のほうがスコアが良いわけでもありません。
• とはいえ、iMatrixデータを工夫することで日本語性能に何らかの効果を及ぼせるかも、という期待はできそうです。

3bit以下で顕著になる量子化の悪影響

• 量子化がもたらす性能変化は予測不能な部分が大きいのですが、確実に言えるのは「3bit以下の低bit量子化では性能が大幅に劣化する」という点です。
• 先ほど紹介したグラフでは、"IQ2_XS"で顕著にベンチマークスコアが低下していましたが、実際の出力内容を見ると実は"IQ3_XS"の時点で回答が破綻するケースが出現します。例えば以下のような例です。

ElyzerTasks100 設問13

IMEとして機能してください。 あなたのタスクはローマ字入力されたアルファベット列を単語ごとにひらがなに変換し、それぞれの単語を漢字に変換する候補を最大3つ提示することです。 （中略） それでは、入力を開始するので、IMEとして出力を表示してください。 inputs: j, u, u, b, u, n, o, s, h, o, s, e, k, I

IQ2_XS量子化 Groups_merged の回答

以下は入力されたアルファベット列をひらがなに変換し、それぞれの単語を漢字に変換する候補を最大3つ提示する例です。 inputs: j, u, u, b, u, n, o, s, h, o, s, e, k, i outputs: - ジュウウブノウホソエキ: 寿生雲鵬, 順守護哀, 住吉水神社 - ゆうう: 優雅, 夢想, 憂う - せきゃ: 挑発する, 決める, 石田紗希子 - おほ: おほほほほ, おほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほほ

• 同じトークンが連続して止まらなくなったり、文章が意味もなく冗長になるのは低bit量子化でよく見る現象です。こうなると、モデルとしては実用が難しくなります。
• 過去に日本語Wikitextを使って量子化によるモデルのPerplexityの推移を調べたことがあったのですが、ここでも量子化クラスが3bitになるとPerplexityが急上昇する傾向が確認できました（Perplexityは一般に低いほど良い）。
  • もちろん英語でも同じようにPPLが悪化しますが、どうやら日本語のほうがより激しくPPLが増加する可能性が高いです（参考記事）。

iMatrix計算に日本語テキストを使うと？

• じゃあ3bit以下の量子化は避ければ？という話ではあるのですが、最近はローカルLLM大型化が進んでいることもあり、実際には3bitクラスの量子化をやむなくチョイスする場面も（個人的には）よくあります。
• そこで、iMatrixの計算用データに日本語を含めることで低bitでの日本語性能の劣化を抑制できないか、ということを考えています。
• 冒頭のllama.cppのRepoの議論でも、英仏混合テキストをiMatrix計算に使うことで仏語でのPPLが改善した（それだけでなく英語性能も一部改善した）という結果が投稿されています。

https://github.com/ggerganov/llama.cpp/discussions/5263#discussioncomment-8353685

• これらの情報を踏まえ、Wikitextã‚„groups_mergedのほか上記の例で用いられているc4データセット（Webクロールコーパス）を使って、iMatrix計算用の日英混合テキストを作成してみることにしました。

huggingface.co

• 新たに用意するテキストについては、200KB程度のgroups_merged.txtで一定の効果が出ていることから日本語200KB＋英語200KBの400KBくらいを目安にざっくり抽出しています。
• というわけで、何種類かのiMatrixテキストでIQ2_XS量子化を行って量子化モデルのベンチマークスコアを取った結果、以下のようになりました。

• wiki_text(en)はwiki.trainと同じもの、wiki_text(en+ja)がwiki.trainに日本語wikitextを追加したもの、c4_en_jaがc4の日＋英テキスト、c4_ja_onlyがc4の日本語のみテキストです。
• 日本語テキストを含めることでベンチマークスコアが改善することがわかります。
• ただし、wiki_text(en+ja)のスコアはwiki_text(en)比で微増といったところでほとんど効果はありません。また、日本語のみのc4_ja_onlyよりも日英混合のc4_en_jaのほうがスコアが高いのも面白いです。
• このテストからc4データセット由来の日英テキストでiMatrix計算をすると良い結果が得られそうなことが分かったので、もう少し深堀りしてみます。
• 上記の例では、c4の英語テキスト200KBの後ろにc4の日本語テキスト200KBを結合したのですが、英語と日本語の混ぜ方で違いがあるかもしれません。
• 日本語テキストを先にして英語テキストを後半に結合したパターンや、英文チャンクと日本語チャンクをランダムにミックスしたパターンも作成し、あらためて量子化後のスコアを測定しました。

• 結果としては、最初のテストで使った「英語テキスト（先）＋日本語テキスト（後）」のパターンが最高スコアとなりました。
• 「英文チャンクと和文チャンクのランダムミックス」や「日本語テキスト（先）＋英語テキスト（後）」は「日本語のみ」よりもスコアが低くなっています（iMatrix計算の後半を日本語テキストのみで行うことに何か効果があるのでしょうか？）

雑感

• 記事が長くなりそうなので、ひとまずこのあたりに。他のモデル、他の量子化サイズでの効果も追って検証できればと思っています。
• なお、今回のテストで最も良さげな効果を示した日英混合iMatrix用テキスト（c4_en_plus_ja）については参考までHuggingFaceにアップしています。

huggingface.co

 

Mergoo: LLMの効率的なマージと微調整のためのライブラリ (MoE, Mixture of Adapters)

 

• 「Merggoo」というLLMマージ用の新しいライブラリができたそうで、開発者の方がRedditでもPRポストを上げておられます。
• もしかするとMegekitに代わるものになるのかもしれません。MoEのルーティングの学習や、LoRA Adapterの混合など。

面白そうなので後で試せればと思いますが、概要だけ先に見ておこうと思います。以下、開発者ブログの和訳です。

Mergoo: 効率的にマージし、微調整する (MoE, Mixture of Adapters)

huggingface.co

私たちは最近、複数の LLM エキスパートを簡単に統合し、統合された LLM を効率的にトレーニングするためのライブラリである mergoo を開発しました。このライブラリでは、さまざまな汎用またはドメインベースの LLM エキスパートの知識を効率的に統合できます。

🚀 Mergooでは次のことが可能です。

• 複数のオープンソースLLMを簡単に統合できます
• さまざまなマージ方法を適用：エキスパートの混合、アダプタの混合、レイヤーごとのマージが可能です
• ゼロから始めることなくMoEを効率的にトレーニングできます
• HuggingFece🤗モデルやトレーナーと互換性があります

å°Žå…¥

mergoo は、汎用的なものからドメイン固有のものまで、さまざまな LLM エキスパートの知識を統合するための信頼性が高く透過的なパイプラインを構築するように設計されています。エキスパートの混合、アダプタの混合、レイヤーごとのマージなどのさまざまな統合手法が組み込まれており、LLM ビルダーに柔軟性を提供します。マージされた LLM は、SFTrainer、PEFT、Trainer などの Hugging Face 🤗 トレーナーを使用して、特定のユースケースに合わせてさらに微調整できます。
次のセクションでは、MoE を使用して完全に微調整された LLM からマージされた LLM を構築する方法と、LoRA で微調整されたエキスパートからアダプタの混合 LLM を作成する方法を示す 2 つの例について説明します。

完全に微調整済みのLLMの混合

Branch-Train-Mixに続いて、ドメイン固有の LLM エキスパートは、Mixture-of-Expert (MoE) レイヤーのエキスパートとしてフィードフォワードパラメータをまとめ、残りのパラメータを平均化することで統合できます。MoE レイヤーは、後で微調整してトークン レベルのルーティングを学習できます。

例として、次のドメイン固有の LLM エキスパートを統合します。

• ベースモデル: metal-llama/Llama-2-7b-hf
• コードエキスパート: codellama/CodeLlama-7b-Python-hf
• WikiChat エキスパート: stanford-oval/Flame-2-7b-WikiChat-fused

マージするための設定を指定します:

config = \
{
    "model_type": "llama",
    "num_experts_per_tok": 2,
    "experts":[
        {
            "expert_name" : "base_expert",
            "model_id" : "meta-llama/Llama-2-7b-hf"
        },
        {
            "expert_name" : "expert_1",
            "model_id" : "codellama/CodeLlama-7b-Python-hf"
        },
        {
            "expert_name" : "expert_2",
            "model_id" : "stanford-oval/Llama-2-7b-WikiChat-fused"
        }
    ],
    "router_layers":[
        "gate_proj",
        "up_proj",
        "down_proj"
    ],
}

次に、マージされたエキスパートのチェックポイントを構築して保存します。

import torch
from mergoo.compose_experts import ComposeExperts
model_id = "mergoo_llama_code_wikichat"
expertmerger = ComposeExperts(config, torch_dtype=torch.float16)
expertmerger.compose()
expertmerger.save_checkpoint(model_id)

以下では、マージされた LLM のチェックポイントが読み込まれ、Python コード命令データセットでさらに微調整されます。

from mergoo.models.modeling_llama import LlamaForCausalLM
import torch
import datasets
import random
from trl import SFTTrainer
from transformers import TrainingArguments

# load the composed checkkpoint
model = LlamaForCausalLM.from_pretrained(
    "mergoo_llama_code_wikichat", 
    device_map="auto", 
    torch_dtype=torch.bfloat16,
)# 'gate' / router layers are untrained hence loaded warning would appeare for them

# load the train dataset
dataset = datasets.load_dataset("iamtarun/python_code_instructions_18k_alpaca")['train']
dataset = dataset['prompt']
random.shuffle(dataset)
train_dataset =  datasets.Dataset.from_dict(dict(prompt=dataset[:-1000]))
eval_dataset = datasets.Dataset.from_dict(dict(prompt=dataset[-1000:]))

# specify training arguments
trainer_args = TrainingArguments(
    output_dir= "checkpoints/llama_moe",
    per_device_train_batch_size = 1,
    per_device_eval_batch_size = 1, 
    learning_rate= 1e-5,
    save_total_limit=1,
    num_train_epochs=1,
    eval_steps= 5000,
    logging_strategy="steps",
    logging_steps= 25,
    gradient_accumulation_steps=4,
    bf16=True
)

trainer = SFTTrainer(
    model,
    args= trainer_args,
    train_dataset= train_dataset,
    eval_dataset= eval_dataset,
    dataset_text_field="prompt",
)

# start training
trainer.train()

その後、コードを Huggingface Hub にプッシュできます (ぜひプッシュしてください):

model.push_to_hub("mergoo_llama_code_wikichat_trained")

mergooはMistralとBertベースのエキスパートもサポートしています。

アダプターの混合(Mixture of Adapters)

mergoo は、複数のアダプタ (LoRA) を統合された MoE スタイルのアーキテクチャに統合することを容易にします。これは、微調整された LoRA の上にゲーティング レイヤーとルーティング レイヤーを適用することで実現されます。

アダプタ混合 LLM を構築するには:

• 同じベースモデルで微調整されたアダプタ（LoRA）のプールを収集する
• Mergoo を適用して MoE スタイルのマージされたエキスパートを作成する
• 下流のタスクでマージされたエキスパートを微調整する

たとえば、顧客サポート領域では次の専門家を統合できます。

• predibase/customer_support
• predibase/customer_support_accounts
• predibase/customer_support_orders

次のように構成を指定して、マージされたチェックポイントを構築します。

import torch
from mergoo.compose_experts import ComposeExperts

model_id = "mergoo_customer_suppoer_moe_lora"
config = {
    "model_type": "mistral",
    "num_experts_per_tok": 2,
    "base_model": "mistralai/Mistral-7B-v0.1",
    "experts": [
        {
            "expert_name": "adapter_1", 
            "model_id": "predibase/customer_support"
        },
        {
            "expert_name": "adapter_2", 
            "model_id": "predibase/customer_support_accounts"
        },
        {
            "expert_name": "adapter_3", 
            "model_id": "predibase/customer_support_orders"
        }
    ],
}

expertmerger = ComposeExperts(config, torch_dtype=torch.bfloat16)
expertmerger.compose()
expertmerger.save_checkpoint(model_id)

注：LoRAでマージ候補のエキスパートを微調整する場合、expert_nameはadapter_で始まる。

「完全に微調整された LLM の混合」セクションで定義されているように、マージされたエキスパートはさらに微調整できます。

結び

以上のように、mergooでは、複数の専門家の知識を確実かつ透過的に統合することができます。mergooはmixture-of-expert、mixture-of-adapters (MoE-LoRA)、layer-wise mergingを含むいくつかの統合技術をサポートします。マージされたLLMは、信頼できるエキスパートを提供するために、下流のタスク上でさらに微調整することができます。

 

github.com

 

Chat Vector の効果 vs. MoEマージ の効果

• 前回の続きです。次はChat Vector処理によってどれくらい日本語チャット機能が改善しているのかを具体的にみてみます。
• 下記の記事で、Chat Vectorを使わなくても単純に2モデルをMoEマージするだけで一定の性能向上が観察できることは確認しています。

sc-bakushu.hatenablog.com

• では、Chat Vectorを加えることでモデルのチャット性能はどのように影響を受けるののでしょうか。

単体の7BモデルにおけるChat Vectorの効果

• まず「LightChatAssistant 2x7B」の再現過程で得られた「ChatNTQ 7BにMistral-7B-v0.2-InstructのChat Vectorを適用したモデル」の性能を測定してみます。

名称	LightChat Assistant 2x7B	Chat NTQ 7B random MoE	ChatNTQ 7B +ChatVector	ChatNTQ 7B
パラメータ	2x7B	2x7B	7B	7B
量子化タイプ	Q8_0	Q8_0	Q8_0	Q8_0
ElyzaTasks100 スコア平均	3.31	3.25	3.23	3.06
標準誤差	0.14	0.14	0.15	0.15
平均字数	273.61	261.27	280.04	240.46

• ChatVector処理だけで平均スコアは3.23に上昇しました。
• 以前作った「ChatNTQ 7Bのx2ランダムマージ」のスコアが3.25だったので、このChat Vectorはランダムマージに近いレベルの性能上昇効果がありそうです。
• 回答の平均字数についてもどちらも共通して増加しているものの、Chat Vector版のほうがより顕著に増えています。
  • 体感的にもChat Vector版の回答は総じて丁寧で、Mistral 7B v0.2 Instructの影響が感じられます。
• 実際の回答例を見てみます。
• 以下のように、元の「ChatNTQ 7B」では解けなかった計算問題が、ランダムマージ版でも、Chat Vector版でも同じように正答できるようになりました。

ElyzaTasks100 設問26	質問: 太郎くんはりんごを5つ持っています。彼はさらに2つのりんごの箱を買いました。1つの箱には3つのりんごが入っています。太郎くんは何個のりんごを持っていますか？
ChatNTQ-7B 回答（不正解×）	太郎くんは最初に5つのりんごを持っていました。その後、2つの箱を買い、それぞれに3つのりんごが入っていたため、太郎くんは合計で8つのりんごを持つことになります。したがって、彼が最初に持っていた5つのりんごと、後から買った2つの箱に入っていた3つのりんごを合わせると、合計で8つのりんごを持っていることになります。
ChatNTQ 2x7B Random MoE 回答（正解〇）	太郎くんが最初に持っていた5つのりんごと、2つの箱の合計個数を計算する必要があります。 太郎くんが最初に持っていた5つのりんごの数は、5です。 1つの箱には3つのりんごが入っているため、もう1つの箱にも同じ数の3つのりんごが入っていると仮定すると、2つの箱には合計6つのりんごが入っています。 したがって、太郎くんが最初に持っていた5つのりんごと、2つの箱に入っている6つのりんごを合計すると、11個のりんごを持っていることになります。 したがって、太郎くんは11個のりんごを持っています。
ChatNTQ-7B + Chat Vector 回答（正解〇）	最初に太郎くんが持っていたりんごは5つです。そして、2つの箱を買って、それぞれ1つの箱に3つずつ入っているので、合計で2 × 3 = 6つのりんごが追加されます。 最初の5つと合わせて、太郎くんは11個のりんごを持っています。

• MoEマージとChat Vectorという全く異なる処理ですが、全般的な性能向上はどちらの手法においても期待できそうな印象です。
• ランダムMoEマージの場合、おそらく総パラメータ数の増加が性能に寄与していて、Chat Vectorの場合は英語モデルの追加学習スキルが性能に寄与しているのだと思います。

Chat VectorモデルのランダムMoEマージ

• つづいて、Chat Vectorを掛けた「ChatNTQ 7B」を単純にランダムMoEマージするとどうなるでしょうか。結果は以下のとおりです。

名称	LightChat Assistant 2x7B	ChatNTQ 7B + ChatVector Random MoE	ChatNTQ 7B + ChatVector	ChatNTQ 7B
パラメータ	2x7B	2x7B	7B	7B
量子化タイプ	Q8_0	Q8_0	Q8_0	Q8_0
ElyzaTasks100 スコア平均	3.31	3.33	3.23	3.06
標準誤差	0.14	0.15	0.15	0.15
平均字数	273.61	286.73	280.04	240.46

• ベンチマーク性能では「LightChatAssistant 2x7B」とほぼ同じレベルのモデルが得られました。
• したがって、「LightChatAssistant 2x7B」の高い日本語チャット性能それ自体は、「Chat Vector効果」 +「マージによるパラメータ増加効果」の2つだけで説明することもできそうです。
• とはいえ実際の出力を見比べてみると、小説生成モデルを掛け合わせた「LightChatAssistant 2x7B」の出力の方が、同一モデルマージの「ChatNTQ-ChatVector 2x7B」より明らかにクリエイティブで面白いと感じます。
• 異なる特化モデルを掛け合わせることの効果は、ベンチマークで測定しきれない部分にこそ現れるのかもしれません。

別のモデルからChat Vectorを抽出してみる

• ついでに、異なるモデルからChat Vectorを抽出することを試してみます。
• 元論文や「LightChatAssistant 2x7B」で差分抽出に使われた「Mistral 7B v0.2 Instruct」は、Mistral公式のファインチューンモデルであり、体感的にも優れたチャットモデルです。
• ただしベンチマーク上は「Mistral 7B v0.2 Instruct」を上回るMistral系モデルがいくつか作出されていて、その代表例がスタンフォード大学系の研究者が公開した「Starling-LM-7B-beta」です。
• Starling-7Bシリーズについては、以下の記事で概要を確認しています。

sc-bakushu.hatenablog.com

• 「Starling-LM-7B-beta」は現在も「LMSYS Chatbot Arena Leaderboard」で7Bモデル最高スコアを示していて、英語チャット性能ではこのクラスのSOTAです。
  • 7Bのオープンウェイトが人手による評価で GPT-3.5-Turbo・Claude 2.1・Gemini Pro など主要各社の商用モデルと同等の評価を得られるというのは少々驚きです。

• このモデルからChat Vectorを抽出して掛け合わせれば、いい感じの日本語チャットモデルが出来上がる予感がします（素人の発想）。
• というわけで「Starling-LM-7B-beta」のChat Vectorを「ChatNTQ 7B」に掛けたモデルを作り、ベンチマークにかけてみました。
• なお、「Starling-LM-7B-beta」のChat Vectorは1.0で掛けてもまったく英語が混ざらなかったので、0.8ではなく1.0の強度を採用しています。
• 結果は以下のとおりです。

名称	Command R V01	LightChat Assistant 2x7B	ChatNTQ + Staling ChatV	ChatNTQ 7B
パラメータ	35B	2x7B	7B	7B
量子化タイプ	Q8_0	Q8_0	Q8_0	Q8_0
ElyzaTasks100 スコア平均	3.42	3.31	3.42	3.06
標準誤差	0.15	0.14	0.15	0.15
平均字数	194.02	273.61	340.82	240.46

• スコア上は「LightChatAssistant 2x7B」を上回り、8bit量子化ベースで「Command R 35B」に並ぶモデルが出来上がりました。
• 出力字数も多く（平均341字）、とにかく丁寧なチャット対応ができるようになっています。ElyzaTasks100では回答の「有用性」が評価基準に含まれるので、評価者のGPT-4もこの観点から高く評価しているようです。
• とはいえ「Command R 35B」は遥かに簡潔な回答（平均194字）で同じだけのスコアを出しているので、純粋な「賢さ」に関して言えば明らかに「Command R 35B」が上だと感じます。

Starling LMのChat VectorモデルのMoEマージ

• では、このモデルをさらにMoEマージすればもっとスコアは上がるのか、と安易に考えてやってみましたが、結果は以下のとおりでした。

名称	LightChat Assistant 2x7B	ChatNTQ + Staling ChatV Random MoE	ChatNTQ + Staling ChatV	ChatNTQ 7B
パラメータ	2x7B	2x7B	7B	7B
量子化タイプ	Q8_0	Q8_0	Q8_0	Q8_0
ElyzaTasks100 スコア平均	3.31	3.18	3.42	3.06
標準誤差	0.14	0.15	0.15	0.15
平均字数	273.61	351.42	340.82	240.46

• 出力字数こそ多少増えているものの、GPT-4の評価は逆に低下しています。
• 体感的にも「口の速さに思考が追い付いていない」ような、ちぐはぐな印象を受けるモデルになってしまいました。
• 単一モデルに対して最適なChat Vector比率とMoEマージ後に最適になるChat Vector比率が異なるという話（こちらのAratakoさんのモデルカード参照）もあり、必ずしも足し算にはならないのだと再確認しました。

雑感

• ということで、ひとまず「LightChatAssistant 2x7B」の後追いをしながらMoEとChatVectorでいくつかの試行錯誤をしてみました。
• なお「Starling ChatV 7Bモデル」についてはベンチマーク性能があまりに高く、何かの参考にもなる気もしたので、HuggingFaceにアップしてみました。

huggingface.co

• Llama-3の小型モデルのリリースが間近に迫っているという話もあり、そちらも楽しみにしながら、CVとMoEで何ができるかも引き続き試していきたいと思います。