Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
人間中心のAIプロダクト開発に向けて意識すること ~データ収集と評価~
Search
masatoto
March 26, 2023
Design
0
170
人間中心のAIプロダクト開発に向けて意識すること ~データ収集と評価~
masatoto
March 26, 2023
Tweet
Share
More Decks by masatoto
See All by masatoto
Weekly AI Agents News!
masatoto
29
43k
Weekly AI Agents News! 12月号 プロダクト/ニュースのアーカイブ
masatoto
0
190
Weekly AI Agents News! 12月号 論文のアーカイブ
masatoto
0
80
Weekly AI Agents News! 11月号 論文のアーカイブ
masatoto
0
250
Weekly AI Agents News! 11月号 プロダクト/ニュースのアーカイブ
masatoto
0
240
Weekly AI Agents News! 10月号 論文のアーカイブ
masatoto
1
440
Weekly AI Agents News! 10月号 プロダクト/ニュースのアーカイブ
masatoto
1
160
Weekly AI Agents News! 9月号 論文のアーカイブ
masatoto
1
150
Weekly AI Agents News! 9月号 プロダクト/ニュースのアーカイブ
masatoto
2
170
Other Decks in Design
See All in Design
最速[要出典]アクセシビリティチェック
magi1125
2
150
ABEMAの進化 – 複雑化したコンテンツ構造とUI改善への道 – / abema-ui-improve
cyberagentdevelopers
PRO
2
500
Webデザイナーが押さえておきたいエンジニアとの連携ポイント
448jp
0
2.6k
東急URBAN HACKSのデザイナーって何やってるの? 〜Designer Night #1〜
tak073
0
200
SaaSのマーケティングを進めるサービスサイトを育てる取り組み / Designship 2024 Main Stage
sms_tech
1
1.4k
root COMPANY DECK / We are hiring!
root_recruit
1
17k
Haruki_Konaka_Portforio.pdf
haruki556
0
880
共創するのはモノではなく価値 ── 日本の「はたらく」を変える挑戦 / Designship2024 MainStage
visional_engineering_and_design
1
670
Arborea Art Book
thebogheart
1
310
界隈からの逃走–デザイン初め新年会2025
sekiguchiy
3
870
Charcoal 2.0: デザインシステムの基盤を再構築
godlingkogami
1
600
Design System for training program
mct
0
170
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
22
1.3k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
3
230
YesSQL, Process and Tooling at Scale
rocio
170
14k
Imperfection Machines: The Place of Print at Facebook
scottboms
266
13k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
KATA
mclloyd
29
14k
Building an army of robots
kneath
302
44k
The Pragmatic Product Professional
lauravandoore
32
6.4k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
19
2.3k
Designing Experiences People Love
moore
139
23k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
127
18k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Transcript
⼈間中⼼のAIプロダクト開発に向けて意識すること データ収集と評価 masatoto_190 2023 3/26
はじめに GoogleのPeople + AI Research チームがまとめたガイドブック (2021年5⽉18⽇更新版) https://pair.withgoogle.com/guidebook このスライドはガイドブックを訳し、⾃分の知⾒を⼀部加筆した。 技術中⼼から⼈間中⼼に考える視野を広げてくれるガイドブックでした。
2019年6⽉12⽇時点で⽻⼭ 祥樹(@storywriter)さんの⽇本語訳サイトも⼤変参考になりました。
データ収集と評価 データの理解と品質維持に全⼒を注ぐ
データ収集と評価 ① 最初から質の⾼いデータ収集を計画する ② ユーザーニーズをデータニーズに置き換える ③ 責任をもってデータを調達する ④ データセットを⽂章化する ⑤
プロンプトを管理する
データを質を意識しないと負債が貯まる • モデル開発に多くの時間を割き、データの質を意識するのが遅れると負債が貯まる。 • データカスケード︓開発していくと⻑期的に技術的負債をもたらす複合的な事象 中途半端なデータの理解 データが現実世界と適合しない データに関するドキュメントがない 雑なデータ前処理 データのドキュメントを
作成する企業はいるのか︖ HuggingFaceにはある https://huggingface.co/docs/datasets/dataset_card
質の⾼いデータを意識する ⾼品質のデータは次のように定義 ü現実世界の現象や実体を正確に表現 ü責任を持って収集、保管、利⽤ ü再現可能 ü⻑期間維持可能 ü関連するアプリケーション間で再利⽤可能 こちらの本にも体系的に 書いてあるのでおすすめ。 画像︓https://www.oreilly.co.jp/books/9784873119564/
データ収集と評価 ① 最初から質の⾼いデータ収集を計画する ② ユーザーニーズをデータニーズに置き換える ③ 責任をもってデータを調達する ④ データセットの⽂章化をする ⑤
プロンプトを管理する ユーザーのニーズに対し、必要なデータが存在することを確認する データ所有者やステークホルダーと共通認識を持つためにドキュメントを作る
②ユーザーニーズにデータニーズを対応づける ユーザー ユーザー⾏動 MLシステム出⼒ MLシステム学習 データセット 重要な特徴 重要なラベル データフォーマット 現実的なデータの
考慮事項 質問事項 ユーザーの⾏動とMLシステム出⼒の 対応が取れているか ユーザーニーズに対して、対応するMLシステムの出⼒に価値があるか確認する。
②ユーザーニーズにデータニーズを対応づける ユーザー ユーザー⾏動 MLシステム出⼒ MLシステム学習 データセット 重要な特徴 重要なラベル データフォーマット 現実的なデータの
考慮事項 質問事項 重要な特徴とラベルは、⼿元にある実データを書くか、理想を書いて関係者にデータがあるか問う⼿もある。 重要な特徴は 顧客と認識合わせにも使える ラベルの粒度も合意をとる
②ユーザーニーズにデータニーズを対応づける ユーザー ユーザー⾏動 MLシステム出⼒ MLシステム学習 データセット 重要な特徴 重要なラベル データフォーマット 現実的なデータの
考慮事項 質問事項 現実的な制限やダイナミクスが データセットで表現されているか 先に質問形式で書いておく ユーザーリサーチ時のドメインエキスパートが重要視していたことをデータの観点で書いておく。
②ユーザーニーズにデータニーズを対応づける ユーザー ユーザー⾏動 MLシステム出⼒ MLシステム学習 データセット 重要な特徴 重要なラベル データフォーマット 現実的なデータの
考慮事項 質問事項 ユーザーやデータの⽣成など 質問事項を記載しておく データ間の関係など気になることはメモしておき、関係者と議論する際に使う。
データニーズを⾔語化する ⽬的と必要なデータ 必要な出⼒情報 考慮すべき制約 例) ⼩売需要予測の祝⽇フラグの対応 開発者が先に必要なデータを⾔語化 新しい技術を使う際は特に共通認識を得るために必要
②ドメイン専⾨家にヒアリング 先のユーザーニーズとデータニーズを対応づけた フォーマットをもとにドメイン専⾨家からフィードバック をもらう。 データに対する仮説の是⾮を問う。 右に追加の質問事項の例を載せています。 データサイエンティストやコンサルの⽅は このあたりをしっかりおこないPoCをする。 ドメイン専⾨家は聞かれて初めて意識する⽅も多い。 簡単なデータや業務フローを⾒せながら語ってもらう。
• 業務の中で重要なデータはどれですか︖ • どのデータを使いますか︖使わないですか︖ • どうやってデータは集められますか︖ • データからどんな問題が⽣じますか︖ レポート、取得、更新など • 重要なデータを集めるは時間や環境はありますか︖ • 業務でデータを扱う際に気をつけるべき3つのポイントとは︖
データ収集と評価 ① 最初から質の⾼いデータ収集を計画する ② ユーザーニーズをデータニーズに置き換える ③ 責任をもってデータを調達する ④ データセットの⽂章化をする ⑤
プロンプトを管理する 既存か新しいデータセット関係なく、注意深くバイアスなど理解する
③責任をもってデータを調達する データの収集 • 既存のデータセットを使⽤する場合 データセットの使⽤条件を必ず確認し、ユースケースに適しているかを検討する • 独⾃のデータセットを構築する場合 製品が対象とする分野の専⾨家を観察し、データの⽣成過程を知る • ユーザーからライブデータを収集する場合
アプリ内のユーザーに直接尋ねる。明⽰的か暗黙的にデータを得る データの整形 • フォーマットを検討する 「国」には「US」、「USA」、「United States」など • 他の ML モデルからのエラー混⼊を回避する 別の予測値を⼊⼒に⽤いる場合、原因の特定が難しくなる • 個⼈を特定できる情報を保護する
独⾃のデータセットを構築する場合の注意点 データの収集プロセスの理解は、潜在的な問題の発⾒に役⽴つ。 データセットを収集したら、時間をかけてデータを理解する。 データの理解の⼿順例 1. データ の情報源を特定 2. データ情報源が更新される頻度を確認 3.
特徴の有効範囲、単位、およびデータ型の調査 4. 外れ値の特定
データ収集と評価 ① 最初から質の⾼いデータ収集を計画する ② ユーザーニーズをデータニーズに置き換える ③ 責任をもってデータを調達する ④ データセットを⽂章化する ⑤
プロンプトを管理する
④データセットを⽂書化 データセットのドキュメントはコードのドキュメントと同じくらい重要 データセットのドキュメントが推奨される⽤途 • チームまたは別のチームの同僚とデータセットを共有・引き継ぎ • 学習済みモデルの動作を解釈 • 複数のデータセットの⽐較 •
外部に公開可能かの確認 データセットのドキュメントには ”データカード” のフォーマットがある • データ情報の記録 • 適⽤された操作と変換のリスト • 経時的な履歴 • 推奨される⽤途
データカード データセットのドキュメント、データに関する役⽴つ情報を含む。 • 何のためのデータセットか • どんなデータを含むのか • どこから収集されたのか • どのように整形されたか
• モデルでの精度はどの程度か 図の引⽤︓https://sites.research.google/datacardsplaybook/
データ収集と評価 ① 最初から質の⾼いデータ収集を計画する ② ユーザーニーズをデータニーズに置き換える ③ 責任をもってデータを調達する ④ データセットを⽂章化する ⑤
プロンプトを管理する
⑤プロンプトを管理する GPT4を使う時代は訓練データが不要な可能性がある。 データセットでなく、プロンプトの管理が求められる。 試⾏錯誤時はどのバージョンが良かったか分かるようにする。 [Instruct] 指⽰⽂ [info] 補⾜情報、制約など [example1] 例題1
[example2] 例題2 [input] 予測対象 [output] ⽣成結果 prompt.txt
プロンプトにドメイン知識を⼊れる 抽出や分類などプロンプトエンジニアリングにより精度向上を狙う 今までは、訓練データの⼊出⼒ペアで暗黙的にドメイン知識を獲得 これからはプロンプトにクラスの説明など具体的な専⾨⽤語を直接指⽰可能 参照するドメイン知識ドキュメントの管理も必要 [Instruct] [info] [example1] [example2] [input]
[output] 分類クラスの情報を別ドキュメントに記載 他のクラスとの区別 そのクラスとする要因 概念の説明 誤分類要因の記述 prompt.txt
個⼈的な学びと失敗 ① 最初から質の⾼いデータ収集を計画する • データのフォーマットが数年おきに変わり、今後も変わることがあり、形式を整えるの⼤変だった。 • プロトタイプの検証で、再現可能な撮影環境を意識して作っても、再現できないこともあった。 ② ユーザーニーズをデータニーズに置き換える •
ドメイン専⾨家へのヒアリングは、説明変数で⾃分が理解できないところだけ聞いていた。 • どの説明変数を重視するかは、機械学習的な感覚でやろうとしていた。 ③ 責任をもってデータを調達する • 既存のデータセットを使う場合のバイアスはあまり考えたことなくて勉強になった。 ④ データセットの⽂章化をする • PoCからシステム開発メンバーに引き継ぎで⽂章化しておらず、データの説明に時間がかかった。