eval-audit

評価監査

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

概要

1. 評価アーティファクトを収集します。トレース、評価器の設定、判定用プロンプト、ラベル付きデータ、メトリクスダッシュボードが対象です。
2. 6 つの領域にわたって診断チェックを実施します。
3. 影響度順に調査結果を並べ、各項目に修正方法を示します。

前提条件

可観測性 MCP サーバーまたはローカルファイルを通じて、評価アーティファクト（トレース、評価器の設定、判定用プロンプト、ラベル付きデータ）にアクセスできること。何もない場合は、「評価インフラがない場合」に進みます。

評価インフラへの接続

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

診断チェック

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

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

1. エラー分析

確認事項： ユーザーは、実際のトレースまたは合成トレースを使って体系的なエラー分析を行っていますか？

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

該当する場合の指摘： エラー分析をせずに構築した評価器は、実際の失敗モードではなく、「有用性」や「一貫性」といった一般的な品質を測定します。まず error-analysis を実行します。トレースがない場合は、先に generate-synthetic-data を実行します。

参照：AI プロダクトには評価が必要です、LLM 評価に関する FAQ

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

研究から借用した一般的なラベル（「ハルシネーションスコア」、「毒性」、「一貫性」）は、ブレインストーミングで考案されたことを示唆します。「クエリの制約の欠落」、「クライアントに適さない口調」、「物件の特徴の捏造」といったアプリケーションに根ざしたカテゴリは、観察に基づいていることを示唆します。

ブレインストーミングで考案されていた場合の指摘： 一般的なカテゴリでは、アプリケーション固有の失敗を見逃し、机上では高いスコアを出しても実際の問題を見逃す評価器ができてしまいます。トレースを起点に、error-analysis でやり直します。

参照：Who Validates the Validators?

2. 評価者の設計

確認項目： 評価者は合格／不合格の二値ですか？

リッカート尺度（1～5）、レターグレード（A～F）、または明確な合格／不合格のしきい値がない数値スコアを使っているものがあれば、指摘してください。

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

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

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

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

曖昧な場合の所見： 全体的な評価を行う判定者は、実行可能な判断を下せません。各判定者が、明確な合格／不合格の定義と少数の例を用いて、1つの失敗モードだけを確認するようにしてください。write-judge-prompt を使ってください。

確認項目： 可能な場合にコードベースのチェックを使っていますか？

書式の検証、制約の充足、キーワードの有無、スキーマへの準拠など、客観的に確認できる基準に LLM 判定者を使っているものがあれば、指摘してください。

判定者に頼りすぎている場合の所見： 客観的なチェックはコード（正規表現、解析、スキーマ検証、実行テスト）に置き換えてください。解釈が必要な基準に限り、LLM 判定者を使ってください。

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

生成品質の主要な評価者として、ROUGE、BERTScore、コサイン類似度、または埋め込み距離を使っているものがあれば、指摘してください。

該当する場合の所見： これらの指標は、正確性ではなく表面的な重複を測定します。検索結果の順位付けには適していますが、生成の評価には適していません。特定の失敗モードに基づく二値評価者に置き換えてください。

参照：LLM 評価に関するよくある質問

3. 判定者の検証

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

確認する項目：混同行列、TPR／TNR の測定値、アラインメントスコア。検証データがないまま本番環境で使われている判定者は、重大な所見です。

未検証の場合の所見： 未検証の判定者は、失敗を一貫して見逃したり、合格したトレースを不合格と判定したりする可能性があります。ホールドアウトテストセットで TPR と TNR を測定して、アラインメントを評価してください。validate-evaluator を使ってください。

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

確認項目： アラインメントは TPR／TNR で測定していますか？ それとも単純な正解率で測定していますか？

主要なアラインメント指標として「正解率」、「一致率」、または Cohen のカッパを使っている場合は、指摘してください。

正解率を使っている場合の所見： クラスの不均衡がある場合、単純な正解率は誤解を招きます。トレースの90％が合格する状況では、常に「合格」と判定する判定者でも正解率は90％になりますが、失敗を一件も検出できません。バイアスの補正に直結する TPR と TNR を使ってください。validate-evaluator を使ってください。

確認項目： 適切な訓練／開発／テストの分割がありますか？

判定者のプロンプトに含まれる少数例が、判定者の性能測定に使ったデータと同じデータから取得されていないか確認してください。

データ漏洩がある場合の所見： 評価データを少数例として使うと、アラインメントスコアが実際より高くなり、実際の判定者の失敗が見えなくなります。訓練（少数例の取得元）、開発（反復改善）、テスト（最終測定）に分割してください。validate-evaluator を使ってください。

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

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

その分野の専門家がデータにラベル付けしているのか、外部委託のアノテーターが行っているのかを確認します。

外部委託のアノテーターに専門知識がない場合の所見： 一般のアノテーターは書式の誤りには気づきますが、特定分野における失敗（誤った医薬品の用量、不適切な法律の引用、物件の特徴の不一致など）を見逃します。その分野の専門家を関与させてください。

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

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

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

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

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

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

参照：LLM 評価の FAQ

5. ラベル付きデータ

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

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

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

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

6. パイプラインの健全性

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

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

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

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

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

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

評価インフラがない場合

ユーザーに評価用の成果物（トレース、評価器、ラベル付きデータ）がない場合：

1. 実際のトレースのサンプルを使い、error-analysis から始めます。
2. 本番データがない場合は、generate-synthetic-data を使ってテスト入力を作成し、それらをパイプラインに通してから、生成されたトレースに error-analysis を適用します。
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 ジャッジを提案する。
• この監査を一度きりの作業として扱う。パイプラインに大幅な変更があった後は、再監査してください。