LLMアプリ評価指標と実装ガイド【2025年版】：自動評価・人手評価・オンライン評価の設計

なぜ評価設計が必要か

LLMアプリは“動く”だけでは不十分です。再現性と改善速度のために、定量指標と審査プロセスを整える必要があります。

3層の評価アーキテクチャ

1. オフライン自動評価：大量ケースを素早く回すベースライン
2. 人手評価：重要ケースの正確性/有害性/トーンを精査
3. オンライン評価：本番での行動指標・A/Bで意思決定

タスク別メトリクス

• 要約: ROUGE/BERTScore + 事実性（faithfulness）
• 生成QA/RAG: 回答関連度、根拠の整合（groundedness）、引用率、コンテキストカバレッジ
• 分類/抽出: 精度/再現率/F1、スパンF1
• 対話: 役に立つ度、礼儀、害の有無、ステップ完遂率

RAG向け自動評価の実装例（擬似）

type Case = { q: string; ctx: string[]; truth: string };

// 1) 検索評価（Recall@k / Precision@k）
function evaluateRetrieval(cases: Case[], k = 5) {
  return cases.map(c => {
    const hits = retrieved(c.q).slice(0, k);
    const recall = hits.some(h => c.ctx.includes(h)) ? 1 : 0; // 簡略化
    return { recall };
  });
}

// 2) 事実性（judge LLMで比較）
async function evaluateFaithfulness(answer: string, ctx: string[]) {
  const judgePrompt = `以下の回答が文脈に整合しているか。根拠文も列挙: ${answer}\n文脈: ${ctx.join('\n')}`;
  const verdict = await callJudge(judgePrompt);
  return parseVerdict(verdict); // {score: 0..1}
}

人手評価設計

• 評価表（rubric）を定義：正確性、網羅性、明瞭さ、害の有無、スタイル
• ダブルブラインド＋相互レビューでバイアス低減
• サンプルサイズ/信頼区間を事前に決める

オンライン評価（A/B）

• ガードレール（ポリシー違反検知、PII検知）を先に配備
• 指標: 解決率、再問い合わせ率、CSAT、反応時間、コスト/1000リクエスト
• 実験単位を明確化（モデル/プロンプト/ツール構成）

// メトリクス送信の一例
fetch('/api/metrics', { method: 'POST', body: JSON.stringify({ kind: 'solve_rate', value: 0.82 }) });

ゴールドデータの作り方

• 実データから代表ケースを抽出 → 正解作成 → 反例（難問）を追加
• 継続学習のため、失敗ケースを自動でバケット化し回収

コストと運用

• 評価の定期実行（ナイトリー）＋差分レポート
• 失敗カテゴリ別ダッシュボード（例：帰納誤り、幻覚、引用漏れ）
• モデル/プロンプト/ツールのバージョニングを管理

まとめ

オフライン・人手・オンラインの三層で回すと、品質改善の速度と確度が大きく向上します。評価は機能ではなく“仕組み”。早期に埋め込むのが成功の近道です。