LLMのオフライン評価とオンライン評価は何が違う？公開前テストと本番データをつなぐ

固定した問題で高得点を取ったLLMアプリでも、本番で利用者の役に立つとは限らない。反対に、クリックや利用時間が増えても、回答の正しさや安全性が改善したとは限らない。公開前のオフライン評価と、本番のオンライン評価は測る対象が違うため、片方だけでは判断できない。

オフライン評価は、同じ入力と採点基準で構成を比較し、既知の失敗を公開前に止める。オンライン評価は、実際の利用者と環境で行動や失敗を観測し、評価セットが見落とした問題を見つける。二つを順番につなぐと、速い回帰確認と現実の効果測定を両立できる。

オフライン評価は変更を速く比べる

オフライン評価では、保存済みの入力へ候補のモデル、プロンプト、検索設定を適用し、同じ基準で採点する。外部へ回答を見せずに実行できるため、開発中の比較、モデル更新時の回帰確認、重大な安全違反の検出に向く。

例えば社内文書への質問回答なら、正しい文書を取得したか、答えが根拠と一致するか、資料にない質問で推測を控えたかを固定データで確認できる。OpenAIの評価設計資料は、変更のたびに継続評価を行い、実際の利用分布を反映したタスク固有の評価を育てることを勧めている。

長所は再現性である。同じ評価セットと採点構成を使えば、変更前後の差を短時間で調べられる。一方、保存したデータは過去の分布しか表さない。新しい言い回し、季節要因、利用者の誤解、外部サービスの変化は、固定セットに入るまで見えない。

オフライン評価の合格は公開許可の必要条件であり、本番での有用性の証明ではない。

オンライン評価では、本番での成功率、利用者の明示的な評価、訂正や再質問、途中離脱、応答時間、費用、危険な出力などを観測する。実際の文脈と利用者行動を含むため、開発者が想定しなかった使われ方を発見できる。

ただし、行動指標は品質を直接表さない。回答が長いため滞在時間が増えたのか、理解できず読み返したのかは数値だけでは分からない。「役に立った」の評価も、回答直後の印象と、後で分かった事実誤りを区別できないことがある。

一つの指標を最大化せず、目的指標とガードレール指標を組にする。問い合わせ解決率を目的にするなら、誤回答、安全違反、再質問、遅延、費用を同時に見る。短期的なクリック増加が長期の満足を保証しないことは、Googleのオンライン実験研究でも指摘されている。

候補構成を本番へ出す前に、オフライン評価の通過条件を決める。全体平均だけでなく、重要な分類ごとの最低値と、一件でも発生してはいけない失敗を定義する。

例えば次のように分ける。

結果を見た後に条件を変えると、都合のよい判断になる。評価セット、採点者、候補構成、実行時刻を版として保存し、どの条件で通過したかを追跡できるようにする。

オフライン評価を通過した候補は、すぐ全利用者へ出さない。まず影の実行で、本番入力を候補にも処理させるが、候補の回答は利用者へ返さず保存して比較する。実際の入力分布で品質、遅延、費用を測れ、利用者への影響を抑えられる。

影の実行でも、外部への書き込みや送信を候補に行わせてはいけない。検索や道具の結果が時間で変わる場合は、現行と候補が同じ入力を受けたかを記録する。個人情報や機密情報を評価へ再利用する範囲、保存期間、アクセス権も先に決める。

次に、限定した利用者または少量の通信へ候補を出す。影の実行と違い、ここからは利用者への実影響がある。重大な誤り、遅延、費用が上限を超えた場合に自動または手動で現行構成へ戻せるようにする。

二つの構成が利用者行動へ与える因果的な差を測るなら、対象を無作為に振り分ける。新構成を希望した人だけへ出して通常利用者と比べると、利用意欲や熟練度の差が結果へ混ざる。

同じ利用者が会話の途中で構成AとBを行き来すると、前の回答の影響を分離しにくい。会話単位か利用者単位か、何を一つの露出とするかを決め、実験中は割り当てを安定させる。共有の知識や外部状態を更新するエージェントでは、一方の操作が他方の条件へ影響する可能性も確認する。

必要な標本数や期間を、途中の数字を見ながら都合よく変えない。開始前に主要指標、ガードレール、停止条件、分析対象を定める。重大な安全問題が出た場合は、統計的な結論を待たず停止する。

オンライン評価で見つけた失敗は、その場の修正だけで終わらせない。個人情報を除去し、再現に必要な入力と状態、期待する振る舞い、失敗分類を付けてオフライン評価へ追加する。修正後は同じ例が通ることと、既存の例を壊していないことを確認する。

OpenAIの資料は、開発時からログを残し、本番データ、専門家が作った正解、過去ログを組み合わせ、評価セットを継続的に増やす考え方を示している。ログを無条件に保存するという意味ではない。取得目的、同意、匿名化、保存期間を満たすデータだけを使う。

流れは一方向ではない。オフライン評価で公開前の既知の失敗を止め、影の実行と限定公開で現実との差を調べ、本番の新しい失敗を次の回帰例へ戻す。この循環が続けば、評価セットは実際の製品とともに更新される。

オフライン評価は「壊していないか」を速く確認し、オンライン評価は「現実に良くなったか」を測る。役割を混ぜず、公開条件、限定公開、監視、回帰例への追加を一続きに設計することが、LLMアプリの変更を安全に積み重ねる基本である。