潜在的な損害をマップする
責任ある生成 AI プロセスの最初の段階は、計画されたソリューションに影響を与える可能性のある潜在的な損害をマップすることです。 このステージには、次に示すように 4 つの手順があります。
- 潜在的な損害を特定する
- 特定された損害に優先順位を付ける
- 優先順位付けされた損害をテストして検証する
- 検証済みの損害を文書化して共有する
1: 潜在的な損害を特定する
生成 AI ソリューションに関連する潜在的な損害は、出力の生成に使用される特定のサービスとモデル、出力のカスタマイズに使用される微調整または接地データなど、複数の要因によって異なります。 ジェネレーティブ AI ソリューションの潜在的な損害には、次のような一般的な種類があります。
- 不快、悲観的、または差別的なコンテンツを生成する。
- 事実の不正確さを含むコンテンツの生成。
- 違法または非倫理的な行動やプラクティスを奨励またはサポートするコンテンツを生成する。
ソリューション内のサービスとモデルの既知の制限事項と動作を完全に理解するには、使用可能なドキュメントを参照してください。 たとえば、Azure OpenAI サービスには 透明性に関するメモが含まれています。サービスおよびそれに含まれるモデルに関連する特定の考慮事項を理解するために使用できます。 さらに、個々のモデル開発者は、 GPT-4 モデルの OpenAI システム カードなどのドキュメントを提供できます。
Microsoft 責任ある AI 影響評価ガイドのガイダンスを確認し、関連する責任ある AI 影響評価テンプレートを使用して潜在的な損害を文書化することを検討してください。
潜在的な損害を特定するために使用するリソースの 情報とガイドライン を確認します。
2: 害に優先順位を付ける
特定した潜在的な損害ごとに、発生する可能性と、発生した場合の影響レベルを評価します。 次に、この情報を使用して、最も可能性が高く影響を及ぼす損害に優先順位を付けます。 この優先順位付けにより、ソリューション内の最も有害なリスクを見つけて軽減することに集中できます。
優先順位付けでは、ソリューションの意図された使用と誤用の可能性を考慮する必要があります。と主観的な可能性があります。 たとえば、シェフやアマチュアの料理人にレシピ支援を提供するスマートキッチンの副操縦士を開発しているとします。 潜在的な損害には、次のようなものがあります。
- このソリューションは不正確な調理時間を提示し、その結果、食べ物が十分に調理されず、病気を引き起こす可能性があります。
- プロンプトが表示されたら、ソリューションは毎日の成分から製造することができる致命的な毒のレシピを提供します。
どちらの結果も望ましくありませんが、致死的な毒物の作成をサポートするソリューションの可能性は、料理不足の食品を作成する可能性よりも高い影響を与える可能性があると判断できます。 ただし、ソリューションの主要な使用シナリオを考えると、不正確な調理時間が推奨される頻度は、毒レシピを明示的に要求するユーザーの数よりもはるかに多いと考えることができます。 最終的な優先順位の決定は、十分に優先順位を付けるためにコンサルティング ポリシーまたは法律専門家を含むことができる開発チームの議論の対象です。
3: 損害の有無をテストして確認する
優先順位付けされた一覧が作成できたので、ソリューションをテストして、問題が発生したことを確認できます。その場合は、どのような条件下で行います。 また、テストによって、一覧に追加できる、以前に特定されていない損害が存在することが明らかになる場合もあります。
ソフトウェア ソリューションの潜在的な損害または脆弱性をテストする一般的なアプローチは、テスト担当者のチームがソリューションの弱点を意図的に調査し、有害な結果を生み出そうとする "レッド チーム" テストを使用することです。 前に説明したスマート キッチン 副操縦ソリューションのテストの例には、毒レシピの要求や、十分に調理する必要がある成分を含むクイック レシピが含まれる場合があります。 赤いチームの成功を文書化し、レビューして、ソリューションの使用時に有害な出力が発生する現実的な可能性を判断する必要があります。
注
Red Teaming は、ソフトウェア ソリューションの整合性を損なう可能性のあるセキュリティの脆弱性やその他の弱点を見つけるためによく使用される戦略です。 このアプローチを拡張して、生成 AI から有害なコンテンツを見つけることで、既存のサイバーセキュリティ プラクティスに基づいて構築され、補完する責任ある AI プロセスを実装できます。
生成型 AI ソリューションの Red Teaming の詳細については、Azure OpenAI Service ドキュメントの 「Red Teaming large language models (LLM) の概要 」を参照してください。
4: 損害の詳細を文書化し、共有する
ソリューションに潜在的な損害が存在することをサポートする証拠を収集したら、詳細を文書化し、関係者と共有します。 その後、新しい損害が特定された場合は、優先順位付けされた一覧を維持して追加する必要があります。