LLM 評価による実験の改善 — フォークではなくファネルへ（6 分読）
Spotify の事例を引用し、LLM 評価（evals）が A/B テストの代替ではなく、実験前の候補選別とリスク管理を行う「評価ファネル」として機能すべきであるという新しいパラダイムを提唱している。
キーポイント
検証と妥当性の区別
LLM 評価は出力の品質基準への適合（検証）を確認し、A/B テストは実際のユーザー反応やビジネス成果への影響（妥当性）を検証する役割を分担する。
実験のヒット率向上
LLM 評価を用いて有望でない候補を事前にフィルタリングすることで、限られた実験リソースをより有望なアイデアに集中させ、成功確率（ヒットレート）を高める。
仮説生成とフィードバックループ
評価モデルは単なるチェック役ではなく、未知のパターンを発見して改善の仮説を生み出し、その後の修正が機能したかを確認する双方向の役割を果たす。
ビジネスリスクのバウンディング
意図された機能が正しく動作していることは評価で確認済みであるため、A/B テストの本質的な目的は「ビジネス成果への寄与」と「予期せぬ悪影響（ハーム）の防止」に限定される。
重要な引用
The right relationship is a funnel, not a fork.
You test to validate the intended change drives the business outcome it was meant to, and to bound the risk of harming the business.
Evals verify: does the output conform to quality standards? Experiments validate: do real users respond as predicted?
影響分析・編集コメントを表示
影響分析
この記事は、LLM 評価ツールが単なる品質チェックリストではなく、製品開発ライフサイクルにおける戦略的な意思決定支援ツールへと進化すべきであることを示唆しています。特に、Spotify のような大規模プラットフォームでの実践事例を基に、実験リソースの最適配分とリスク管理の効率化を提案しており、AI エンジニアリングやプロダクトマネジメントの実務において即座に適用可能な重要なフレームワークを提供します。
編集コメント
LLM 評価の活用において、多くの組織が「代替手段」として捉えがちですが、本稿は「前段のプロセス」として再定義する視点が極めて重要です。実験コストを削減しつつ、より高品質なイノベーションを生み出すための具体的なマインドセット転換を促す良質な記事です。
TL;DR LLM 評価は、関連性、一貫性、品質を大規模に評価する自動化された判断者であり、強力な新ツールです。オンライン実験と組み合わせることで、テスト対象のヒット率が向上し、時間とともに評価と実験の両方をより賢くするフィードバックループが生まれます。
Spotify では、A/B テストの約 12% が shipped されたポジティブな結果で終了します。約 64% は有効な学習をもたらします：回帰の検出、アイデアの却下、仮説の精緻化です。実験の価値は勝率だけでは測れません。
今、新たな能力が加わりました。LLM 評価は、以前にはスケーリングできなかった次元（関連性、一貫性、トーン、意図との整合性）を、テストセットから A/B テストのバリアントに至るあらゆるデータ上で、人間による注釈よりも高速かつ低コストで評価できます。評価と実験は異なるものを測定します。適切な関係性は「分岐」ではなく「漏斗（ファネル）」です。Schultzberg と Ottens (2024) はこれを評価漏斗と呼び、評価は実験の代わりにではなく、実験の前に行うべきだと述べています。強力な評価スタックとは、変更が意図した通り機能するかを確認するためにテストを行う必要がないことを意味します。評価ですでにそれが示されています。あなたがテストするのは、意図された変更が本来目指すべきビジネス成果を導くことを検証し、ビジネスへの悪影響のリスクを限定するためです。
評価がもたらすもの、そしてもたらさないもの
シュルツバーグとオッテンスは、「検証（verification）」と「妥当性確認（validation）」を区別しています。評価は検証を行います：出力は品質基準に適合しているか？一方、実験は妥当性確認を行います：実際のユーザーは予測通りに反応するか？評価は、実験の帯域幅を消費する前に、有望でない候補を排除します。これにより、続く実験の的中率が高まります。
評価は仮説も生成します。例えば、信頼を損なうコンテンツ（例えば、適合しないユーザーに共有された推薦など）を検出するために LLM 判定器（LLM judge）を構築するチームを考えましょう。この判定器は、チームが注目していなかったパターンを浮き彫りにします。これらのパターンが製品改善の課題となります。改善策を実装した後、同じ判定器でその効果が検証できます：検出された違反件数が減少すればよいのです。つまり、評価は二つの役割を果たしています：何を改善すべきか発見することと、改善が実現したことを確認することです。
しかし、評価にできることは、改善版を受け取ったユーザーが実際に良い結果を得たかどうかを伝えることではありません。例えば、その改善策が、最終的に離脱につながる信頼の緩やかな侵食を防げたかどうかは分かりません。この問いには実験が必要です。
測定している次元の他にも、測定していない次元が存在します。Spotify では、二次指標（セッション時間の低下、クラッシュ率の上昇、リテンションの低下など）における回帰を防ぐため、展開された実験の約 42% をロールバックしています。これらは評価やオフライン評価では検出されませんでした。ガードレール指標 に関する私たちの研究で説明した通り、ガードレールの目的は、最適化対象ではないが重要視する次元を監視することです。評価（eval）は特定の次元における実装の品質を測定します。一方、実験は本番環境のシステムやエンドユーザーへの影響を定量化するものです。
2 つの較正層と 1 つのフィードバックループ
評価（evals）は代理指標です。実際に重要視する結果に代わってスコアを代入するものです。この置換が有効なのは、そのスコアが実際の結果を追跡している限りであり、これは 代理指標 について私たちが説明してきたのと同じダイナミクスです。
現在、LLM（大規模言語モデル）による判定者は、従来の定量的指標（ランキングスコア、精度、再現率など）の上に第 2 の較正層を追加します。両方の層はオンラインでの結果に対して検証される必要があります。どちらもドリフト（ズレ）する可能性があります。判定者が「バリアント A の方が優れている」と言う場合、実際にユーザーエクスペリエンスが向上しているのか、それとも結果を導かない表面的なパターンに報酬を与えているだけではないのかを確認する必要があります。
例えば、Anthropic が Opus 4.5 モデルをリリースした際、Qodo のコーディング評価では改善が見られませんでしたが、制御された実験であれば長期的なタスクにおける大幅な改善は明らかになっていたはずです。不適合（miscalibration）は双方向に起こり得ます。オフラインとオンラインの信号を較正しない限り、私たちの評価（evals）は意見に過ぎず、証拠ではありません。 構造的に、長時間実行されるタスクや長期的な振る舞いを評価で捉えることは困難です。しかし、オンラインの結果との対応関係を改善するために評価を継続的に調整することで、評価はより優れた*検証*ツールへと進化しています。将来、AI の発展に伴い、評価が十分に正確に対応し、*検証*（validations）として機能するようになる可能性を否定するものではありません。オフラインとオンラインの較正ループを整備しておくことで、AI がさらに改善され続ける中で、評価が評価ファネルにおいて果たすべき役割について継続的な透明性を確保できます。
スピード圧力にさらされているチームは、A/B テストを「高コスト」と呼ぶことがあります。経験からわかるのは、主要なビジネス指標の重大な回帰（regression）を検出せずにリリースすることは、非常に高コストになり得るということです。システムが複雑であればあるほど、リスクを限定することが重要になります。
Close the loop
評価を早期かつ頻繁に実施し、最適な処置を見つけましょう。その後、実験によって実際のユーザーやシステムが予測通りに反応するかを検証し、最適化対象外だった指標も監視してください。すべての変更が同じ程度の証拠を必要とするわけではありません：反復とデータ収集のための迅速な方向性テストと、リリース決定のための厳格なテストを使い分けます。
次に、A/B テストのデータ自体に対して LLM 評価（LLM evals）を実行します。審査員が好んだバージョンが実際にユーザーにとってより良いパフォーマンスを示したでしょうか？これは従来の評価ファネルを拡張するものです。LLM による審査により、「指標が動いたか？」だけでなく「定性的な側面が変化したか？」という問いも可能になります。評価スコアと実験結果の間に大きな乖離がある場合、それは診断上の貴重な手がかりとなります。各サイクルが次のサイクルの較正に役立ちます。
信頼を損なう推奨チームに戻りましょう：実験は最終段階です。改善されたバージョンを受け取ったユーザーがより良い長期的エンゲージメントを示す場合、チームは審査員が測定しているものが実際に重要であることを確認したことになります。一方、審査員のスコアは向上したがユーザーの結果は変わらなかった場合、それは較正のシグナルとなります：審査員は何らかのものを捉えているが、価値を駆動するものではないということです。どちらの結果もシステムをより賢くします。
Spotify はすでに実験の形において強力な評価文化を確立しています。LLM 評価はこの文化を上流に拡張し、明確な役割を果たします：実験前に最良の治療法を見つけ、実験後に判定者を較正することです。Ankargren (2025) が主張するように、成功はスケーラブルで基本を適切に行うことから生まれます。システムが使いやすく、かつ信頼できるほど厳密であればあるほど、その価値は複利のように蓄積されます。
原文を表示
TL;DR LLM evals, automated judges that assess relevance, coherence, and quality at scale, are a powerful new tool. Paired with online experiments, they raise the hit rate of what we test and create a feedback loop that makes both evals and experiments smarter over time.
At Spotify, only about 12% of A/B tests end in a shipped positive result. Around 64% produce valid learning: a regression caught, an idea ruled out, a hypothesis refined. The win rate understates the value of experimentation.
Now we have a new capability. LLM evals can assess dimensions we couldn't scale before (relevance, coherence, tone, intent alignment) faster and cheaper than human annotation, on any data from test sets to A/B test variants. Evals and experiments measure different things. The right relationship is a funnel, not a fork. Schultzberg and Ottens (2024) call it an evaluation funnel, where evals belong *before* your experiment, not *instead of* it. A strong eval stack means you don't test to find out if the change does what you intend. Evals already told you that. You test to validate the intended change drives the business outcome it was meant to, and to bound the risk of harming the business.
What evals give us, and what they don’t
Schultzberg and Ottens distinguish *verification* from *validation*. Evals verify: does the output conform to quality standards? Experiments validate: do real users respond as predicted? Evals discard the non-promising candidates before they consume experiment bandwidth. They raise the hit rate of the experiments that follow.
Evals also generate hypotheses. Consider a team that builds an LLM judge to flag trust-breaking content, say a recommendation shared with a user it doesn't fit. The judge surfaces patterns the team didn't know to look for. Those patterns become product fixes. After the fix ships, the same judge can verify it worked: the flagged violations should drop. That's the eval doing two jobs: discovering what to improve, and confirming the improvement was realized.
What the eval can't tell you is whether users who received the improved version actually had better outcomes: whether the fix prevented the slow erosion of trust that eventually leads to churn. This question requires an experiment.
Beyond the dimensions you're measuring are the ones you aren't measuring. At Spotify, teams roll back about 42% of launched experiments to prevent regression in secondary metrics: session length dropping, crash rates climbing, retention eroding. No evals or offline evaluation flagged those. As we've described in our work on guardrail metrics, the point of a guardrail is to watch dimensions you care about but aren't optimizing for. An eval measures quality of implementation in one dimension. An experiment quantifies the impact on systems in production and end users.
Two calibration layers, one feedback loop
Evals are proxies. They substitute a score for an outcome you actually care about. That substitution is only valid as long as the score tracks the real outcome, the same dynamic we've described with proxy metrics.
Now LLM judges add a second calibration layer on top of traditional quantitative metrics (ranking scores, precision, recall). Both layers need validation against online outcomes. Both can drift. When the judge says Variant A is better, does it actually deliver a better user experience, or is the judge rewarding surface patterns that don't drive outcomes?
For example, when Anthropic released the Opus 4.5 model, Qodo's coding evals showed no improvement, but the model had improved substantially on longer tasks a controlled experiment would have surfaced. Miscalibration runs both ways. Without offline-online signal calibration, our evals are opinions, not evidence. By construction, long-running tasks and long-term behaviour are challenging to capture with evals. By continuously adjusting the evals to improve their mapping to online outcomes, the evals are becoming better and better* verification* tools. We are not ruling out that in the future, as AI develops, evals can map well enough to start acting as *validations*: By having the offline/online calibration loop in place we have continuous transparency on what role evals *can play* in the evaluation funnel as AI keeps improving.
Teams under speed pressure sometimes call A/B tests "costly." We know from experience that shipping without an experiment can be incredibly costly, if a major regression in top business metrics goes undetected. The more complex the system, the more important it is to bound the risk.
Close the loop
Run evals early and often to find the best treatments. Then let the experiment validate that real users and systems respond as predicted, and monitor the metrics you didn't optimize for. Not every change needs the same evidence: quick directional tests for iteration and data gathering, rigorous tests for ship decisions.
Then: run your LLM evals on the A/B test data itself. Did the version the judge preferred actually perform better with users? This extends the traditional evaluation funnel. LLM judges let us ask not just "did the metric move?" but "did the qualitative aspects change?" When the gap between eval scores and experiment outcomes is large, that's diagnostic gold. Each cycle helps calibrate the next.
Return to the trust-breaking recommendation team: the experiment is the final step. If users who received the improved version show better long-term engagement, the team has confirmed that what the judge measures actually matters. If the judge scores improved but user outcomes didn't, that's the calibration signal: the judge is capturing something, but not the thing that drives value. Both results make the system smarter.
Spotify already has a strong evaluation culture in the shape of experimentation. LLM evals extend that culture upstream, with a clear role in the funnel: find the best treatments before the experiment, and calibrate the judges after it. As Ankargren (2025) argues, success comes from doing the basics well at scale. The value compounds when the system is simple enough to use, and rigorous enough to trust.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み