ファインチューニングに必要な容量を与えましょう。

キャンペーンを正当化する成果を定義します。

観察可能なタスクを定義します。チケットを分類する、フィールドを抽出する、回答形式を守るなどです。まず参照となる指示を練り、その出力を保存します。プロンプトの変更で十分なら、それは比較対象の候補になります。この対照群がなければ、ファインチューニングによる向上とされるものは、単により良い言い回しや回答の別の処理によるものである可能性があります。

フォーマットの妥当性と内容の正確性は分けて考えましょう。パーサーを通過するJSONオブジェクトでも、誤ったカテゴリを含んでいる可能性があります。保持すべき挙動、たとえば欠損フィールドの処理や稀なクラスの扱いを加えます。ランク、学習率、ステップ数を選ぶ前に、受け入れ基準と却下理由を定めましょう。

判断の根拠となるデータを選びます。

同じ会話、同じドキュメント、同じソースのバリアントは、その近さが評価の独立性を脅かす場合、1つのセットにまとめましょう。学習された変換や結果に基づく調整の前に分割を行います。行ごとのランダム分割は、すでにほぼ見た例に対して進歩したような印象を与えかねません。

教育用の例: 会話ごとにまとめた1,200件のチケットを、グループを守ったうえで840件の学習例、180件の検証、180件のテストに振り分けます。これらの数値は例示的な計画を示すものであり、提供されるコーパスではありません。検証は変種の選択に使い、最終テストは取り置きます。単なる比率が品質を保証すると信じるのではなく、各集合のカテゴリと長さを確認しましょう。

基準と比較するバリアントを選定します。

完全な適応は、対象となるベースの重みを変更します。LoRAは対象モジュールに低ランク行列を追加し、その寄与を学習します。ランク、対象モジュール、スケール、選択したオプションが実験を定義します。ランクを上げるとアダプタのパラメータ数は増えますが、あなたのタスクが改善する証明にはなりません。

説明用の4096×4096行列では、ランク8のLoRA行列2つは8×(4096+4096)=65,536個の値を持ち、稠密行列の16,777,216個とは対照的です（バイアスやその他のモジュールを除く）。この数の比は、モデル全体やメモリのピークを表すものではありません。ベース、アクティベーション、学習されたパラメータの状態も考慮する必要があります。

技術的な出典: PEFT — 設定とLoRA行列

ワークフロー全体の精度を選択します。

4ビットで読み込まれたベースは、すべての演算、すべてのテンソル、キャッシュが4ビットを使うことを意味しません。量子化のメタデータや別の精度で保持されるモジュールが割り当てに影響します。bitsandbytesでは、4ビットまたは8ビットで読み込まれたモデルの学習は追加のパラメータを対象とし、量子化された重みの一般的な更新ではありません。

ベースの形式、計算の型、学習可能なモジュール、バージョンを記録しましょう。実際のステップ、評価、使用したいエクスポート操作を比較します。マージ、逆量子化、別形式の生成は、学習時とは異なるスペースを必要とする場合があります。適応中に収まる手法は、サイクル全体が同じカードに収まる証明にはまだなりません。

技術的な出典: Transformers 5.17 — bitsandbytesと追加パラメータ

定義した試行予算でバリアントを比較します。

例示的なデータセットでは、適応なしの基準、ランク8のLoRA、ランク16の変種を、同じモジュール、データ、ステップの予算、評価ルールで保持します。このときランクが検討対象の因子です。ランクと学習率を同時に変えると別の問いが生まれます。アブレーションガイドでは、この相互作用を読みやすくする方法を説明しています。

各試行の前に、トークン化されたいくつかの例と損失に寄与する部分を確認しましょう。試行後は、特定した予測を同じ評価器で突き合わせます。平均だけでなく、欠落した出力やリグレッションも記録します。稀なクラスが体系的に誤りになると、品質契約によっては全体の改善が無効になりえます。

alpha、dropout、初期化も文書化しましょう。古典的なLoRA設定では、スケールはalpha/rです。ランクが変わるときにalphaを維持するのかalpha/r比を維持するのかを明示します。これらのプロトコルはまったく同じ問いに答えるものではありません。rsLoRAのような別のスケール規則は、別個に識別する必要があります。

技術的な出典: PEFT — ランク、alpha、LoRAスケーリングのルール

さらに計算資源を投じる前に、何を修正すべきかを判断します。

損失が下がっているのに検証品質が停滞している場合は、ステップを増やすのではなく分析が必要です。ラベルの誤り、表現の繰り返し、切り詰められた入力、学習時と推論時のフォーマットのずれを確認しましょう。修正方法を選ぶために、カテゴリごとにエラー例を保存しておきます。

タクソノミーやパースを修正する場合は、評価器をバージョン管理し、必要な候補のスコアを再計算します。異なるルールで得られた2つの数値を直接比較しないでください。修正を選ぶために最終テストを確認するなら、それはもはや開発の一部です。次の結論に向けて、独立した新しい評価を用意しましょう。

再利用したい結果を検証します。

PEFT形式はアダプターのパラメータとその設定を保持しますが、通常ベースの重みは含みません。したがって、そのベースの正確な識別子とリビジョンを成果物とともに保管しておきましょう。進化するバージョンを指すモデル名だけでは、条件を再現するのに十分ではありません。

実際に使用する予定の結果を新しいプロセスで再読み込みします。いくつかの確認用入力を再生し、その後評価プロトコルを実行します。tokenizer、テンプレート、生成パラメータ、依存関係、メトリクス、データの出所をアーカイブします。成果物がマージされている場合は、その変換を記録し、その出力を確認します。これは確認すべきステップであり、目に見えない形式的な作業ではありません。

技術的な出典: PEFT — チェックポイントの内容とベースモデル

結果に基づいて次のステップを選びます。

GPUは、完全なステップと評価のピーク、必要な最大入力、互換性のあるソフトウェアスタックに基づいて比較します。プランには、対照、優先するバリアント、エラーの確認、復旧のための時間を確保しておきます。注文時に環境を選ぶことは、望ましい準備を表明するものであり、あなたの適応を自動的に保証するものではありません。

結論では、採用した候補または十分な利得が得られなかったことを明示し、対象としたグループ、既知のリグレッション、再読み込みの条件を記載する必要があります。あなたのノートには参照と選択理由が残ります。メモリ計測パックは計測の理解を助けますが、あなたに代わって検証済みのLoRA学習を提供するものではありません。