LLMアプリのドリフトとは？入力・知識・評価基準の変化を見逃さない
モデルやプロンプトを変更していないのに、LLMアプリの回答品質が下がることがある。利用者の質問、参照する文書、外部サービス、期待される答えが時間とともに変わるからだ。このように、開発時の前提と本番の状態がずれていく問題をドリフトとして監視する。
ドリフトは一つの数値ではない。「最近の入力は長くなった」という変化と、「正答率が下がった」という結果は別である。先に何が変わったかを分類し、品質、速度、安全性への影響を評価する必要がある。
モデルを固定してもシステムは変わる
従来の機械学習では、学習時と本番時で入力特徴の分布が変わるデータドリフトや、入力と正解の関係が変わる概念ドリフトが問題になる。LLMアプリでは、事前学習済みモデルだけでなく、プロンプト、検索、道具、参照文書、採点者を組み合わせるため、変化の入口が多い。
例えば問い合わせ分類で、以前は「解約」が中心だったのに、新制度の開始後は「移行期限」の質問が急増すれば、入力の意図分布が変わる。RAGで新しい規程が追加されたのに検索索引が古いままなら、知識の鮮度がずれる。外部APIの返却項目が変われば、エージェントは同じ道具名でも異なる結果を受け取る。
モデル名だけを監視しても、こうした変化は見つからない。実行時の構成と入力、取得した根拠、道具の結果、評価結果を対応付ける。
入力ドリフトは内容と形式を分けて見る
Google Cloudの生成AI運用資料は、評価時の入力分布と本番入力を比較し、文字数やトークン数、新しい語彙、概念、意図、話題の変化を測る方法を挙げている。LLMでは数値特徴だけでなく、文章の内容と形式の両方を見る。
形式の変化には、入力長、添付ファイル数、言語、文字コード、JSONなどの構造、会話ターン数がある。内容の変化には、新しい製品名、制度、質問意図、敵対的な指示の増加がある。個々の文章を保存しなくても、長さの分布、言語、分類済みの意図、エラー種別を集計できる場合がある。
入力分布が変わっただけで、直ちに品質低下とは限らない。新しい利用者層へ正しく届いた結果かもしれない。変化を検知したら、その分類の回答品質と利用者行動を別に確認する。
知識と道具のドリフトを監視する
RAGの品質はモデルだけでなく、原本の更新、分割方法、埋め込み、索引、検索条件に依存する。原本が新しくても索引更新が失敗すれば、回答は古い。逆に古い文書を削除しても断片が索引に残れば、廃止済みの情報を返す。
知識側では、原本の更新時刻、索引へ反映した版、文書件数、削除件数、閲覧権限の反映、検索結果の鮮度を測る。代表質問で期待する文書が取得できるかも継続評価する。
道具側では、APIの版、応答Schema、欠損率、エラー率、遅延、返却値の範囲を記録する。正常なHTTP応答でも、単位や意味が変われば誤操作につながる。Schemaの変更は早く止め、値の分布変化は影響を調べるというように扱いを分ける。
評価基準にもドリフトがある
評価データセットが古くなると、本番で重要になった質問が含まれず、点数だけが高い状態になる。正解そのものも、料金、規程、製品仕様の更新で変わる。基準日と根拠文書を持たない評価例は、正しい新回答を誤って不合格にする可能性がある。
LLM-as-a-Judgeを使う場合は、採点モデル、採点指示、参照資料の変更も評価ドリフトになる。候補モデルの品質が同じでも、採点者を変えたため点数が動くことがある。採点構成を固定した基準セットで比較し、変更前後の結果を同じ系列へ無条件に混ぜない。
本番で増えた意図、利用者が訂正した回答、専門家が見つけた失敗を評価セットへ追加する。古い例は即座に捨てず、現在も有効か、過去版の回帰確認に残すか、根拠とともに決める。
品質低下はラベルが遅れて現れる
入力長やエラー率はすぐ測れるが、回答が本当に正しかったかは後から分かることが多い。利用者の評価、問い合わせの再発、専門家監査、確定した業務結果など、遅れて得られる正解をどの実行へ結び付けるかを設計する。
即時指標だけで自動修正すると危険である。例えば再質問が増えた原因は回答品質だけでなく、利用者層や画面の変更かもしれない。先行指標として入力分布、検索失敗、拒否率、遅延を見ながら、遅れて得られる品質指標で仮説を確認する。
全体平均ではなく、言語、意図、利用者区分、文書群、道具ごとに分ける。少数の重要な利用場面だけが悪化しても、全体では隠れることがある。
アラートは変化の検知で終わらせない
しきい値を超えたという通知だけでは、担当者は動けない。アラートには、変化した指標、基準期間と現在期間、影響する分類、関連する構成版、確認用の評価結果を含める。誰が確認し、どの条件で限定停止やロールバックを行うかも決める。
Google Cloudの運用資料は、ドリフト、ずれ、性能低下を検知したときに所有者へ通知する仕組みと、継続評価を組み合わせるよう示している。NISTのAIリスク管理資料も、公開前の試験だけでなく、運用中の性能測定と迅速な対応を扱っている。
すべての変化を障害にすると、通知が多すぎて無視される。Schema破壊、安全違反、重大な品質低下は即時対応とし、話題や入力長の緩やかな変化は調査対象にする。しきい値は最初から普遍的な値として決めず、通常時の変動と業務上の損失から調整する。
ドリフトを検知しても自動再学習とは限らない
従来の予測モデルでは、新しいデータで再学習する対応が考えられる。LLMアプリでは、原因が索引更新の失敗なら再学習では直らない。新しい質問意図ならプロンプトやルーティング、古い知識なら原本と索引、API変更なら道具の変換層を修正する。
対応前に、入力、知識、道具、評価基準、モデル構成のどこが変わったかを切り分ける。修正候補は新しい本番例を含むオフライン評価へ通し、影の実行や限定公開で確認する。ドリフト検知は変更を自動で正当化する信号ではなく、再評価を始める信号である。
LLMアプリの品質は、固定したモデルの性能だけでは保てない。入力、知識、道具、評価基準の変化を別々に観測し、品質指標と結び付けることで、何がずれ、どこを直すべきかが分かる。変化を見つける仕組みと、評価して安全に直す流れを一組にすることが継続運用の基本である。