8-4 評価と改善
Evaluation and Improvement
1. LLM評価の難しさ
1.1 従来のテストとの違い
LLMの出力は確率的であり、同じ入力でも異なる出力が生成される場合がある。 また、「正解」が一意に定まらないタスクも多く、 従来のユニットテストのような厳密な検証が難しい。 主観的な品質評価が必要な場合もあり、 評価方法自体の設計が重要な課題となる。
| 観点 | 従来のソフトウェア | LLMアプリケーション |
|---|---|---|
| 正解の定義 | 明確(期待値と比較) | 曖昧(複数の正解あり) |
| 再現性 | 高い(決定論的) | 低い(確率的) |
| 評価指標 | 合否(Pass/Fail) | スコア、主観評価 |
| テストケース | 境界値、網羅性 | 多様な入力パターン |
1.2 評価の観点
LLMの出力品質を評価する観点は多岐にわたる。 タスクの種類によって重要な観点が異なるため、 アプリケーションの目的に応じた評価指標を選択する必要がある。
| 観点 | 説明 |
|---|---|
| 正確性 | 事実と合致しているか |
| 関連性 | 質問に対して適切に回答しているか |
| 完全性 | 必要な情報が含まれているか |
| 一貫性 | 矛盾がないか |
| 流暢性 | 自然な文章か |
| 有害性 | 不適切な内容を含んでいないか |
2. 評価手法
2.1 自動評価
自動評価は、人手を介さずにLLMの出力を評価する手法である。 大量のテストケースを効率的に評価できるが、 主観的な品質の評価には限界がある。 複数の手法を組み合わせることが推奨される。
| 手法 | 説明 | 適用場面 |
|---|---|---|
| 完全一致 | 期待値との文字列比較 | 構造化出力、分類 |
| BLEU / ROUGE | n-gram重複による類似度 | 翻訳、要約 |
| 埋め込み類似度 | 意味的な類似度を計算 | 意味の近さを評価 |
| LLM-as-Judge | 別のLLMが評価 | 主観的品質 |
2.2 人手評価
人手評価は、最も信頼性の高い評価方法である。 ただし、コストと時間がかかるため、 重要なサンプルに絞って実施することが現実的である。 評価基準を明確にし、評価者間のばらつきを最小化する工夫が必要である。
| 手法 | 説明 |
|---|---|
| 絶対評価 | 1〜5のスケールで評価 |
| 比較評価 | 2つの出力を比較してどちらが良いか |
| A/Bテスト | 本番環境での実ユーザー評価 |
高品質な入出力ペアのデータセットを「Golden Dataset」と呼ぶ。 このデータセットを基準として、モデルやプロンプトの変更による 品質の変化を評価する。継続的な品質管理の基盤となる。
3. MLOps / LLMOps
3.1 MLOpsとは
MLOpsは、機械学習モデルの開発・デプロイ・運用を効率化する プラクティスとツールの総称である。 DevOpsの考え方を機械学習に適用したものであり、 モデルのライフサイクル全体を管理する。 LLMアプリケーションでは「LLMOps」と呼ばれることもある。
| 活動 | 内容 |
|---|---|
| 実験管理 | モデル、パラメータ、結果の記録 |
| バージョン管理 | モデル、データ、プロンプトの版管理 |
| CI/CD | 自動テスト、自動デプロイ |
| 監視 | 性能、品質、コストの継続的モニタリング |
| フィードバックループ | 本番データを学習・改善に活用 |
@startuml !theme plain skinparam backgroundColor #FEFEFE skinparam defaultFontName Noto Sans JP title LLMOps 継続的改善サイクル rectangle "プロンプト設計" as Prompt #DBEAFE rectangle "評価" as Eval #DBEAFE rectangle "改善" as Improve #DBEAFE rectangle "CI/CD" as CICD #D1FAE5 rectangle "本番環境" as Prod #D1FAE5 rectangle "監視" as Monitor #FEF3C7 rectangle "ログ収集" as Log #FEF3C7 rectangle "フィードバック" as Feedback #FEF3C7 Prompt --> Eval Eval --> Improve Improve --> Prompt Improve --> CICD : 検証OK CICD --> Prod Prod --> Monitor Monitor --> Log Log --> Feedback Feedback --> Prompt : 改善材料 note right of Prompt 開発フェーズ プロンプト改善 RAG改善 end note note right of CICD デプロイフェーズ end note note right of Monitor 運用フェーズ 性能・品質・コスト監視 end note @enduml
図1: LLMOpsの継続的改善サイクル
3.2 LLMOpsツール
LLMアプリケーションの運用を支援するツールが登場している。 プロンプトの管理、トレースの記録、評価の自動化などの機能を提供する。
| ツール | 機能 |
|---|---|
| LangSmith | トレース、評価、プロンプト管理 |
| Weights & Biases | 実験管理、可視化 |
| MLflow | 実験管理、モデルレジストリ |
| Promptfoo | プロンプトのテスト、比較 |
4. 継続的改善
4.1 改善のサイクル
LLMアプリケーションの品質は、継続的な改善によって向上させる。 本番環境からのフィードバックを収集し、 分析して改善策を実施するサイクルを回す。
| ステップ | 活動 |
|---|---|
| 収集 | ユーザーフィードバック、ログ、メトリクス |
| 分析 | 失敗パターン、改善機会の特定 |
| 仮説 | 改善案の立案 |
| 実験 | オフライン評価、A/Bテスト |
| 展開 | 検証済みの改善を本番に適用 |
4.2 改善のアプローチ
LLMアプリケーションの改善には、複数のアプローチがある。 コストと効果のバランスを考慮し、適切な手法を選択する。 一般的には、プロンプト改善から始め、 それで不十分な場合にRAGやファインチューニングを検討する。
| アプローチ | コスト | 効果 |
|---|---|---|
| プロンプト改善 | 低 | 即効性あり |
| RAG改善 | 中 | 知識の追加・更新 |
| モデル変更 | 低〜中 | 基本性能の向上 |
| ファインチューニング | 高 | 特定タスクへの最適化 |
フィードバックの収集
ユーザーからのフィードバックは改善の重要な情報源である。 「役に立った/立たなかった」のボタン、詳細なコメント、 実際の利用パターンなど、複数のチャネルから収集する。 プライバシーに配慮しつつ、改善に活用できる仕組みを構築することが重要である。
AI/LLMプロジェクトの基本を学習しました。 これで「ITプロジェクト入門」の全内容が完了です。 学んだ知識を実際のプロジェクトで活用してください。
[1] Huyen, C. (2022). Designing Machine Learning Systems.
[2] LangChain Documentation.