← レッスンに戻る
第9章 · ベストプラクティス

Eval (評価) と継続的改善

Evaluation · 約 12 分

重要キーワード

English日本語説明
Eval 評価 プロンプト/モデルの品質測定
Goldset 理想出力データ テストケースの集合
LLM-as-Judge LLM採点 別モデルが採点する評価方式
Regression Test リグレッションテスト 変更による劣化検出

Eval (評価)

LLM アプリの品質を 継続的に測る 仕組みは不可欠です。 コードのテスト同様、Eval なしの LLM アプリは未テストのコード と思ってください。

Eval の構成

  1. Goldset (理想解答付きデータ) を作る (50〜500 件)。
  2. 指標 を定義する:
  3. 正答率 (exact / contain)
  4. LLM-as-Judge スコア
  5. 人手評価サンプル
  6. レイテンシ / コスト
  7. プロンプト・モデル変更時に必ず実行。

簡単な eval スクリプト

wzxhzdk:0

LLM-as-Judge

別の Claude (高性能モデル) に 採点役 をさせる手法。

wzxhzdk:1

判定モデルは 被評価モデルと別 にするのが望ましい。

Eval ツール

Regression テスト

wzxhzdk:2

モニタリング

失敗例分析の重要性

スコアが上がっても、特定パターンで劣化する場合があります。 - カテゴリ別 (タスク/言語/長さ) でブレイクダウン - 失敗例を 10 件は手で読む - 新しい失敗パターンが Goldset に追加されているか

試す

Eval 設計を Claude に依頼。

▶ Eval 設計依頼
「請求書 PDF から金額・発行日・取引先名を JSON 抽出」する LLM 機能の評価セットを設計してください。境界ケース 5 種、必須指標 4 つ、判定方法 (exact / fuzzy / LLM-as-judge) を表で。

演習問題

演習 1: 5 件の Goldset を作って試す

あなたが書いた任意のプロンプトに対し、5 件のテストケース (input + 期待 output) を作成し、現状の正答率を測定。 次に、プロンプトを 1 箇所だけ修正して再測定し、改善か劣化かを判定してください。

スタータープロンプト:
Python で簡単な eval ハーネスを書いてください。
1. cases: list[(input, expected)] を定義
2. プロンプトテンプレートに入力を差し込み Claude を呼ぶ
3. 期待出力が応答に含まれるかで OK/NG
4. 全体スコアと、NG ケースの一覧を出力
anthropic SDK で claude-haiku-4-5 を使う。
ヒントを見る

exact match だけだと厳しすぎることが多いので、まず substring 一致から始めるのが現実的です。

理解度チェック

  1. Eval を CI に組み込む利点は?
    1. プロンプト変更による品質劣化を早期検知
    2. GPU 温度上昇を防止
    3. API キーを更新
    4. ログを暗号化
  2. LLM-as-Judge を使うときの注意は?
    1. judge モデルと評価対象は別のものを使う
    2. 判定 LLM はランダムで OK
    3. ユーザー入力をそのまま判定
    4. 判定回数は 1 回で十分
  3. Anthropic 公式の評価環境は?
    1. Workbench
    2. Forge
    3. Studio
    4. BigQuery
  4. Eval の Goldset を育てる正しいループは?
    1. 失敗例を Goldset に追加し続ける
    2. Goldset を月初に全削除
    3. 正解した例だけ追加
    4. Goldset は固定で変更しない
解答と解説を見る
  1. A — リグレッションをコード変更同様に検知できるようになります。
  2. A — 同じモデルだとバイアスが乗りやすいので別モデルが望ましい。
  3. A — Anthropic Console 内の Workbench で評価できます。
  4. A — 新しい失敗パターンを Goldset に取り込んで育てるのが定石です。