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

次のステップ