人間中心のAIプロダクト開発に向けて意識すること ~エラーハンドリング~

Transcript

1. ⼈間中⼼のAIプロダクト開発に向けて意識すること ユーザーとAIのエラーハンドリング @ottamm_190 2023/03/26
2. はじめに GoogleのPeople + AI Research チームがまとめたガイドブック (2021年5⽉18⽇更新版) https://pair.withgoogle.com/guidebook このスライドはガイドブックを訳し、⾃分の知⾒を⼀部加筆した。 技術中⼼から⼈間中⼼に考える視野を広げてくれるガイドブックでした。 2019年6⽉12⽇時点で⽻⼭ 祥樹（@storywriter）さんの⽇本語訳サイトも⼤変参考になりました。
3. エラーと上⼿な失敗 エラーへの対処がAIシステムの信頼に直結する
4. エラーと上⼿な失敗 ➀ エラーと失敗を定義する ➁ エラーの原因を特定する ➂ 失敗しても先に進めるようにする ü ユーザーが確信度の低い予測を「エラー」と⾒なすのはいつか ü 複雑なAIのエラーの原因をどのようにすれば特定できるのか ü AIが失敗したとき、ユーザーが先に進めるようになっているか
5. エラーと上⼿な失敗 ➀ エラーと失敗を定義する ➁ エラーの原因を特定する ➂ 失敗しても先に進めるようにする AIシステムは出⼒をすれば成功ではない ユーザーの期待に答える必要がある ユーザーはいつエラーを引き起こすのかを知りたい
6. エラーと失敗を区別する システムエラー • ユーザーの観点から定義されたプロダクトのバグによるエラー ユーザーエラー • システム設計者の観点から定義されたユーザーの「誤⽤」のせいで起こるエラー コンテキストエラー • ユーザーの期待に応えられないエラー • システムは「意図した通りに動いている」が、ユーザーはエラーだと認識 • システムの動作が⼗分に説明されていない • ユーザーのメンタルモデルを壊れている • 予測の精度が悪いときに起こる AIシステムの制限による失敗 • システムの限界のため出⼒は不可だが、ユーザーからは応答を求められている状態 • エラーメッセージでは、システムの制限を具体的にユーザーに知らせる
7. 使い始めと慣れた時でエラーの感度が変わる 需要予測の場合 ・データが少ないとき、コンテキストエラーにならない。 ・データが溜まってきたとき、予測を外されるとコンテキストエラーになる。 新商品（学習期間が短い） 予測が外れても新商品だし…と許容される。 既存商品（学習期間が⻑い） ⻑いこと販売しているはずなのに… 予測誤差を許容できなくなってくる。 ⽋損期間があり、 学習期間が短いなど。
8. 状況に応じた利害とエラーのリスクを検討する AI のエラーや失敗は、ときに深刻な結果をもたらす 前提として、ユーザーは忙しい • AI 製品を使⽤時はマルチタスク、時間のプレッシャーにさらされている • システムの出⼒を再確認する余裕がない Ø 潜在的に起こりうるエラーのリスクを測定する Ø 状況の利害関係を評価する
9. 潜在的に起こりうるエラーのリスクを測定する エラーが起こる可能性が低いケース • ユーザーはタスクの専⾨知識を持っている • 過信せず、吟味して使う • システムの信頼度が⾮常に⾼い • 成功する可能性が⾼い エラーが起こる可能性が⾼いケース • ユーザーがタスクの初⼼者 • 注意⼒が散漫や反応時間が短い (マルチタスク) • システムの信頼度が低い • 成功の条件が狭い PoCをするときはこちらのケースが多い。 導⼊するとこちらのケースが多い。
10. 状況の利害関係を評価する 利害が⼩さい • お試し的な実験 • 遊びやクリエイティブのとき • 推薦が必須でないとき 利害が⼤きい • 健康、安全、または財政上の決定 • デリケートな社会的状況 • クリエイティブでも競合製品と類似するとき ChatGPTで利⽤が最適。 利害があるときは慎重に 個別モデルを検討
11. エラーと上⼿な失敗 ➀ エラーと失敗を定義する ➁ エラーの原因を特定する ➂ 失敗しても先に進めるようにする ユーザー体験に基づきエラーごとに原因を特定する エラーの種類を理解する
12. エラーの特定と対策 予測と訓練データのエラーを⾒つける ユーザーの⼊⼒エラーを想定し、対策しておく システム側は別サービスの出⼒の品質をチェックする データセットや モデルのエラー 複数のAIシステム間の データエラー ユーザーの ⼊⼒エラー コンテキストエ ラー AI システム ユーザー
13. 予測と訓練データのエラーを⾒つける • ラベリングミスまたは誤分類 • データの⽋損や不完全 • データやモデルのバイアス [左図] Principles of Explanatory Debugging to Personalize Interactive Machine Learning,2015 [右図] Errudite: Scalable, Reproducible, and Testable Error Analysis, ACL2019 https://www.rungalileo.io/ 分析ツールの論⽂が多く出ている。 データ分析ツールもMLOps製品として開発 NLPだとGalileo など
14. システム側は別サービスの出⼒の品質を監視する 複数のシステムを連携するとき • 別のシステムの出⼒が期待通りか監視しておく • 複数のAIシステムの関係を視覚的に表現する ChatGPT API response request システム ロバスト評価 テストに対し、期待する結果か 形式は想定内の崩れか
15. ⼊⼒エラーを想定して対策しておく 予期しない⼊⼒があることを事前に考えておく • もし検索時にスペルミスしてもシステムが修正するとユーザーが期待していたら • 対応︓ユーザーの⼊⼒と予想される回答の範囲を⽐較し、意図を確認 ユーザーの慣れから起こるミスを考えておく • UIの変更によってユーザーの⾏動が変化し、望ましくない結果につながるとき • 対応︓慣れを壊さない⽅法を検討 ⼊⼒の意図を間違えることを意識する • システム側がユーザーの⾏動または選択を不適切に重み付けするとき • 対応: システムが⼊⼒と出⼒を説明し、ユーザーがフィードバックを通じてシステム を修正できるようにする。
16. エラーと上⼿な失敗 ➀ エラーと失敗を定義する ➁ エラーの原因を特定する ➂ 失敗しても先に進めるようにする ⼈とAIの協調を⽬指す ⼈がAIのエラーを引き継ぎ、改善していく
17. ➂ 失敗しても先に進めるようにする システムに障害が発⽣した後、ユーザーができることに焦点を当てる フィードバックの機会を作る • ユーザーが経験するエラーの多くは、システムを改善するためにフィードバックを 必要とする。 • ミスラベルなど、システム⾃体が容易に認識できないエラーは、外部からのフィー ドバックで修正する。 • プロンプトで修正を要求する。 ⾃動化や⽀援を⽌めて、主導をユーザーに戻す • AI システムに障害が発⽣した多くの場合、ユーザーに出⼒をさせるよう引き継ぐ
18. [実践] エラーを洗い出す モデルが⽣成しうる様々なエラーの種類を洗い出す。 システムの制限 システム固有の限界のため、システムが 正しい答えを提供できない。 ⽂脈 システムは「意図したとおりに動作している」が、シス テムのアクションが⼗分に説明されていない、ユーザーのメン タルモデルを壊している、または不⼗分な仮定に基づいて いるため、ユーザーはエラーを認識する。 背景 システムが正しく動作していない状況だが、ユーザー もシステムもエラーを認識していない状態。 スクリーンショット、画像、ログを追加して、エラーが発⽣したとき にユーザーが⾒ているものを記述する。
19. [実践] 解決策をまとめる エラーの根拠 エラーの解決策 モデル改善の機会
20. 個⼈的な学びと失敗 ➀ エラーと失敗を定義する • 画像ごとのスコアのカラーの正規化範囲が画像枚に設定されており、画像間の違いを指摘された。 • コンテキストエラーは専⾨家なほど、バイアスもあり、起きやすいように感じる。 • 利害が多いケースでChatGPTがどこまで使えるかのPoCが今後増える。 ➁ エラーの原因を特定する • 別サービスの出⼒品質の監視が意外とできていないと思った。 • 予測精度のロバスト評価やエラー分析をきちんとする。 ➂ 失敗しても先に進めるようにする • 予測の不確実性の⾼さから⾃信がないときは⼈間に戻す。 • ChatGPTならサービス外の質問か分類するか、答えないように指⽰し、次に繋げる。