少量データによる人格再現におけるLoRA/SFT Configのパラメータについて

Posted at 2026-05-09

概要

本記事は、100件程度の少量データを使用した人格再現の検証結果として見えた各パラメータの役割とモデルに与える影響をまとめたものである。

検証概要

各パラメータの役割に入る前に、検証に関しての概要とパラメータ調整で解決対象となった問題点に関して説明する。
本検証ではパラメータチューニング、情報のリサーチの多くでGPT-5.4およびGPT-5.5を使用している。（記事は自分で書いてます）

検証前提

使用モデル
- ELYZA-japanese-Llama-2-7b-instruct
- Llama-3-Swallow-8B-Instruct-v0.1（検証の最後で入れ替え）
使用環境
- Google Colaboratory
- H100、G3を使用
使用データ
- 100件ほどの会話データ
- 対象が会話の起点になる場合が多く、一部補間を実施
初期パラメータにおける問題点
- 最初に設定したパラメータに関しては後述する。
- 最初のパラメータで学習した結果以下のような問題が発生
  - データ量が少なく、パターンが少ないためLoRAがかなり弱い傾向がある
  - 推論時のパラメータを少しでもずらすと推論が大きく崩れる
  - ちょうどいい推論パラメータがほぼなく、"ぽい何か"にしかならない
- 以降は、この少量データでどうにか解決しようと試行錯誤することになる

初期パラメータ

初期パラメータに関しては以下の2つの記事を参考とした(推論パラメータはそのたびに試行錯誤したため省略する）
- https://zenn.dev/openmose/articles/da584f45198047
- https://wandb.ai/npaka3/qlora-zundamon/reports/Elyza-7B-QLoRA---Vmlldzo2MDk3MzYw
Lora config (prft==0.19.1)

peft_config = LoraConfig(
  r=8,
  lora_alpha=16,
  lora_dropout=0.05,
  bias="none",
  task_type="CAUSAL_LM",
  target_modules=["q_proj", "v_proj", "o_proj"],
)

SFTConfig (trl==1.3.0)

training_arguments = SFTConfig( 
    output_dir="Set Your Dir",
    
    bf16=True,
    num_train_epochs=5,
    max_steps=-1,

    per_device_train_batch_size=4,
    gradient_accumulation_steps=4,

    optim="paged_adamw_32bit",
    learning_rate=5e-5,
    lr_scheduler_type="cosine",
    warmup_ratio=0.05,
    max_grad_norm=0.3,
    weight_decay=0.01,

    save_steps=50,
    logging_steps=10,
    report_to="wandb",

    dataset_text_field="text",
    max_length=512,
    packing=False,
    group_by_length=True,
    dataset_num_proc=2,
)

各パラメータによる影響

以上の検証前提を踏まえて、試行錯誤をした結果としていじったパラメータに関しては、初期値からの前後の範囲でいじるとモデルにどういった影響が出るかをある程度見ることができたため以下にまとめる。（いじってないパラメータは言及しない）

LoraConfig

パラメータ名	公式による説明	一般的な影響	今回の検証での影響
lora_dropout	LoRA layers に対する dropout 確率。 LoRA 側の更新に正則化をかける。	値を大きくした場合、LoRA経路にかかるDropOutの確率が高くなり、更新はより抑制・正則化されやすい。値を小さくすると、LoRAの更新がより素直に通りやすい。	今回の検証では、0.05~0.1の間で変更を実施した。 0.05で実施した場合には、再現したい対象「ぽさ」が比較的残るが、推論の際に応答が崩れやすくなる傾向が見られた。 0.1に近づけてくに従って、崩れは抑えられ安定はするが、同時に再現したい対象の新も薄くなる傾向が見られた。
target_modules	LoRA を差し込む対象モジュールを指定する。	対象を増やすほど、LoRA が触る層の範囲と学習対象パラメータは増え、特に今回のような少量データの場合は過学習を起こすリスクが高くなる。また、対象モジュールを増やすほどLoRA自体のファイルサイズも大きくなる。	今回の検証では、['q_proj','v_proj','o_proj'] と['q_proj','k_proj','v_proj','o_proj'] の2つのパターンを検証。結果的に、このパラメータの変更によって推論時の応答に対する大きな影響は見られなかった。

SFTConfig

パラメータ名	公式による説明	一般的な影響	今回の検証での影響
learning_rate	学習率。 LoRAのようなアダプタ学習の場合は、更新するパラメータが少ない分学習を進めるために比較的大きな値に設定することが多い。	値を大きくすると、1stepあたりの更新幅が大きくなる。値を小さくすると、更新幅が小さくなる。	今回の検証では、3e-5、5e-5の二つのパターンで検証を実施した。 3e-5で実施した場合には、推論時のLoRAの影響が明確に弱く、応答時にベースモデルの影響が大きく見られた。 5e-5で実施した場合には、応答にLoRAによる影響が乗っているのが見られた。
num_train_epochs	データ全体を何周学習するかを決める。max_stepsが指定されている場合はそちらが優先される。	値を大きくすると、同じデータに対しての反復回数が多くなる。値を小さくすると、反復回数は減る。	今回の検証では、epoch数を5と7の二つのパターンで実施した。 epoch数5の場合は、そうれなりに応答は成立していた一方で、epoch数を7に増やした場合には、文体の混線や一人称の崩れなどが見られたため、今回のようなデータ数では一定上増やすと対象の影響が乗りすぎて壊れる（過学習気味）ようである。

総評

データ量が少量であったため、操作したパラメータ数は少ないものの7~8B規模のモデルで少量データでLoRAを使用したチューニングをする場合には、少しでも数値をいじると大きく崩れるためかなりシビアであることがよくわかった。
また、やはり少量データによるチューニングとプロンプトエンジニアリングだけでは"口調をまねた何か"にしかならず、パーソナリティの付与には程遠い。
データ量は増やせないため、別のアプローチを検討したい。

Appendix

他のパラメータに関してもChatGPTでまとめていたので、以下に記述しておく
ここでは推論時のパラメータに関しても記載する。

LoraConfig

パラメータ名	公式による説明	一般的な影響
r	LoRA の rank。低ランク行列の次元であり、LoRA 側の表現容量と学習パラメータ量に関わる。	値を大きくすると、LoRA 側の次元と学習パラメータ量が増える。値を小さくすると、表現容量はより小さくなる。
lora_alpha	LoRAのscaling係数。通常のLoRAでは概ねlora_alpha/rの形で有効スケールに反映され、RSLoRAでは lora_alpha/sqrt(r)になる。	値を大きくすると、LoRA 更新の有効スケールは大きくなりやすい。値を小さくすると、LoRA 更新の効きは弱くなりやすい。
bias	どのbiasを更新対象にするかを指定する。'all'や'lora_only'を使うと、アダプタ無効化後もベースモデルと同一出力には戻らない。	'none'はbiasを触らず、'all'/'lora_only' はbias側にも更新を広げる
task_type	PEFTがどのタスク種別としてモデルを扱うかを指定する。今回のCAUSAL_LMはcausal language modeling用。	品質を直接上下する『つまみ』というより、追加したパーツ（アダプタ）にどういう役割を与えて機能させるか、という動作ルールを決める設定。

SFTConfig

パラメータ名	公式による説明	一般的な影響
per_device_train_batch_size	1デバイスあたりのバッチサイズ。gradient_accumulation_stepsと合わせて実効バッチサイズを形作る。	値を大きくすると、1step で処理するサンプル数が増え、メモリ消費も増えやすい。固定データ量では1epoch あたりの更新回数は減りやすい。値を小さくするとその逆。
gradient_accumulation_steps	勾配を何step分ためてからoptimizerを更新するか。実効バッチサイズと更新頻度に影響する。	値を大きくすると、per-device batchを保ったまま実効バッチサイズを大きくできる一方、optimizer更新はより間引かれる。値を小さくすると更新はより頻繁になる。
bf16	bfloat16混合精度を使う設定。主にメモリ使用量と学習速度に関わる。	Trueにすると、対応ハードウェア上でメモリ削減や速度改善が見込める。 Falseにすると、より高精度だが重い設定へ寄る。
optim	使用するオプティマイザを指定する。更新則とメモリ使用量に影響する。	より軽量な optimizer はメモリ効率を上げやすく、optimizer の種類を変えると更新の癖も変わる。
lr_scheduler_type	学習率スケジューラの種類。学習率の時間変化の仕方を制御する。	一定のままに近いもの、途中で減衰するもの、周期的に変化するものなど、学習率の時間推移が変わる。
warmup_ratio	全training stepsのうち、学習率を立ち上げるwarmup区間の比率。	値を大きくすると、低学習率で立ち上げる期間が長くなる。値を小さくすると、目標学習率へ早く到達する。
max_grad_norm	勾配クリッピングの上限。勾配爆発を抑え、学習安定性に寄与する。	値を大きくすると、クリッピングは緩くなる。値を小さくすると、より強く勾配を制限する。
weight_decay	biasとLayerNormを除く重みに適用されるweight decay。	値を大きくすると、重みにかかる減衰・正則化が強くなる。値を小さくすると、減衰は弱くなる。
weight_decay	biasとLayerNormを除く重みに適用されるweight decay。	値を大きくすると、重みにかかる減衰・正則化が強くなる。値を小さくすると、減衰は弱くなる。
max_length	SFTで扱う最大シーケンス長。	値を大きくすると、より長い文脈を保持できる一方、計算量とメモリ消費は増えやすい。値を小さくすると、長いサンプルは切り捨てられやすい。
packing	短いサンプルを1シーケンスに詰めるかどうか。	Trueにすると、短いサンプルを詰めて計算効率を上げやすい。 Falseにすると、サンプル境界をそのまま保ちやすい。
train_sampling_strategy/group_by_length	長さでまとめてサンプリングするかなど、学習時のサンプル順序・グルーピングを制御する。	group_by_length系を使うと、近い長さ同士が集まり paddingを減らしやすい。ランダム寄りにすると、順序のばらつきは増える。

推論パラメータ

パラメータ名	公式による説明	一般的な影響
max_new_tokens	入力プロンプト長を除いた、新規生成トークン数の上限。	値を大きくすると、より長く話せるが、脱線・補完・長い説明へ流れ込む余地も増える。値を小さくすると、短く打ち切られやすい。
temperature	次トークン確率分布をどれだけ平坦化／尖鋭化するかを決める。低いほど決定的、高いほどランダムになる。	値を大きくすると候補分布が平坦化し、出力の自由度が上がる。値を小さくすると高確率語へ寄りやすく、より決定的になる。
top_p	累積確率がpに達するまでの語彙候補集合にサンプリングを制限する。低いほど候補が絞られる。	値を大きくすると、候補集合が広がり自由度が上がる。値を小さくすると、候補が絞られ保守的になる。
repetition_penalty	既出トークンに対するペナルティで、繰り返し生成を抑える方向に働く。	値を大きくすると、既出トークンの再使用がより抑えられる。値を 1.0 に近づけると、抑制は弱くなる。
do_sample	サンプリングを使うかどうか。Falseの場合は greedy/beam系のより決定的な生成になり、Trueの場合は確率分布からのサンプリングになる。	Trueにすると、temperatureやtop_pなどのサンプリング系パラメータが効く。 Falseにすると、出力はより決定的になりやすい。

参考ドキュメント

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up