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

次のステップ