評価

docs.scrimba.com

プロンプトを変更して1回試してみたところ答えが良く見えたので、そのままリリースしたら、1週間後にユーザーが静かに悪化したケースに当たった。評価（evaluationの略）はその解決策です。AI機能が機能しているかの反復可能なテストであり、入力と良い出力がどのようなものかを対にしたセットで、毎回同じ方法で採点されるため、変更が実際に役に立つかどうかを判断できます。モデルは確率的なブラックボックスで、同じ質問に実行のたびに異なる答えを返すため、測定が唯一の知る方法です。そしてこの規律こそが、デモと製品を分ける多くの要素です。

目視評価がなぜ失敗するのか

AI の答えを手で確認するのは最初は問題がないように感じます。プロンプトを実行し、返答を読んで、良く見えるので先に進みます。問題は、3つのことがあなたに静かに働きかけており、すでにそのすべてに出会っているということです。

次の3つがあります：

• 出力は変動します。 同じプロンプトでも実行のたびに異なる答えを返すため、1つの良い結果は次の実行も良い結果になることを約束しません。
• 変更は回帰を引き起こします。 1つのケースを修正するプロンプト編集は、多くの場合、見ていない別のケースを壊します。
• スケーラビリティがありません。 5つの答えは読むことができます。行を変更するたびに500の答えを読むことはできません。

これらはいずれも、あなたが何か間違ったことをしたことを意味しません。目視評価がこのサイズの仕事には不向きなツールであることを意味しており、それを行うより良い方法があります。

Juno目視評価がなぜ失敗するのか 答えを手で読むことは3つの理由で失敗します。すべてモデルの仕方に根ざしています。出力は実行から実行で変動し、編集は見ていないケースを静かに壊し、百の答えがあったら手では対応できません。これは規律の問題ではなく、仕事のサイズに不向きなツールです。良いニュースは、修正は親切で、次に来ることです。

1つの返答を目視評価することは、ほぼ何も教えてくれません。その理由はモデルの動作方法にあります。出力は非決定論的であり（同じプロンプトでも実行のたびに異なる答えを返す）、単一の返答は1のサンプルサイズです。それが実際にどの程度の頻度で機能するかを推定するために多くの実行を必要とするため、合格率（ケースが正しく出てくる割合）を教えることはできません。

回帰が隠れるのは関連する理由があります。1つのケースを手で修正して、他のケースの記録がないため、次の編集は見ることをやめた何かを壊す可能性があります。それを見る唯一の方法は、毎回同じ方法で採点される固定されたケースセットであり、低下は番号として表示されます。本番環境での驚きではなく。

数学の上に人間の問題があります。手作業による審査は人によって、また気分によって変わります。同じ答えは月曜日には良く見えて、金曜日には弱く見えます。そこで「それは良く見える」を固定されたケースセットに対する測定された合格率に変換する必要があります。同じケースに対する雰囲気を数値に変えてください。

Juno目視評価がなぜ失敗するのか 1つの返答はサンプルサイズが1なので、モデルが1回動作したことを教えているだけで、どの程度の頻度で動作するかは教えてくれません。実際の合格率を見るには多くのケースを実行します。回帰を捕捉するには、そのケースセットを修正し、毎回同じ方法で採点します。手作業による審査は審査者に応じて変動するため、「良く見える」を測定された数値で置き換えることです。

ポイント調査が失敗するのは、あなたが不注意だからではなく、選択バイアスが組み込まれているためです。動作すると予想されるケースを見るため、確認しない行動は、ユーザーの前で回帰する行動です。追跡しない指標は、まさに動く指標です。

ベースラインスコアがなければ、すべての品質の変更は自分に話すストーリーです。変更を特定の編集に帰することはできず、変更セットを二分探索してどれが**合格率**（正しく出てくるケースの割合）を低下させたかを見つけることはできません。測定していないからです。「それはより良く感じられる」は矛盾する何もないために存在しています。

雰囲気ベースの反復も過剰適合します。同じ小さなサンプルの例を繰り返し入力し、それらが正しく見えるまで調整し、本物のトラフィックが別の場所に静かに移動している間、その小さなプライベートセットにプロンプトをそっと訓練します。手作業による審査はその分布シフトを見ることはできません。新しい入力は入力していないものであるため。バージョン管理された評価セットと追跡されたスコアは、変更が良く感じられるのではなく役に立つと言う唯一の方法です。反復と推測の違いです。

Juno目視評価がなぜ失敗するのか 雰囲気で出荷し、その後、ポイント調査しなかった1つのパスがエラーログを点灯するのを見たことがあります。選択バイアスがその仕事をしています。ベースラインは帰属がなく、二分探索もなく、変更がどの編集によってその数が動いたかを証明することはできません。バージョン管理されたセットと追跡されたスコアを保つか、入力し続けている5つの例に過剰適合している間、実際のトラフィックは見えない場所に走ります。

評価セットを構築する

評価セットはテストケースのリストです。各ケースには、入力と、その入力の良い出力がどのようなものかがあります。小さく始めてください。共通の状況といくつかのトリッキーなエッジケースをカバーする10から20のケースは、何もないより遠かに有用で、野生での新しい失敗を発見するときにセットを拡大できます。

eval_set = [
    {"input": "食べ物が冷たく遅かった。", "expected": "NEGATIVE"},
    {"input": "人生最高の食事です!", "expected": "POSITIVE"},
    {"input": "それは良かった、特に特別なことはなかった。", "expected": "NEUTRAL"},
    # ...発見するときに実際のケースとエッジケースを追加します
]

ユーザーが悪い答えを報告した場合、それが与えるべき出力とともに、セットに追加してください。その後、評価セットは、あなたが繰り返したくないすべての間違いの成長するメモリになります。修正したバグは保つテストになるのと同じ方法です。

Juno評価セットを構築する 評価セットはテストケースのリストです。入力と、良い答えが何かを示します。日常の状況と数個のトリッキーなものをカバーする10から20で始めます。ユーザーが悪い答えに当たるたびに、それが与えるべき答えとともに追加して、セットはあなたが繰り返したくないすべての間違いを静かに記憶します。

**評価セット**は、テストケースのコレクションであり、各ケースは入力と良いと認める出力を対にしたものです。重要な数値はサイズではなく、カバレッジです。20個の選別されたケースセットは、毎回50個の使い捨てケースに勝ちます。

3つのことをカバーするようにしてください。ユーザーが実際に達する一般的なパス、2つのラベルが近い決定の境界（ライン上の曖昧なケース）、そしてあなたが既に見ているの既知の失敗モード。チェリーピックされた親切な入力はスコアを良く見させ、何も教えてくれません。セットを実トラフィックの代表にしてください。

ユーザーが報告するすべてのバグは、セット内の永続的なケースになります。それを回帰スイートに変えます。修正されたバグはケースが毎回実行されるようになったため、修正されたままです。期待される出力がフリーテキストではなく構造化されている場合、ラベルやJSONフィールドのような場合、完全一致比較で採点できます。これは明確で曖昧ではありません。構造化出力を参照してください。

チューニングに対して決してを使わない別の保持されたスライスを保つてください。プロンプトを調整して、見ている正確なケースに合格するまで、あなたが既に研究した答えで自分自身を採点しており、スコアはもう何も意味しません。

Juno評価セットを構築する 生のサイズをカバレッジが上回ります。一般的なパス、ラベル間の曖昧な境界、そして既に見たことのある失敗を打ちます。報告されたすべてのバグを永続的なケースに変えて、セットを回帰スイートのように機能させてください。見ないことを保つ保持されたスライスを保つか、学習したケースで自分自身を採点しています。

**評価セット**をプロンプトの隣に正しくバージョン管理されたアセットとして扱ってください。2つは一緒に移動し、プロンプト変更は静かに良い答えが何をカウントするかをシフトできるためです。セットのラベル品質は、メトリックの上限です。1つの間違った「expected」値があなたのスコアをキャップし、静かに間違ったレッスンを教えるため、ラベルを慎重にキュレーションすることはケースの収集と同じくらい重要です。

テストリークに対するガード。正確なセットに合格するまでチューニングする場合、その数は劇場です。反復している間は見ないスライスを保つ、時間をかけて回転させて、それが遅く兎に角チューニングループに漏れないようにしてください。

クラスバランスを監視してください。90パーセントが明確にポジティブなセットは、実際に重要な10パーセントのすべての失敗を隠している間、お世辞のように見える数値を報告します。難しいケースと珍しいケースが実際の重みを持つようにサンプリングしてください。デスクで決して発明しないフレージングを表面化させるため、想像ではなく本番ログからケースを取得してください。

セットが腐ることを受け入れてください。製品がシフトするにつれて、古いケースはユーザーが送るものを反映することを停止し、新しい失敗モードが表示されます。セットは見たことがありません。キュレーションは進行中の仕事であり、1回限りの構築ではありません。

Juno評価セットを構築する セットはプロンプトの隣に正しくバージョン管理されたアセットであり、そのラベル品質はメトリックの厳しい上限です。1つの悪い期待値があなたの全体的なスコアをキャップします。スライスを保つと回転させるか、報告された数は劇場です。クラスバランスを監視し、ログから実ケースをサンプリングし、製品が移動するときセットが腐ることを想定して、キュレーションは本当に終わることはありません。

採点方法

異なるタスクは異なる採点が必要なため、最初のステップは、期待する答えの種類にチェックを一致させることです。

• 完全一致は1つの正しい答えがある場合に機能します。分類ラベル、抽出されたフィールド、はい、またはいいえ。出力を期待値と直接比較します。
• 基準ベースの採点は、サマリーや返答のように1つの正しい答えがない場合に機能します。出力が条件を満たしているかをチェックします。サマリーが重要な事実に言及しているか。50語未満か。トーンは丁寧か。
• LLMジャッジは、基準に対して出力をスコアリングするために、2番目のモデル呼び出しを使用します。シンプルなチェックが取得できない曖昧な品質の質問にスケーリングしますが、ジャッジ自体はモデルであり、間違う可能性があり、今後は人間の判断に対してそれをサニティチェックします。

# 評価セット上での完全一致採点
def run_evals(eval_set, classify):
    passed = 0
    for test in eval_set:
        output = classify(test["input"])
        if output == test["expected"]:
            passed += 1
        else:
            print(f'FAIL: "{test["input"]}" -> got {output}, wanted {test["expected"]}')
    print(f"{passed}/{len(eval_set)} passed")

完全一致は始めるために最も親切な場所であり、以前の章から分類と抽出の仕事に完璧に適合します。LLM ジャッジのアイデアが機能する理由は、答えが基準を満たしているかどうかをスポットするは、多くの場合、答えを生成するのが簡単だったことよりも簡単な予測であり、エッセイを書くのは簡単だった方法をレビューすることと同じです。しかし、ジャッジは同じ欠陥を持つ別の予測子であり、そのスコアを有用な推定として扱い、明確なルーブリックを与え、時々サンプルで自分の成績をチェックしてください。

Juno採点方法 答えに合う確認を選びます。1つの正しい答えがある場合は完全一致、いくつかの良いものがある場合は基準、ファジーな品質の場合は2番目のモデルをジャッジとして使用してください。完全一致は最も穏やかな開始であり、既に練習した分類と抽出に上手に並びます。しかし、ジャッジもモデルであるため、時々自分で成績を見てください。

タスクに採点者を一致させ、その後、気にすることをまだキャプチャする最も安い採点者にアクセスしてください。**採点者**は、出力が合格したかどうかを決定するコードまたはモデル呼び出しであり、間違った選択は実際の失敗を逃すか、良かった答えにフラグを立てます。

完全一致はラベルと抽出されたフィールド用です。出力を期待値と比較し、結果は決定論的であるため、それを信頼できます。これは構造化出力と自然に組み合わされます。モデルが固定されたスキーマを返すため、フリーテキストの散文の代わりに比較するもの空をクリーンに提供します。

プログラムによる基準は中間地帯を安く覆います。長さを確認し、必要な文字列が存在することを確認し、JSONが解析することを確認し、正規表現を実行してください。これらはモデル呼び出しなしでミリ秒で実行されるため、ジャッジに費用をかける前に、半構造化されたもの全てにそれらを使用してください。

LLM ジャッジはオープンエンドの品質の場合であり、サマリーまたは返答には多くの良い形があり、正確なターゲットはありません。ジャッジが一貫した標準を適用するように、書かれたルーブリックが必要で、ジャッジのグレードとサンプルの独自のラベルを比較するキャリブレーションチェックが必要です。採点者はコードであることも信頼する必要があることを覚えておいてください。信頼できない採点者はあなたに自信のある間違ったスコアを渡します。

Juno採点方法 重要なものをキャッチするさらに安い採点者を使用してください。ラベルとフィールドの場合は完全一致、長さ、有効な JSON、必要な文字列のプログラムによるチェック、オープンエンドの品質のためだけのモデルジャッジ。完全一致は固定スキーマが比較するものをクリーンに提供するため、構造化出力と良く組み合わされます。選んだもの何でも、採点者はあなたが信頼するコードであり、信頼できない採点者はあなたに自信のある間違ったスコアを渡します。

LLM ジャッジは最も興味深い方法で壊れる採点者であり、それに傾く前にそのバイアスを計画してください。**ジャッジ**は長い答えをサポートし、ペアを比較するときに最初のオプションを選び、スタイルのように読む文章に報酬を与え、その絶対スコアは不十分に、8回の実行は次回の実行から8ではありません。

ジャッジを自分で評価しているモデルとして扱ってください。ジャッジモデルをピンし、バージョン管理してください。更新すると、スコアはそれと共に移動するためです。ラベル付けされたサンプルで、ジャッジ対人間の合意を測定できるように、いくつかのアンカーサンプルを持つタイトなルーブリックをそれに与えてください。それをどの程度信頼するか知ります。

できる場所では、絶対的な1から10のスコアではなく、ペアワイズ比較を尋ねてください（「AまたはBが良いか」）。相対的な判断は、通常、モデルが調整された数にヒットするよう求めるより信頼できます。ジャッジをピン、ルーブリックをタイト、人間に対してチェックしてください。

循環性と法案を気をつけてください。同じモデルファミリーが独自の出力をジャッジングしはブラインドスポットを共有します。ジェネレータが行ったフローはジャッジが逃す可能性があるフローであり、スケールで各ケースをジャッジングすることは、最初の上に、2番目のモデル法案です。

Juno採点方法 ジャッジは意見を持ち、あなたが求めなかったことがあります。長い答えが好きで、最初のオプション、そしてそのように読む散文であり、絶対スコアは実行間で彷徨きます。ピン、バージョン、タイトなルーブリックで渡し、人間とどのくらい頻繁に同意するかトラック、あなたが採点者を採点しているためです。ペアワイズ比較に傾き、モデルが自身のファミリーを採点することをブラインドスポットを共有し、法案を倍にすることを認識してください。

すべての変更で実行する

評価セットは、実際に実行した場合にのみ有用です。プロンプトをコードのように扱ってください。プロンプト、モデル、または取得の変更を出荷する前に、評価を実行し、スコアを前のスコアと比較してください。数値が低下した場合、1つの手テストがたまたま良く見えたとしても、回帰を引き起こしました。

これはプロンプトエンジニアリングを推測から、自信を持って反復できるものに変えます。何かを変更し、測定し、より高くスコアされるものを保ち、より低くスコアされるものを破棄します。これは通常のソフトウェアを信頼できるようにするのと同じループで、AI機能のファジーな部分に適用されます。

スコアが低下した場合、回帰を引き起こしました。1つの幸運な手テストはセットをオーバーライドしません。毎回数値をタイブレーカーにしてください。

Junoすべての変更で実行する 評価セットは実行した場合にのみ役に立ちます。習慣にしてください。変更する前に評価を実行し、前回のスコアに対してスコアを確認してください。それが下がった場合、それは回帰を修正する必要があり、波状を無視する必要はありません。変更、測定、より高くスコアされるものを保つ、反復しています。

マージをテストスイートゲートの方法で変更をゲートするように、開発ループにeval実行をワイヤーしてください。プロンプト、モデル、または取得（サポートドキュメントを引き込むステップ）への変更は、セットを実行し、前回の実行にスコアを比較するまで出荷されません。1つの手テスト後の直感ではなく、番号は、変更が改善であるかどうかを決定します。

一度に1つの変数を変更してください。プロンプトを編集し、同じパスでモデルを交換した場合、スコアの移動には2つの可能な原因があり、どちらかに帰することはできません。変更を分離し、セットを実行し、結果を読み、次に移動します。

総合スコア（すべてのケースに対して平均化された単一の数値）だけではなく、ケースごとの差を読んでください。一定の合計は、1つのケースが修正され、1つが同時に壊れたことを隠すことができます。ネットがゼロですが、動作は静かにシフトします。どのケースが反転したかを見ることは、変更が実際に行ったことを教えてくれます。

時間をかけてスコアを追跡して、改善が見えるようにし、回帰が突き立てるようにしてください。ログされた履歴は「これはより良く感じられます」を指すことができるラインに変え、それは急激な低下を引き起こした変更に素早くトレースバックします。

Junoすべての変更で実行する テストがマージをゲートするのと同じ方法でスコアの変更をゲート。実行なし、出荷なし。スコアの移動が1つの原因を持つように、1つの変数を変更ごとに、ケースごとの差を読むことで、フラットな合計は1つのケースを修正することができます。時間をかけてスコアをログして、勝が見え、回帰がスタンドアウトします。

実際のゲートにしてください。儀式ではなく。CI でスコア閾値を設定して、閾値を下回るドロップが誰かが見るのを思い出すことに依存するのではなく、ビルドが失敗するようにしてください。そしてモデルバージョンバンプのたびにセットを再実行してください。同じプロンプトが新しいウェイトに異なる着地するためです。モデルバージョンをピンしてくださいテストするまで、新しいものを採用する前に再評価してください。

2つのトラップに心を留めてください。最初に、評価セット（期待した結果を持つテストケースの固定集合）はプロキシであり、基本的なトruthではありません。セットに対して厳しくチューニングすると、過剰適合します。スコアをクライムし、実際の動作は失速します。セットを拡大して回転させ続けてください。テストを暗記するのではなく、タスクを測定していることを確認してください。

2番目に、オフライン評価は全体像ではありません。それをオンライン信号と組み合わせて、サンプル本番トラフィック、ユーザーフィードバック、苦情率、実際の失敗を新しいケースとしてセットにフィードしてください。

出力は非決定論的であり、同じ入力は実行間で異なるスコアを持つことができます。ケースごとに十分なサンプルを実行し、単一実行ノイズを追いかけるのではなく許容範囲に対して判断してください。1ポイントの振れは測定呼吸であり、回帰ではありません。バーを設定して、その分散に耐える水準に設定してください。週全体を幽霊を調査するために費やすか。全く行ったことがあります。

Junoすべての変更で実行する CI にしきい値を設定して、悪い変更がビルドを失敗させ、モデルバージョンバンプで評価を再度実行してください。新しいウェイトは同じプロンプトを異なります読むため。セットはプロキシであり、それを拡大して回転させ続けて、オンライン信号と組み合わせてください。出力は非決定論的であり、幽霊を調査するのではなく許容範囲に対して判断してください。そうです、私は行ったことがあります。

実践で

最後のセクションからの run_evals 関数は、小さければ、完全で有効なeval ハーネスです。分類器と評価セットを指し、合格するケースの数を教え、どのケースが失敗しているかを正確に示します。

run_evals(eval_set, classify_review)
# FAIL: "それは良かった、特に特別なことはなかった。" -> got POSITIVE, wanted NEUTRAL
# 2/3 passed

その1つの失敗行は、十数の成功した手テストより価値があります。実際の弱点を指し、修正して再測定できるようになったためです。最終章、安全と限界は、本物のユーザーの前に、これのいずれかを置く前に設計に対するリスクをカバーします。

Juno実践でrun_evalsのような小さなハーネスは既に食い込んでいます。スコアと、正確に壊れたケースを提供します。1つを修正して、再度実行して、数値が移動するのを見てください。次に、実ユーザーが到着する前に、安全と限界が保護するものをカバーします。

小さな**eval ハーネス**は、評価セット内のすべてのケースを実行し、期待した出力に対して出力をスコアする、「セーム見えます」を動かすことができる数に変えるループです。セットを実行し、スコアと失敗のリストを得、最も安い実際の失敗を修正し、再度実行します。

失敗した各ケースは、明確な完了の定義を持つ作業の単位です。ケースはパス。これは「プロンプトを改善してください」より鋭いターゲットで、正確にヒットするタイミングと、正確に回帰するタイミングを見ることができます。

これが本物のユーザーを満たす前に、次の章、安全と限界は、前もって設計するリスクをカバーします。

Juno実践で ハーネスはvibesを動かすことができる数に変えます。セットを実行し、スコアと失敗を読み、最も安い実際のケースを修正してください。各失敗は、完了の明確な定義を持つタスクであり、「それをより良くする」より鋭いターゲットです。その後、本物のユーザーが見る前に、安全と限界。

本番環境では、その小さなハーネスはあなたが手で実行するスクリプトをやめ、システムの一部になります。それは CI ゲート、あなたが設定したラインの下にスコアがドロップすると、リリースをブロックするチェック、プラス、単一実行が見ることのない遅いドリフトをキャッチするために、リリース全体を監視するダッシュボードに成長します。

オフライン評価、出荷する前にスコアする固定セット、オンライン監視、本物のトラフィックの後に収集する信号、および相互フィードに相互フィード。本番の失敗は新しいオフラインケースになり、オフラインセットはあなたの修正が開催されたかどうかを教えます。ここで勝つ、クレバー、最も賢いプロンプトはチームではありません。彼らはオフラインで測定した、みんなが目視評価をしている間、彼らはチームです。

これが規律です。次の章、安全と限界は、これが本物のユーザーに到達する前に設計するリスクをカバーします。

Juno実践で 成熟してください。スクリプトは CI ゲートプラスダッシュボードになり、オフライン評価とオンライン監視が互いをフィード。「良く見えます」で出荷し、後でそれの支払いをしたことがあります。ここで勝ったチームはモニタリングしながらオフライン測定した、残りはオフラインで目視評価をしました。実ユーザーが到着する前に、安全と限界を読んでください。