強力な実証的評価を作成する

成功基準を定義した後、次のステップはそれらの基準に対してLLMのパフォーマンスを測定するための評価を設計することです。これはプロンプトエンジニアリングサイクルの重要な部分です。

このガイドでは、テストケースの開発方法に焦点を当てます。

評価とテストケースの構築

評価設計の原則

1. タスク固有にする: 実際のタスク分布を反映した評価を設計します。エッジケースを考慮することを忘れないでください！

   エッジケースの例

2. 可能な限り自動化する: 自動採点を可能にする質問を構造化します（例：多肢選択、文字列マッチ、コード採点、LLM採点）。
3. 品質よりも量を優先する: わずかに低いシグナルの自動採点でより多くの質問を持つ方が、高品質な人間による手動採点の評価で少ない質問を持つよりも良いです。

評価の例

評価の採点

評価を採点するためにどの方法を使用するかを決定する際は、最も高速で、最も信頼性が高く、最もスケーラブルな方法を選択してください：

1. コードベースの採点: 最も高速で信頼性が高く、非常にスケーラブルですが、ルールベースの厳格さを必要としない複雑な判断には微妙さが欠けます。

   • 完全一致: output == golden_answer
   • 文字列マッチ: key_phrase in output

2. 人間による採点: 最も柔軟で高品質ですが、遅くて高価です。可能であれば避けてください。

3. LLMベースの採点: 高速で柔軟、スケーラブルで複雑な判断に適しています。まず信頼性をテストしてからスケールしてください。

LLMベースの採点のヒント

• 詳細で明確なルーブリックを持つ: 「答えは常に最初の文で'Acme Inc.'に言及すべきです。そうでない場合、答えは自動的に'不正解'として採点されます。」
  特定のユースケース、またはそのユースケースの特定の成功基準でさえ、包括的な評価のために複数のルーブリックが必要な場合があります。
• 実証的または具体的: 例えば、LLMに'正解'または'不正解'のみを出力するよう指示するか、1-5のスケールで判断するよう指示します。純粋に定性的な評価は迅速かつ大規模に評価するのが困難です。
• 推論を促す: 評価スコアを決定する前にまず考えるようLLMに求め、その後推論を破棄します。これは、複雑な判断を必要とするタスクの評価パフォーマンスを向上させます。

次のステップ