品質を測る：基本的な評価（eval）の作り方

言語モデルで何かを作る人の多くは、同じやり方で品質を測ります。変更を試し、一つか二つの出力を眺め、「こっちの方が良さそう」と判断するのです。それは通用しなくなるまで通用します――二つのプロンプトを前に、どちらが実際に良いか言えなくなるまで、あるいは、あるケースを直しつつ他の五つを静かに壊す微調整を出荷してしまうまで。解決策は評価（eval）です。漠然とした品質感覚を、比較できる数値に変える、小さく再現可能なテスト。始めるのにフレームワークもプラットフォームもいりません。必要なのは一握りの例と、それらを二度同じやり方で採点する規律です。本稿ではそれをゼロから組み立てます。

なぜ「良さそう」では失敗するのか

単一の出力でモデルを判断することには三つの問題があり、どれ一つとっても致命的です。それは汎化しません――印象的なデモは次の百件の入力について何も語りません。それは再現可能ではありません――あなたの印象は、たまたま見た例とそのときの気分に左右されます。そしてそれはリグレッションを検出できません――ある変更があるケースを良くし別のケースを悪くするとき、一度に一つの出力を目視していても、そのトレードオフは決して見えてきません。評価はこの三つすべてを解決します。入力を固定し、採点を固定し、運の良いサンプルではなくセット全体を見るのです。

目標は完璧で科学的なベンチマークではありません。なんとなくよりはマシなもの――バージョンBがバージョンAに勝つと言われたとき、それを信じられるくらい誠実な測定です。

ステップ1：実際の例からなるデータセット

評価は、システムが実際に行う仕事を代表する入力のセットから始まります。これは最も重要なステップであり、人々が最も飛ばしたがるステップです。始めるには20〜50件で十分です――量よりも質がはるかに重要です。大切なのはそれらが代表的であること。実際の、あるいは現実的な利用から取られ、簡単なケース、よくあるケース、そして特に難しく奇妙なケースを網羅していることです。

厄介な入力を意図的に含めましょう。空の入力、曖昧な質問、拒否すべきリクエスト、先週壊れたケース。簡単な例だけから作った評価は、実際のユーザーが何か難しいものを送ってくるその瞬間まで、すべて順調だと報告します。あなたのデータセットは、正しく扱いたい状況を集めた小さな博物館であり、恐れている状況を過剰に代表しているべきです。

ステップ2：「良い」とは何かを決める

何かを採点する前に、あなたのタスクにとって良い出力とは何かを言わなければなりません――これは聞こえる以上に難しく、価値があります。基準を明示することを強いるからです。タスクが違えば定義も違います。

• 完全一致タスクには一つの正解があります。分類ラベル、抽出フィールド、はい/いいえ。良いとは、出力が期待される答えと等しいことです。
• 構造化タスクは形を重視します。妥当なJSON、必要なフィールドの存在、正しい形。良いとは、解析でき、形に従っていることです。
• オープンエンドなタスク――要約、説明、下書き――には唯一の正解がありません。良いは基準で定義されます。正確か、トピックから外れていないか、事実をでっち上げていないか、長さとトーンは適切か。

結果を見る前に定義を書き留めましょう。出力を見た後で「良い」の意味を決めるのは、欲しかった結論へ自分を言いくるめるやり方です。定義はあなたの固定された物差しであり、答えに合わせて曲がる物差しは何も測りません。

ステップ3：採点方法を選ぶ

定義を手にしたら、それをすべての例に一貫して適用する方法が必要です。コストの低い順におおよそ三つの誠実な選択肢があります。

プログラムによるチェックは、適用できる場合に最良です。正解や必須の形式があれば、数行のコードで出力を期待される結果と比較したり、JSONが解析でき正しいフィールドを持つかを確認したりできます。これは速く、無料で、完全に再現可能で、誰の気分にも左右されません。タスクが許す場所ではどこでも使いましょう。

人間の判断は、自動チェックに抵抗するオープンエンドな仕事のための代替手段です。各出力を読み、書き留めた基準に照らして採点します。誠実に保つには、曖昧な印象ではなく、単純で定義されたスケールで採点しましょう――「合格／際どい／不合格」に各一行のルールを添えるだけでも、直感に勝ります。罠は一貫性のなさです。同じ人が、疲れた午後には同じ出力を違うように採点します。基準を書き留めることが、一回のセッションを通じて採点を安定させるのです。

モデル・アズ・ジャッジは、二つ目の言語モデルを使って基準に照らして出力を採点し、人間流の判断を多くの例へ安価にスケールさせます。これは本当に有用であり、本当に誤りやすいものです――ジャッジには独自の偏りがあり、自信たっぷりで流暢な誤答にだまされ得ます。使うなら検証しましょう。人間にサンプルを採点させ、ジャッジが一致するか確認します。一度も確認していないジャッジは、信頼すべきでない数値です。

ステップ4：実行して失敗を読む

これで部品がそろいました。データセット、良いの定義、採点方法。すべての例をシステムに通し、一つずつ採点し、単純な要約を計算します――何割が合格したか、平均スコア、あなたの方法が集計するものを何でも。その一つの数値があなたのベースラインです。それ自体はほとんど意味を持ちませんが、その価値は、何かを変えてもう一度走らせた瞬間に現れます。今や「良さそう」が「71%から78%になった」となり、それは胸を張れる主張だからです。

しかし数値は報酬の小さい方の半分です。大きい方の半分は失敗を読むことです。低いスコアだったすべての例を引き出し、パターンを探します。システムが誤って扱う入力のカテゴリー、繰り返される間違い、一貫して取りこぼす種類の質問。集計スコアは物事が機能しているかを教えます。失敗は何を直すべきかを教えます。失敗を隠すベースラインは、診断のない体温計です。常に平均だけでなく、分布の底を読みましょう。

ステップ5：一度に一つだけ変える

評価は、比較に使うときその真価を発揮します。単一の変更を加え――違うプロンプト、新しい指示、別のモデル――同じデータセットを同じ採点で再実行します。数値が上がり、どの失敗カテゴリーも悪化していなければ、その変更を残します。下がったなら、ユーザーより先にリグレッションを捕らえたわけで、それこそが狙いです。

規律は、一回の実行につき一つの変数だけ変えることです。三つを一度に変えれば、スコアが良くなってもどれが効いたのか、あるいは二つが効いて三つ目が害したのか、何もわかりません。一つの変更、一つの再実行、一つの比較。それは感じるよりも遅く、そして数値を意味あるものに保つ唯一の方法です。

まとめ

基本的な評価は四つの誠実な部品です。代表的な例の小さなセット、良いとは何かの書き留められた定義、一貫した採点方法、そして一度に一つだけ変えて再実行する習慣。スプレッドシートと午後一回で組み立てられます。完璧なベンチマークにはならないし、その必要もありません――なんとなくよりマシで、信頼できるほど再現可能で、失敗がどこに固まるかを見せるほど明らかであればよいのです。「良さそう」が、あなたが擁護できる数値になれば、その後のあらゆる判断がより簡単に、より誠実になります。