LoRA（Low-Rank Adaptation, Hu et al., 2021）は少ないパラメータで強力な適応を実現し、運用現場でも広く使われています。一方で「一度デプロイすれば長期間動く」という期待は誤りで、数週間〜数ヶ月で静かに劣化します。原因を3つに分解し、それぞれへの対処を示します。
劣化要因1：入力分布ドリフト
ユーザーの質問カテゴリ、語彙、長さ分布は時間で変わります。特にToC製品は季節性・トレンドの影響が大きく、学習時のデータ分布から数ヶ月でずれます。監視はKL divergenceや Population Stability Index (PSI) で入力側分布を追跡し、閾値超過でアラート。埋め込みベクトル空間での重心移動も有効な指標です。
劣化要因2：ベースモデル更新
ホスト型の場合（Bedrock、Vertex AI、Azure）、ベースモデルがプロバイダ側で更新されるとLoRAの効き方が変わります。LoRA は特定の重み行列にΔW = BA を足す方式で、ベースのWが変わればΔWの意味も変化します。自前ホストならこの問題はないが、プロバイダ任せの場合は model_version ピン留めが必須です。
劣化要因3：プロンプトテンプレート変更
下流のプロンプトテンプレートが変わると、fine-tune時に最適化された入力分布からずれます。「Please output JSON only」を「Respond with JSON」に変えただけで性能が数ポイント落ちる事例は珍しくありません。テンプレート変更はfine-tune再評価のトリガーとして扱うべきです。
モニタリング設計
(1) オンライン品質プロキシ：ユーザークリック率、フォローアップ質問率、rejection率などをdaily集計しCUSUMやEWMAで変化検知。(2) シャドウeval：本番入力の1%を golden判定器（上位モデル or ルールベース）で評価し、正答率を時系列追跡。(3) 分布監視：入力埋め込みの重心・分散を週次で記録。(4) コスト監視：LoRAが劣化するとリトライやfallbackが増え、コストが先行指標として動くことが多い。
リメディエーション戦略
閾値超過時の対応は3段階。第1に温度・プロンプトの微調整で回復するか試す（コスト最低）。第2に新しいデータで継続学習（continual fine-tune）。ただしカタストロフィック忘却に注意し、旧データを一定比率混ぜる rehearsal を推奨。第3に全面再学習。ベースモデルが変わった時はこれが必須です。
組織面の落とし穴
fine-tuneチームとプロンプトチームが別組織だと、プロンプト変更がfine-tune側に通知されず劣化が放置されがちです。fine-tuneを使っている機能のprompt templateは変更レビューをMLOpsチーム必須レビュアに設定する運用が有効です。monthly review会でLoRAの稼働品質を全体監査する組織も増えています。