6.8 AIの評価とテスト

概要と動機

通常のソフトウェアのテストは、心地よい想定に基づいています。同じ入力が与えられれば、プログラムは同じ出力を返し、その出力が何であるべきかを正確に断言できます。人工知能は、その想定を壊します。モデルは同じ質問に二通りの答え方をし、どちらも許容できることがあります。合格か不合格かではなく、間違いから見事までの連続で採点されえます。そして、断言する単一の正解がないことがよくあります。したがって評価の規律、つまり一つの出力を一つの期待値と照らすのではなく、多くの代表的なケースにわたってモデルがどれだけうまく振る舞うかを測ることは、あらゆる信頼できるAIシステムの背骨になります。チームが自分たちを恥じ入らせるAI機能を出荷するとき、根本原因はほとんど常に、リリース前に品質を測る真剣な方法がなかったことです。

大きなチームにとって、評価は変更を安全にするものです。モデルを入れ替え、プロンプトを書き直し、検索を調整し、ツールを加え、それらの変更のすべてが、堅実だと思っていた振る舞いを静かに劣化させえます。品質を測る繰り返し可能な方法がなければ、各変更は賭けで、各回帰はユーザーによって発見されます。本章は、構築の章に対する測定の相棒です。生成AIとLLMアプリケーション(6.3章)、AIエージェントとエージェント型システム(6.7章)、機械学習エンジニアリングとMLOps(6.2章)。一般的なテスト戦略(2.4章)を確率的な世界に拡張します。

企業と政府の設定は、賭け金をさらに上げます。数十のAI機能を動かす企業は、すべてのチームが採点をゼロから再発明しないよう、共有の評価プラットフォームを必要とします。政府機関は、文書化され監査可能な評価を必要とします。「テストした」が「ここに証拠、データセット、指標、承認がある」にならなければならないからです。評価は、責任あるAIと信頼できるAI(6.5章)が、価値観の表明であることをやめ、規制当局に示せるものになる所です。

主要原則

評価を、ローンチ前にボルトで留める後付けではなく、第一級のプロダクトとして扱います。
モデルを持ち上げる玩具の例ではなく、実際の使用を映す代表的なデータで測定します。
速い反復のためのオフライン評価と、真実のためのオンライン評価を組み合わせます。
人間の判断をアンカーとして使い、すべての自動化された採点者をそれに対して較正します。
評価セットを汚染から守らなければ、数字があなたに嘘をつきます。
評価を継続的インテグレーションにゲートとして配線し、品質が静かに退行できないようにします。
本番でも測り続けます。コードが変わらなくても品質はずれるからです。

推奨事項

評価駆動開発を採用する

プロンプトを調整したりモデルを選んだりする前に、評価を書きます。これはテスト駆動開発を映します。「良い」が測定可能な言葉で何を意味するかを定義し、それに向けて築きます。ここでの評価とは、各出力に数字や評点を返す採点方法と組になった、入力のデータセットを意味します。小さく始めます。実際のユーザーの意図を反映する注意深く選んだ20のケースは、千のランダムなものに勝ります。システムがどこで失敗するかを学ぶにつれて集合を育て、すべての本番の失敗を恒久的なケースとして戻し、同じ間違いが気づかれずに戻れないようにします。

評価駆動開発は、チームの行動を変えます。良いの定義が書き留められ実行可能なとき、変更が役立ったかどうかについての議論は、好みの問題ではなく確認可能になります。評価セットを、それが測るプロンプトとコードのすぐ隣の、バージョン管理されたレビュー済みの成果物にしてください。

オフライン評価とオンライン評価を分け、両方を使う

オフライン評価は、固定のデータセットを管理された環境でシステムに通すもので、速く、安く、繰り返し可能なので、何かが出荷される前にバージョンを比較できます。オンライン評価は、タスクの完了、エスカレーション率、親指の上下のフィードバック、下流のビジネスの成果のような指標で、実際のユーザーとともにライブのシステムを測ります。オフラインは変更がおそらく安全かを教え、オンラインは実際に機能したかを教えます。両方が必要です。オフラインの集合は現実を完全には捉えられず、オンラインのシグナルは唯一のガードレールにするには遅れて届くからです。

二つをループにつなげます。オンラインの指標が下がったり、ユーザーが悪い答えに旗を立てたりしたら、そのケースを捉え、ラベルを付け、オフラインの集合に折り込みます。実験を、プロダクト分析と実験(7.4章)の領域である、あらゆるプロダクトの変更に使うのと同じ管理された比較を通して行います。新しいモデルがタスクの成功を上げると示すA/Bテストは、どんなオフラインのスコアよりも価値がありますが、テストを実行する勇気を与えたのはオフラインのスコアです。

代表的な評価セットを築き、汚染から守る

評価は、そのデータの分だけ誠実です。ゴールデンデータセット、つまり検証済みの期待される出力や採点のルーブリックを伴う入力の選り抜きの集まりを築き、ユーザーが尋ねるものの実際の分布を映します。一般的なケース、まれだが重要なケース、敵対的なケース、システムが現在間違えるケース。まともな平均の中に失敗するカテゴリーを隠すのではなく、セグメントごとの品質を読めるよう、層別化します。間違った答えの上に築かれたゴールデンセットは、ないよりも悪いので、ドメインの専門家に期待される答えを検証してもらいます。

それからそのデータを汚染から守ります。テストセットの汚染は、評価の例がモデルの訓練データやプロンプト自体に漏れ、モデルが事実上答えを見たために良く機能するように見えるときに起こります。だから、モデルが公開ベンチマークで見事なスコアを出しながら、実際のトラフィックでつまずくことがあるのです。評価データの一部を非公開に保ち、信頼できない第三者には決して送りません。集合を時間とともに更新します。開発者が評価セットに対してスコアが無意味になるまでプロンプトを手で調整する、より微妙な漏れ、本物の改善ではなくテストへの過学習の一形態に注意します。ときどきしか見ない新しい保持セットを取っておきます。

タスクに合う指標を選ぶ

測定を出力の形に合わせます。正しいラベルがある分類と抽出では、古典的な指標が適用されます。適合率と再現率(旗を立てた項目のうちいくつが正しかったか、正しい項目のうちいくつを見つけたか)、それらのバランスをとるF値、完全一致の精度。自信のある確率が重要なものについては、較正、つまり述べられた80パーセントの確信が約80パーセントの確率で正しいかを測ります。よく較正され、不確かなときを知るモデルは、過信するモデルよりはるかに安全だからです。

生成的な出力はより難しい。BLEUやROUGEのような参照ベースの指標は、もともと機械翻訳と要約のために作られ、重なる単語や句を数えることで、生成されたテキストを参照テキストと比較します。安く繰り返し可能ですが、品質の弱い代理です。表面的な重なりを報い、参照と違う言い回しの正しい答えを罰します。粗い回帰のシグナルとして使い、良いの定義としては使いません。自由回答のタスクには、ルーブリックベースの採点がよく機能します。明示的な基準(根拠づけられているか、完全か、安全か、正しい書式か)を定義して、それぞれを採点します。ルーブリックは主観的な品質を、読めてレビューできるものにします。

LLM-as-a-judgeを使うが、人間に対して較正する

生成的な出力を手で採点することはスケールしないので、チームはますます、強力な大規模言語モデルを自動化された審査員として使い、入力、出力、ルーブリックでプロンプトし、採点を求めます。このLLM-as-a-judgeアプローチは速く、驚くほど有能ですが、管理しなければならない本物のバイアスを伴います。審査員は、より長い答えを好み、一対比較で最初に示された選択肢を好み(位置バイアス)、自分の書き方を報い、流暢だが間違った推論に左右されえます。チェックしなければ、偏った審査員は、自信に満ちた、正確で、間違った数字を与えます。

審査員を人間のラベルに対して較正します。人に標本を採点してもらい、モデルの審査員がそれにどれだけよく一致するかを確認し、信頼できるほど一致が高くなるまで審査員のプロンプトを調整し続けます。既知のバイアスを意図して減らします。選択肢の順序をランダム化し、長さを制御し、裸の数字ではなく、理由を伴うルーブリックに基づいた採点を求めます。審査員を、固定された神託ではなく、定期的な再較正を要する測定器として扱います。審査員を築くときは、利用できる最も有能なモデルを既定にします。弱い審査員は弱い物差しだからです。

真実のために人間をループに保つ

人間による評価は、すべての自動化された指標が測られるアンカーのままなので、それをうまく行うことに投資します。明確なアノテーションのガイドラインを書き、アノテーターを訓練し、アノテーター間の一致、つまり独立したレビュアーが同じケースに同じ評点を与える度合いを測定します。低い一致は通常、レビュアーが不注意なのではなく、ルーブリックが曖昧なことを意味するので、ルーブリックを直します。賭け金の高い領域では、法律や医療の答えを判断する文脈を欠くクラウドワーカーではなく、資格のある専門家を使います。

安全と敵対的な堅牢性のためにレッドチームで試す

標準の評価セットは、システムが妥当な入力に対して正しいことをするかを測ります。レッドチーム演習、つまり自分のシステムを意図して攻撃し、どこで誤動作するかを見つけることは、圧力のもとで何が起こるかを測ります。プロンプトインジェクション、脱獄、安全でないコンテンツ、プライバシーの漏洩、偏った出力を探ります。一回限りの演習ではなく、繰り返し可能なスイートにします。成功した攻撃のすべてを恒久的な回帰ケースに変え、直された脆弱性が直されたままであるようにします。この仕事は、責任あるAIと信頼できるAI(6.5章)に直接つながり、規制対象の設定では、安全レビューを満たす証拠であることがよくあります。

エージェントをエンドツーエンドのタスクの成功で評価する

多くのステップにわたって計画し行動するエージェントは、一度に一つの出力で判断できません。重要なのは、タスク全体が成功したかです。エージェントは会議を予約したか、チケットを解決したか、ワークフローを正しく安全に完了したか。エージェントが現実的だが安全な固定物に対して行動できる、サンドボックス化された環境でタスクレベルの評価を築き、最終的な成果と軌跡、つまりそこに至るために取ったステップとツール呼び出しの連なりを採点します。危険あるいは無駄な経路を通って得られた正しい答えも、依然として問題です。これは、一つの間違った行動が本物の結果を招きうる、AIエージェントとエージェント型システム(6.7章)に不可欠です。

評価をCIに配線し、本番を監視する

評価を自動にします。あらゆるプロンプト、モデル、検索の変更で、オフラインのスイートを継続的インテグレーション(CI)で実行し、より広いテスト戦略(2.4章)に根ざした実践として、ユニットテストでゲートするのと同じように、それでマージをゲートします。スコアは雑音が多いので、完全な実行を要求するのではなく、閾値と傾向でゲートし、主要な指標が下限を下回るか、設定した余裕を超えて退行したらビルドを失敗させます。それから本番で見続けます。オフラインのテストが見逃す緩やかな劣化を捉えるために、品質のシグナル、出力の分布、入力のドリフトを監視し、それは機械学習エンジニアリングとMLOps(6.2章)のオブザーバビリティの実践につながります。ローンチ時に正確だったモデルは、それが記述する世界が足元で変わるにつれて衰ええます。

トレードオフ: 長所と短所

評価のアプローチ	長所	短所	最適な場合
人間による評価	最高の忠実度、ニュアンスを捉える	遅く、高価で、スケールしにくい	真実、賭け金が高い、審査員の較正
LLM-as-a-judge	速く、安く、大きな集合にスケールする	偏りがある。較正が必要	生成的な出力の頻繁なオフライン実行
参照ベースの指標(BLEU、ROUGE)	安く、決定的で、繰り返し可能	本物の品質の弱い代理	粗い回帰のシグナル。最終的な判定ではない
古典的な指標(適合率、再現率、F値)	客観的で、よく理解されている	正しいラベルのあるタスクにしか合わない	分類、抽出、検索
公開ベンチマーク	モデル間で比較可能。セットアップ不要	汚染。あなたのタスクへの貧しい適合	早期のモデルの絞り込み。リリースのゲートではない
オンライン評価(A/B、フィードバック)	実際のユーザーと成果を反映する	遅い。露出の後に届く	変更が実際に役立ったことの確認

中心的な緊張は、速度対忠実度です。人間による評価は最も信頼でき最もスケールせず、自動化された採点はその逆です。解決は、それらを層にすることです。絶え間ない反復には速く安い方法を使い、定期的な較正でそれらの方法を人間の判断に結びつけ、完全な人間のレビューは、最も賭け金の高い決定と、安い指標がまだ現実に追随しているかの確認のために取っておきます。二つ目の緊張は、オフラインの利便性対オンラインの真実です。オフラインの集合は速く動けるようにしますが、本番を完全には映さないので、強いオフラインのスコアを、終わったという証明ではなく、慎重なオンラインのテストを実行する許可として扱ってください。

チームで議論すべき問い

「十分に良い」の基準は何で、それを定義する評価セットを誰が所有しますか。 すべてのAI機能には暗黙の品質の閾値があり、暗黙のままだと、各エンジニアが勘で自分のものを設定し、論争はその部屋で最も年長の人が決着させます。基準を、セグメントごとの目標スコアを伴う実行可能な評価セットとして書き留めることで、その論争は測定可能な問いに変わります。成功の現在の定義、その背後のデータ、実際に誰がそれを保守しているかの誠実な説明を持ち込んでください。所有者のない評価セットは、手入れされないコードと同じくらい速く腐るからです。基準がリスクの階層によって異なるかを決めてください。公開された法律の答えは、社内のブレインストーミングの補助より高い基準を満たすべきです。答えは、測定がユーザーとの間に立たないままAIの変更を誰かが今出荷できるかを教えるはずです。
評価の数字が、汚染されたり過学習したりしておらず誠実だと、どうやって知りますか。 スコアが役立つのは、本物の品質を予測するときだけで、それがそうでなくなる方法は多くあります。ベンチマークのデータが訓練に漏れる、数字が無意味になるまで開発者がテストセットに対してプロンプトを調整する、検証されなかった答えの上に築かれたゴールデンデータセット。評価データがどこから来たか、そのどれだけが非公開に保たれているか、どれだけ頻繁に更新されるかの証拠を持ち込んでください。まれにしか見ない新しい保持セットを保っているかを議論してください。誰も最適化の対象としていない数字を、少なくとも一つ持つためです。モデルが影響したことのないデータでもスコアが保たれる理由を説明できないなら、自分の反射を測っているのです。
人間はどこでループに留まり、自動化された審査員をそれらに較正し続けるにはどうしますか。 LLM-as-a-judgeと参照指標は、規模で採点できるようにしますが、確認しなければ見えない形で人間の判断からずれます。自動化された採点と人間によるレビューの間の現在の一致率、それを最後に測ったのはいつか、どのバイアス(長さ、位置、スタイル)をテストしたかを持ち込んでください。コストにかかわらず、どの決定が人間の採点者を要するかを決めてください。通常は最も賭け金の高いものと、自動化された審査員を再較正するために使われるものです。アノテーションの品質も話してください。一貫しない人間のラベルに対して較正された審査員は、その不整合を引き継ぐからです。答えは、一度きりの祝福ではなく、再較正のスケジュールを生むべきです。
今日、どのAIの変更が評価でゲートされ、どれがまだ誰かの自信だけでユーザーに届いていますか。 一部の変更では走り、他では走らないゲートは、安全の幻想を与えながら、本物の回帰をゲートされない経路にすり抜けさせます。静かなプロンプトの微調整、検索の調整、変更に数えられると誰も思わなかったモデルのバージョンの更新。大きなチームでは、危険はプロンプトに触れられる人の数とともに増えます。ゲートされない各経路が、どのデータセットも見たことのない回帰を出荷する方法だからです。現在CIでオフラインのスイートを起動する変更の種類の一覧、起動しないもの、ゲートされない変更に起因した直近のインシデントを持ち込んでください。ゲートが徹底する閾値と傾向を決めてください。雑音の多いスコアは、完全な実行の要求ではなく、下限と回帰の余裕を要求するからです。企業と政府の設定では、ゲートをリリースの記録自体に結びつけ、変更が測定されたという証拠が、誰かが一度撮ったスクリーンショットではなく、監査証跡の一部になるようにしてください。
評価にいくら使っていて、その支出は各機能のリスクに合っていますか。 評価は無料ではありません。アノテーションの労働、自動化された審査員が実行のたびに燃やす計算、ゴールデンデータセットを代表的に保つ継続的な仕事のすべてに本物のお金がかかり、これらのコストに決して名前を付けないチームは、賭け金の高い機能に投資不足になるか、使い捨ての機能に金メッキを施しがちです。相反する引力は忠実度と予算の間にあります。最も信頼できる方法である専門家による人間のレビューは、最もスケールしないので、どこでも賄えず、どこで価格に見合うかを決めなければなりません。評価の実行ごとの現在のコスト、機能ごとのアノテーションの時間、各システムの誠実なリスクの階層を持ち込み、お金がどこへ行き、危険がどこに住むかを部屋が見られるようにしてください。企業にとって、これは多くのチームにわたってアノテーションと計算を償却する、共有の評価プラットフォームの最も強い論拠で、政府機関にとっては、リスクの階層は、監督機関が後で要求する証拠の深さに直接対応づけられるべきです。
より良いモデルが現れたとき、それが役立つかをどれだけ速く証明でき、切り替えを許されるのは誰ですか。 評価スイートの価値が最も鋭く実現されるのは、より強いモデルが出荷される日です。新しいモデルに対して、午後のうちにゴールデンデータセットとレッドチームのスイートを実行できるチームは、手で採点するチームが何か月も見逃す改善を採用できるからです。緊張は速度と慎重さの間にあります。より良いモデルが現れた日に動きたく、平均のスコアが隠す答えのカテゴリーを、入れ替えが静かに劣化させることは許せません。新しいプロバイダーに対して完全なオフラインの比較を実行するのに現在かかる時間、評価セットがモデル間で可搬か、回帰が最も重要になるセグメントを持ち込んでください。規制対象と公共の設定では、モデルの変更を承認する権限を誰が持ち、どんな文書化された証拠を要求するかを名指ししてください。市民に向き合う決定の背後のモデルを文書化せずに入れ替えることは、まさに監査人があなたに正当化を求める変更だからです。

セクター別の視点

スタートアップ。 作れる最小の誠実な評価を築き、プロダクトとともに育ててください。それぞれ検証済みの期待される答えを持つ20から40の実際のケースのスプレッドシートを、マージのたびにスクリプトで実行することは、あなたのニッチのどんな公開ベンチマークにも勝り、ほとんどコストがかかりません。手作業の採点が実際に痛くなるまで、共有のプラットフォームとLLM-as-a-judgeは飛ばしますが、同じ恥を二度かかないよう、ユーザーが報告したすべての失敗を、初日から集合に折り込んでください。

小規模事業者。 おそらく評価の専門家はおらず、AIはツールに埋め込まれたものを買っているので、あなたの仕事は、証拠を築くのではなく要求することです。各ベンダーに、品質をどう測定したか、あなたのものに似たデータでテストしたか、自分が選んでいない更新の後の回帰にどう気づくかを尋ねてください。ツールを自分で抜き打ち確認するために、自分の実際のケースの小さな非公開の集合を保ってください。顧客に届く間違った自動化された答えは、その確認の数分よりはるかにコストがかかるからです。

大企業。 見返りは、十数のチームがそれぞれ採点を再発明しないための、共有の評価プラットフォームです。ゴールデンデータセットの共通のストア、CIでゲートされるオフラインのスイート、較正スコアとともに登録されたLLM審査員のプロンプト、機能ごとのオンライン指標。その上に、必要な基準とリリース前の承認を設定するリスクの階層でガバナンスを重ね、賭け金の高い機能が社内の補助より高いゲートを通るようにします。プラットフォームは、チームにわたってアノテーションと計算を償却し、それが、各グループに即興させるのではなく、築くことの最も強い理由です。

政府。 評価は、単に行われるのではなく、監査可能でなければならないので、すべてのリリースについて、データセットのバージョン、指標、レビュアーの名前、承認を説明責任の証拠として保管してください。レッドチームのスイートは、システムが情報源にない政策や法律を発明することを拒否するのを証明すべきで、調達は、ベンダーにモデルをどう評価したかの開示と、あなたの評価データの可搬性を認めるよう求めるべきです。監督機関がツールが安全だとどう知るかを尋ねるとき、答えは安心ではなく、日付のある記録でなければなりません。

事例

スタートアップ。 AIの契約レビューアシスタントを築く4人の会社は、社内の弁護士が、旗を立てるべきリスクをラベル付けした、40の実際の条項のスプレッドシートから始めました。すべてのプロンプトの変更は、マージ前にスクリプトでその集合に対して実行され、スコアがプルリクエストに表示されました。ユーザーが見逃された条項に旗を立てると、それはすぐにシートに入ったので、集合はプロダクトとともに育ちました。量が増えると、説明の品質を採点するためにLLM-as-a-judgeを加えましたが、標本で弁護士と一致することを確認した後にだけでした。安く、非公開で、誠実であることは、彼らのニッチのどんな公開ベンチマークにも勝りました。

大企業。 大手銀行は、サポート、検索、社内ツールにわたって十数のAI機能を動かしており、各チームが異なる採点をしていました。共有の評価プラットフォームを築きました。ゴールデンデータセットを保存し、CIでオフラインのスイートを実行し、較正スコアとともにLLM審査員のプロンプトを登録し、機能ごとにオンライン指標を追跡する共通の場所。ガバナンスは、必要な基準とリリース前に必要な承認を設定するリスクの階層としてその上に座りました。新しい不正の説明機能は、評価セットがレビューされ、レッドチームのスイートが合格し、責任ある所有者が結果に署名するまで、出荷できませんでした。プラットフォームの再利用により、チームは測定の仕方ではなく、自分たちの領域について議論しました。

政府。 公衆衛生機関は、職員が承認されたガイダンスから給付の質問に答えるのを助けるアシスタントをデプロイしました。間違った答えが誰かの受給資格に影響しうるので、評価は監査可能でなければなりませんでした。すべてのリリースが、一般的な質問、エッジケース、敵対的なプロンプトをカバーする文書化された評価セットを実行し、結果、データセットのバージョン、指標、レビュアーの名前が説明責任の証拠として保管されました。レッドチームのスイートが、システムが情報源にない政策や法律を発明することを拒否するのを確認しました。監督機関が機関にツールが安全だとどう知ったかを尋ねたとき、答えは安心ではなく、日付のある記録でした。

ビジネスケース: 動機、ROI、TCO

評価は、他のあらゆるAIへの投資をより安全で速くすることで元を取ります。その投資収益率(ROI)は、より少ない本番インシデント、チームが自信をもってプロンプトとモデルを変えられるためのより速い反復、より良いモデルが現れた日に、役立つかを証明できるので採用できる能力として現れます。その価値を測る最も明確な方法は、その不在のコストです。一回の公開のハルシネーション、偏った出力、データ漏洩は、何年もの評価インフラストラクチャよりはるかに多くの是正、失われた信頼、規制上の露出のコストがかかりえます。それは、CIで無料で回帰を見つけることと、新聞でそれを見つけることの違いです。

総所有コスト(TCO)は本物で、名指しする価値があります。アノテーションの労働、自動化された審査員が消費する計算、使用が移るにつれて評価セットを代表的に保つ継続的な仕事に払います。企業の規模では、共有のプラットフォームがこれの大半を多くのチームにわたって償却し、それが、各グループに即興させるのではなく築くことの最も強い論拠です。リーダーシップに論拠を示すには、具体的なリスク(あなたの領域での一回の悪い公開の答えのコスト)を具体的な能力(新しい各モデルを安全に採用する速度)と組にし、評価を、組織が無謀にならずに速く動けるようにする統制として枠づけてください。

アンチパターンと落とし穴

雰囲気での出荷。 データセットも繰り返し可能なスコアもなく、手でいくつかのプロンプトを試してAIの変更を判断すること。
ベンチマークの劇場。 汚染と分布の不一致を無視して、強い公開ベンチマークのスコアを、システムがあなたのタスクに合う証明として信頼すること。
評価セットへの過学習。 新しい保持セットなしに、数字が高く無意味になるまで同じ固定の集合に対してプロンプトを調整すること。
較正されていない審査員。 LLM-as-a-judgeをデプロイし、人間の採点者との一致を確認せずにそのスコアを信頼すること。
指標崇拝。 BLEUやROUGEを品質であるかのように最適化し、参照テキストにたまたま重なる、より悪い答えを出荷すること。
一回限りのレッドチーム。 ローンチ前に一度システムを攻撃し、発見を恒久的な回帰テストに決して変えないこと。
オフラインだけの自信。 良いオフラインのスコアが機能の動作を意味すると信じ、本物の成果のオンライン測定がないこと。
孤児の評価セット。 誰も所有せず、本番の失敗を決して吸収せず、現実を映さなくなっていくデータセット。

成熟度モデル

レベル1、開始: AIの変更は、誰かがたまたま心配したとき、反応的に、少数の例で手作業で判断されます。データセットも、繰り返し可能なスコアも、ゲートもありません。回帰はユーザーに見つけられ、システムが先月より良いか悪いかを誰も言えません。
レベル2、発展: 小さなゴールデンデータセットを保ち、大きな変更の前に手で実行するチームがあり、いくつかの古典的あるいは参照ベースのスコアが存在します。重要な機能には人間によるレビューが行われますが、採点はチーム間で一貫せず、評価は自動化もゲートもされず、各グループが異なって行います。
レベル3、標準化: オフラインのスイートが、あらゆるプロンプト、モデル、検索の変更で継続的インテグレーションで走ってマージをゲートし、組織全体で一つの文書化された実践に従います。LLM-as-a-judgeは人間のラベルに対して較正され、レッドチーム演習は繰り返し可能なスイートで、データセットは所有され、バージョン管理され、本番の失敗によって供給され、汚染は積極的に防がれています。
レベル4、管理: 評価は、ベースラインに対するデータで測定され、制御されます。審査員と人間の一致率、レッドチームの合格率、セグメントごとのスコア、オンラインのタスクの成功、ドリフトが時間とともに追跡され、マージは単一の完全な実行ではなく、閾値と回帰の余裕でゲートされます。アノテーションのコストと実行ごとの計算が機能ごとに予算化され、再較正はスケジュールに沿って行われ、各結果は責任ある所有者と承認を伴います。
レベル5、オーケストレーション: 共有の評価プラットフォームが組織全体に仕え、オフラインとオンラインの評価がビジネスの成果に結びついた継続的なループを形づくります。新しいモデルは、到着した日に可搬な評価セットに対して証明され、ポートフォリオは使用とリスクが移るにつれて適応し、評価の証拠は規制当局と監督機関に対して監査可能で、一つのチームの失敗からの教訓がすべてのチームのデータセットに流れます。

議論のためのアイデア

オフラインのスコアが、オンラインの実験を正当化するのに十分強いとき、そして十分でないときを、どう決めますか。
あなたのリスクの状況にとって、人間による評価と自動化された採点の正しい比率は何で、どれくらいの頻度で見直すべきですか。
公開ベンチマークとあなたの非公開の評価セットが、どのモデルが良いかで食い違うとき、どちらを信頼し、なぜですか。
CIで実行するには遅すぎるものに膨れ上がらせずに、ユーザーの行動が移るにつれて評価セットを代表的に保つにはどうしますか。
あなたの領域のレッドチームのスイートには何が属し、攻撃を設計する資格があるのは誰ですか。
すべてのステップを採点するコストに溺れずに、最終的な答えだけでなくエージェントの軌跡をどう評価しますか。

要点

AIの評価は、出力が非決定的で正解が一つであることはまれなので、ソフトウェアのテストと異なります。正確な値を断言する代わりに、代表的なケースにわたって品質を測ります。
評価駆動開発を実践します。まず測定可能な品質を定義し、それに向けて築き、すべての本番の失敗を集合に戻します。
速度と忠実度で方法を層にします。絶え間ない反復には安い自動化された採点、アンカーとして人間の判断、それらを揃えておく較正。
汚染と過学習から守らなければ、実際のシステムがユーザーを失望させる間も、数字があなたを持ち上げます。
オフラインの評価をゲートとしてCIに配線し、本番で品質とドリフトを測り続けます。ローンチ時に良かったモデルは衰ええるからです。

参考文献とさらなる読み物

Chip Huyen, AI Engineering: Building Applications with Foundation Models.
Lianmin Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.
Kishore Papineni et al., BLEU: A Method for Automatic Evaluation of Machine Translation.
Chin-Yew Lin, ROUGE: A Package for Automatic Evaluation of Summaries.
Percy Liang et al., Holistic Evaluation of Language Models (HELM).
Deep Ganguli et al., Red Teaming Language Models to Reduce Harms: Methods, Scaling Behaviours, and Lessons Learned.
OWASP Foundation, OWASP Top 10 for Large Language Model Applications.
National Institute of Standards and Technology, AI Risk Management Framework.