evaluating-llms について
エンジニア向けのLLM評価スキルです。プロンプト、RAGの品質、安全性、ベンチマーク、運用監視を対象に、自動指標、LLMによる判定、人手レビューの方法を扱います。
主な機能
- 01自動指標とLLMによる判定
- 02RAGASによるRAG品質評価
- 03幻覚・偏り・毒性の検出
- 04標準ベンチマークの実行
- 05運用監視とA/Bテスト
活用シーン
- 01プロンプト出力と形式の検証
- 02RAGパイプラインの品質測定
- 03モデルやプロンプト設定の比較
- 04本番LLMアプリケーションの監視
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ ancoleman/ ai-design-components --skill evaluating-llmsインストール後、Claude Code で/evaluating-llmsを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
outputs.yamlexamples/python/benchmark_testing.pyclassification_metrics.pydeepeval_example.pyllm_as_judge.pyragas_example.pyunit_evaluation.pyexamples/typescript/langsmith-integration.tsllm-as-judge.tsunit-evaluation.tsreferences/benchmarks.mdevaluation-types.mdllm-as-judge.mdmetrics-reference.mdproduction-evaluation.mdrag-evaluation.mdsafety-evaluation.md詳細
LLM 評価
自動メトリクス、LLM-as-judge パターン、標準化されたベンチマークを使用して大規模言語モデル(LLM)システムを評価し、本番環境での品質と安全性を確保します。
このスキルを使用するタイミング
次のような場合にこのスキルを適用してください。
- 個々のプロンプトの正確性と書式をテストする
- RAG(検索拡張生成)パイプラインの品質を検証する
- LLM の出力におけるハルシネーション、バイアス、または有害性を測定する
- 異なるモデルやプロンプト設定を比較する(A/B テスト)
- モデルの能力を評価するためにベンチマークテスト(MMLU、HumanEval)を実行する
- LLM アプリケーションの本番環境モニタリングを設定する
- LLM の品質チェックを CI/CD パイプラインに統合する
よくあるきっかけ:
- 「RAG システムが正しく動作しているか、どうテストすればよいですか?」
- 「LLM の出力におけるハルシネーションを測定するにはどうすればよいですか?」
- 「生成品質の評価には、どのメトリクスを使えばよいですか?」
- 「自分のユースケースで GPT-4 と Claude を比較するにはどうすればよいですか?」
- 「LLM の応答におけるバイアスを検出するにはどうすればよいですか?」
評価戦略の選択
判断の枠組み:どの評価アプローチを選ぶか?
タスクの種類別:
| タスクの種類 | 主なアプローチ | メトリクス | ツール |
|---|---|---|---|
| 分類(感情、意図) | 自動メトリクス | 正解率、適合率、再現率、F1 | scikit-learn |
| 生成(要約、創作文) | LLM-as-judge + 自動評価 | BLEU、ROUGE、BERTScore、品質ルーブリック | 判定用の GPT-4/Claude |
| 質問応答 | 完全一致 + 意味的類似度 | EM、F1、コサイン類似度 | カスタム評価器 |
| RAG システム | RAGAS フレームワーク | 忠実度、回答/コンテキストの関連性 | RAGAS ライブラリ |
| コード生成 | 単体テスト + 実行 | Pass@K、テスト合格率 | HumanEval、pytest |
| マルチステップエージェント | タスク完了 + ツールの正確性 | 成功率、効率 | カスタム評価器 |
サンプル数とコスト別:
| サンプル数 | 速度 | コスト | 推奨アプローチ |
|---|---|---|---|
| 1,000+ | 即時 | $0 | 自動メトリクス(正規表現、JSON 検証) |
| 100-1,000 | 数分 | 1 件あたり $0.01-0.10 | LLM-as-judge(GPT-4、Claude) |
| < 100 | 数時間 | 1 件あたり $1-10 | 人手による評価(ペアワイズ比較) |
階層型アプローチ(本番環境向けの推奨):
- レイヤー 1: すべての出力に対する自動メトリクス(高速、低コスト)
- レイヤー 2: 10% のサンプルに対する LLM-as-judge(きめ細かな品質評価)
- レイヤー 3: 1% のエッジケースに対する人手レビュー(検証)
中核となる評価パターン
単体評価(個々のプロンプト)
単一のプロンプトと応答のペアについて、正確性をテストします。
方法:
- 完全一致: 応答が期待される出力と完全に一致するかを確認します
- 正規表現による照合: 応答が期待されるパターンに従っているかを確認します
- JSON Schema の検証: 構造化出力を検証します
- キーワードの有無: 必須の用語が応答に含まれているかを確認します
- LLM-as-Judge: 評価プロンプトを使用して合否を判定します
すぐに始められるユースケース:
- メール分類(スパム/スパムではない)
- エンティティ抽出(日付、氏名、場所)
- JSON 出力形式の検証
- 感情分析(肯定的/否定的/中立)
クイックスタート(Python):
import pytest
from openai import OpenAI
client = OpenAI()
def classify_sentiment(text: str) -> str:
response = client.chat.completions.create(
model="gpt-3.5-turbo",
messages=[
{"role": "system", "content": "Classify sentiment as positive, negative, or neutral. Return only the label."},
{"role": "user", "content": text}
],
temperature=0
)
return response.choices[0].message.content.strip().lower()
def test_positive_sentiment():
result = classify_sentiment("I love this product!")
assert result == "positive"
単体評価の例については、examples/python/unit_evaluation.py と examples/typescript/unit-evaluation.ts を参照してください。
RAG(検索拡張生成)の評価
RAGAS フレームワークのメトリクスを使用して、RAG システムを評価します。
重要なメトリクス(優先順位順):
-
忠実性(目標:> 0.8) - 最重要
- 測定内容:回答は検索されたコンテキストに基づいていますか?
- ハルシネーションを防ぎます
- 失敗した場合:根拠に基づくことを強調し、引用を必須にするようプロンプトを調整します
-
回答の関連性(目標:> 0.7)
- 測定内容:回答はクエリにどの程度適切に答えていますか?
- 失敗した場合:プロンプトの指示を改善し、少数ショットの例を追加します
-
コンテキストの関連性(目標:> 0.7)
- 測定内容:検索されたチャンクはクエリに関連していますか?
- 失敗した場合:検索を改善します(より優れた埋め込み、ハイブリッド検索)
-
コンテキストの適合率(目標:> 0.5)
- 測定内容:関連するチャンクは無関係なチャンクより上位にランク付けされていますか?
- 失敗した場合:検索パイプラインに再ランキングのステップを追加します
-
コンテキストの再現率(目標:> 0.8)
- 測定内容:関連するチャンクはすべて検索されていますか?
- 失敗した場合:検索件数を増やし、チャンク分割の戦略を改善します
クイックスタート(RAGAS を使用した Python):
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_relevancy
from datasets import Dataset
data = {
"question": ["What is the capital of France?"],
"answer": ["The capital of France is Paris."],
"contexts": [["Paris is the capital of France."]],
"ground_truth": ["Paris"]
}
dataset = Dataset.from_dict(data)
results = evaluate(dataset, metrics=[faithfulness, answer_relevancy, context_relevancy])
print(f"Faithfulness: {results['faithfulness']:.2f}")
包括的な RAG 評価パターンについては、references/rag-evaluation.md と examples/python/ragas_example.py を参照してください。
LLM-as-Judge による評価
高性能な LLM(GPT-4、Claude Opus)を使用して、ほかの LLM の出力を評価します。
使用する場面:
- 生成品質の評価(要約、創作文章)
- ニュアンスを考慮する評価基準(トーン、明瞭さ、有用性)
- ドメイン固有のタスク向けのカスタム評価基準
- 中規模の評価(100~1,000 サンプル)
人間の判断との相関: 適切に設計された評価基準の場合、0.75~0.85
ベストプラクティス:
- 明確で具体的な評価基準を使用します(詳細な基準を定めた 1~5 の尺度)
- 評価プロンプトに少数ショットの例を含めます
- 複数回の評価を平均して、ばらつきを抑えます
- バイアス(位置バイアス、冗長性バイアス、自己選好)に注意します
クイックスタート(Python):
from openai import OpenAI
client = OpenAI()
def evaluate_quality(prompt: str, response: str) -> tuple[int, str]:
"""Returns (score 1-5, reasoning)"""
eval_prompt = f"""
Rate the following LLM response on relevance and helpfulness.
USER PROMPT: {prompt}
LLM RESPONSE: {response}
Provide:
Score: [1-5, where 5 is best]
Reasoning: [1-2 sentences]
"""
result = client.chat.completions.create(
model="gpt-4",
messages=[{"role": "user", "content": eval_prompt}],
temperature=0.3
)
content = result.choices[0].message.content
lines = content.strip().split('\n')
score = int(lines[0].split(':')[1].strip())
reasoning = lines[1].split(':', 1)[1].strip()
return score, reasoning
LLM-as-Judge の詳しいパターンとプロンプトテンプレートについては、references/llm-as-judge.md と examples/python/llm_as_judge.py を参照してください。
安全性とアラインメントの評価
LLM の出力におけるハルシネーション、バイアス、有害性を測定します。
ハルシネーションの検出
方法:
-
コンテキストへの忠実性(RAG):
- RAGAS の忠実性メトリクスを使用します
- LLM が、主張がコンテキストによって裏付けられているか確認します
- スコア:裏付けられた主張数 / 主張の合計数
-
事実の正確性(クローズドブック):
- 信頼できる情報源にアクセスできる LLM-as-Judge
- ファクトチェック API(Google Fact Check)
- エンティティ単位の検証(日付、名前、統計)
-
自己一貫性:
- 同じ質問に対して複数の回答を生成します
- 回答間の一致度を測定します
- 一貫性が低い場合は、ハルシネーションの可能性があります
バイアスの評価
バイアスの種類:
- ジェンダーバイアス(固定観念的な連想)
- 人種・民族バイアス(差別的な出力)
- 文化的バイアス(西洋中心の前提)
- 年齢・障害バイアス(障害者差別や年齢差別にあたる表現)
評価方法:
-
ステレオタイプテスト:
- BBQ(Bias Benchmark for QA):58,000 組の質問と回答
- BOLD(Bias in Open-Ended Language Generation)
-
反事実評価:
- 属性を入れ替えて回答を生成します
- 例:「Dr. Smith(he/she)recommended...」→ 出力を比較します
- バリエーション間の一貫性を測定します
有害性の検出
ツール:
- Perspective API(Google): 有害性、脅迫、侮辱のスコア
- Detoxify(HuggingFace): オープンソースの有害性分類器
- OpenAI Moderation API: ヘイト、ハラスメント、暴力の検出
包括的な安全性評価パターンについては、references/safety-evaluation.md を参照してください。
ベンチマークテスト
標準化されたベンチマークを使用して、モデルの能力を評価します。
標準ベンチマーク:
| ベンチマーク | 対象範囲 | 形式 | 難易度 | ユースケース |
|---|---|---|---|---|
| MMLU | 57分野(STEM、人文科学) | 多肢選択式 | 高校〜専門家レベル | 汎用知能 |
| HellaSwag | 文の補完 | 多肢選択式 | 常識レベル | 推論の検証 |
| GPQA | 博士課程レベルの科学 | 多肢選択式 | 非常に高い(専門家レベル) | 最先端モデルのテスト |
| HumanEval | 164件のPython問題 | コード生成 | 中程度 | コード生成能力 |
| MATH | 12,500件の競技問題 | 数学の問題解決 | 高校数学競技レベル | 数学的推論 |
ドメイン固有のベンチマーク:
- 医療: MedQA(USMLE)、PubMedQA
- 法律: LegalBench
- 金融: FinQA、ConvFinQA
ベンチマークを使用する場面:
- 複数のモデルを比較する場合(GPT-4 vs Claude vs Llama)
- 特定のドメインで使用するモデルを選定する場合
- ベースラインとなる能力を評価する場合
- 学術研究や論文発表
クイックスタート(lm-evaluation-harness):
pip install lm-eval
# Evaluate GPT-4 on MMLU
lm_eval --model openai-chat --model_args model=gpt-4 --tasks mmlu --num_fewshot 5
ベンチマークテストのパターンの詳細については、references/benchmarks.mdとscripts/benchmark_runner.pyを参照してください。
本番環境での評価
本番環境でLLMの品質を監視し、最適化します。
A/Bテスト
2つのLLM構成を比較します。
- バリアントA: GPT-4(高コスト、高品質)
- バリアントB: Claude Sonnet(低コスト、高速)
指標:
- ユーザー満足度スコア(高評価/低評価)
- タスク完了率
- 応答時間とレイテンシ
- 成功したインタラクションあたりのコスト
オンライン評価
リアルタイムで品質を監視します。
- 応答品質: N件ごとの応答をLLM-as-judgeで採点
- ユーザーフィードバック: 明示的な評価、高評価/低評価
- ビジネス指標: コンバージョン率、サポートチケットの解決率
- コスト追跡: 使用トークン数、推論コスト
Human-in-the-Loop
サンプルに基づいて人間が評価します。
- ランダムサンプリング: 応答の10%を評価
- 信頼度ベース: 信頼度の低い出力を評価
- エラー検知による評価: 不審な応答にフラグを付けて確認
本番環境での評価パターンと監視戦略については、references/production-evaluation.mdを参照してください。
分類タスクの評価
出力が離散的なタスク(感情、意図、カテゴリ)向けです。
指標:
- 正解率: 正しい予測数 / 予測総数
- 適合率: 真陽性数 /(真陽性数 + 偽陽性数)
- 再現率: 真陽性数 /(真陽性数 + 偽陰性数)
- F1スコア: 適合率と再現率の調和平均
- 混同行列: 予測エラーの詳細な内訳
クイックスタート(Python):
from sklearn.metrics import accuracy_score, precision_recall_fscore_support
y_true = ["positive", "negative", "neutral", "positive", "negative"]
y_pred = ["positive", "negative", "neutral", "neutral", "negative"]
accuracy = accuracy_score(y_true, y_pred)
precision, recall, f1, _ = precision_recall_fscore_support(y_true, y_pred, average='weighted')
print(f"Accuracy: {accuracy:.2f}")
print(f"Precision: {precision:.2f}")
print(f"Recall: {recall:.2f}")
print(f"F1 Score: {f1:.2f}")
分類評価の完全な例については、examples/python/classification_metrics.pyを参照してください。
生成タスクの評価
自由形式のテキスト生成(要約、創作、応答)向けです。
自動評価指標(使用には注意が必要です):
- BLEU: 参照テキストとのn-gramの重複度(0〜1のスコア)
- ROUGE: 再現率重視の重複度(ROUGE-1、ROUGE-L)
- METEOR: ステミングを考慮した意味的類似度
- BERTScore: 文脈埋め込みの類似度(0〜1のスコア)
制限事項: 自動評価指標と人間の判断との相関は、創造的/主観的な生成では弱い傾向があります。
推奨アプローチ:
- 自動評価指標: 長さや形式など、客観的な側面を迅速にフィードバック
- LLM-as-judge: 関連性、一貫性、有用性などを詳細に評価
- 人間による評価: 好みや創造性など、主観的な基準を最終検証
生成タスクの評価パターンの詳細については、references/evaluation-types.mdを参照してください。
クイックリファレンス表
評価フレームワークの選定
| タスク | 使用するフレームワーク | 主な指標 |
|---|---|---|
| RAG システム | RAGAS | 忠実性 > 0.8 |
| 分類 | scikit-learn の指標 | 正解率、F1 |
| 生成品質 | LLM-as-judge | 品質評価基準(1~5) |
| コード生成 | HumanEval | Pass@1、テスト合格率 |
| モデル比較 | ベンチマークテスト | MMLU、HellaSwag のスコア |
| 安全性の検証 | ハルシネーションの検出 | 忠実性、ファクトチェック |
| 本番環境のモニタリング | オンライン評価 | ユーザーフィードバック、ビジネス KPI |
Python ライブラリの推奨
| ライブラリ | 用途 | インストール |
|---|---|---|
| RAGAS | RAG の評価 | pip install ragas |
| DeepEval | LLM の汎用評価、pytest との統合 | pip install deepeval |
| LangSmith | 本番環境のモニタリング、A/B テスト | pip install langsmith |
| lm-eval | ベンチマークテスト(MMLU、HumanEval) | pip install lm-eval |
| scikit-learn | 分類の指標 | pip install scikit-learn |
安全性評価の優先度マトリックス
| アプリケーション | ハルシネーションのリスク | バイアスのリスク | 有害性のリスク | 評価の優先度 |
|---|---|---|---|---|
| カスタマーサポート | 高 | 中 | 高 | 1. 忠実性、2. 有害性、3. バイアス |
| 医療診断 | 致命的 | 高 | 低 | 1. 事実の正確性、2. ハルシネーション、3. バイアス |
| クリエイティブライティング | 低 | 中 | 中 | 1. 品質/流暢さ、2. コンテンツポリシー |
| コード生成 | 中 | 低 | 低 | 1. 機能の正確性、2. セキュリティ |
| コンテンツモデレーション | 低 | 致命的 | 致命的 | 1. バイアス、2. 偽陽性/偽陰性 |
詳細なリファレンス
各トピックの詳細なドキュメントについては、以下を参照してください。
- 評価の種類(分類、生成、QA、コード):
references/evaluation-types.md - RAG 評価の詳細(RAGAS フレームワーク):
references/rag-evaluation.md - 安全性評価(ハルシネーション、バイアス、有害性):
references/safety-evaluation.md - ベンチマークテスト(MMLU、HumanEval、ドメイン別ベンチマーク):
references/benchmarks.md - LLM-as-judge のベストプラクティスとプロンプト:
references/llm-as-judge.md - 本番環境での評価(A/B テスト、モニタリング):
references/production-evaluation.md - すべての指標の定義と数式:
references/metrics-reference.md
実行例
Python の例:
examples/python/unit_evaluation.py- pytest を使った基本的なプロンプトテストexamples/python/ragas_example.py- RAGAS による RAG 評価examples/python/deepeval_example.py- DeepEval フレームワークの使用例examples/python/llm_as_judge.py- 評価器としての GPT-4examples/python/classification_metrics.py- 正解率、適合率、再現率examples/python/benchmark_testing.py- HumanEval の例
TypeScript の例:
examples/typescript/unit-evaluation.ts- Vitest + OpenAIexamples/typescript/llm-as-judge.ts- GPT-4 による評価examples/typescript/langsmith-integration.ts- 本番環境のモニタリング
実行可能なスクリプト
コードをコンテキストに読み込まずに評価を実行できます(トークンを消費しません)。
scripts/run_ragas_eval.py- データセットに対して RAGAS 評価を実行scripts/compare_models.py- 2 つのモデルを A/B テストscripts/benchmark_runner.py- MMLU/HumanEval ベンチマークを実行scripts/hallucination_checker.py- 出力内のハルシネーションを検出
使用例:
# Run RAGAS evaluation on custom dataset
python scripts/run_ragas_eval.py --dataset data/qa_dataset.json --output results.json
# Compare GPT-4 vs Claude on benchmark
python scripts/compare_models.py --model-a gpt-4 --model-b claude-3-opus --tasks mmlu,humaneval
他のスキルとの連携
関連スキル:
building-ai-chat: AI チャットアプリケーションを評価します(このスキルでは、そのスキルで構築したものをテストします)prompt-engineering: プロンプトの品質と有効性をテストしますtesting-strategies: LLM 評価にテストピラミッドを適用します(ユニット → 統合 → E2E)observability: LLM 品質の本番環境での監視とアラートbuilding-ci-pipelines: LLM 評価を CI/CD に統合します
ワークフローとの連携:
- プロンプトを作成します(
prompt-engineeringスキルを使用) - プロンプトをユニットテストします(
llm-evaluationスキルを使用) - AI 機能を構築します(
building-ai-chatスキルを使用) - RAG パイプラインを統合テストします(
llm-evaluationスキルを使用) - 本番環境にデプロイします(
deploying-applicationsスキルを使用) - 品質を監視します(
llm-evaluationとobservabilityのスキルを使用)
よくある落とし穴
1. 生成における自動評価指標への過度な依存
- BLEU/ROUGE と創造的なテキストに対する人間の評価との相関は弱いです
- 解決策:LLM による評価や人間による評価を重ねて行います
2. RAG システムにおける忠実性の軽視
- ハルシネーションは RAG で最も多い失敗要因です
- 解決策:忠実性の指標を優先します(目標値 > 0.8)
3. 本番環境での監視不足
- モデルは時間とともに劣化し、プロンプトはアップデートによって動作しなくなることがあります
- 解決策:継続的な評価を設定します(LangSmith、カスタム監視)
4. LLM による評価の偏り
- 評価用の LLM には偏りがあります(位置バイアス、冗長性バイアス)
- 解決策:複数の評価結果を平均し、多様な評価プロンプトを使用します
5. ベンチマークの網羅性不足
- 1 つのベンチマークでは、モデルの能力全体を捉えられません
- 解決策:異なる分野のベンチマークを 3~5 個使用します
6. 安全性評価の不足
- 本番環境の LLM は有害なコンテンツを生成する可能性があります
- 解決策:評価パイプラインに有害性、偏り、ハルシネーションのチェックを追加します