製品で実際に使うプロンプトで AI モデルを比較する

機能をテスト可能なケースに変える

モデルの順位表ではなく、ユーザーが必要とする出力から始めます。アクション項目を抽出する機能なら、担当者、作業、期限を正しく保持し、不明な項目は不明のまま残すことが成功条件です。文章が整っていても期限を勝手に補った要約は、このケースでは不合格です。

開始セットの例として、12 個の許可された例（4 個の通常の入力、4 個のあいまいな入力、および 4 個のエッジケース）を準備します。これらの数値は管理可能な演習であり、統計的に検証されたサンプル サイズではありません。共有する権限のない個人情報や機密情報を削除します。期待される結果または明示的な受け入れルールを各ケースの横に保管してください。

解釈できる比較を実行する

Anthropic の評価ガイドでは、出力が変化する可能性があるため、タスクとそのタスクの繰り返し試行を区別しています。この記事では、その基本的な違いを手動スクリーニング演習に適用します。いくつかの明確な回答では、本番環境の失敗率を確立することはできません。

別の候補がすでに失敗した後で、ある候補に修正されたプロンプトを与えることは避けてください。プロンプトを改善する必要がある場合は、新しいバージョンを作成し、そのバージョンですべての候補を再実行します。そうしないと、モデルだけでなく命令も比較することになります。

1. 現在のカタログから候補エージェントを明示的に選択します。どの候補が回答したかを知る必要がある場合は、Auto を使用しないでください。
2. 概要、ソース資料、および要求された形式を同一にしてください。最初の回答についてはAsk separatelyし、ラベルを保持してください。
3. 日付、表示されたエージェント名、プロンプトのバージョン、および表示される設定を記録します。間違った応答とは別に、欠落している応答に注意してください。
4. 散文の品質を比較する前に、ルールに照らして各結果を確認してください。重要なケースまたはあいまいなケースを繰り返し、失敗を含むすべての試行を保持します。

• Anthropic：タスク、試行、評価設計↗

例: 会議メモのアクション アイテム

架空の入力: 「ミラは火曜日にドラフトを送信します。チームは価格設定の見直しのためにまだオーナーを必要としています。」目的の結果には、割り当てられたタスクが 1 つと割り当てられていないタスクが 1 つ含まれます。両方を Mira に割り当てたり、価格見直しの日付を発明したりすることはありません。

成果物は、最も見栄えのよい回答のスクリーンショットではなく、ケースごとの記録表です。返された原文を各行に添え、同僚が採点の根拠を確認できるようにします。形式の不備と事実の誤りは分けてください。直せる表のレイアウトと、勝手に追加された約束では影響が異なります。

スクリーニング実行のプロンプト

評価手順は、回答に適用する別のチェックリストに保管してください。別のエージェントに潜在的なエラーを特定するよう依頼できますが、その判定は検査すべき別の出力です。 Consensusは、最初の比較後に観察されたトレードオフを要約するのに役立ちます。ラベル付きの結果とスコアを明示的に指定します。

提供された会議メモからアクション アイテムを抽出します: [許可されたメモ]。タスク、所有者、期限、およびサポートする抜粋を含むテーブルを返します。提供されたテキストのみを使用してください。所有者や期限が不特定の場合は「不明」と書きます。提案を合意された約束に変えないでください。未解決の質問は個別に保存してください。 ID を入力: [ケース ID]。

次のテストで候補リストを使用する

各候補が対応できたケース、重大な失敗、未解決の質問をまとめます。機能の最低要件を満たす候補だけを残します。該当候補がなければ、勝者を決める前に機能を絞るか、与える文脈を改善します。

統合トライアルでは、実際のモデルのエンドポイント、ツールのアクセス、システム命令、レイテンシー、使用コスト、障害処理を個別にチェックする必要があります。 Colay のクレジットは、その API ワークロードの見積もりではありません。 Colay では、自分で採点できる実際の匿名化された 1 つのケースから始めて、比較によって最終候補リストが変更された場合にのみ拡張します。

質問と回答