← レッスンに戻る
第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 スクリプト

def eval_prompt(prompt_template: str, cases: list[tuple[str, str]]) -> dict:
    correct = 0
    rows = []
    for inp, expected in cases:
        out = run_claude(prompt_template.format(input=inp))
        ok = expected.strip() in out
        if ok:
            correct += 1
        rows.append({"input": inp[:50], "expected": expected, "output": out[:80], "ok": ok})
    return {"score": correct / len(cases), "rows": rows}

LLM-as-Judge

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

def judge(question, gold, predicted) -> dict:
    prompt = f'''
基準:
- factuality: 0-2 (事実性)
- concision: 0-2 (簡潔性)
- format: 0-2 (形式遵守)

質問: {question}
理想: {gold}
出力: {predicted}

採点を JSON で返してください: {{"factuality": x, "concision": y, "format": z, "comment": "..."}}
'''
    res = client.messages.create(
        model="claude-opus-4-7",
        max_tokens=200,
        temperature=0.0,
        messages=[{"role": "user", "content": prompt}],
    )
    import json, re
    m = re.search(r"\{.*\}", res.content[0].text, re.DOTALL)
    return json.loads(m.group(0))

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

Eval ツール

Regression テスト

# .github/workflows/eval.yml
name: LLM Eval
on: [push, pull_request]
jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run evals
        run: python -m evals.runner --threshold 0.8
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

モニタリング

失敗例分析の重要性

スコアが上がっても、特定パターンで劣化する場合があります。 - カテゴリ別 (タスク/言語/長さ) でブレイクダウン - 失敗例を 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 に取り込んで育てるのが定石です。