実証的なパフォーマンス評価
コードの例に直接進むには、評価のクックブックをご覧ください。
タスクにおいて可能な限り高い精度をClaudeに提供するように最適化することは、経験的な科学であり、継続的な改善のプロセスです。プロンプトの変更がClaudeのパフォーマンスを向上させたかどうかを判断しようとしている場合、異なるClaudeモデルを相互にテストしている場合、またはユースケースが本番環境に対応できるかどうかを評価している場合、適切に設計された評価システムは成功のために不可欠です。
このガイドでは、プロンプト開発のライフサイクル、さまざまなタイプの評価（eval）、それらの長所と短所について説明し、ユースケースに最適な評価を選択する方法についてのガイドラインを提供します。
評価の使用方法
LLMを使用する際、評価は本番ライフサイクル全体に不可欠な要素であるべきです。評価は、進捗状況を追跡し、問題を特定し、データに基づいた意思決定を行うための定量的な指標を提供します。本番ライフサイクルの各段階における評価の役割は次のとおりです。
- プロンプトエンジニアリング：プロンプトエンジニアリングのプロセスは、プロンプトを書くことではなく、厳密な評価セットを構築することから始めるべきです。これらの評価は、プロンプトの有効性を測定するための基盤として機能し、時間の経過とともにプロンプトを反復および改善するのに役立ちます。
- 開発：Claudeを使用してアプリケーションやワークフローを開発する際は、プロンプトエンジニアリングの段階で設計した評価を使用して、プロンプト自体が変更されていない場合でも、プロンプトのパフォーマンスを定期的にテストしてください。プロンプトの外部および下流のワークフローの一部が、意図せずにモデルのパフォーマンスに影響を与える可能性があります。これにより、問題を早期に発見し、ワークフローが期待どおりに機能していることを確認できます。
- 最終テスト：アプリケーションまたはワークフローを本番環境にデプロイする前に、開発段階で使用していない評価を少なくとも1セット作成してください。この保留された評価セットは、プロンプトの真のパフォーマンスを評価し、開発中に使用された評価に過剰適合していないことを確認するのに役立ちます。
- 本番環境：アプリケーションまたはワークフローが本番環境に移行したら、評価を引き続き使用してパフォーマンスを監視し、潜在的な問題を特定します。また、評価を使用して、異なるClaudeモデルやプロンプトのバージョンのパフォーマンスを比較し、更新や改善に関するデータに基づいた意思決定を行うこともできます。
本番ライフサイクル全体で評価を組み込むことで、プロンプトが最適に機能し、アプリケーションまたはワークフローが可能な限り最高の結果を提供していることを確認できます。
評価の構成要素
評価には通常、4つの部分があります。
- 入力プロンプト：モデルに入力されるプロンプト。Claudeは、このプロンプトに基づいて補完（出力とも呼ばれる）を生成します。評価を設計する際、入力列には、テスト時にプロンプトテンプレートに入力される一連の可変入力が含まれることがよくあります。
- 出力：評価対象のモデルに入力プロンプトを実行することで生成されるテキスト。
- ゴールデンアンサー：モデルの出力と比較される正解。ゴールデンアンサーは、必須の完全一致である場合と、採点者（人間またはLLM）に完璧な回答の例を提供することを目的とした場合があります。
- スコア：以下で説明する採点方法のいずれかによって生成される数値で、モデルが質問にどの程度うまく答えたかを表します。
評価の採点方法
評価において時間がかかり、コストがかかる可能性がある側面は2つあります。質問とゴールデンアンサーのペアを作成すること、および採点です。質問とゴールデンアンサーを作成するのは通常、一度限りの固定コストですが、採点は評価を再実行するたびに発生するコストであり、頻繁に行う可能性があります。その結果、迅速かつ安価に採点できる評価を構築することが、設計上の選択の中心になるべきです。
評価を採点する一般的な方法は3つあります。
- コードベースの採点：標準のコード（主に文字列マッチングと正規表現）を使用してモデルの出力を採点することを含みます。一般的なバージョンには、回答との完全一致をチェックすること、または文字列に一部のキーフレーズが含まれていることをチェックすることが含まれます。これは、評価がそれを可能にするように設計できる場合に最適な採点方法です。高速で非常に信頼性が高いためです。ただし、多くの評価ではこのスタイルの採点は許可されません。
- 人間による採点：人間がモデルが生成した回答を見て、ゴールデンアンサーと比較し、スコアを割り当てます。これは、ほぼすべてのタスクに使用できるため、最も有能な採点方法ですが、特に大規模な評価を構築した場合、非常に時間がかかり、コストがかかります。可能であれば、人間による採点を必要とする評価を設計することは避けるべきです。
- モデルベースの採点：Claudeは自己採点に非常に適しており、創作文章のトーンの分析や自由形式の質問応答の正確性など、従来は人間を必要としていた可能性のあるさまざまなタスクを採点するために使用できます。これは、Claudeの採点者プロンプトを作成することで実現できます。
評価の種類
Claudeのタスクに対するパフォーマンスを測定するために使用できる評価にはいくつかの種類があります。それぞれの種類には長所と短所があります。
| 評価の種類 | 説明 | 長所 | 短所 |
|---|---|---|---|
| 多肢選択式問題（MCQ） | 複数の回答があり、そのうちの少なくとも1つが正解である閉じた形式の質問 | - 自動化が容易- トピックに関する一般的な知識を評価- 明確な解答キー- 正確さがどのようなものかを知るのが容易 | - テストが公開されている場合、トレーニングの漏洩の可能性- より複雑またはオープンエンドのタスクの評価が制限される |
| 完全一致（EM） | モデルの回答が正解と完全に同じ文字列であるかどうかをチェック | - 自動化が容易- 特定の知識またはタスクを評価する際の高い精度- 正確さがどのようなものかを知るのが容易 | - より複雑またはオープンエンドのタスクの評価が制限される- 正解のバリエーションをキャプチャできない可能性がある |
| 文字列マッチング | モデルの回答に解答文字列が含まれているかどうかをチェック | - 自動化が容易- モデルの出力に特定の情報が存在することを評価 | - モデルの応答の完全なコンテキストまたは意味をキャプチャできない可能性がある- 偽陽性または偽陰性が発生する可能性がある |
| オープンアンサー（OA） | 複数の解決策が可能であるか、評価に複数のステップのプロセスが必要なオープンエンドの質問 | - 高度な知識、暗黙知、または定性的なオープンエンドのパフォーマンスを評価するのに最適- 人間またはモデルによって採点可能 | - 自動化がより困難- 採点のための明確なルーブリックが必要- モデルベースの採点は人間による採点よりも精度が低い可能性がある |
評価を設計するためのベストプラクティス
特定のユースケースに合わせて評価を設計する際は、次のベストプラクティスを念頭に置いてください。
- タスク固有の評価：可能な限り、タスクに固有の評価を行います。評価における分布が、実際の質問と質問の難易度の分布を表すようにしてください。
- モデルベースの採点のテスト：モデルベースの採点者がタスクを適切に採点できるかどうかを知る唯一の方法は、それを試してサンプルを読み、タスクが適切な候補であるかどうかを確認することです。
- 可能な限り自動化する：多くの場合、巧みな設計により評価を自動化できます。タスクに忠実であることを維持しながら、自動採点を可能にする方法で質問を構成するようにしてください。質問を多肢選択式に再フォーマットすることは一般的な戦術です。
- 質の高さよりも量を優先する：一般に、質の高い質問の量が非常に少ないよりも、質問の量が多く質が低い方が望ましいです。
- 評価のクックブックを使用する：評価のクックブックには、ガイダンスとコピー可能なコードを含む、人間とモデルによって採点されるさまざまなタイプの評価の実装例が提供されています。
これらのベストプラクティスに従い、ユースケースに適した評価の種類を選択することで、Claudeのパフォーマンスを効果的に測定し、プロンプトとワークフローを改善するためのデータに基づいた意思決定を行うことができます。