コンテンツにスキップ

LoRA評価パイプラインのバグ修正と、キャプション手法（タグ付け）の検討

📁 docs/ai-manga/artifact/20260827_020213_LoRA評価パイプライン_バグ修正とキャプション手法検討.md

背景

購入した同人誌からスタイル・キャラクターLoRAを学習するパイプライン（#5299）で、学習自体は複数サークル分完走していたが、「学習済みLoRAの各エポックをForge WebUI APIで生成・比較評価する」スクリプト（evaluate_lora.py）だけが機能しておらず、評価が進まない状態が続いていた。原因を調査したところ2件のバグが見つかり、修正した（PR #7211）。

発見したバグ

1. LoRAがForgeに一切適用されていなかった

evaluate_lora.pyは<lora:{ファイル名}:{強度}>をプロンプトに埋め込む方式でLoRAを指定していたが、Forge WebUIはこの記法だけではmodels/Lora/ディレクトリに実体ファイルが存在するLoRAしか適用できない。評価対象のLoRAファイルはlora-training/outputs/にあるだけで一度もmodels/Lora/へ配置されていなかったため、強度・エポックをいくら変えても常にベースモデルのみの画像が生成され続けていた。

修正では、画像生成の直前に評価対象LoRAをmodels/Lora/へ一時コピーし、Forge WebUI APIの/sdapi/v1/refresh-lorasエンドポイントで認識させ、生成が終わったら削除するstage_lora_for_forge / unstage_loraを追加した。

def stage_lora_for_forge(lora_path: Path, forge_lora_dir: Path, base_url: str) -> Path:
    """LoRAファイルをForgeのLoRAディレクトリに一時配置し、認識させる。"""
    forge_lora_dir.mkdir(parents=True, exist_ok=True)
    staged_path = forge_lora_dir / lora_path.name
    shutil.copy2(lora_path, staged_path)
    refresh_forge_loras(base_url)
    return staged_path

2. エポック番号の抽出漏れ

エポック番号を抽出する正規表現がepoch[_-](\d+)となっていたが、kohya_ssが実際に出力するファイル名は{output_name}-{epoch:06d}.safetensors（例: kyokuchokyoku_style-000015.safetensors）で、epochという文字列自体を含まない。そのため全ファイルが「エポック0」として扱われ、評価ログ上ではどのエポックを見ているのか区別がつかなくなっていた。ファイル名末尾の連番を拾う-(\d{3,})$に修正し、番号なしの最終出力ファイル（末尾エポックと内容が重複する）は評価対象から除外した。

修正の検証結果

修正後、きょくちょ局スタイルLoRAのepoch015を強度0.5・0.8で生成したところ、明確に異なる構図・色味の画像が生成されることを確認した（修正前はハッシュ値が完全一致する同一画像だった）。実際の生成結果は以下の通り（成人向け表現を含む）。

epoch015 / weight 0.5 epoch015 / weight 0.8
epoch015 weight0.5 epoch015 weight0.8

プロンプトは1girl, masterpiece, best quality, kyokuchokyoku_style、seedは42で固定し、LoRA強度のみを変えている。

キャプション（タグ付け）手法の検討

学習パイプラインではWD14 Tagger（ローカルで動くdanbooruタグ付けモデル）を使ってデータセットに自動タグ付けをしている。「タグ付けの精度は、ローカルの軽量モデルよりクラウドの大規模モデル（GPT-4V・Gemini等）の方が高いのでは」という素朴な疑問から、実際のプラクティスを調べた。

結論: 今のWD14ローカル運用は理にかなっている

Illustrious/Pony系のようなSDXL派生モデルは、danbooruタグの語彙そのものを学習素材にしている。学習時のキャプション形式をベースモデルの学習形式（danbooruタグ）に一致させないと、モデルが誤った概念の紐付けを覚えてしまうというのがコミュニティの一般的な理解であり、WD14タグ付けは今も業界標準的な位置づけになっている。

クラウド大規模VLMは規約上そもそも使えない

精度・文脈理解の面ではGPT-4V・Gemini・Claudeのような大規模VLMに分があるが、R18コンテンツを含む同人誌の学習データという用途では、そもそも利用規約上使えない。各社ともNSFW画像のアップロード・処理を制限しており、性的表現と判定された画像は拒否・検閲される。クラウドが「賢い」かどうか以前に選択肢に入らない。

次に試す価値があるのはローカルの高精度キャプショナー

「賢さ」を求めるなら次の一手はクラウドではなく、ローカルGPUで動く高精度キャプショニングモデルへの乗り換え・併用になる。代表例がJoyCaption（SigLIPビジョンエンコーダ＋Llama-3.1-8Bの構成で、SFW/NSFWを均等に扱い検閲なしで自然言語キャプションを生成できる）。実務では「WD14タグ＋JoyCaptionの自然言語キャプションを両方付与するハイブリッド運用」も語られており、タグの機械的な列挙だけでは拾えない構図・雰囲気の情報を補う手段として検討価値がある。

今後の展望

  • 全サークル（きょくちょ局・ろこまに・defpoint_style）の全エポックを本評価し、採用エポック・強度を確定する
  • ai-manga-pipelineへのLoRA統合
  • JoyCaptionのローカル導入検証（WD14タグとの併用可否）
  • 評価スクリプトのGemini Vision依存部分（ImageEvaluator）をOllama Vision系モデルへ移行する

関連リンク