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

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

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

評価設計の原則

  1. タスク固有にする: 実際のタスク分布を反映する評価を設計します。エッジケースを考慮することを忘れないでください!
  2. 可能な限り自動化する: 自動採点を可能にする質問を構造化します(例:多肢選択、文字列マッチ、コード採点、LLM採点)。
  3. 品質よりも量を優先する: わずかに低いシグナルの自動採点でより多くの質問を持つ方が、高品質な人間による手動採点の評価で少ない質問を持つよりも良いです。

評価の例

何百ものテストケースを手作業で書くのは困難です!ベースラインとなる例のテストケースセットからより多くを生成するためにClaudeに手伝ってもらいましょう。
成功基準を評価するのに有用な評価方法がわからない場合は、Claudeとブレインストーミングすることもできます!

評価の採点

評価を採点する方法を決定する際は、最も速く、最も信頼性が高く、最もスケーラブルな方法を選択してください:

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

    • 完全一致: output == golden_answer
    • 文字列マッチ: key_phrase in output
  2. 人間による採点: 最も柔軟で高品質ですが、遅くて高価です。可能であれば避けてください。

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

LLMベースの採点のコツ

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

次のステップ