Open2

AI Engineering読書メモ

ta.toshiota.toshio

Chapter 4「Evaluate AI Systems」

1. 評価ができなければデプロイは無意味

  • 主張：アプリケーションをデプロイしても、動作を評価できなければ意味がない。
  • 解説：たとえユーザーに好評でも、実際に正しく機能しているか分からなければ投資対効果が不明瞭。評価パイプラインを最初に設計し、定量・定性両面で利用状況と品質を可視化すべき。

2. Evaluation-Driven Development（評価駆動開発）の提唱

  • 主張：ソフトウェアのテスト駆動開発にならい、AIでも「評価基準を先に定義してから開発する」べき。
  • 解説：どの指標で成功とみなすかを事前に決めることで、無駄な実装を減らし、ROI の高いアプリケーションに集中できる。

3. 評価基準は４つのバケットに整理できる

  1. ドメイン固有能力：コード生成や専門分野の知識など、業務要件に直結する能力
  2. 生成品質：流暢さ・一貫性・事実整合性（hallucination 検出）
  3. 指示追従性：フォーマットやスタイルなど、ユーザー指示にどれだけ忠実か
  4. コスト＆レイテンシ：API／ホスティング費用と応答速度

例：法律文書要約なら「法務知識」「要約の忠実度」「1000字以内」「応答200 ms以下」を基準に。

4. モデル選定は「ビルド vs バイ」＋「公開ベンチ vs プライベート評価」が鍵

  • ホスト or API：データプライバシー、コスト、機能性、制御性、レイテンシの要件で選択
  • 公開ベンチマークの限界：汚染（訓練データ重複）やカバレッジ不足で“優れたモデル”を見誤る
  • プライベート評価パイプライン：自社業務に即したテストセット／AI Judge／ルーブリックで厳密に比較すべし

5. 評価パイプラインの設計ステップ

  1. コンポーネントごとの評価：入力→中間→最終出力を独立検証
  2. 評価ガイドライン作成：何を“良い”とみなすか／範囲外入力のハンドリング定義
  3. 評価手法とデータ：自動メトリクス（類似度、logprob、AI Judge）＋必要に応じ人手評価
  4. 継続的モニタリング＆反復：本番でも日次サンプリング評価、基準見直しとトラッキング

6. No Perfect Metric—but “多様な手法の組み合わせ”で限界を補う

  • 一次元スコアで全能を測るのは不可能
  • 自動評価（AI Judge、専門分類器、ベンチ）と人手評価を“補完的”に運用
  • スライス分析やブートストラップで信頼性を担保

これらの主張をもとに、AIシステム開発では「何を、どのように、どれだけ評価するか」を最初に決め、その後も継続的に評価→改善を繰り返すことが成功の鍵になります。