ユニットテストが行えない非決定的な Foundation Models の出力を統計的に評価できる Evaluations フレームワークの紹介。評価軸を試行錯誤することでプロンプトのブラッシュアップサイクルにつながる、まさに「evaluation-driven development」。
Meet the Evaluations framework
0:00 – Introduction
- 生成 AI 機能は「同じ入力に同じ出力」というユニットテストの前提を壊す
- 非決定的な出力をどれだけの頻度で正しく生成できるか測定する新しいテスト手法が必要
- Evaluations フレームワークで、予期しない出力や安全でない結果の発生率を計測可能
3:10 – Demo app Book Tacker: a manual evaluation
- デモアプリ Book Trackerの紹介
#Playgroundで試した結果、いくつかの問題を発見- タグが多すぎる
- 本のタイトルがタグになっている
- 複数単語のタグが生成される
- モデルの性能を評価薄る人手評価（human judgement）を作成したが、これはスケーラブルではない：そこで自動化できスケーラブルな評価手法を作った
4:31 – Building your first evaluation
- Evaluation プロトコルの実装手順（5 ステップ）
- Subject：
ModelSubjectによる subject の定義（テスト対象のコード） - Dataset：
ModelSampleを使ったデータセットの作成（プロンプトと期待値のペア） - Evaluators & Metrics：
MetricとEvaluatorsによる評価指標とタグ数の合否判定ロジックの定義 - Analysis：
aggregateMetricsでサンプル全体の集計を定義 - Tests：次
- Subject：
8:06 – Running the evaluation and reading the report
- Swift Testing の
.evaluatesトレイトで評価を実行 - 最適化ターゲットの設定
#expect(result.aggregateValue(.mean(of: rangeMetric)) >= 0.8)のように合格基準を数値で表現
- 評価レポートの確認
- サンプルごとの結果・プロンプト・測定値・モデルレスポンスの全文を確認可能
- 例：
@Guideでタグ数を 3〜8 に制約したBookTagsの@Generable定義 - 評価を再実行し、修正が正しかったかを検証：「ヒルクライム」プロセス
10:57 – Building robust datasets
- さきほどは 2 サンプルで検証したが、これでは不十分。優れたデータセットの条件は：
- 数千件規模
- ジャンル・レビューの長さ・フィクション/ノンフィクション・文体・個人的な感想など多様性が重要
- 自分のような出力（タグ付け）をして欲しい場合、まずは個人的なスタイルを期待値としたより多くのサンプルを提供することから始める
- 手作業では限界があるため、Evaluations フレームワークの
SampleGeneratorで大量合成が可能- シードセットからプロンプトを与えて合成サンプルを生成
targetCountで目標サンプル数（シードを含む合計）を指定
14:20 – Refining metrics and evaluators
- 複数のメトリクスを追加してより深い洞察を得る。タグ付けを例とすると：
TagTotal：タグ数の分布（スコアリング型、合否ではなく数値）wordCount：タグが単一単語かのチェック（スペース含みを除外）hasGenreTag：既知ジャンル（knownGenres）との一致確認
aggregateMetricsでの集計computeMean・computeStandardDeviation・computeVarianceを組み合わせて分布を把握
15:41 – Evaluation-driven development and hill-climbing
- ヒルクライミングのループ
- 最適化ターゲットの失敗を検出
- 原因を分析して変更を加える（例：
@Guideにカウント範囲を追加） - 再実行して結果を確認
- このループを中心に開発を進めるのが evaluation-driven development（評価駆動開発）
16:12 – Model judges: qualitative metrics
- 定量的なメトリクスが合格でも、タグの内容が間違っている場合がある
- 読者の感想がタグになっている、ジャンルの誤推論など
- Model Judge：人間の評価を模倣する第２のモデルで出力を採点
- ジャッジモデルは評価対象と同等以上の能力が必要（ここでは Private Cloud Compute を使用）
- データセット全体にわたって一貫したスコアリングが可能
18:42 – Building a model judge
ModelJudgeEvaluatorは通常のEvaluatorと同じMetric型を返す- 設定のポイント
- スコアスケールは偶数レベルにする（中立デフォルトを避けるため）
- 例：1〜4 の 4 段階スケール
judgeパラメータにジャッジモデルを指定
- スコアスケールは偶数レベルにする（中立デフォルトを避けるため）
- レポートでジャッジの根拠（rationale）も確認可能
21:19 – Refining with score dimensions
- ジャッジモデルによるスコアが人間が評価したスコアと異なる場合がある
- 評価の問いが広すぎることが多い（e.g. “relevant”, “”useful for browsing）
- 二つの評価軸を
ScoreDimensionで分割、descriptionで詳解し、scaleも評価軸ごとに分ける- e.g. relevant → Relevance（関連性）：タグが本自体を表しているか
- e.g. useful for browsing → Usefulness（有用性）：ブラウジングに役立つ粒度か
- 評価軸を分けるだけ、何を評価するかを伝えているだけで不十分：アプリのコンテクスト（使われ方）が抜けているため
ModelJudgePromptでどんなアプリかというコンテキストをジャッジに伝え、評価精度を高める
23:45 – Reviewing dimension results
- 次元ごとに分かれた rationale で診断が明確化
- Relevance のスコアでどの種類のタグが間違っているかがわかる
- Usefulness のスコアでブラウジングの失敗の原因がわかる
- 次のヒルクライミングの反復に向けた明確な方向性が得られる
24:20 – Best practices
- 小さく始める（20〜30 の焦点を絞ったサンプルから）
- 定量的な特性にはヒューリスティック（コードで計測できるもの）を使う
- 定性的な特性には
ModelJudgeEvaluatorを使う - ジャッジはシンプルな設定から始める
- 評価の根拠を次の変更に活かす
- スコアがすべて同じなら問いかけが広すぎるサイン
- 問題を切り分けられないなら次元を分割
- ジャッジがアプリを理解していないならコンテキストを追加すること。
