evals を使い始めるのに、それほど多くのことは必要ありません。小規模なチームで機能するパターンは、AIエンジニアリングに適用されるテスト駆動開発によく似ています。 1/ 抽象的なベンチマークではなく、ユーザーストーリーに評価を固定する: 製品/デザインの対応者と一緒に座り、モデルがユーザーのために行う必要がある具体的なことをリストアップします。「保険金請求の質問に正確に答える」、「自然言語からSQLクエリを生成する」。それぞれについて、10〜20の代表的な入力と目的の出力/動作を書き込みます。これは初めての eval ファイルです。 2/ たとえ脆くても、初日から自動化します。「ただ目で見るだけ」という誘惑に抵抗してください。 まあ、Vibesはあまり長くはスケールしません。評価をコードでラップします。例をループし、モデルを呼び出し、特定の部分文字列が表示されることをアサートする単純な pytest を記述できます。粗雑ですが、始まりです。 3/ モデルを使用して、よりハードな評価データをブートストラップします。何百ものエッジケースを手動で書くのはコストがかかります。推論モデル (O3) を使用して、合成バリエーション (「火災による損害に関する 50 件の請求に関する質問をお寄せください」) を生成し、ハンド フィルターをかけることができます。これにより、関連性を犠牲にすることなくカバレッジがスピードアップします。 4/リーダーボードを追いかけないでください。失敗したものを反復処理します。本番環境で何かが失敗した場合は、プロンプトを修正するだけでなく、失敗したケースを評価セットに追加してください。時間が経つにつれて、スイートは実際の障害モードを反映するように成長します。定期的に評価をスライスして (入力長、ロケールなどで)、特定のセグメントで回帰しているかどうかを確認します。 5/ 製品の成熟に合わせてメトリクスを進化させます。規模を拡大するにつれて、より微妙なスコアリング (セマンティック類似性、人間による評価、コスト/レイテンシの追跡) が必要になります。evalハーネスにフックを組み込んで、これらを記録し、時間の経過に伴う傾向を把握します。UI をインストルメント化して暗黙的なフィードバック (ユーザーが「サムズアップ」をクリックしたか) を収集し、それをオフライン評価にフィードバックします。 6/ 評価を表示する。チームと利害関係者の前に、評価合格率、コスト、レイテンシを示すシンプルなダッシュボードを配置します。スタンドアップで使ってみて。これにより、説明責任が生まれ、ML 以外の人々がトレードオフの議論に参加するのに役立ちます。 最後に、evals をコア エンジニアリング成果物として扱います。 所有権を割り当て、コード レビューで確認し、新しいトリッキーなケースを追加したときに祝います。この分野は、規模を拡大するにつれて複利の配当を支払います。