Loading...
  • ビルド
  • 管理
  • モデルと料金
  • クライアントSDK
  • APIリファレンス
Search...
⌘K
Log in
成功の定義と評価の構築
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...

Solutions

  • AI agents
  • Code modernization
  • Coding
  • Customer support
  • Education
  • Financial services
  • Government
  • Life sciences

Partners

  • Amazon Bedrock
  • Google Cloud's Vertex AI

Learn

  • Blog
  • Courses
  • Use cases
  • Connectors
  • Customer stories
  • Engineering at Anthropic
  • Events
  • Powered by Claude
  • Service partners
  • Startups program

Company

  • Anthropic
  • Careers
  • Economic Futures
  • Research
  • News
  • Responsible Scaling Policy
  • Security and compliance
  • Transparency

Learn

  • Blog
  • Courses
  • Use cases
  • Connectors
  • Customer stories
  • Engineering at Anthropic
  • Events
  • Powered by Claude
  • Service partners
  • Startups program

Help and security

  • Availability
  • Status
  • Support
  • Discord

Terms and policies

  • Privacy policy
  • Responsible disclosure policy
  • Terms of service: Commercial
  • Terms of service: Consumer
  • Usage policy
ビルド/テストと評価

成功基準を定義し、評価を構築する

LLMベースのアプリケーションの成功基準を定義し、パフォーマンスを測定するための評価を設計する方法を学びます。

LLMベースのアプリケーションの構築を成功させるには、成功基準を明確に定義し、それに対するパフォーマンスを測定するための評価を設計することから始まります。このサイクルはプロンプトエンジニアリングの中心です。

プロンプトエンジニアリングのフローチャート:テストケース、予備的なプロンプト、反復的なテストと改善、最終検証、リリース

成功基準を定義する

良い成功基準は以下の特性を持ちます:

  • 具体的: 達成したいことを明確に定義します。「良いパフォーマンス」ではなく、「正確なセンチメント分類」と指定します。

  • 測定可能: 定量的メトリクスまたは明確に定義された定性的スケールを使用します。数値は明確性とスケーラビリティを提供しますが、定量的メトリクスと一緒に一貫して適用される場合、定性的メジャーも価値があります。

    • 倫理やセーフティなどの「曖昧な」トピックでさえ定量化できます:
      セーフティ基準
      悪い安全な出力
      良い10,000回の試行のうち、0.1%未満の出力がコンテンツフィルターで毒性フラグが立てられる。

  • 達成可能: 業界ベンチマーク、以前の実験、AI研究、または専門知識に基づいてターゲットを設定します。成功メトリクスは現在の最先端モデルの能力に対して非現実的であってはいけません。

  • 関連性: 基準をアプリケーションの目的とユーザーニーズに合わせます。強い引用精度は医療アプリケーションにとって重要かもしれませんが、カジュアルなチャットボットではそうではありません。

一般的な成功基準

ここに、ユースケースにとって重要かもしれない基準があります。このリストは完全ではありません。

ほとんどのユースケースでは、複数の成功基準に沿った多次元評価が必要になります。


評価を構築する

評価設計の原則

  1. タスク固有である: 実世界のタスク分布を反映する評価を設計します。エッジケースを考慮することを忘れないでください!

  2. 可能な限り自動化する: 自動採点を可能にするように質問を構造化します(例:多肢選択、文字列マッチ、コード採点、LLM採点)。
  3. 品質より量を優先する: 自動採点の信号がやや低い多くの質問の方が、高品質な人間による手採点評価の少ない質問よりも優れています。

評価の例

数百のテストケースを手作業で作成するのは難しいかもしれません!ベースラインのテストケースセットからさらに多くを生成するのをClaudeに手伝ってもらいましょう。
成功基準を評価するのに役立つ評価方法がわからない場合は、Claudeとブレインストーミングすることもできます!

評価を採点する

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

  1. コードベースの採点: 最速で最も信頼性が高く、非常にスケーラブルですが、ルールベースの厳密性が低い、より複雑な判断に対する微妙さが不足しています。

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

  3. LLMベースの採点: 高速で柔軟、スケーラブルで複雑な判断に適しています。スケーリングする前に信頼性を確認するためにテストしてください。

LLMベースの採点のヒント

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

次のステップ

基準をブレインストーミングする

claude.aiでClaudeを使用してユースケースの成功基準をブレインストーミングします。

ヒント:このページをClaudeへのガイダンスとしてチャットにドロップしてください!

評価クックブック

人間、コード、LLM採点評価のコード例をさらに参照してください。

Was this page helpful?

  • LLMベースの採点のヒント