metadata

license: apache-2.0
language:
  - ja
tags:
  - mistral
  - mixtral
  - not-for-all-audiences
  - nsfw
base_model:
  - NTQAI/chatntq-ja-7b-v1.0
  - stabilityai/japanese-stablelm-instruct-gamma-7b
  - Elizezen/Antler-7B
  - Elizezen/Hameln-japanese-mistral-7B

LightChatAssistant-4x7B-optimized-experimental

GGUF版はこちら/Click here for the GGUF version

概要

Aratako/LightChatAssistant-2x7B-optimized-experimentalと同じようなChat Vectorの加算割合の最適化を、 Aratako/LightChatAssistant-4x7Bの設定をもとに行ったモデルです。素晴らしい手法を提案いただいた@Sdff-Ltbaさんに感謝します。

元々のLightChatAssistant-4x7BではChat Vectorの加算割合が全レイヤで0.8と固定でした。この加算割合の最適化をOptunaのTPESamplerを使って各レイヤごとで行い、その後MoEを行って作成したモデルです。作成に利用したスクリプトは以下で公開しています。

https://github.com/Aratako/Task-Vector-Merge-Optimzier

最適化の大まかな流れは以下の通りです。

ある加算割合で対象モデルにTask Vectorを加算、それらのモデルでMoE
ステップ1で出来上がったモデルを用いて何らかのタスクに対する評価を行い、スコアを取得（今回はMT-Benchをカスタマイズしたものを利用）
そのスコアを評価値として返し、それを最大化するように加算割合を最適化（TPEというベイズ最適化ベースの手法）

なお、experimentalと付いている通り、あくまで実験として作成したモデルです。主に下記の理由であまりパフォーマンスの向上が出来ていない可能性もあります。

探索空間が140次元に対し、試行回数が50回とかなり少ない
最適化のため評価値取得の際、各試行のモデル出力の評価にGPT-4による評価を利用しているが、これが人間の評価と一致するか不明。また、評価プロンプトや評価に使う問題が良くない可能性もある。
レイヤごとで切り分けて最適化を目指しているが、この切り分け方が良くない可能性がある

などなど問題があるかと思いますので、あくまで実験的なものとしてご認識ください。

余談ですが、各ベースモデル単体に対して同じ流れで個別で最適化を行い、最適化されたモデルをMoEする方法だと出力がかなり悪化しました。MoE前提で最適化を行う場合は、MoEまでを全体フローに取り入れ、MoEを行ったモデルを利用した評価値で最適化したほうが良さそうです。