eval-audit

Eval Audit

LLM 評価パイプラインを調査し、具体的な次のステップを含む問題の優先順位付きリストを作成します。

概要

1. 評価アーティファクトを収集します：トレース、評価器の設定、ジャッジプロンプト、ラベル付きデータ、メトリクスダッシュボード
2. 6 つの領域にわたって診断チェックを実施します
3. 各指摘事項に修正方法を示す、影響度順のレポートを作成します

前提条件

オブザーバビリティ MCP サーバーまたはローカルファイルを通じて、評価アーティファクト（トレース、評価器の設定、ジャッジプロンプト、ラベル付きデータ）にアクセスできること。存在しない場合は、「評価インフラストラクチャがない場合」に進みます。

評価インフラストラクチャへの接続

ユーザーがオブザーバビリティ MCP サーバー（Phoenix、Braintrust、LangSmith、Truesight など）に接続しているか確認します。利用可能な場合は、それを使用してトレース、評価器の定義、実験結果を取得します。利用できない場合は、CSV、JSON のトレースエクスポート、ノートブック、評価スクリプトなどのローカルファイルを依頼します。

診断チェック

以下の各領域を順に確認します。利用可能なアーティファクトを調査し、問題が存在するか判断して、存在する場合は指摘事項を記録します。

ユーザーの製品への影響度に基づいて、指摘事項に優先順位を付けます。影響が最も大きいものから提示します。

1. エラー分析

確認項目： ユーザーは実際のトレースまたは合成トレースに対して、体系的なエラー分析を実施していますか？

確認対象：ラベル付きトレースデータセット、失敗カテゴリの定義、トレースレビューのメモ。評価器が存在するにもかかわらず、失敗カテゴリが文書化されていない場合、エラー分析は省略された可能性があります。

不足している場合の指摘事項： エラー分析をせずに構築された評価器は、実際の失敗モードではなく、「有用性」や「一貫性」などの一般的な品質を測定します。まず error-discovery を使い、トレースが存在しない場合は先に generate-synthetic-data を使います。

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

確認項目： 失敗カテゴリはブレインストーミングによって考案されたものですか、それとも観察に基づいていますか？

研究から借用した「幻覚スコア」「有害性」「一貫性」などの一般的なラベルは、ブレインストーミングに基づいていることを示唆します。「検索クエリの制約の欠落」「クライアントに合わないトーン」「物件の特徴の捏造」など、アプリケーションに根差したカテゴリは、観察に基づいていることを示唆します。

ブレインストーミングに基づいている場合の指摘事項： 一般的なカテゴリでは、アプリケーション固有の失敗を見落とし、書面上では高評価でも実際の問題を見逃す評価器が作られます。トレースから始めて、error-discovery を使い、やり直します。

参照：Who Validates the Validators?

2. 評価器の設計

確認事項： 評価器は二値の合否判定になっていますか？

リッカート尺度（1～5）、アルファベットの成績評価（A～F）、または明確な合否のしきい値がない数値スコアを使用しているものがあれば、指摘してください。

二値判定でない場合の指摘： リッカート尺度は調整が難しく、アノテーターは3と4の違いについて意見が分かれ、判定者にもそのばらつきが引き継がれます。write-judge-prompt を使い、明確な定義を設けた二値の合否判定への変更を検討してください。

参照：ビジネス成果につながる LLM 判定者の作成

確認事項： LLM 判定者のプロンプトは、具体的な失敗モードを対象にしていますか？

全体的な評価（「この回答は役に立ちますか？」「この出力の品質を評価してください」）を行うものがあれば、指摘してください。

曖昧な場合の指摘： 全体的な評価を行う判定者からは、実行可能な結論が得られません。各判定者は、明確な合否の定義と少数のショット例を用いて、失敗モードを1つだけ確認する必要があります。write-judge-prompt を使ってください。

確認事項： 可能な場合、コードベースのチェックを使用していますか？

フォーマットの検証、制約の充足、キーワードの有無、スキーマへの準拠など、客観的に確認できる基準に LLM 判定者を使用している場合は、指摘してください。

判定者に過度に依存している場合の指摘： 客観的なチェックはコード（正規表現、解析、スキーマ検証、実行テスト）に置き換えてください。解釈が必要な基準に限り、LLM 判定者を使用してください。write-code-eval を使ってください。

確認事項： 類似度指標を主な評価方法として使用していますか？

生成品質の主な評価器として、ROUGE、BERTScore、コサイン類似度、または埋め込み距離を使用している場合は、指摘してください。

使用している場合の指摘： これらの指標が測るのは表面的な重なりであり、正確性ではありません。検索結果のランキングには適していますが、生成の評価には適していません。具体的な失敗モードに基づく二値評価器に置き換えてください。

参照：LLM 評価 FAQ

3. 判定者の検証

確認事項： LLM 判定者を人間のラベルと照らして検証していますか？

確認項目：混同行列、TPR/TNR の測定値、整合性スコア。検証データがないまま本番環境で使われている判定者は、重大な指摘事項です。

未検証の場合の指摘： 未検証の判定者は、失敗を継続的に見落としたり、合格したトレースを誤って指摘したりする可能性があります。保留テストセットで TPR と TNR を使って整合性を測定してください。validate-evaluator を使ってください。

参照：ビジネス成果につながる LLM 判定者の作成

確認事項： 整合性は TPR/TNR で測定していますか、それとも単純な正解率で測定していますか？

主な整合性指標として、「正解率」、「一致率」、または Cohen のカッパを使用している場合は、指摘してください。

正解率を使用している場合の指摘： クラスに偏りがあると、単純な正解率は誤解を招きます。トレースの90％が合格する場合、常に「Pass」と判定する判定者でも正解率は90％になりますが、失敗は一切検出できません。バイアス補正に直接対応する TPR と TNR を使用してください。validate-evaluator を使ってください。

確認事項： 適切な train/dev/test 分割を行っていますか？

判定者のパフォーマンス測定に使用したデータと同じデータから、判定者プロンプトの少数ショット例が選ばれていないか確認してください。

データ漏洩がある場合の指摘： 評価データを少数ショット例として使うと、整合性スコアが実際より高くなり、判定者の真の失敗が見えなくなります。train（少数ショット例の取得元）、dev（反復改善用）、test（最終測定用）に分割してください。validate-evaluator を使ってください。

4. 人によるレビューのプロセス

確認事項： トレースをレビューしているのは誰ですか？

分野の専門家と、外部委託されたアノテーターのどちらがデータにラベルを付けているかを確認します。

外部委託先に分野の専門知識がない場合の所見： 一般のアノテーターは書式の誤りを見つけられても、分野固有の失敗（誤った医療用量、誤った法的引用、物件の特徴の不一致など）を見逃します。分野の専門家を関与させてください。

参照：AI プロダクト改善のためのフィールドガイド

確認事項： レビュアーはトレース全体を確認していますか、それとも最終出力だけですか？

出力だけを確認している場合の所見： 最終出力だけをレビューしても、パイプラインのどこで問題が起きたかは分かりません。入力、中間ステップ、ツール呼び出し、取得したコンテキスト、最終出力を含むトレース全体を表示してください。

確認事項： レビュアーにはデータがどのように表示されていますか？

生の JSON、書式設定されていないテキスト、トレースデータがセルに入ったスプレッドシートがないか確認します。

生の形式の場合の所見： レビュアーは品質を判断する代わりに、データの読み解きに労力を費やしています。自然な形式で表示してください。Markdown をレンダリングし、コードに構文ハイライトを付け、表は表として表示します。build-review-interface を使用してください。

参照：LLM 評価に関する FAQ

5. ラベル付きデータ

確認事項： ラベル付きデータは十分にありますか？

エラー分析では、飽和状態に達するための目安は約 100 件のトレースです。判定器の検証では、信頼性の高い TPR/TNR を得るために Pass の例が約 50 件、Fail の例が約 50 件必要です。ラベル付きデータが少ない場合は、トレースをより効果的にサンプリングして、さらに収集します。

• ランダム： ほかの戦略と併せて、未知の問題を発見できるよう、常にランダムサンプルを含めます。
• クラスタリング： 意味的に類似したトレースをグループ化し、各クラスターから代表例をレビューします。
• データ分析： レイテンシー、ターン数、ツール呼び出し数、トークン数の統計を分析し、外れ値を特定します。
• 分類： 既存の eval、予測モデル、または LLM を使用して、問題のあるトレースを抽出します。慎重に使用してください。
• フィードバック： 顧客からの明示的なフィードバック（苦情、低評価のシグナル）を使用して、トレースを絞り込みます。

不十分な場合の所見： データセットが小さいと、失敗率の信頼性が低くなり、信頼区間が広くなります。上記のサンプリング戦略を使ってラベル付きデータをさらに収集するか、generate-synthetic-data で補完してください。

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

確認事項： 重大な変更の後にエラー分析を再実施していますか？

モデルの切り替え、プロンプトの書き換え、新機能の追加、本番環境でのインシデントに対し、最後にエラー分析を行った時期を確認します。

古い場合の所見： パイプラインの変更後は失敗モードが変化するため、古いパイプライン向けに構築された評価器では新しい失敗の種類を見逃します。重大な変更のたびにエラー分析を再実施してください。

確認事項： 評価器は保守されていますか？

判定器の定期的な再検証や、評価データセットの更新が行われているか確認します。

設定後に放置されている場合の所見： パイプラインの進化に伴い、評価器の精度は低下します。新しい人手によるラベルを使って判定器を再検証し、現在の使用状況を反映するよう評価データセットを更新してください。

評価インフラがない場合

ユーザーに評価アーティファクト（トレース、評価器、ラベル付きデータ）がない場合：

1. 実際のトレースのサンプルに対して error-discovery を実行します。
2. 本番データがない場合は、generate-synthetic-data でテスト入力を作成してパイプラインに通し、得られたトレースに対して error-discovery を適用します。
3. エラー分析が完了する前に、評価器、判定器、ダッシュボードの構築を推奨しないでください。

レポート形式

影響の大きい順に所見を提示します。それぞれについて：

### [Problem Title]
**Status:** [Problem exists / OK / Cannot determine]
[1-2 sentence explanation of the specific problem found]
**Fix:** [Concrete action, referencing a skill or article]

6 つの診断領域に分類します。問題が見つからなかった領域は省略します。

アンチパターン

• 実際のアーティファクトを確認せず、チェックリストとして監査を実行する。
• ユーザーのパイプラインで見つかった問題に結び付かない、一般的なアドバイスを報告する。
• エラー分析が完了する前に評価器を推奨する。
• コードベースのチェックで対処できる失敗に対して、LLM 判定器を提案する。
• この監査を一度きりの作業として扱う。パイプラインに重大な変更があった後は、再監査してください。