YOLO-PEFT：検出モデルのPEFTを試行錯誤から計画問題へ

導入

PEFT（Parameter-Efficient Fine-Tuning）は大規模言語モデルで広く使われています。しかし、LoRA や RS-LoRA をそのままリアルタイム物体検出器に適用しても、同じようにうまくいくとは限りません。YOLO 系モデルには畳み込み、特徴融合、検出ヘッドなど多様な部品があり、Transformer のように規則的なブロックが並ぶ構造とは異なります。

YOLO-PEFT は、この「アダプタをどこに置くか」という実務上の問題を、手作業の試行錯誤ではなく、監査可能な制約計画として定式化します。

主なポイント

• 配置を計画問題として扱う：入力は検出器のグラフ、PEFT の要求、リソース予算です。出力は対象モジュールの計画、または訓練前の Refuse です。
• 構造に基づく検査：各モジュールに演算子としての役割と検出タスク上の意味を割り当て、演算子の妥当性、検出器固有の意味、グラフインターフェース、デプロイ条件を明示的に確認します。
• 除外理由を残す：使わないモジュールには理由コードが記録されるため、後から判断の根拠を追跡できます。
• YOLO での報告結果：公式の VOC07+12 trainval から VOC07 test へのプロトコルでは、計画器が選んだ RS-LoRA が YOLO11s で 0.7138、YOLO12s で 0.7307 mAP50-95 を達成しました。Full-SFT はそれぞれ 0.6428、0.6662 と報告されています。
• 拒否判断の重要性：RT-DETR-L では、評価された 7 種類の LoRA 系構成すべてが事前定義された災害的しきい値を超え、Full-SFT へ切り替える判断を支持しました。
• 効率面のトレードオフ：YOLO11 の監査では、LoRA によりピーク訓練メモリが 43.9% 削減されましたが、訓練時間は 1.72 倍になりました。

意義と影響

この研究の意義は、単に特定の mAP を上げたことではありません。物体検出モデルの微調整で属人的になりがちな対象モジュール選択を、検査可能なプロセスに変えた点にあります。実運用では、なぜある層を選び、なぜ別の層を除外したのかを説明できることが、再現性やデバッグの面で大きな価値を持ちます。

同時に、PEFT の汎用性に対する注意喚起にもなっています。言語モデルで便利な手法でも、検出器のような異なる構造では配置制約が変わります。YOLO-PEFT の Refuse は、常に答えを出すのではなく、リスクが高い場合に止まる仕組みとして重要です。

ただし、未見の検出器アーキテクチャに対する拒否の妥当性は、まだ検証課題として残されています。したがって本手法は、評価された検出器ファミリーと校正範囲における構造化フレームワークとして理解するのが適切です。

出典：Hugging Face Daily Papers