評価 (LLM-as-a-judge)¶

エージェントを改善するには「今の実装がどれくらい良いか」を数値で測れる必要がある。ソフトウェアのユニットテスト相当だが、LLM の出力は非決定的かつ正解が 1 つに定まらないので、従来の assert 方式では回らない。この章では LLM エージェントの評価 (eval) の基本を整理する。

なぜ評価が難しいか¶

LLM 出力の評価特有の問題:

非決定性: 同じ入力でも温度 0 でも微妙にブレる。1 回の試行で成功 / 失敗を決められない
正解が多様: 「富士山の高さは?」に対する正解は「3776 メートル」「約 3776 m」「3,776m」等複数。文字列完全一致は使えない
人間の主観が絡む: 丁寧さ / 簡潔さ / 有用さといった軸は数値化が難しい
コストが高い: テストのたびに LLM を叩くので金銭コスト / 時間コストがかかる
回帰検知が必要: プロンプトや依存モデルを変えたとき、以前より悪化していないかを知りたい

これらを踏まえて、実用的な評価手法は次の 4 つに分けて考える。

4 つの評価軸¶

(1) 決定論的チェック (プログラムで書ける assertion)¶

LLM 出力の一部が機械的に検証できるとき。

JSON 出力なら schema バリデーション
数値 / 型の範囲チェック
特定フレーズの有無
禁止語の含有チェック
出力長の上限

利点: 早い / 安い / 確実限界: 品質や関連性は測れない、「正しいが質が低い」を見逃す

assert "tool_calls" in response
assert json.loads(response["arguments"])["query"]
assert len(final_answer) < 2000

(2) 参照一致 (reference-based metrics)¶

正解例 (reference) を用意しておき、そことの類似度を測る。

BLEU / ROUGE / METEOR: 機械翻訳由来の n-gram 重なりメトリクス。自由度の低いタスク向け
埋め込み類似度: reference と output をそれぞれ埋め込んで cosine 距離で測る
Exact / fuzzy match: 選択肢問題や単語レベルの回答なら

利点: 自動化可能限界: 「正しいが表現が違う」を低評価する (false negative 多め) / 正解を事前に用意するコスト

(3) LLM-as-a-judge¶

別の LLM (通常はより強いモデル) に「この応答は質問に対して適切か?」を判定させる方式。現在のエージェント評価の主流。

judge prompt:

以下はユーザ質問と AI アシスタントの応答です。次の観点で評価してください。
- 正確性 (事実誤認がないか)
- 完全性 (質問に全部答えているか)
- 簡潔性 (不必要に冗長でないか)
- 各 1〜5 点で採点し、JSON で返してください。

ユーザ質問: {question}
AI 応答: {response}

出力形式:
{"accuracy": 5, "completeness": 4, "conciseness": 3, "comment": "..."}

利点: 自由度の高いタスクにも使える / 主観軸を疑似的に定量化できる限界:

judge の主観が偏る (自分と同じスタイルを高く評価する問題)
cost と latency (評価のたびに別 LLM を叩く)
judge 自体の精度 が天井になる

現実的には judge には GPT-5.4 / Claude Opus クラスの強いモデルを使い、judge 自体の評価は人手サンプリングで定期的に校正する。

(4) 人手評価 (human in the loop)¶

最終手段。LLM judge と組み合わせる。

抽出サンプル 100〜500 件に人手でラベリング
親指 up/down、5 段階評価、指示通りか/そうでないか
LLM judge の出力を人手でチェック (judge の品質校正)

利点: 最終的な品質保証限界: スケールしない / 遅い / コスト高

実務では (1) + (3) + 定期的な (4) の組み合わせが主流。

評価データセットの作り方¶

どの評価軸でも、評価対象のデータセットが必要。良いデータセットの条件:

代表性: 本番で起きる質問の分布を反映
サイズ: 50〜1000 件程度。100 件が実用最小
多様性: 簡単 / 難しい / エッジケース / 失敗パターンを含む
バージョン管理: データセットは時間とともに成長する

データセットの調達経路:

本番トレースから抽出 (第 8 章 Observability の Langfuse トレースが素材になる)
実際のユーザ質問と応答を選別 → スコア付け → データセット化
人手で質問を列挙 (社内ナレッジで「よくある質問トップ 50」等)
LLM に生成させる (多様な質問を擬似生成、人手で選別)
既存のベンチマーク (HELM / MMLU / GSM8K 等) — 汎用性能評価には使えるが個別ユースケースとは合わない

Langfuse の評価機能¶

本リポジトリの Langfuse は評価の実務をそこそこ支援する:

Datasets: トレースを選別してデータセット化
Scores: 各トレース / observation に数値スコア + コメントを付ける (人手 / LLM / プログラム由来を区別可能)
Experiments: 新しいプロンプト / モデル / 設定でデータセットを再実行して結果を比較
LLM-as-a-judge: judge プロンプトを UI で定義して全トレースに自動採点させる (有料機能の場合あり)

典型フロー:

本番で 1 週間ほどトレースを溜める
Langfuse UI で気になるトレースにコメント + タグを付ける
「難しい質問 50 件」を Dataset として切り出す
プロンプト変更 or モデル変更したときに Experiment でデータセットを再実行
スコアの分布変化を比較し、悪化していないか確認

回帰テスト (regression test)¶

エージェントは頻繁に変わる: プロンプト修正、ツール追加、モデル乗り換え、依存ライブラリ更新。変更のたびに以前より悪化していないかを自動で検知したい。回帰テストの典型形:

評価データセット (100 問)
    ↓
各問に対して旧プロンプト / 新プロンプトで応答生成
    ↓
judge LLM で採点
    ↓
スコア分布を比較
    ↓
新プロンプトが旧より下回るなら CI 失敗

CI に組み込むには:

速度: 100 問 × judge = 数十分〜数時間なので PR ごとはきつい (毎日 1 回 / 週 1 回 / 手動起動が現実的)
コスト: 1 回数ドル〜数十ドル規模 / 評価対象と judge 両方の課金
しきい値: スコアの単純な平均より、分布 (p10 / p50) の変化を見る方が robust

OSS / SaaS で evaluation harness を提供しているものの例: promptfoo / Braintrust / LangSmith / Phoenix / Langfuse Experiments。RAG 特化で retrieval 品質 (context precision / recall / faithfulness) を測りたい場合は RAGAS / TruLens / DeepEval が定番で、既存 harness と組み合わせて使うことも多い。

メトリクス設計の原則¶

「何を測るか」はユースケース次第だが、共通する指針:

(1) 複数軸で測る¶

「品質」を 1 つの数値に潰さず、複数軸に分ける:

正確性 (ファクトが合っているか)
完全性 (必要なことが全て含まれているか)
簡潔性 (不必要な冗長がないか)
安全性 (有害 / 不適切な出力がないか)
コスト / レイテンシ

ユースケースによっては「形式準拠 (JSON が壊れていないか)」「citation の正確性 (引用が実在するか)」「指示追従 (system prompt の制約を守ったか)」などが必要。

(2) ビジネス KPI に繋げる¶

内部メトリクスだけでなく、本番でユーザ満足度 / タスク完了率 / 再利用率がどう動いたかを追う。評価スコアが上がっても KPI が下がれば意味がない。

(3) 負のメトリクスも測る¶

hallucination 率 (嘘をついた率)
拒否すべき質問を実行してしまった率
無限ループに陥った率
タイムアウト率

agent-demo と評価¶

現状 agent-demo は評価機構を持たないが、Langfuse に全トレースが溜まっているので準備は整っている。拡張するなら:

Langfuse UI で 21〜51 件ほど「良いターン」「悪いターン」にスコア付け
それを Dataset として切り出し
system prompt を変えて Dataset を再実行
人手 + LLM judge でスコア比較

ここまでやって初めて「エージェントを改善する」サイクルが回る。観測 (第 8 章) と評価 (この章) は車の両輪で、片方だけでは運用できない。

まとめ¶

LLM 評価は難しい: 非決定 / 多様な正解 / 主観軸 / コスト / 回帰検知
4 つの評価軸: (1) 決定論的チェック / (2) 参照一致 / (3) LLM-as-a-judge / (4) 人手
実務では (1) + (3) + 定期的な (4) の組み合わせ
評価データセットが評価の起点。本番トレースから抽出するのが現実的
Langfuse の Datasets / Scores / Experiments で最小限の評価 loop が組める
回帰テスト: プロンプト / モデル / 依存の変更時に品質悪化を検知する仕組み
複数軸で測る + ビジネス KPI に繋げる + 負のメトリクスも追う
観測 (第 8 章) と評価はセット。観測だけではデバッグしかできず、評価だけでは対象が無い