評価のベストプラクティス

生成 AI の出力にはばらつきがあります。同じ入力に対してモデルが異なる出力を生成することがあるため、従来のソフトウェアテスト手法だけでは AI システムを十分に検証できません。こうしたばらつきがあっても AI システムを検証できるのが、評価（evals）です。

このガイドでは、評価設計の基本的な考え方を紹介します。Evals API の使い方は、モデル性能の評価を参照してください。

評価とは

評価とは、モデルの性能を測定するための体系的なテストです。AI システムの動作には非決定性がありますが、評価は正確性、性能、信頼性の確保に役立ちます。また、評価は、LLM ベースのアプリケーションの性能を改善する数少ない手段の一つです。その改善にはファインチューニングを用います。

評価の種類

「評価」という言葉は、次のいずれかを指すことがあります。

• モデル単体の性能を比較する業界標準のベンチマーク。MMLU や Hugging Face のリーダーボードに掲載されているベンチマークなど
• 用途に合わせて評価を設計するときに使える標準的な数値指標。ROUGE や BERTScore など
• LLM アプリケーションの性能を測定するために自分で実装する個別のテスト

このガイドでは、3 つ目の種類にあたる独自の評価の設計を扱います。

評価結果の読み方

評価スコアは、多くの場合 0 から 1 までの数値で表されます。ただし、スコアだけでは評価は完結しません。指標と人間の判断を組み合わせて、確かめたいことを実際に検証できているか確認してください。

評価プロセスの設計

評価ワークフローには、次の重要なステップがあります。

1. 評価目的の設定：何をもって成功と判断しますか？
2. データセットの収集：目的に照らして評価するには、どのようなデータが役立ちますか？ 合成した評価データ、分野固有の評価データ、購入した評価データ、人間が選定した評価データ、本番データ、過去のデータを検討してください。
3. 評価指標の設定：成功基準を満たしたことをどのように確認しますか？
4. 評価の実行と比較：評価と改善を繰り返し、対象のタスクやシステムでモデルの性能を高めます。
5. 継続的な評価：変更のたびに評価を実行するように継続的評価（CE）を設定します。アプリケーションを監視して、動作が一定しない新たなケースを見つけ、評価セットに順次追加します。

具体例を見てみましょう。

例：文字起こしの要約

LLM ベースのアプリケーションが文字起こしをどの程度うまく要約できるかを検証するには、たとえば次のように評価を設計します。

1. 評価目的の設定
   モデルが、内容の関連性と正確性の両面で参照要約に匹敵する要約を生成できることを目標とします。
2. データセットの収集
   生成された要約へのユーザーのフィードバックから得た本番データと、分野の専門家（ライター）が作成したデータセットを組み合わせて、何を「良い要約」とするかを判断します。
3. 評価指標の設定
   文字起こしと参照要約のペア 1,000 件を評価用に取り分けます。このセットで、実装したシステムの ROUGE-L スコアが 0.40 以上、G-Eval で測定した一貫性スコアが 80% 以上になることを基準とします。
4. 評価の実行と比較
   Evals API を使い、OpenAI ダッシュボードで評価を作成して実行します。
5. 継続的な評価
   変更のたびに評価を実行するように継続的評価（CE）を設定します。アプリケーションを監視して、動作が一定しない新たなケースを見つけ、評価セットに順次追加します。

例：ドキュメントに基づく質問応答

LLM ベースのアプリケーションがドキュメントに基づいて質問に答えられるかを検証するには、たとえば次のように評価を設計します。

1. 評価目的の設定
   モデルが正確に回答できること、ユーザーのプロンプトについて推論する際に必要なコンテキストを取り出せること、ユーザーのニーズを満たす回答を返せることを目標とします。
2. データセットの収集
   ユーザーが自分の質問への回答にどの程度満足したかを示す本番データ、分野の専門家が作成した質問に対してあらかじめ設定した正解、ログに残っている過去のデータを組み合わせます。
3. 評価指標の設定
   コンテキストの再現率が 0.85 以上、コンテキストの適合率が 0.7 超、肯定的な評価を得た回答の割合が 70% 以上であることを基準とします。
4. 評価の実行と比較
   Evals API を使い、OpenAI ダッシュボードで評価を作成して実行します。
5. 継続的な評価
   変更のたびに評価を実行するように継続的評価（CE）を設定します。アプリケーションを監視して、動作が一定しない新たなケースを見つけ、評価セットに順次追加します。

評価が必要な箇所の特定

基本的な構成からより複雑なアーキテクチャに移行するにつれて、評価の対象も複雑になります。代表的なアーキテクチャには次の 4 つがあります。

• モデルとの単一ターンの対話
• ワークフロー
• 単一エージェント
• マルチエージェント

以下の説明を参考に、システムのどこで非決定性が生じるかを特定してください。その箇所に評価を実装します。

モデルとの単一ターンの対話

このアーキテクチャでは、ユーザーがモデルに入力を渡します。モデルはその入力と、開発者が指定したプロンプトがあればそれも併せて処理し、対応する出力を生成します。

例

オンライン小売を例に考えます。システムプロンプトで、顧客の質問を分類するようモデルに指示します。分類先は次のいずれかです。

• order_status
• return_policy
• technical_issue
• cancel_order
• other

一貫性のある効率的なユーザー体験を提供するため、モデルはユーザーの意図に合うラベルだけを返す必要があります。顧客が「注文は今どうなっていますか？」と質問した場合を考えます。

ワークフロー型アーキテクチャ

より複雑な問題を解くには、モデルとの単一ターンの対話から、複数のモデル呼び出しをつなぐ多段階のワークフローに移行することが多くなります。ワークフローにしても、新しい種類の非決定性は生じません。ワークフローを構成する複数のモデル呼び出しは、個別に評価できます。

例

先ほどと同じく、顧客が注文状況を尋ねたとします。ワークフロー型アーキテクチャでは、顧客の問い合わせを振り分け、次の手順で処理します。

1. 注文 ID の抽出
2. 注文の詳細の照会
3. 最終回答を生成するモデルへの注文詳細の受け渡し

このワークフローの各ステップには、モデルが従うべきシステムプロンプトがあります。モデルはそれらに従い、取得したすべてのデータを顧客にわかりやすい形で返します。

単一エージェントのアーキテクチャ

ワークフローとは異なり、エージェントは柔軟な判断を必要とする非定型の問題を解決します。エージェントには指示と一連のツールが与えられ、どのツールを使うかはエージェント自身が状況に応じて選びます。この選択が新たな非決定性の要因になります。

例

カスタマーサービスの例を単一エージェントで実装してみます。このエージェントは、次の 3 つのツールを利用できます。

• 注文照会ツール
• パスワードリセットツール
• 商品 FAQ ツール

顧客が注文状況を尋ねると、エージェントはツールを呼び出すか、顧客に返答するかをその場で判断します。たとえば、「注文は今どうなっていますか？」と尋ねられた場合、エージェントは顧客に注文 ID を尋ね返すことができます。これにより、顧客はより自然なやり取りができます。

マルチエージェントのアーキテクチャ

単一エージェントのアーキテクチャにツールやタスクを追加していくと、モデルが指示に従ったり、呼び出すべきツールを正しく選んだりするのが難しくなることがあります。マルチエージェントのアーキテクチャでは、異なる分野を専門とする複数のエージェントを用意して、この問題に対処します。ただし、複数のエージェント間での振り分けと引き継ぎが、新たな非決定性の要因になります。

例

単一エージェントの例をマルチエージェントのアーキテクチャに分けると、次の 4 つのエージェントで構成できます。

1. 振り分け担当エージェント
2. 注文担当エージェント
3. アカウント管理担当エージェント
4. 販売担当エージェント

顧客が注文状況を尋ねると、振り分け担当エージェントは、注文を照会できるように会話を注文担当エージェントに引き継ぐことがあります。顧客が話題を変えて商品について尋ねた場合、注文担当エージェントは問い合わせを振り分け担当に戻す必要があります。振り分け担当は、商品情報を取得するために販売担当へ引き継ぎます。

評価器の作成と組み合わせ方

独自の評価を設計する際には、いくつかの種類の評価器から選べます。評価器にどのような役割を担わせたいかを考えると、適した方法を選びやすくなります。

指標に基づく評価

定量評価では数値スコアが得られ、そのスコアを使って結果を絞り込んだり、順位を付けたりできます。回帰テストを自動化する際のベンチマークとしても役立ちます。

• 例：完全一致、文字列一致、ROUGE や BLEU による採点、関数呼び出しの正確性、実行による評価（たとえば text2sql のように、生成結果を実行して機能や動作を検証する方法）
• 課題：特定の用途に合わない場合や、微妙な違いを捉えられない場合があること

人間による評価

人間の判断による評価は品質が最も高い反面、時間と費用がかかります。

• 例：システムの出力にざっと目を通して改善や悪化の傾向をつかむ方法や、従業員、契約スタッフ、外部のラベル付け業者が出力の品質を判定するランダム化盲検テスト（少数の出力候補に順位を付ける、各出力を 1〜5 の段階で採点するなど）
• 課題：専門家の判断にばらつきがあり、費用と時間がかかること
• 推奨事項：
  • 人間による詳細なレビューを複数回行い、採点表を改善します。
  • 基準を言葉で説明するだけでなく、異なる点数に相当する具体例を示します（たとえば 10 点満点で 1 点、3 点、8 点の例）。
  • 数値スコアに加えて、合否を分けるしきい値を設けます。
  • 複数の評価者の判断をまとめるには、投票で合意を得る方法があります。

LLM による判定とモデル採点器

モデルを使って出力を判定すると、人間による評価よりも実行コストが低く、大規模に運用しやすくなります。判定能力の高い LLM が必要な場合は、まず gpt-6-astra を使います。コストやレイテンシの最適化に取り組む前に、人間が付けたラベルと判定が一致するかを検証してください。

• 例：
  • 一対比較：判定モデルに 2 つの回答を提示し、指定した基準に照らしてどちらが優れているかを判定させます。
  • 個別回答の採点：判定モデルが回答を 1 件ずつ独立に評価し、あらかじめ定めた品質指標に従って点数や評定を付けます。
  • 参照回答に基づく採点：判定モデルに参照回答や模範解答を渡し、それを基準に対象の回答を評価させます。
• 課題：位置バイアス（回答の提示順に影響されること）、冗長性バイアス（長い回答を好むこと）
• 推奨事項：
  • 判定の信頼性を高めるには、一対比較や合否判定を使います。
  • 可能であれば、採点には最も能力の高いモデルを使います。まず gpt-6-astra を使い、そのうえで、採点基準や参照回答セットに対して、特化型のリーズニングモデルのほうが良い結果を出すかを検証してください。
  • LLM は一般に長い回答を好むため、回答の長さが判定に与える影響を抑えます。
  • 採点の前に推論を行うと評価の性能が向上するため、推論と思考の連鎖を採点手順に組み込みます。
  • LLM による判定が人間による評価よりも速く、低コストになり、人間のアノテーションと安定して一致するようになったら、評価の規模を拡大します。
  • タスクの本質を保ちながら、自動採点できる形式で質問を作成します。よく使われる方法は、質問を選択式に書き換えることです。
  • 採点基準は明確かつ具体的に記述します。

どの方法にも限界があります。LLM による判定の品質は問題のコンテキストによって変わります。一方、専門家に正解ラベルを付けてもらうには費用と時間がかかります。

エッジケースへの対応

どのアーキテクチャでも、まず主要な正常系のシナリオを評価する必要があります。ただし、実際の AI システムでは、期待どおりの性能を発揮しにくいエッジケースに頻繁に遭遇します。信頼性と良好なユーザー体験を確保するには、こうしたケースの評価も重要です。

エッジケースは、いくつかの種類に分けられます。

入力の多様性

モデルに入力するのはユーザーなので、システムは多様な入力に柔軟に対応できる必要があります。たとえば、次のような入力があります。

• 英語以外の言語による入力や、複数の言語が混在する入力
• プレーンテキスト以外の形式（XML、JSON、Markdown、CSV など）
• 画像など、異なるモダリティの入力

指示への準拠と機能上の正しさを評価する際は、ユーザーが実際に試す可能性のある入力を考慮してください。

コンテキストの複雑さ

多くの LLM ベースのアプリケーションは、リクエストのコンテキストを十分に理解できずに失敗します。ユーザーが提供した情報のほか、過去の会話履歴に含まれるノイズも、コンテキストの理解に影響します。

具体例を挙げます。

• 1 件のリクエストに含まれる複数の質問や意図
• 入力ミスやつづりの誤り
• コンテキストがほとんどない短いリクエスト（ユーザーが「返品」とだけ入力した場合など）
• 長いコンテキストや長時間続く会話
• プロパティ名の意味が曖昧なデータを返すツール呼び出し（たとえば "on: 123" の「on」が注文番号を表す場合）
• 複数回のツール呼び出しによって、誤った引数が渡されるケース
• 複数回の引き継ぎによって、エージェント間の引き継ぎが循環するケース

パーソナライズとカスタマイズ

AI は個々のユーザーの要望に合わせることでユーザー体験を向上させますが、この柔軟性は多くのエッジケースも生みます。明示的に対応したいケースとブロックしたいケースについて、評価内容を明確に定めてください。

• モデルに本来とは異なる動作をさせようとするジェイルブレイクの試み
• 出力形式の指定（JSON 形式や箇条書きなど）
• ユーザープロンプトがシステムプロンプトと矛盾するケース

評価を活用した性能改善

評価手法が成熟し、性能を安定して測定できるようになったら、評価データを活用してアプリケーションの性能を改善する段階に進みます。

その他のリソース

評価設計の参考になるコード例やサードパーティの資料へのリンクは、OpenAI Cookbook にあります。OpenAI の評価ツールについては、次の資料も参照してください。

• モデル性能の評価
• 要約タスクの評価方法
• ファインチューニング
• 採点器
• Evals API リファレンス