成功基準を定義した後、次のステップはそれらの基準に対して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に評価スコアを決める前に考えるように指示し、その推論は破棄します。これにより、特に複雑な判断を必要とするタスクの評価パフォーマンスが向上します。

次のステップ