評価（Evals）の完全ガイド：100件の手動レビューと『慈悲深い独裁者』から始める

視点

これはHamel HusseinとShrea Shankarです。彼らはMavenの#1 eval コースの講師であり、OpenAIやAnthropicのチームを含む2,000以上のPMとエンジニアを指導してきました。彼らのプロセスは意外に最初は手動を中心としており、それこそがポイントです。

「最大の誤解は：AIが自動的に評価できないのか？」 それは機能しません。Hamelが存在しないバーチャルツアーをスケジュールしたトレースを示したとき、ChatGPTは「良さそうだ」と言いました。その機能が存在しないことを知るコンテキストがないからです。ドメインエキスパートはそれを数秒で見つけます。LLMは製品の匂いを見落とします。

プロセス：オープンコーディングと慈悲深い独裁者。 トレース（LLM相互作用のログ）を見ます。何が間違っているかについて簡単なメモを書きます。見えるエラーの最初のもの、または最も上流のもののみです。すべてを見つけようとしないでください。委員会を使用しないでください。あなたが信頼するセンスを持つ1人の人を指定してください（ドメインエキスパート）。非公式に保ちます：「jank」はメモとして問題ありません。「理論的飽和」に達するまで少なくとも100つのトレースを実施します。新しいことを学ぶのをやめたときです。

エラー分析がテスト作成より前にあります。 これはユニットテストにジャンプするソフトウェアエンジニアリングとは異なります。LLMでは、サーフェスエリアが大きすぎて、動作が確率的すぎます。最初にデータ分析が必要です。何をテストするかを理解するためです。オープンコーディングの後に初めて、パターンを自動化された評価にコード化します。

リアルエステートエージェントの例は完璧です。 ユーザーが空き状況を尋ねます。AIは「それはありません、良い一日を」と言います。技術的には正しい。製品的には？ひどい。リード管理ツールは人間に引き継ぐべきであり、会話を閉じるべきではありません。それは製品の人だけが見つけることができるものです。

評価を高くしないでください。 バイナリスコアのみ（合格/不合格）。1つのドメインエキスパート、委員会ではありません。データをサンプリングして、すべてをレビューしないでください。目標は完璧さではありません。実用的な改善です。プロセスを高くすると、実行しません。

主要なポイント

• LLMはエラー分析ができません - コンテキストがありません。明らかな製品の失敗で「良さそうだ」と言う
• オープンコーディング - 最初のエラーについて簡単なメモを書く。すべてを見つけない。非公式である
• 慈悲深い独裁者 - あなたが信頼するセンスを持つ1つのドメインエキスパート。委員会ではない
• 最低100トレース - 理論的飽和まで。20後に中毒になる
• 理論的飽和 - 新しいことを学ぶのをやめたときに止める
• バイナリスコアのみ - 合格/不合格。1～5スケールはしない。すべてを扱いやすくする
• エラー分析→テスト - ソフトウェアエンジ異なります。コード化する前に理解する
• 製品の人が必要 - エンジニアは製品の匂いを見落とす。ドメイン専門知識が重要
• サンプル、すべてをレビューしない - プロセスを持続可能にする
• 「Jank」は有効 - メモを非公式に保つ。仕上げより具体性が重要

大きな絵

AI評価は自動テストではありません。人間の判断を必要とするデータ分析です。信頼できるAI製品を出荷している企業は、洗練されたフレームワークを使用していません。ドメインエキスパートをトレースの前に置いて、味覚を開発させています。近道は存在しません。