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

次のステップ