LLM 評価メソドロジー：自社ユースケースで信頼できる評価を構築する
LLM 評価メソドロジー：自社ユースケースで信頼できる評価を構築する
モデルを替える、プロンプトを直す、バージョンを上げる — 良くなったのか悪くなったのか、どう判断しますか？公開ベンチマークのスコアは、テストデータが自社の実シナリオと大きく異なるため、ほぼ役に立ちません。本記事では自社業務のための評価体系（評価セット、採点手法、A/B 比較、回帰テスト）を解説します。これがあれば、モデル変更のたびに感覚ではなく根拠で判断できます。
30 秒でわかる要点
評価の本質はスコアを 1 つ選ぶことではなく、固定の評価セットを作ることです。実業務から 30〜100 件の代表入力を抽出 → 「良い回答」の基準を定義 → 変更の前後で同じ問題を実行 → 人間または LLM-as-judge で採点 → 結果を比較して判断。評価セット自体をコードと同様にバージョン管理します。
なぜ公開スコアでは足りないのか
MMLU や MTEB などの公開ベンチマークには価値がありますが、3 つの本質的限界があります。
- データ分布が違う：汎用知識や学術問題を測るもので、自社は内部文書・特定フォーマット・業界用語かもしれません
- 自社の制約がない：出力形式、トーン、コンプライアンス要件、拒否境界は測定されません
- 対策可能：学習時に類似問題を見ている可能性があり、高スコアが汎化を保証しません
公開スコアの正しい使い方は「候補の絞り込み」です。最終選択は必ず自社の評価セットで行います。
評価セットは資産であり、使い捨てスクリプトではありません
良い評価セットは繰り返し使います。モデル交換、プロンプト修正、エンジン更新、温度変更 — すべて同じ問題で実行します。事業の進化に合わせて新しい問題を追加し、コードと同様にバージョン管理します。半日の投資が、その後のすべての判断を速くします。
ステップ 1：評価セットを作る
1. 実業務からサンプリング。 本番ログや関係者要件から 30〜100 件の代表入力を選び、以下を覆います。
| カテゴリ | 目安 | 例 |
|---|---|---|
| 高頻度の典型タスク | 50-60% | 最も多い日常の質問 |
| エッジ／困難ケース | 20-30% | 長い入力、曖昧さ、複数制約 |
| 拒否すべき／境界 | 10-20% | 答えてはいけない、情報不足 |
2. 各件に「良い回答」の基準を定義。 唯一の正解を固定するのではなく（多くのタスクに正解はありません）、チェックポイントを列挙します：事実が正しいか、要点を覆っているか、形式が要件どおりか（JSON フィールド、長さ、トーン）、捏造すべきでないときに捏造していないか。
3. 構造化ファイルに保存。 id、入力、チェックポイント、カテゴリ。JSONL でも CSV でも構いません。スクリプトから安定して読めることが重要です。
{
"id": "case-001",
"input": "この製品説明を画像生成プロンプトに書き直してください",
"checkpoints": ["主体とスタイル記述を含む", "単一パラグラフ", "原文にない数字を足さない"],
"category": "high_frequency"
}
ステップ 2：採点手法を選ぶ
| 手法 | やり方 | 向いている | 限界 |
|---|---|---|---|
| 人間採点 | チェックポイントごとに採点 | 品質重視・小規模 | 遅い、高コスト、主観 |
| LLM-as-judge | 強モデルが rubric で採点 | 中規模・高速反復 | judge 自身のバイアス |
| 自動指標 | 完全一致、JSON 検証、正規表現 | 構造化出力 | 開放的品質は測れない |
実務では組み合わせます。構造化タスクは自動指標で足切りし、開放タスクは LLM-as-judge で一次スクリーニング、judge が割れたサンプルを人間が抜き取り確認します。
LLM-as-judge の 2 つの規律
① judge は被評価モデルと別ファミリの強モデルを使い、自己選好バイアスを避けます。② 採点 rubric はファイルに固定し、実行ごとに言い換えないでください。judge スコアは相対比較用であり、絶対的な品質結論ではありません — 表面の流暢さに引きずられることもあります。人間の抜き取り確認は必須の安全網です。
ステップ 3：A/B 比較
2 つのモデル／プロンプトを比べるとき、道具より規律が重要です。
- 同一問題・同一パラメータを固定（温度、max_tokens、システムプロンプト。被試験変数以外は全部同じ）
- 変数は 1 つだけ — モデルとプロンプトを同時に替えると帰因できません
- ブラインド採点：A/B 出力の順序をシャッフルして採点者へ渡し、位置バイアスを避けます
- 件ごとの結果を記録、平均だけ見ない — 長い入力で A が明らかに良く、短い入力で B がわずかに良い、ということはよくあります
- 分布を見る、平均だけではない：平均が近いときは失敗の重大度を比較します — 1 つの深刻なハルシネーションは 10 の軽微なスタイル差より重要です
# 最小 A/B 骨格：同一問題を 2 構成で実行して保存
import json
cases = [json.loads(l) for l in open("eval_set.jsonl")]
results = []
for case in cases:
for variant in ["model_a", "model_b"]:
out = call_model(variant, case["input"]) # 自社の呼び出しラッパー
results.append({"id": case["id"], "variant": variant, "output": out})
json.dump(results, open("run_001.json", "w"), ensure_ascii=False, indent=2)
ステップ 4：回帰テストの流れ
評価を変更フローに組み込みます。
- モデル交換／バージョン更新：評価セット全件を実行し、前版ベースラインと比較
- プロンプト修正：評価セット ＋ そのプロンプト関連のサブセット
- エンジン／量子化ティア変更：評価セットを実行し、あわせてレイテンシと VRAM も記録
- 判定ルール：主要チェックポイントは劣化不可、平均の小幅変動は分布で判断
回帰の価値は静かな劣化を捉えることです。上流モデル更新後、エラーは出ないのに出力スタイルが変わる — 固定評価セットだけがこれを検出できます。クラウド API のモデルはプラットフォーム更新に伴い変わるため月 1 回の回帰を推奨します。ローカルモデルはアップグレード前に毎回実行します。
評価は一度きりではありません
評価セットは事業とともに新問を追加し、旧問は残します。各実行の結果（日付、モデル／バージョン、パラメータ、スコア）をアーカイブします。3 か月後「なぜこのモデルを選んだのか」を振り返るとき、その記録が答えになります。モデルバージョン管理ガイドと同じ規律を評価にも適用してください。
よくある誤解
誤解 1：サンプルは多いほど良い。 エッジを覆う 30 件の高品質サンプルは、重複だらけの 500 件より情報量が多いです。まず網羅性、次に量です。
誤解 2：平均だけ見れば良い。 平均は分布を隠します。1 つの深刻な誤りは 10 の小幅な変動より重要 — 失敗を重大度で分級してください。
誤解 3：プロンプトと一緒に評価セットも書き換える。 評価セットは物差しです。スコアを良く見せるための改題は禁止、変更するなら明示的にバージョンを記録しベースラインを作り直します。
誤解 4：LLM-as-judge の結論を真理として扱う。 相対比較ツールであり、人間抜き取りで較正が必要です。特に高リスク場面では必須です。
FAQ
評価セットは何件必要？
LLM-as-judge は信頼できますか？
クラウドモデルは更新されます。劣化をどう防ぎますか？
A/B 比較の注意点は？
評価データとファインチューニングデータは分けるべき？
価格はどこで見られますか？
関連記事
- Qwen モデル選びガイド — 家族の使い分け
- RAG ナレッジベース構築実践 — 評価が必要な典型場面
- ローカルデプロイ完全プレイブック — 配備フロー
- Qwen API トラブルシューティング — 呼び出しのデバッグ
- 料金 — クラウドのリアルタイム価格