0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ファインチューニングが普及したら何が変わるか — タスクベクトルとモデルマージの展望

0
Posted at

こんにちは、ダックスフントです。

最近、LoRAを使ったファインチューニングの検証をしていたところ、「Task Arithmetic(タスクアリスメティック)」という概念に出会いました。ファインチューニングの前後で重みがどう変わったかを「タスクベクトル」として捉え、それを足したり引いたりするだけで、複数のモデルの能力を1つに融合できるという考え方です。Task Arithmeticはモデルマージ分野の1手法ですが、シンプルながら応用の幅が広く、モデルマージという分野全体の可能性を感じました。

本記事では、Task Arithmeticを起点に、TIES-merging・DAREといった周辺手法や、Pythonで実行可能なツール「mergekit」を紹介しつつ、ファインチューニングが広く普及した未来にどのようなエコシステムが生まれるかを調査してみました。


TL;DR

  • Task Arithmetic は、ファインチューニング前後の重みの差分「タスクベクトル」を足し引きするだけで、データ公開不要でモデルの能力を合成・除去できる手法(ICLR 2023)
  • タスクベクトルを組み合わせることで、学習データが存在しない複合タスクを近似できる可能性がある
  • モデルマージはアンサンブルと異なり推論コストが増えず、1つのモデルとして動く
  • TIES-merging(NeurIPS 2023)や DARE などの後続手法が、マージ時の干渉・ノイズ問題を改善している
  • ツール mergekit を使えばYAML設定を書くだけで主要な手法を試せる
  • 国内では NHK の研究(言語処理学会 2025)で、英語由来のタスクベクトルを日本語モデルへ転移する有効性が確認されている

1. 背景:ファインチューニング時代の課題感

「データを渡せない」という壁

LLMをある特定のタスクに特化させたいとき、良く採用される方法はコンテキストエンジニアリングやRAG、ファインチューニングです。その中でファインチューニングについては、LoRAのような軽量手法の登場で、以前と比べてはるかに手軽にモデルを特化させられるようになりました。

しかし、ファインチューニングした能力を他者と共有しようとすると、途端に壁にぶつかります。「どんなデータで学習させたか」を公開したくないケースが多いからです。医療・法律・社内業務など、実用的なドメインほど学習データは機密性が高く、「データをオープンにすれば再現できるのに」という状況が生まれやすいです。

モデル共有の現状

現在のLLMコミュニティでは、HuggingFace Hub にモデルをアップロードして公開するという文化が根付いています。フルモデル(モデルのパラメータ全て)を丸ごと公開する方法が一般的ですが、数十GBに達する場合も多く、ストレージや帯域の問題が生じます。

モデルを共有する主な方法を整理すると、次のようになります。

共有方法 データ公開の要否 コスト 再現性
フルモデルの公開 不要 ストレージ大(数GB〜数百GB)
データセットの公開 必要 再学習コストが発生
LoRAアダプタの公開 不要 軽量(数十〜数百MB) 高(ベースモデルが同じなら)
タスクベクトルの公開 不要 非常に軽量 条件付き

タスクベクトルという考え方は、この「データを出さずに、軽量な差分だけ共有する」という課題に対する解決策の1つになります。


2. Task Arithmetic(タスクベクトル)とは何か

当該手法のコンセプト:重みの差分をタスクベクトルとして扱う

2023年にILCR 2023で発表された論文「Editing Models with Task Arithmetic」(Ilharco et al., 2023)が提案した手法です。

考え方は非常にシンプルです。あるタスクでファインチューニングしたモデルの重みを θ_ft、学習前のベースモデルの重みを θ_pre とすると、その差分:

τ = θ_ft - θ_pre

これを「タスクベクトル」と呼びます。τ はそのタスクの能力がどの方向に、どれだけ増えたかを表すベクトルです。

そして重要なのは、このタスクベクトルを算術的に操作できるという点です。

タスクベクトルの3つの操作

操作 意味
加算(能力の合成) θ_new = θ_pre + τ_A + τ_B タスクAとBの能力を1つのモデルに融合
減算(能力の除去) θ_new = θ_pre - τ_toxic 毒性応答などの「望ましくない能力」を削除
スケーリング(強度調整) θ_new = θ_pre + λ · τ 特定タスクへの特化度合いを調整

λ(スケーリング係数)を大きくするほどそのタスクへの特化度が増し、小さくするほどベースモデルに近い汎用性が保たれます。

論文の概要

  • タイトル: Editing Models with Task Arithmetic
  • 著者: Gabriel Ilharco, Marco Tulio Ribeiro, Mitchell Wortsman, Suchin Gururangan, Ludwig Schmidt, Hannaneh Hajishirzi, Ali Farhadi
  • arXiv: 2212.04089
  • 学会: ICLR 2023

論文では、画像分類や自然言語処理の複数タスクで実験が行われ、タスクベクトルの加算によるマルチタスク化がそれぞれのタスクを個別にファインチューニングした場合の精度に近い性能を出せることが示されました。また、モデル間のタスクベクトルの「類推関係」(Aに対するBの関係はCに対するDの関係、という形)が成立するという興味深い性質も報告されています。


3. タスクベクトルで何ができるか

マルチタスクモデルの構築

複数のタスクに特化したモデルを個別にファインチューニングし、それぞれのタスクベクトルをベースモデルに加算すれば、1つのモデルで複数タスクをこなせるマルチタスクモデルが完成します。

追加の学習コストはゼロです。タスクベクトルの足し算はただの行列演算なので、GPUも推論時間の増加も不要です。

学習データがないタスクをタスクベクトルの組み合わせで近似する

タスクベクトルの加算が特に威力を発揮するのは、欲しい能力に対応する学習データが手元にないときです。

たとえば「医療文書を日本語で要約するモデル」が欲しいとします。このためには、医療知識・日本語・要約という3つの能力が必要ですが、3つが揃ったデータセットを一から揃えるのはコストがかかります。

ここでタスクベクトルを組み合わせる発想が使えます。

θ_new = θ_pre
      + τ_医療     (医療文書で学習したタスクベクトル)
      + τ_日本語   (日本語テキストで学習したタスクベクトル)
      + τ_要約     (要約タスクで学習したタスクベクトル)

「医療×日本語×要約」の学習データは不要で、それぞれの能力を独立に獲得したタスクベクトルを足し合わせるだけです。もちろん完全な再現は難しい場合もありますが、個別タスクのデータが揃っていれば、ゼロからファインチューニングするよりも手軽な出発点になります。

以下に、同じ考え方が応用できる例を示します。

目標とする能力 データ収集の難しさ 組み合わせで代替できるタスクベクトル
医療文書の日本語要約 専門家の監修が必要 医療ドメイン + 日本語 + 要約
日本語でのコード解説 日本語×コードの対訳が必要 コード生成・理解 + 日本語
法律文書の平易な言い換え 弁護士監修が必要 法律ドメイン + 言い換え・平易化
社内ナレッジを使ったQ&A対話 社内データは公開不可 対話スタイル + ドメイン知識(社内タスクベクトルは非公開のまま)

最後の例がとくに重要で、社内専用のタスクベクトルを「非公開」のまま保ちながら、汎用的な対話スタイルのタスクベクトル(公開されているもの)と組み合わせるということが将来的には可能になるかもしれません。データは出さず、能力だけを合成するという発想です。

ただし、この組み合わせの有効性はタスク同士の相性(干渉の少なさ)に依存します。無関係なタスクベクトルを何でも足せばよいわけではなく、後述するTIES-MergingやDAREのような干渉を抑える手法を組み合わせることが実用上は重要になります。

望ましくない能力の除去

タスクベクトルの「減算」を使うと、モデルから特定の能力を削ることができます。論文では、有害な発言をするようにファインチューニングされたモデルのタスクベクトルをベースモデルから引くことで、毒性を低減できることが示されています。安全性フィルタリングへの応用として活用できる性質です。

データ非公開でも能力を共有する

本記事の主要テーマです。タスクベクトル τ は差分のベクトルデータにすぎないため、学習データを一切公開せずに能力を共有できます。受け取った側は θ_new = θ_pre + τ の計算をするだけで、その能力を自分のベースモデルに組み込めます。

企業や個人が特化したタスクベクトルを公開し、他者がそれを組み合わせて使うというエコシステムが、将来的には想定できます。

LoRAとの組み合わせ

LoRAは、ファインチューニングの際にフルパラメータを更新する代わりに、低ランク行列の積として重み更新を近似する手法です。LoRAアダプタの重み自体が「ベースモデルからの差分」に相当する構造を持っているため、タスクベクトルの考え方と非常に相性が良いです。

実際、LoRAアダプタをそのままタスクベクトルとして扱ってマージする研究や実装も登場しています。計算コストの小さいLoRAのアダプタを複数組み合わせることで、軽量かつ柔軟なモデル構築が可能になります。


4. 国内研究事例:日本語平易化への Task Arithmetic の応用(言語処理学会 2025)

Task Arithmeticは海外の研究が先行していますが、国内でも実タスクへの応用研究が進んでいます。言語処理学会 第31回年次大会(2025年3月)で発表された「日本語平易化への Task Arithmetic の応用とその検証」(小西, 2025, NHK)では、日本語の平易化コーパスが量・質ともに不十分という課題に対し、英語コーパスで学習した平易化のタスクベクトル(Simp Vector)を、日本語継続事前学習済みモデル(Swallow)に加算するアプローチが検討されました。実験では BLEU・SARI の両指標でスコアの向上が確認され、日本語の学習データなしに英語由来の能力を日本語モデルへ転移できる可能性が示されています。一方、スケールファクター λ が大きすぎると出力が破綻する傾向も観察されており、転移強度の調整が実用上の課題として残っています。


5. モデルアンサンブルとモデルマージ、何が違うのか

「複数のモデルを組み合わせる」というと、モデルアンサンブルという方法が従来はメジャーでした。このモデルアンサンブルとモデルマージの違いは以下のようになります。

モデルアンサンブルとは

アンサンブルは推論時に複数のモデルを並べて動かし、それぞれの出力を統合する手法です。代表的な方法として以下があります。

  • Voting(多数決): 各モデルの出力ラベルで多数決を取る
  • Averaging(平均): 各モデルの予測確率を平均する
  • Stacking: 複数モデルの出力を入力にして、別のモデル(メタモデル)が最終判断する

アンサンブルは精度向上に効果的ですが、「推論のたびにN個のモデルを全て動かす」という点で、推論コストがN倍になるという根本的な制約があります。

モデルマージとの本質的な違い

モデルマージは、複数モデルの重みを事前に統合してしまい、1つのモデルを作る手法です。

比較軸 モデルアンサンブル モデルマージ
重みの統合タイミング 推論時(統合しない) 事前(1つのモデルに統合)
推論コスト N倍(モデル数分) 1倍(シングルモデルと同じ)
デプロイの複雑さ 複数モデルを管理 シングルモデルとして配置
追加学習の要否 不要 不要(マージのみ)
精度の特性 一般に高い(異なるモデルを組み合わせた時の多様性が効く) マージ手法・組み合わせ次第

モデルマージの最大の利点は、推論コストが増えない点です。アンサンブルのような精度向上効果を、シングルモデルの推論コストで実現できる可能性があります。

なぜ今モデルマージが注目されているのか

2023〜2024年にかけて、モデルマージはLLMコミュニティで急速に注目を集めました。背景にはいくつかの要因があります。

  1. 高性能なオープンソースLLMの増加: Meta の Llama や Mistral AI の Mistral-7B など、高品質なベースモデルが次々と公開されたことで、同じベースモデルをもとにした多様なファインチューニングモデルが大量に生まれました。共通のベースがあれば、重みの統合が成立しやすくなります。

  2. OpenLLM Leaderboardでの実績: HuggingFace の Open LLM Leaderboard において、2023〜2024年頃に複数のマージモデルが上位を占める現象が起きました。追加学習なしに既存モデルを組み合わせるだけで、個々のモデルを上回る性能が出ることが広く認知されるきっかけになりました。

  3. 学習コストの節約: ファインチューニングには計算リソースが必要ですが、マージは行列演算のみで追加学習が不要です。複数の特化モデルを手に入れさえすれば、マルチタスクモデルがほぼコストゼロで作れます。

  4. ツールの整備: 後述する mergekit のような使いやすいツールが登場したことで、コミュニティへの普及が加速しました。


6. モデルマージ技術の系譜

Task Arithmeticをきっかけに、様々なモデルマージ手法が生まれています。時系列と特徴を整理します。

手法 発表年 学会等 核心アイデア mergekit対応
Naive Merge / Model Soups 2022年 ICML 2022 重みの単純平均
Task Arithmetic 2023年 ICLR 2023 タスクベクトルの算術演算
TIES-Merging 2023年 NeurIPS 2023 符号の衝突を3段階で解消
DARE 2023年 arXiv(ICML 2024) ランダムドロップ+リスケール
SLERP 実装コミュニティ発 球面線形補間による滑らかなマージ

Naive Merge(単純平均)とその限界

最も単純な方法は、複数モデルの重みを単純に平均する「Naive Merge」です。「Model Soups」(Wortsman et al., 2022, ICML 2022)として論文化された手法も、本質的にはファインチューニング済みモデルの重みを平均する考え方です。

ただし、単純平均には限界があります。タスクAとタスクBのモデルで特定のパラメータの符号が逆(一方が正、もう一方が負)だった場合、平均を取ると互いに打ち消し合い、どちらのタスクにも効果がない重みになってしまいます。この「干渉問題」を解決するために、後続の手法が生まれました。

TIES-Merging:符号の衝突を解消する

TIES-Merging: Resolving Interference When Merging Models」(Yadav et al., NeurIPS 2023)は、この干渉問題に正面から取り組んだ手法です。

3つのステップからなります:

  1. Trim(トリミング): 各モデルのタスクベクトルから、絶対値が小さい(=影響が少ない)パラメータを0にリセットします。ノイズを落とすイメージです。
  2. Elect Sign(符号選出): モデル間でパラメータの符号が異なる場合、「どちらの符号を採用するか」を、合計の移動量が大きい符号を選ぶ形で決定します。
  3. Disjoint Merge(分離マージ): 選出された符号と一致するパラメータだけを平均します。符号が逆のパラメータは無視することで、打ち消し合いを防ぎます。

Task Arithmeticの単純な加算と比べ、TIES-MergingはパラメータのTrim(トリミング)とSign(符号)の整合を取るため、複数モデルをマージしたときの性能劣化が小さくなる傾向があります。

DARE:スパース化でノイズを落とす

Language Models are Super Mario: Absorbing Abilities from Homologous Models as a Free Lunch」(Yu et al., 2023)は、DAREと呼ばれる手法を提案しました。

アイデアはシンプルです。タスクベクトルのパラメータをランダムに確率 p でドロップ(ゼロに設定)し、残ったパラメータを 1/(1-p) 倍にリスケールします。論文では、90〜99%のデルタパラメータをランダムに削除しても性能を維持できることが示されました。

これはファインチューニング済みモデルのデルタパラメータの多くが冗長(あってもなくても性能に大差ない)であることを示唆しており、マージ前のノイズ除去として活用できます。DAREはTIES-Mergingと組み合わせた「DARE-TIES」としても使われます。

SLERP:球面線形補間

SLERPは元々コンピュータグラフィックスで四元数の回転補間に使われてきた手法(Shoemake, 1985)を、モデルマージに応用したものです。2つのモデルを高次元空間上の点として捉え、線形補間ではなく超球面上の最短経路で補間することで、中間点でのベクトルの大きさが減少しにくいという特性があります。

ただし、SLERPのモデルマージ応用は学術論文由来ではなく、mergekitなどの実装コミュニティが創案した技術です。HuggingFaceブログや mergekit の実装を通じてコミュニティに広まりました。2モデル間の補間に特化していて、tという係数(0〜1)を動かすことで2つのモデルの中間的な性格を連続的に変化させられます。


7. mergekitで試す

mergekitとは

mergekit は、Arcee AI が開発するオープンソースのモデルマージツールキットです。GitHubスター数は7,000以上(2024年時点)あり、LLMコミュニティで広く使われています。

対応する主なモデルマージ手法は以下の通りです:Task Arithmetic、TIES-Merging、DARE(DARE-TIES / DARE-Linear)、SLERP、Linear / Naive Merge、そして Arcee AI 独自の手法など15種類以上に対応しています。

LlamaやMistralをはじめとする多くのアーキテクチャに対応しており、十分なVRAMがあればGPUで、なければCPUでも動作します。また、HuggingFace Spacesには公式のデモ(mergekit-gui)が公開されており、YAMLの設定をアップロードするだけでマージを実行しHuggingFaceにアップロードまで行えます。

YAML設定例(TIES-mergingの場合)

mergekitの設定はYAMLで記述します。以下は2つのモデルをTIES-Mergingでマージする場合の例です。

merge_method: ties

base_model: mistralai/Mistral-7B-v0.1

models:
  - model: model-a/mistral-7b-finetuned-task-a
    parameters:
      weight: 1.0
      density: 0.5   # パラメータの保持率(TrimステップのK%に相当)
  - model: model-b/mistral-7b-finetuned-task-b
    parameters:
      weight: 1.0
      density: 0.5

parameters:
  normalize: true   # 符号選出後の正規化
  int8_mask: true   # メモリ節約

dtype: bfloat16
  • merge_method: 使用するマージ手法(ties / dare_ties / slerp / linear など)
  • base_model: タスクベクトルを計算する基準となるベースモデル
  • density: TIES-Mergingの「Trim」ステップで保持するパラメータの割合(0.5なら上位50%を保持)
  • weight: 各モデルのタスクベクトルの重み付け

このYAMLを用意して mergekit-yaml config.yaml ./output を実行すると、マージ済みモデルが ./output に保存されます。


8. 考察:タスクベクトルが普及した未来

計算コスト低下がもたらす変化

LoRAの登場でファインチューニングのコストは大幅に下がりました。今後さらに計算リソースが安価になり、個人・中小企業でも気軽にLLMをファインチューニングできる時代が来た場合、次のような変化が想定されます。

  • 特定のタスクに特化したモデルが爆発的に増える
  • HuggingFace Hubへのタスクベクトル・LoRAアダプタの公開数が急増する
  • コミュニティが自分たちでタスクベクトルを組み合わせてマルチタスクモデルを作り始める

すでにその萌芽は見えます。2024年時点でHuggingFace Hub上にはLoRAアダプタが大量に公開されており、マージモデルのコレクションも増え続けています。

「モデルのデルタ」を共有するエコシステム

LoRAアダプタの公開がすでに行われていることを考えると、将来的には「タスクベクトルのマーケットプレイス」のような仕組みが生まれる可能性もあります。

  • ある企業がカスタマーサポート特化のタスクベクトルを公開する
  • 別の企業がコード生成特化のタスクベクトルを公開する
  • ユーザーが自分のベースモデルに好みのタスクベクトルを足し合わせてカスタムモデルを作る

データを一切出さずに、能力だけを共有・組み合わせられるという点が、このエコシステムの核心です。

懸念点

一方で、いくつかの課題もあります。

品質保証の難しさ: タスクベクトルやマージの組み合わせが増えると、どの組み合わせが安全で効果的かを評価するコストが増大します。マージモデルの品質評価は現時点でもベンチマークに依存することが多く、実運用での挙動は試してみないとわからない部分があります。

著作権・ライセンスの問題: ベースモデルのライセンスによっては、そこから派生したタスクベクトルの公開・商用利用が制限される場合があります。タスクベクトルが「ベースモデルの派生物」に当たるかどうかの法的解釈はまだ定まっていません。

有害な能力の加算リスク: タスクベクトルは「能力の足し算・引き算」です。有害なコンテンツを生成するように学習されたモデルのタスクベクトルを加算することで、通常は安全なモデルに有害な能力を注入できてしまうリスクがあります。


9. まとめ

本記事のポイントを整理します。

  • Task Arithmetic は、ファインチューニング前後の重みの差分「タスクベクトル」を算術的に操作することで、データ公開不要で能力の共有・合成・除去を実現する手法(ICLR 2023)
  • タスクベクトルの加算でマルチタスク化、減算で能力除去、スケーリングで特化度調整ができる
  • 欲しい能力に対応する学習データがない場合でも、複数のタスクベクトルを組み合わせて近似できる可能性がある(例:医療×日本語×要約を別々に用意して合算)
  • TIES-Merging(NeurIPS 2023)はTrim・Elect Sign・Disjoint Mergeの3ステップで符号の衝突を解消し、マージ精度を改善する
  • DARE は多くのデルタパラメータが冗長であることを利用し、ランダムドロップ+リスケールでノイズを除去する
  • モデルアンサンブルとの最大の違いは「推論コストが増えない」点。アンサンブルはN倍のコストがかかるが、マージは1つのモデルとして動く
  • モデルマージが注目された背景は、高性能OSSモデルの増加・OpenLLM Leaderboardでの実績・学習コストゼロというメリット・mergekitなどのツール整備
  • mergekit を使えばYAMLの設定を書くだけで主要なマージ手法を試せる
  • 国内でも応用研究が進んでおり、NHKの研究(言語処理学会 2025)では英語の平易化能力のタスクベクトルを日本語モデルに転移することで、日本語の平易化コーパスなしに平易化性能の向上が確認された
  • ファインチューニングが普及した未来では、タスクベクトルを気軽に共有・組み合わせるエコシステムが生まれる可能性がある一方、品質保証・ライセンス・安全性の課題も残る

まずは mergekit を手元の環境で試してみるのが、モデルマージを体感する最短ルートだと思います。


参考文献

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?