モデルの比較を、チームが検討できるベンダーの決定に変える

意思決定とデモを分離する

承認してほしい対象を明確にします。探索的な実験、限定的な試行、本番利用のどれでしょうか。手動比較は統合実験に予算を付ける根拠にはなり得ます。ただし、サービスの信頼性、契約、実際の構成での動作など、本番利用の重要な疑問は残ります。

文章の魅力などを採点する前に、必須の合格条件を決めます。根拠のないフィールドを含めず有効なレコードを返す必要があるなら、流暢な文章を高く評価する平均点でその要件を薄めてはいけません。各条件の担当を決め、製品担当は許容する動作、技術担当は統合、事業側の担当者は契約などの条件を確認します。

検討会議にコンパクトな証拠パケットを提供します

Colay で、Ask separately を使用して最初の回答を収集します。選択したエージェントに同一の内容を提供し、回答をレビューできるようにしておきます。後で Consensus を使用してメモを作成する場合は、パケットを明示的に指定します。自信を持って合成しても、含まれなかった証拠を復元することはできません。

NIST の AI リスク管理フレームワークは、リスクの考慮事項を AI の設計、開発、使用、評価の一部として扱います。以下のメモは、当社が提案する作業形式であり、NIST 認定や Colay がガバナンス プロセスを完了しているという主張ではありません。

• 特徴と境界: 誰が出力を使用するか、どのアクションに使用するか、モデルが決して決定してはいけないもの。
• 比較条件: ソース入力、プロンプト バージョン、候補ラベル、日付、手動実行の制限。
• 証拠: 代表的な成功、重大な失敗、未解決のケースと、元の出力が添付されています。
• 推奨事項: 優先候補、信頼できる代替案、オープンゲート、所有者および再検討の日付。

• NIST: AI リスク管理フレームワーク↗

具体例：限定的な試行の候補を選ぶ

顧客が渡したプロジェクトメモを要約する架空の製品を考えます。候補 A は文章が最も整っていますが、あるケースで担当者を作り上げます。B は平易な要約で、担当者不明という状態を保ちます。C は利用できる回答が返らず評価できません。これは判断形式を示す架空の観察であり、実在のモデルの結果ではありません。

チームは B を統合試行に選び、プロンプト修正後の A を代替候補として残せます。C は未評価であり、劣っていると決まったわけではありません。この三つの観察から API の稼働率、契約の適合性、運用費は推測できません。メモにはこの境界を明記します。

反対意見を維持するプロンプト

査読者に最も強い反対意見を最初に読むよう依頼してください。その反対意見によって選択が変わる場合は、脚注に埋め込むのではなく、推奨事項を更新してください。 2 番目のエージェントにメモの批評を依頼することはできますが、繰り返しの承認はベンダーに関する独立した証拠ではありません。

この証拠パケット [パケット] から決定メモの草案を作成します。決定が求められています: [実験、パイロット、または本番]。必須の合格条件: [ゲート]。候補をこれらのゲートと比較します。観察されたすべての強度または失敗の入力 ID を引用します。未テストと失敗を区別します。推奨事項、代替案、最も強い反対意見、不足している証拠、次のテスト、および所有者のプレースホルダーを返します。価格、契約条件、実績などの数値をでっち上げないでください。欠落しているゲートを多数決の合意によって解決しないでください。

承認を行動に移すのに十分な範囲に限定する

次のステップを指定して会議を終了します。つまり、誰が実際のエンドポイントをテストするのか、どのような入力を使用するのか、その結果によってパイロットが停止されるのかなどです。将来の切り替えによって記憶から調査が再開されないように、選ばれなかった候補の証拠を保管しておいてください。

Colay は、この初期のエンドユーザー比較からプロバイダー キーの設定を削除しました。アプリケーションのベンダー契約や自動評価ダッシュボードは提供されません。そのサブスクリプションにはクレジットと制限が使用されます。現在のレビューの問題を解決できる最小の比較から始めて、コミットメントを拡大する前に統合の証拠に投資します。

質問と回答