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
160
人間中心のAIプロダクト開発に向けて意識すること ~データ収集と評価~
masatoto
March 26, 2023
Tweet
Share
More Decks by masatoto
See All by masatoto
Weekly AI Agents News!
masatoto
22
17k
Weekly AI Agents News! 8月号 論文のアーカイブ
masatoto
1
69
Weekly AI Agents News! 8月号 プロダクト/ニュースのアーカイブ
masatoto
1
110
Weekly AI Agents News! 7月号 論文のアーカイブ
masatoto
1
160
Weekly AI Agents News! 7月号 プロダクト/ニュースのアーカイブ
masatoto
0
120
LLM based AI Agents Overview -What, Why, How-
masatoto
1
310
ヘルプデスクの事例で学ぶAIエージェント
masatoto
13
6.9k
Weekly AI Agents News! 6月号 論文のアーカイブ
masatoto
1
130
Weekly AI Agents News! 6月号 プロダクト/ニュースのアーカイブ
masatoto
0
110
Other Decks in Design
See All in Design
Emil Storyboards (2024)
abbsant
0
150
Blender 4.1 で レッツ Vket Cloud!
kamera25
0
260
SpectrumTokyoMeetup12_自動貯金アプリ『finbee』での取り組みについて
shihorishimazu
2
340
情報サービスユニット UXUIチーム紹介/btobuxui
nikkei_engineer_recruiting
2
180
202409_会社概要資料_Englishver.pdf
zakkerooni
0
150
Information Architects: The Missing Link in Design Systems
soysaucechin
0
250
デザインプリンシプルのつくりかた(freee技術の日)
magi1125
4
3.6k
DMMデザイナーのプロダクトへの携わり方と組織再編
takumasaito
1
350
美しいUIを作るために デザイナーが意識している ちょっとした考え方
yuichi_hara7
18
11k
0-1に挑むデザイナーが 知っておきたい2つの前提
swaaan
3
950
Карта процесса-опыта. Презентация метода
ashapiro
0
170
JBUG京都#1登壇資料_「考える」をマネジメントする_ビーワークス高濱
webnaut
1
450
Featured
See All Featured
Statistics for Hackers
jakevdp
793
220k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Code Reviewing Like a Champion
maltzj
518
39k
Bootstrapping a Software Product
garrettdimon
PRO
304
110k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
190
16k
Thoughts on Productivity
jonyablonski
66
4.2k
Why Our Code Smells
bkeepers
PRO
334
56k
Large-scale JavaScript Application Architecture
addyosmani
508
110k
A Modern Web Designer's Workflow
chriscoyier
691
190k
Imperfection Machines: The Place of Print at Facebook
scottboms
263
13k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.4k
Why You Should Never Use an ORM
jnunemaker
PRO
53
8.9k
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からシステム開発メンバーに引き継ぎで⽂章化しておらず、データの説明に時間がかかった。