AI 支援機能の UX 成熟度ガイドライン
概要
以下のガイドラインは、AI 支援機能の成熟度の UX の側面に焦点を当てています。適切な機能成熟度を判断するには、安定性やドキュメントなど他の側面も考慮する必要があります。
AI 支援機能の UX 成熟度を評価するには、プロダクト開発フローの 3 つの基準を使用します。
- 検証: 問題の検証: どれだけ問題を理解しているか?
- 検証: ソリューションの検証: ソリューションは問題にどれだけ対処しているか?
- 構築: 改善: ソリューションはどれだけ成功しているか?
AI 機能のための推奨検証
| 基準/成熟度 | Experiment | Beta | GA |
|---|---|---|---|
| 問題の検証 | 仮定のみに基づくことができる (証拠は不要)。 | 証拠と仮定の組み合わせ。 | 証拠のみ、または高リスクな仮定がない。 |
| ソリューションの検証 | 不要。 | 6 人の社内ユーザーによるソリューション検証。 | 6 人の社外ユーザーによるソリューション検証。 |
| 改善 | 該当なし (リリース前のデータがない)。 | チームが設定した品質目標が達成されている。 | チームが設定した品質目標が達成されている。 |
| AI 出力とユーザビリティの品質 | 不要。 | チームが設定した品質目標が達成されている。 | チームが設定した品質目標が達成されている。 |
検証: 問題の検証
ソリューションを決定するには、顧客の問題を理解することが不可欠です。AI 問題検証のガイドラインを参照してください。
検証: ソリューションの検証
AI ソリューションは、標準的なソリューション検証プロセスに従いますが、いくつかの追加の考慮事項があります。
- テストにおいて AI システムの出力を早期にシミュレートすることで、エンジニアリング作業に情報を提供できることがあります。
- AI システムは、不正確または予測不可能な出力を生成する可能性があります。AI のエラー、信頼、リスクに関するユーザーフィードバックを収集することが重要です。
詳細については、AI ソリューション検証のガイドラインと AI ユーザビリティメトリクスを参照してください。
構築: 改善
ソリューションはどれだけ成功しているか? この質問に答えるため、機能の UX 成熟度の文脈において、チームは成功指標として機能利用率を超えてユーザビリティシグナルを含めるよう努めるべきです。高い利用率は必ずしも機能が成功していることを意味しません。ユーザビリティシグナルは、有用性、効率性、効果性、満足度、学習可能性 の観点からソリューションの成功を評価するのに役立ちます。
成功指標に AI 応答の正確性を含めることも重要です。AI 搭載機能は、不正確、無関係、または有害な応答や出力を生成する可能性があります。不正確な応答のリスクは機能によって異なります。形成的評価の一環として AI システムの応答をテストすることが重要です。たとえば、1 人以上の専門評価者 (内部または外部) がさまざまなシナリオをテストして AI 応答を評価することができます。
AI 出力の品質評価
GitLab は AI ベンダーから使用するモデルを直接制御していませんが、これらのモデルの出力は、私たちが制御するさまざまな技術 (プロンプトエンジニアリング、RAG、コンテキスト強化など) によって影響を受けることがあります。エンドユーザーはこの仕組みを気にしないため、出力の品質は機能の品質として直接認識されます。そのため、チームが出力品質の信頼度とリスクを判断する際に役立つ以下のガイドラインを提供しています。
品質の信頼度は、機能がユーザー体験を損なう有害または不正確な結果を生成する、あるいは生成しないことについての確信の度合いを測るものです。リスクは、機能が有害または不正確な結果を生成する可能性の度合いを測るものです。
チームは UX リサーチガイダンスを使用して信頼度レベルを判断できます。以下は追加の提案です。
- 高い信頼度 = 2 つ以上の顧客向けソースからの強力な証拠 (下記参照)。
- 中程度の信頼度 = 少なくとも 1 つの顧客向けソースから良好なパフォーマンスの証拠があり、悪いパフォーマンスの証拠がほとんどまたはまったくない。
- 低い信頼度 = 良好なパフォーマンスの顧客向け証拠がない、または悪いパフォーマンスの証拠がある。
リスクは、機能がユーザー、組織、GitLab、または世界に及ぼし得る潜在的な害の度合いを測るものです。脆弱性のあるコードの作成、悪い報道のリスク、虚偽情報の生成などがリスクの例です。
信頼度とリスクのさまざまな状態を判断するのに役立つさまざまなツールやプロセスがあります。
注: Duo Enterprise については、Definition of Done が SSOT です。
高い信頼度 & 低いリスク
AI 搭載機能が出力品質に高い信頼度を持ち、有害または不正確な結果を生成するリスクが低い場合、機能は主に標準的な機能成熟度の定義に依存できます。この場合、評価データセットは不要ですが、機能にはユニットテストなどの基本的なガードレールが必要で、主に既存の AI Framework と AI Gateway に依存できます。
少なくとも 10 人の外部ユーザーで出力の品質を検証する UX Bash を実施することを検討してください。出力品質を評価するためにそれらを実施する方法のフレームワークがあります。
- 機能の品質について基準となる理解を持つべきです。
- ユーザーが少なくとも出力を有用だと感じる閾値以上
- 出力品質がユーザーの懸念を引き起こさない (安全でない、不快、リスクがあるなど)
- 初期の評価データセットに基づいて提案された品質閾値を持つこと。
低い信頼度 & 低いリスク
AI 搭載機能が出力品質に低い信頼度しか持たず、有害または不正確な結果を生成するリスクが低い場合、機能は主に小規模で基本的な評価に依存でき、通常は開発中に開発者によって、またユニットテスト内で実施されます。この場合、評価データセットは不要ですが、信頼度を向上させるための計画を策定する必要があります。この状態の機能は、信頼度を高める前に GA に移行すべきではありません。
少なくとも 10 人の外部ユーザーで出力の品質を検証する UX Bash を実施することが推奨されます。出力品質を評価するためにそれらを実施する方法のフレームワークがあります。
- 機能の本番利用が想定される少なくとも 100 個のプロンプト (ユーザー入力と望ましい LLM 出力) のデータセットを開発します。LLM の望ましい挙動と望ましくない可能性のある挙動の両方に焦点を当てた例を提供します。
- 機能の主要なユースケースをデータセットに含めるべきです。
- 評価データセットは現実的な顧客利用を代表するものであるべきです。
- 可能な限り、GitLab ベースのデータに基づく履歴データに評価を基づかせることを強く推奨します。
不明な信頼度 & 不明なリスク
AI 搭載機能が出力品質について不明な信頼度を持ち、有害または不正確な結果を生成するリスクが不明な場合、解決しようとしている根本的なユーザー問題に立ち返ります。
以下を定義することが役立ちます。
- 機能が何をすべきか
- 機能が何をすべきでないか
- 高品質な出力の例
このような不明な領域にいる場合、AI 機能のリリースを進めるべきではありません。不確実性を取り除く方法のアイデアを得るために、Slack の AI-powered ステージ (#s_ai-powered) に連絡してください。
高い信頼度 & 高いリスク
AI 搭載機能が出力品質に高い信頼度を持ち、有害または不正確な結果を生成するリスクが高い場合、機能は評価データセットを開発する必要があります。
毎回少なくとも 10 人の外部ユーザーで出力の品質を検証する複数の UX Bash を実施することが必須です。出力品質を評価するためにそれらを実施する方法のフレームワークがあります。
- 特定したリスク領域に焦点を当てた少なくとも 500 件の評価のデータセットを開発します。
- データセットは CEF でサポートされ、毎日の CEF 実行に含まれます。
- サポートされるすべてのユースケースおよび/またはサポートされるプログラミング言語には、大規模な評価のためのデータセットがあります (数百件以上の評価が必要)。
- 理想的には、最終的な UX Bash を実施して、実際のエンドユーザーが評価品質閾値に同意することを確認します。
- 機能を GA に進める前に、リーダーシップから明示的な承認を得ます。
低い信頼度 & 高いリスク
AI 搭載機能が出力品質に低い信頼度しか持たず、有害または不正確な結果を生成するリスクが高い場合、チームが出力品質の信頼度を高めるまで機能を進めるべきではありません。
毎回少なくとも 10 人の外部ユーザーで出力の品質を検証する複数の UX Bash を実施することが必須です。出力品質を評価するためにそれらを実施する方法のフレームワークがあります。
- 特定したリスク領域に焦点を当てた少なくとも 100 件の評価のデータセットを開発します。
- データセットは CEF でサポートされ、毎日の CEF 実行に含まれます。
- 実験的な、デフォルトでオフのリリースを超える検討をする前に、リーダーシップから明示的な承認を得ます。
bfd74782)