LLMテスティング（エルエルエムテスティング）
LLM（大規模言語モデル）の出力品質・安全性・信頼性を体系的に検証する手法の総称。従来のソフトウェアテストとは異なり、確率的な出力を扱うためファジーマッチング・LLM-as-Judge・統計的評価など独自のアプローチが必要となる。
LLMテスティングとは
LLMテスティングは、大規模言語モデルの出力を体系的に検証・評価するプロセスの総称である。従来のソフトウェアテスト（入力に対して決定的な出力を期待する）とは根本的に異なり、LLMの出力は確率的であるため、同じプロンプトに対して毎回異なる応答が生成される。この非決定性がLLMテストの最大の課題である。
LLMテスティングは大きく3つの領域に分類される。(1) 機能テスト（正確性・関連性・形式準拠の検証）、(2) 安全性テスト（有害出力・バイアス・プロンプトインジェクションの検出）、(3) 性能テスト（レイテンシ・スループット・コスト効率の計測）。
テスト手法の分類
| テスト手法 | 概要 | 適用場面 | ツール例 |
|---|---|---|---|
| ゴールデンテスト | 期待出力との完全/部分一致 | 事実回答、分類 | pytest, Jest |
| LLM-as-Judge | 別のLLMが出力品質を評価 | 自由形式応答 | OpenAI Evals, Braintrust |
| ルベリック評価 | 採点基準に基づくスコアリング | 文章品質、分析 | Promptfoo, RAGAS |
| A/Bテスト | 2バージョンの比較評価 | プロンプト改善 | Langsmith, Weights & Biases |
| アドバーサリテスト | 攻撃的入力での安全性検証 | セキュリティ | Garak, Microsoft PyRIT |
| リグレッションテスト | モデル/プロンプト変更時の品質維持 | 本番運用 | Promptfoo, DeepEval |
評価メトリクス
LLMの出力品質を定量化するメトリクスは目的によって異なる。
正確性メトリクス:
- Exact Match (EM): 期待出力との完全一致率
- F1 Score: トークンレベルの適合率と再現率の調和平均
- BLEU/ROUGE: 機械翻訳・要約の品質指標
- Semantic Similarity: 埋め込みベクトルのコサイン類似度
安全性メトリクス:
- Attack Success Rate (ASR): プロンプトインジェクション攻撃の成功率
- Toxicity Score: 有害コンテンツの検出率（Perspective API等）
- Bias Score: 性別/人種/年齢等のバイアス度合い
性能メトリクス:
- Time to First Token (TTFT): 最初のトークン生成までの遅延
- Tokens per Second (TPS): 1秒あたりの生成トークン数
- Cost per Query: 1クエリあたりのAPI費用
主要テスティングツール
| ツール | 開発元 | 特徴 | 価格 |
|---|---|---|---|
| Promptfoo | OSS | CLI/CI統合、Red Team自動化 | 無料（OSS） |
| DeepEval | Confident AI | pytest統合、14種のメトリクス | 無料（OSS）+有料クラウド |
| Braintrust | Braintrust | LLM-as-Judge、実験管理 | フリーミアム |
| LangSmith | LangChain | トレーシング+評価+デバッグ | フリーミアム |
| OpenAI Evals | OpenAI | OpenAIモデル専用評価 | 無料（OSS） |
| Garak | NVIDIA | LLM脆弱性スキャナ | 無料（OSS） |
Promptfooは最も広く使われているOSSテスティングツールで、YAML設定ファイルで評価シナリオを定義し、CI/CDパイプラインに統合できる。複数のLLMプロバイダを横断した比較評価にも対応している。
CI/CDへの統合
LLMアプリケーションの品質をプロンプト変更やモデル更新のたびに検証するため、CI/CDパイプラインへのテスト統合が重要である。
一般的なワークフロー:
- プロンプトテンプレートの変更をGitにコミット
- CIパイプラインでPromptfoo/DeepEvalが評価セットに対してLLMを実行
- 各メトリクスのスコアを閾値と比較
- 閾値未満のメトリクスがあればPRをブロック
- スコアダッシュボードを更新して時系列トレンドを可視化
GitHub ActionsでのPromptfoo統合はpromptfoo eval --ciコマンド一つで実行でき、結果はPRコメントとして自動投稿される。
テスト設計のベストプラクティス
テストケースの多様性: エッジケース、多言語入力、長文入力、空入力、悪意ある入力を網羅する。「うまくいくケース」だけのテストでは本番障害を防げない。
評価の再現性: temperatureを0に設定してテスト実行し、出力のばらつきを最小化する。統計的有意性が必要な場合は同じテストケースを5〜10回実行して平均値を取る。
ゴールデンデータセットの管理: 専門家が正解をアノテーションしたデータセットを用意し、定期的に更新する。ドメイン固有のテストケースは品質維持に不可欠である。
よくある質問
Q1: LLMのテストカバレッジはどう定義すべきですか？
コードカバレッジの概念はLLMに直接適用できないが、「インテントカバレッジ」として想定ユースケースの網羅率を指標にできる。主要なユーザー意図（質問応答、要約、コード生成等）ごとにテストケースを用意し、各意図で80%以上のスコアを達成することを目標とする。
Q2: LLM-as-Judgeは信頼できますか？
GPT-4oやClaude 3.5クラスのモデルをジャッジとして使用した場合、人間評価との一致率は80〜90%程度とされている。ジャッジモデル自体のバイアス（自社モデルへの甘い評価等）があるため、複数のジャッジモデルを使用するか、一定割合で人間レビューを併用することを推奨する。
Q3: テストにかかるコストはどの程度ですか？
評価セット100件をGPT-4oで実行する場合、約$2〜$5のAPI費用がかかる。LLM-as-Judgeを使用すると評価コストが追加される（ジャッジ実行で+$1〜$3）。CI/CDで毎コミット実行する場合は月$50〜$200程度を見込む。コスト削減には評価セットの重要度によるサンプリングや、安価なモデル（GPT-4o-mini等）でのスクリーニングが有効である。