オンライン vs オフラインのLLM評価：必要なのはどちらか（そしていつか）

オンライン vs オフラインのLLM評価：必要なのはどちらか（そしていつか）

オンライン vs オフラインのLLM評価は、2つではなく1つの意思決定です。先週火曜日、私たちの promptfoo スイートがそれを証明しました。システムプロンプトを1つ書き換えたところ、47件のテストケースでfaithfulnessが0.91から0.74へ低下したのです。CIの実行時間はおよそ90秒。オフラインチェックがマージ前にそのリグレッションを捕まえましたが、本番モニタリングだったなら、サポート問い合わせという姿に化けて、ずっと後から気づいたはずです。オフラインもオンラインも結論は同じで、2つのレーン、2つの役割です。

オフラインLLM評価は、デプロイ前にモデルを固定データセットに対して実行し、変更が測定済みの品質を損なっていないことを証明します。オンライン評価は、リリース後に本番トラフィックをスコアリングし、データセットにはそもそも含まれていなかった問題を露呈させます。ほとんどのチームには両方が必要で、順序も決まっています。オフラインがデプロイのゲートになり、オンラインがドリフトを捕まえます。

重要なポイント

• オフライン評価はデプロイ前に固定データセットに対して実行され、オンライン評価はリリース後にライブトラフィックをスコアリングする。
• ほとんどのチームには両方が必要。オフラインがデプロイのゲートになり、オンラインがデータセットの見落としを捕まえる。
• オフラインはプロンプトのリグレッションとフォーマット崩れを捕まえ、オンラインはドリフト、負荷時のレイテンシ、統合の癖を捕まえる。
• オフライン評価をCIのマージゲートとして組み込み、本番トレースからのオンラインスコアを評価セットへストリームで還流させる。

オンライン評価とオフライン評価はどこが違うのか？（9つの軸）

2つのモードは9つの軸で異なりますが、決定的なのはデータソースです。オフライン評価はデプロイ前に固定・バージョン管理されたデータセットをスコアリングし、オンライン評価はリリース後にライブトラフィックをスコアリングします。コスト、レイテンシ、リスク、ガバナンスなど、その他の違いはすべてこの分岐から派生します。

Label Studioのラーニングセンターは、この2つをライバルではなく補完的なモードとして位置づけており、私たちも同意見です。次の表は、その枠組みをLLM特有のメトリクスまで拡張したものです。同社の汎用ML版ではカバーされていない指標も含めています。

私たちの解釈はこうです。オフラインの列は「この変更で何か壊れたか？」に答え、オンラインの列は「本番はテストした内容からドリフトしていないか？」に答えます。最も大きく食い違うのはメトリクスの種類の行で、各メトリクスの詳細はLLM評価メトリクスガイドで分解して解説しています。

各モードは何を検知し、何が両方をすり抜けるのか？

それぞれのモードには、もう一方からは見えない専用の失敗クラスがあります。オフラインが捕まえるのは自分が加えた変更、オンラインが捕まえるのは周囲の世界が加えた変更です。そして本当に高くつく失敗、つまり両方の網を生き延びる失敗には、人間のレビュアーが必要です。この分類は、各モードが報告する内容を私たちが統合したものであり、公開された標準規格ではありません。

オフライン専用の象限こそ、CIゲートが投資に見合う場所です。フォーマット準拠率を99%から91%へ静かに落とすプロンプトの書き換えは、コードレビューでは見えず、47ケースのスイートなら一目瞭然です。オンライン専用の象限はもっと厄介です。実際のユーザーはゴールデンセットに存在しない言い回しを使い、サードパーティAPIはステージングでは再現しないタイミングでタイムアウトし、誰かが4万文字のプロンプトをチャットボットに投げ込んで「どうなるか」を試します。この側面については、本番環境でのエージェント評価ガイドで、単一出力だけでなくマルチステップの軌道全体のスコアリングを扱っています。

最後の行は、チームが最もスキップしがちで、そして最も火傷する行です。ユーザーを失う原因になる失敗とは、どちらのモード単独でも捕まえられない失敗です。そこにはヒューマンインザループが要ります。

オフライン評価をCIゲートにどう組み込むか？（誰も見せない設定例）

プロンプト、モデル、検索設定に触れるすべてのプルリクエストに、評価ランナーを必須ステータスチェックとして追加します。閾値をアサートし、それを下回ったらマージをブロックします。promptfooのドキュメントはこのCIパターンそのものを記載しており、私たちが運用しているのもこれです。

GitHub Actionsのステップ

現在運用しているゲートを簡略化したバージョンです。

name: llm-eval-gate

on:
  pull_request:
    paths: ["prompts/**", "evals/**", "src/rag/**"]

jobs:
  faithfulness-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - name: Run offline evals, fail the PR on regression
        run: npx promptfoo@latest eval --config evals/support-agent.yaml
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}  # LLM-as-judge

YAML設定がテストケースとアサーションを宣言します。スイートが閾値を下回ると eval は非ゼロで終了し、GitHubは必須チェックを失敗としてマークし、マージボタンはグレーになります。paths フィルターが重要です。READMEの修正でジャッジトークンを消費すべきではありません。

このゲートが実際に検知したもの

実際のバージョンでは、プロンプトに影響するPRのたびに、サポートエージェントのRAGチェーンを47件のゴールデンケースに対してスコアリングしています。フル実行はCI時間で約90秒かかり、faithfulnessが0.82を下回ると自動的にマージがブロックされます。3か月間で、リリースされれば確実に問題になっていたリグレッションを2件捕まえました。faithfulnessを0.91から0.74へ押し下げたシステムプロンプトの書き換えと、コンテキスト長を倍増させてanswer relevancyを閾値の下へ引きずり込んだリトリーバーの変更です。どちらもレビュー時点では危険には見えませんでした。

CIのfaithfulnessゲートのコストはPRあたり90秒です。本番でのfaithfulnessリグレッションのコストは、サポート問い合わせ1件とロールバックです。

このパターンに組み込めるランナー（promptfoo、DeepEvalなど）の比較は、LLM評価ツールのまとめ記事で行っています。

どのツールがどのモードに対応するのか？（ツール×モード対応マトリクス）

両方のレーンを単独できれいにカバーするツールは存在しません。promptfooとDeepEvalはオフライン優先のランナーで、エクスポートした本番データをスケジュールでスコアリングできます。LangfuseとLangSmithはオンライン優先のトレースストアで、取り込んだトレースにLLM-as-judgeのスコアラーを後付けします。このマトリクスは各ベンダーのドキュメントを読んだ私たちの解釈であり、絶対的な正解ではありません。

CIで不良プロンプトをブロックするマージゲートが最優先なら、promptfooまたはDeepEvalを選んでください。ライブトラフィックのスコアリングが最優先ならLangfuseまたはLangSmithで、その選択についてはLangfuse vs LangSmithの比較記事で深く掘り下げています。OpenAI Evalsは依然として異色で、本番側のないレジストリスタイルのオフラインランナーです。

promptfooはPRのゲートになり、Langfuseは本番トレースをスコアリングします。どちらも他方の代わりにはなりません。

フィードバックループはオンラインの失敗をどうオフラインテストに変えるのか？

スコアの低い本番トレースをサンプリングし、ラベルを付け、オフライン評価セットへコミットします。すると回帰テストスイートは本番が投げつける驚きのたびに成長し、次のデプロイは拡張されたセットでゲートされます。このフライホイールという枠組みは私たちのものですが、ほとんどのチームが決して構築しない部分でもあります。

私たちによる運用サイクルは次の通りです。

1. オンラインスコアラーがジャッジスコア0.7未満のトレースにフラグを立てる。
2. フラグ付きトレースを週に20〜30件サンプリングする。
3. 人間が各ケースにラベル付けする：期待出力と失敗クラス。
4. ラベル付きケースが新しいゴールデン例としてオフライン評価セットに加わる。
5. 次のPRは拡張されたスイートに対して実行され、ループが再起動する。

サンプリングはLLMオブザーバビリティ層から始まります。トレースこそが原料だからです。頻度については、ドリフトは複利的に効くため、月次より週次が優れます。私たちは週に10〜15件をラベル付けしており、新しいラベルがパス率を動かさなくなった時点でセットは「十分に大きい」状態です。狭い領域のサポートエージェントなら150〜250件程度が目安です。モード間の境界は曖昧になり続けています。Deepchecksの報告によれば、Union.aiのエンジニアは「オフライン」評価を数分ごとにスケジュール実行しており、事実上ほぼリアルタイムのチェックへ変えています。

評価セットは固定の成果物ではありません。本番に驚かされるたびに、毎週成長していくものです。

両方が必要になるのはいつか？（フェーズ別のオンライン vs オフラインLLM評価）

リリース週以降は両方が必要ですが、バランスはフェーズで移り変わります。デプロイ前はオフラインが単独で受け持ち、リリース週にはシャドウまたはカナリアのスコアリングが加わり、安定運用期はオンラインモニタリングを主軸にオフラインの定期再実行を組み合わせ、ドリフトアラートはオフラインでの再現テストと評価セットの拡張で締めくくるべきです。

デプロイ前は、厳格にするコストが最も安い場所です。ブロックされたマージのコストは数分、不良リリースのコストは信頼です。リリース週はチームが投資不足に陥りがちなフェーズですが、小規模トラフィックでのシャドウスコアリングは低コストで、ゴールデンセットが嘘をついていなかったかを暴いてくれます。安定運用期には慢心が忍び込むので、再評価はカレンダーに固定してください。

EU AI法はどう関係するのか？

EU AI法のハイリスク義務は2026年8月まで段階的に適用され、完全な期限のタイムラインはEUR-Lexで公開されています。そして適合性のパターンは2つのモードにきれいに重なります。文書化されたオフラインのエビデンスは、リリース前にシステムが品質目標を満たしていたことを示し、継続的なオンラインモニタリングは、リリース後も満たし続けていることを示します。私たちの読みでは、監査証跡には両方の成果物が必要です。オフラインログだけではシステムの継続的な適合を証明できず、ダッシュボードだけではリリース時の適合を証明できないからです。これは解釈であり、法的助言ではありません。要件全体のマッピングはLLM評価パイプラインのピラー記事で行っています。

オフライン評価はエビデンスであり、オンライン評価は早期警戒システムです。規制当局が求めているのは両方です。

著者について： Mert BaturはTechsy.ioの共同創業者です。Techsy.ioではB2Bクライアント向けにAIエージェント、自動化システム、音声/SDRパイプラインを提供しています。Techsyチームが実際に本番環境で使っているLLMツールスタックについて執筆しています。LinkedInでつながってください。

よくある質問

オフラインLLM評価とは？

オフラインLLM評価は、デプロイ前にモデルやプロンプトを固定・バージョン管理されたデータセットに対して実行する評価です。典型的なチェック項目には、検索コンテキストへのfaithfulness、answer relevancy、フォーマット準拠、ベンチマークスコアが含まれます。実行中にデータセットが変わることはないため、結果は再現可能でdiffが取れます。まさにこの性質のおかげで、オフラインスイートはCIのマージゲートとして機能します。

オンラインLLM評価とは？

オンラインLLM評価は、リリース後に本番のライブトラフィックをスコアリングする評価です。LLM-as-judgeのスコアラーがサンプルトレースをハルシネーション、トーン、ツールコールの正確性について採点し、スコアはダッシュボードへストリームされます。オフラインテストには見えないシグナルも吸収します。負荷時のレイテンシ、ユーザーフィードバック、そして実際のクエリがゴールデンセットとどう異なるか、です。

オフラインLLM評価とオンラインLLM評価はいつ使い分けるべき？

デプロイのゲートにはオフライン評価を使います。プロンプト、モデル、検索設定の変更はすべて、マージ前にスイートを通過すべきです。リリース後の監視にはオンライン評価を使います。ほとんどのチームはどちらか一方ではなく、両方を順序立てて運用しています。まずオフライン、リリース週以降はオンライン、そして本番の失敗はオフラインセットへ還流させます。

オンラインLLM評価とオフラインLLM評価の具体例は？

オフラインの例：promptfooスイートが200件のゴールデンサポート質問をすべてのプルリクエストで実行し、faithfulnessが0.82を下回るとマージをブロックします。オンラインの例：Langfuseがライブトレースの10%をLLM-as-judgeのハルシネーションチェックでスコアリングし、週平均が低下したらアラートを発報します。同じルーブリックで、データソースだけが異なります。

ヒューマンインザループはLLM評価にどう組み込む？

人間は、どちらのモードもカバーできない隙間を埋めます。未知のエッジケース、主観的な品質判断、ブランドトーンの漂移です。現実的な運用頻度は、スコアの低いサンプルトレースを週に10〜20件ラベル付けし、ラベル付きケースをオフライン評価セットへコミットすることです。レビューキューは副業ではなく、パイプラインへのインプットです。

Langfuseの評価はオンラインスコアリングでどう機能する？

Langfuseはアプリケーションからトレースを取り込み、各トレースをルーブリック（ハルシネーション、関連性、有害性、カスタムプロンプト）に対してスコアリングするLLM-as-judge評価器を付与します。スコアはセッションとユーザーをキーにしたダッシュボードに集約されます。チームは継続的にスコアの低いトレースをオフラインデータセットへエクスポートし、回帰テストに活用しています。このパターンに供給するトレースストアの比較は、オブザーバビリティプラットフォームのまとめ記事で行っています。

オフライン評価をCI/CDパイプラインにどう追加する？

プロンプト、モデル、検索設定に触れるプルリクエストへ、評価ランナーを必須ステータスチェックとして追加します。promptfooもDeepEvalもヘッドレスで動作し、アサーション失敗時には非ゼロで終了するため、マージは自動的にブロックされます。この記事の前半で示したYAMLゲートはそのまま使えるテンプレートです。まずは30〜50ケースから始めてください。

EU AI法はオフライン評価とオンライン評価のどちらを求めている？

実質的には両方です。ハイリスクシステムに対し、同法はリリース前に品質目標を満たしたという文書化されたエビデンス（つまりオフラインの成果物）と、デプロイ後の継続的モニタリング（つまりオンラインテレメトリ）を期待しています。段階的な期限はEUR-Lexに従い2026年8月まで続きます。これは適合性パターンに関する私たちの読みであり、法的助言ではありません。

LLM-as-a-judgeはオフラインとオンラインの両モードで使える？

はい、そしてそうすべきです。ルーブリックは移行できるからです。オフラインでは、CI中にジャッジが評価セットの全出力をバッチでスコアリングします。オンラインでは、同じジャッジプロンプトがサンプルされた本番トレースをほぼリアルタイムでスコアリングします。両モードで1つのルーブリックを保つことが、オフラインのベースラインとオンラインのドリフトシグナルを比較可能にします。

オフライン評価とオンライン評価でどのメトリクスが違う？

オフラインのメトリクスは、正解データに対する出力品質を測定します。faithfulness、answer relevancy、フォーマット準拠、ベンチマークスコアです。オンラインのメトリクスは運用と行動のシグナルを加えます。p95レイテンシ、エラー率、ライブトラフィック上のハルシネーション率、ドリフトスコア、ユーザー満足度です。オフラインのリストは「良いか？」を問い、オンラインのリストは「まだ良いか？」を問います。

まとめ

• オフライン評価とオンライン評価は二者択一ではなく補完的なレーンです。一方がリリースするもののゲートになり、もう一方がリリース済みのものを監視します。
• 今週CIゲートから始め、リリース時にオンラインのトレーススコアリングを追加し、評価セットが陳腐化する前にフィードバックループを配線してください。
• ループこそがシステムです。静的なゴールデンデータセットは腐敗し、成長するデータセットは複利的に効きます。

評価パイプラインを第三者の目で確認したい方は、無料相談をご利用ください。