# Polytropon

[Polytropon](https://hf.co/papers/2202.13914)は、その「インベントリ」に多数の異なるLoRAアダプターを持つマルチタスクモデルです。このモデルは、ルーティング関数を用いてインベントリから正しいアダプターの組み合わせを学習し、特定のタスクに対して最適なモジュールのサブセットを選択します。PEFTは、Polytropon用の[Multi-Head Adapter Routing (MHR)](https://hf.co/papers/2211.03831)もサポートしています。MHRは、アダプターヘッドをより細粒度で組み合わせることで、ルーティング関数を構築・改善します。アダプターヘッドは互いに重複しないブロックに分割され、それぞれに対して異なるルーティング関数が学習されるため、より高い表現力が得られます。

論文の抄録は以下の通りです:

*モジュール化された設計は、ニューラルモデルが知識の異なる側面を分離し再結合することを促し、新しいタスクへのより体系的な汎化を可能にします。本研究では、各タスクが（潜在的に小さい）インベントリからの潜在離散スキル（latent discrete skills）の部分集合に関連付けられていると仮定します。その際、スキルはパラメータ効率の高い（スパース / 低ランク）モデルのパラメータ化に対応します。これらとタスク-スキル割当行列を同時に学習することで、各タスクのネットワークは、アクティブなスキルのパラメータの平均としてインスタンス化されます。タスク間でスキルが非自明なソフトパーティションを形成することを好むよう、インドアン・ビュッフェ・プロセス（Indian Buffet Process）の事前分布や2段階の学習率などの一連の誘導バイアスを実験的に適用しました。潜在スキルモデルは、主に以下の2つの設定で評価しました。1) BabyAIプラットフォームの8レベルにおける、グラウンデッドな指示追従のためのマルチタスク強化学習。2) CrossFit（160のNLPタスクで構成されるベンチマーク）における、事前学習済みテキスト-テキスト生成モデルのファインショット適応。完全共有、タスク固有、または条件付き生成のパラメータを持つベースライン（タスク間で知識が絡み合っている場合）と比較して、ネットワークのモジュール化された設計は、強化学習におけるサンプル効率と、教師あり学習におけるファインショット汎化を大幅に向上させることがわかりました。さらに、離散スキルが明示的なタスク階層を生成するため、解釈可能性にどのように寄与するかを示しました。*

論文の抄録は以下の通りです:

*タスク横断汎化のためのパラメータ効率型ファインチューニング（PEFT）は、テストタスクへの少ショット適応の前に、マルチタスク学習セット上でアダプタを事前学習することから成り立っています。Polytropon [Ponti et al., 2023]（Poly）は、事前学習と少ショット適応の両方の段階で、各タスクに対して（可変サイズの）アダプタのサブセットを選択するルーティング関数とともに、アダプタのインベントリを共同で学習します。本論文では、アダプタルーティングがその成功において果たす役割を調査し、その知見に基づいて新しいバリアントを設計します。まず、より細粒度のルーティングにより表現力が向上するという直観に基づき、MHR（Multi-Head Routing）を提案します。MHRはアダプタパラメータのサブセットを組み合わせ、同程度のパラメータ予算のもとでPolyを上回る性能を発揮します。また、アダプタではなくルーティング関数のみファインチューニングを行うことで（MHR-z）、極端なパラメータ効率のもとで競争力のある性能を実現します。第二に、Poly/MHRの性能は、アダプタの再構成や局所適応を促進するモジュール化された帰納的バイアス（以前に仮定されていたもの）によるものではなく、より良いマルチタスク最適化の結果であることが判明しました。実際、MHRは他のどの手法よりもタスク間の勾配整合性が高いことが示されました。これはルーティングがマルチタスク事前学習の段階でのみ重要であることを意味するため、少ショット適応時に事前学習済みアダプタの平均をファインチューニングし、ルーティングを破棄するMHR-muを提案します。これにより、MHR-muは単一アダプタのファインチューニングにおける有効な手法として確立されます。*

まず学習なしでルーティングを試したい場合は、[Arrow LoRA バリアント](./lora#Arrow)を確認できます。

# API

## PolyConfig[[peft.PolyConfig]]

#### peft.PolyConfig[[peft.PolyConfig]]

```python
peft.PolyConfig(task_type: Optional[Union[str, TaskType]] = None, peft_type: Optional[Union[str, PeftType]] = None, auto_mapping: Optional[dict] = None, peft_version: Optional[str] = None, base_model_name_or_path: Optional[str] = None, revision: Optional[str] = None, inference_mode: bool = False, r: int = 8, target_modules: Optional[Union[list[str], str]] = None, exclude_modules: Optional[Union[list[str], str]] = None, modules_to_save: Optional[list[str]] = None, init_weights: bool = True, poly_type: Literal['poly'] = 'poly', n_tasks: int = 1, n_skills: int = 4, n_splits: int = 1)
```

[ソース](https://github.com/huggingface/peft/blob/main/src/peft/tuners/poly/config.py#L25)

**パラメータ:**

r (`int`) : Polyの各LoraのAttention次元。

target_modules (`Union[List[str],str]`) : Poly を適用するモジュールの名前。

exclude_modules (`Optional[Union[List[str], str]]`) : アダプタを適用しないモジュールの名前。文字列を渡す場合、正規表現によるマッチングが行われます。文字列のリストを渡す場合、完全一致が行われるか、モジュールの名前が渡された文字列のいずれかで終わるかがチェックされます。

modules_to_save (`List[str]`) : Poly層を除き、最終的なチェックポイントに保存されるように学習可能に設定されるモジュールのリスト。

init_weights (bool) : Poly重みの初期化を実行するかどうか。

poly_type (`Literal["poly"]`) : 使用する Poly モジュールのバリアントです。現在サポートされているのは "poly" のみです。

n_tasks (`int`) : マルチタスクシナリオにおけるタスクの数。

n_skills (`int`) : 各 Poly レイヤーあたりのスキル (LoRA) の数。

n_splits (`int`) : Poly層内の各LoRAにおける分割数。1より大きい値は、Multi-Head Routing (MHR) が使用されていることを示します。

これは[PolyModel](/docs/peft/main/ja/package_reference/poly#peft.PolyModel)の設定を保存するための設定クラスです。
- [ポリトロポン（Poly）](https://huggingface.co/papers/2202.13914)
- [マルチヘッドルーティング (MHR)](https://huggingface.co/papers/2211.03831)

## PolyModel[[peft.PolyModel]]

#### peft.PolyModel[[peft.PolyModel]]

```python
peft.PolyModel(model, peft_config: Union[PeftConfig, dict[str, PeftConfig]], adapter_name: str, low_cpu_mem_usage: bool = False, state_dict: Optional[dict[str, torch.Tensor]] = None)
```

[ソース](https://github.com/huggingface/peft/blob/main/src/peft/tuners/poly/model.py#L28)