Eval Audit

LLM eval パイプラインを検査し、影響度でソートされた具体的な次のステップを含む問題のプライオリティ付きリストを作成します。

概要

1. eval アーティファクトを収集：トレース、evaluator 設定、judge プロンプト、ラベル付きデータ、メトリクスダッシュボード
2. 6つの領域にわたって診断チェックを実行
3. 各問題が修正に紐付けられた、影響度でソートされた検出結果レポートを作成

前提条件

observability MCP サーバーまたはローカルファイルを通じた eval アーティファクト (トレース、evaluator 設定、judge プロンプト、ラベル付きデータ) へのアクセス。存在しない場合は「Eval インフラがない場合」にスキップしてください。

Eval インフラへの接続

ユーザーが observability MCP サーバー (Phoenix、Braintrust、LangSmith、Truesight など) に接続しているかどうかを確認してください。利用可能な場合、それを使用してトレース、evaluator 定義、実験結果を取得してください。そうでない場合は、ローカルファイルを依頼してください：CSV、JSON トレースエクスポート、ノートブック、または評価スクリプト。

診断チェック

以下の各領域を確認してください。利用可能なアーティファクトを検査し、問題が存在するかどうかを判断し、問題がある場合は検出結果を記録してください。

ユーザーの製品への影響度で検出結果をプライオリティ付けしてください。最も影響度の高い検出結果を最初に表示します。

1. エラー分析

チェック： ユーザーが実際またはシンテティックトレースに対して体系的なエラー分析を行いましたか？

探すもの：ラベル付きトレースデータセット、障害カテゴリ定義、トレースレビューからのノート。evaluator は存在するがドキュメント化された障害カテゴリがない場合、エラー分析はスキップされた可能性が高いです。

欠けている場合の検出結果： エラー分析なしで構築された evaluator は、実際の障害モードではなく一般的な品質 ("有用性"、"一貫性") を測定します。error-analysis から始めるか、トレースが存在しない場合はまず generate-synthetic-data を使用してください。

参照：Your AI Product Needs Evals、LLM Evals FAQ

チェック： 障害カテゴリは意見ベースで出されたか、観察されたか？

研究から借りてきた一般的なラベル ("幻覚スコア"、"毒性"、"一貫性") は意見ベースを示唆します。アプリケーション由来のカテゴリ ("クエリ制約がない"、"クライアントトーンが間違っている"、"作られた物件機能") は観察を示唆します。

意見ベースの場合の検出結果： 一般的なカテゴリはアプリケーション固有の障害を見落とし、ペーパーテストでは良い点数を取るが実際の問題を見落とす evaluator を生成します。トレースから始めて error-analysis でやり直してください。

参照：Who Validates the Validators?

2. Evaluator デザイン

チェック： evaluator はバイナリ合格/不合格ですか？

Likert スケール (1～5)、成績 (A～F)、または明確な合格/不合格しきい値のない数値スコアを使用しているものはすべてフラグを立ててください。

バイナリでない場合の検出結果： Likert スケールはキャリブレーションが難しいです。注釈者は 3 と 4 の差について意見が分かれ、judge がそのノイズを継承します。write-judge-prompt を使用して、明示的な定義を持つバイナリ合格/不合格に変換することを検討してください。

参照：Creating an LLM Judge That Drives Business Results

チェック： LLM judge プロンプトは特定の障害モードをターゲットにしていますか？

全体的に評価する ("このレスポンスは有用ですか？"、"このアウトプットの品質をレート付けしてください") ものはすべてフラグを立ててください。

曖昧な場合の検出結果： 全体的なジャッジは実行不可能な判定を生成します。各ジャッジは、明示的な合格/不合格定義と少数ショット例を持つ、正確に 1つの障害モードをチェックする必要があります。write-judge-prompt を使用してください。

チェック： 可能な限りコードベースのチェックが使用されていますか？

形式検証、制約充足、キーワード存在、スキーマ適合など、客観的にチェック可能な基準に LLM judge が使用されているものはフラグを立ててください。

judge に過度に依存している場合の検出結果： 目的的にチェック可能な基準をコード (正規表現、パース、スキーマ検証、実行テスト) に置き換えてください。解釈を必要とする基準のために LLM judge を予約してください。

チェック： 類似度メトリクスが主な評価として使用されていますか？

ROUGE、BERTScore、コサイン類似度、または埋め込み距離が生成品質の主要な evaluator として使用されているものはフラグを立ててください。

存在する場合の検出結果： これらのメトリクスは正確性ではなく、表面レベルのオーバーラップを測定します。検索ランキングに適していますが、生成評価には適していません。特定の障害モードに基づいたバイナリ evaluator に置き換えてください。

参照：LLM Evals FAQ

3. Judge 検証

チェック： LLM judge は人間ラベルに対して検証されていますか？

探すもの：混合行列、TPR/TNR 測定、アラインメントスコア。検証データなしで本番環境にある judge は重大な検出結果です。

未検証の場合の検出結果： 未検証の judge は障害を一貫して見落とすか、合格トレースにフラグを立てるかもしれません。ホールドアウトテストセットで TPR と TNR を使用してアラインメントを測定してください。validate-evaluator を使用してください。

参照：Creating an LLM Judge That Drives Business Results

チェック： アラインメントは TPR/TNR で測定されていますか、それとも生の精度で測定されていますか？

"精度"、"同意率"、または Cohen の Kappa を主要なアラインメントメトリクスとして使用しているものはフラグを立ててください。

精度を使用している場合の検出結果： クラス不均衡では、生の精度は誤解を招きます。常に "合格" を言う judge は、90% のトレースが合格しても 90% の精度を得ますが、ゼロの障害をキャッチします。TPR と TNR を使用してください。これらはバイアス補正に直接マッピングされます。validate-evaluator を使用してください。

チェック： 適切な train/dev/test 分割がありますか？

judge プロンプト内の少数ショット例が、judge パフォーマンスを測定するために使用されたのと同じデータから来ているかどうかを確認してください。

リークしている場合の検出結果： 評価データを少数ショット例として使用すると、アラインメントスコアが膨らみ、実際の judge 障害が隠れます。train (少数ショットソース)、dev (イテレーション)、test (最終測定) に分割してください。validate-evaluator を使用してください。

4. 人間レビュープロセス

チェック： 誰がトレースをレビューしていますか？

ドメインエキスパートまたはアウトソースされた注釈者がデータにラベル付けしているかどうかを判断してください。

ドメイン専門知識なしでアウトソースされている場合の検出結果： 一般的な注釈者は形式エラーをキャッチしますが、ドメイン固有の障害 (間違った医療用量、不正な法的引用、一致しない物件機能) を見落とします。ドメインエキスパートを関与させてください。

参照：A Field Guide to Improving AI Products

チェック： レビュアーは完全なトレースを見ていますか、それとも最終アウトプットだけですか？

アウトプットのみの場合の検出結果： 最終アウトプットのみをレビューすると、パイプラインが破裂した場所が隠れます。完全なトレースを表示してください：入力、中間ステップ、ツール呼び出し、取得されたコンテキスト、および最終アウトプット。

チェック： データはどのようにレビュアーに表示されていますか？

raw JSON、フォーマットされていないテキスト、またはセル内にトレースデータがあるスプレッドシートはフラグを立ててください。

raw 形式の場合の検出結果： レビュアーはデータを解析するのに時間を費やし、品質を判定するのではなく、データを見やすく表示してください。自然な形式でフォーマットしてください：markdown をレンダリング、コードをシンタックスハイライト、テーブルをテーブルとして表示します。build-review-interface を使用してください。

参照：LLM Evals FAQ

5. ラベル付きデータ

チェック： 十分なラベル付きデータがありますか？

エラー分析の場合、~100 トレースが飽和の大まかなターゲットです。judge 検証の場合、信頼できる TPR/TNR のために ~50 個の合格と ~50 個の不合格の例が必要です。ラベル付きデータが不足している場合、より効果的にトレースをサンプリングしてさらに収集してください：

• ランダム： 他の戦略と一緒に常にランダムサンプルを含めて、未知の問題を発見してください。
• クラスタリング： トレースをセマンティック類似度によってグループ化し、各クラスタから代表的なものをレビューしてください。
• データ分析： レイテンシ、ターン、ツール呼び出し、トークンの統計を分析して外れ値を見つけてください。
• 分類： 既存の eval、予測モデル、または LLM を使用して問題のあるトレースを抽出してください。注意して使用してください。
• フィードバック： 明示的な顧客フィードバック (苦情、マイナス信号) を使用してトレースをフィルタリングしてください。

不十分な場合の検出結果： 小規模なデータセットは信頼できない障害率と広い信頼区間を生成します。上記のサンプリング戦略を使用してより多くのラベル付きデータを収集するか、generate-synthetic-data で補足してください。

6. パイプラインの衛生管理

チェック： 重大な変更後にエラー分析が再実行されていますか？

エラー分析が最後に実行されたのはいつか、モデルスイッチ、プロンプト書き直し、新機能、本番インシデントと比較して確認してください。

古い場合の検出結果： パイプライン変更後に障害モードがシフトし、古いパイプラインに対して構築された evaluator は新しい障害タイプを見落とします。重大な変更のたびにエラー分析を再実行してください。

チェック： evaluator はメンテナンスされていますか？

judge の定期的な再検証またはリフレッシュされた評価データセットを探してください。

設定して放置の場合の検出結果： Evaluator はパイプラインが進化するにつれて劣化します。新しい人間ラベルに対して judge を再検証し、現在の使用方法を反映するように eval データセットを更新してください。

Eval インフラがない場合

ユーザーが eval アーティファクト (トレースなし、evaluator なし、ラベル付きデータなし) を持っていない場合：

1. 実トレースのサンプルで error-analysis から始めてください。
2. 本番データが存在しない場合、generate-synthetic-data を使用してテスト入力を作成し、パイプラインを実行してから、結果のトレースに error-analysis を適用してください。
3. エラー分析を完了する前に、evaluator、judge、またはダッシュボードの構築を推奨しないでください。

レポート形式

検出結果を影響度でソートして表示してください。各項目について：

### [問題のタイトル]
**ステータス：** [問題が存在する / 問題なし / 決定できない]
[見つかった特定の問題について 1～2 文の説明]
**修正：** [具体的なアクション、スキルまたは記事を参照]

6つの診断領域の下にグループ化してください。問題が見つからなかった領域は省略してください。

アンチパターン

• 実際のアーティファクトを検査せずに監査をチェックリストとして実行すること。
• ユーザーのパイプラインで見つかったものから切り離されたアドバイスを報告すること。
• エラー分析が完了する前に evaluator を推奨すること。
• コードベースのチェックで処理できる障害に LLM judge を提案すること。
• この監査を 1 回限りのイベントとして扱うこと。重大なパイプライン変更後に再監査してください。