生成AIのためのデータ収集とデータエンジニアリング

2024/09/20『第10回 Data-Centric AI勉強会 ~Stability AI特別回~』の登壇資料です。
https://dcai-jp.connpass.com/event/329013/#_=_

Transcript

1. 生成AIのためのデータ収集と データエンジニアリング 2024/09/20 Stability AI Japan 澁井雄介
2. 自己紹介 shibui yusuke • いろいろ → Stability AI Japan（いまここ） • MLOpsコミュニティ運営 • MLOps & データ & バックエンド & インフラ & その他諸々エンジニア • 最近やりたいこと：生成AIで生み出される マルチモーダルデータのデータ基盤 &DataOps • Github: @shibuiwilliam • FB: yusuke.shibui cat : 0.55 dog: 0.45 human : 0.70 gorilla : 0.30 物体検知
3. 『事例でわかる MLOps』9月末出版！ • 豪華執筆陣による共著です！ • https://www.amazon.co.jp/dp/4065369568/ • 私も事例を寄稿しました！ • 10/2（水）18:00-に出版記念イベントを 開催します！ • https://mlops.connpass.com/event/328296/
4. • 発売中！ • https://www.amazon.co.jp/dp/4798169447/ • 発売中！ • https://www.amazon.co.jp/dp/4798173401/
5. 技術評論社 Software & Designで MLOpsについて連載しました！ • 2023年8月号　 MLOpsの概要 • 2023年9月号　 MLOpsのためのスキルセットとチーム構成 • 2023年10月号　方針策定とMLOpsのためのツール • 2023年11月号　MLOpsのための技術選定 • 2023年12月号　LLMのためのDevOps • 2024年1月号　 MLOpsと評価 • 2024年2月号　 推論システム（予定） • 2024年3月号　 機械学習システムの引き継ぎ • 2024年4月号　 LLMのデータエンジニアリング • 2024年5月号　 機械学習の使い途と未来 MLOpsについてあまり他では取り上げられないテーマを 中心に記事を書きました！
6. 今日話すこと • 生成AI時代のデータで重要なこと • 集める、整理する、使う
7. 生成AI時代の データで 重要なこと
8. 課題から始める データ たくさんある モデル たくさんある 用途 たくさんある 魅力的な技術が多々あって目移りしがちだが、 どんな状況でも課題から始めることが重要 Stable Diffusion Flux Llama Gemini StableLM OpenSora Stable Audio Chat Coding 画像生成 音声生成 RAG 自動運転 動画生成 研究
9. 課題から始める データ たくさんある モデル たくさんある 用途 たくさんある データの課題は データそのものに起因 ユースケースの課題は モデルかデータに起因 モデルの課題は データに起因 Stable Diffusion Flux Llama Gemini StableLM OpenSora Stable Audio Chat Coding 画像生成 音声生成 RAG 自動運転 動画生成 研究
10. 数十億件、 PBサイズの非構造化データから始まる生成 AI開発 データセットを用 意する 実験、学習する APIやアプリに 組み込む ビジネス化する ここが遅いと ここが停滞し これが作れず リリースできない データ ダウンローダ GPUとインフラ 事業計画 データ 検査 巨大なストレージ データ パイプ ライン DWHと 検索 ライセンス チェック 認識 分類 GPU! 高速なデータローダ デザイン UI/UX バック エンド DB 課金 ユーザ 管理 監視 運用 営業 PR マーケティ ング BizDev パートナー シップ 売上 コスト 利益 継続率 競合 アルゴリズム
11. 数十億件、 PBサイズの非構造化データから始まる生成 AI開発 データセットを用 意する 実験、学習する APIやアプリに 組み込む ビジネス化する ここが遅いと ここが停滞し これが作れず リリースできない データ ダウンローダ GPUとインフラ 事業計画 データ 検査 巨大なストレージ データ パイプ ライン DWHと 検索 ライセンス チェック 認識 分類 GPU! 高速なデータローダ デザイン UI/UX バック エンド DB 課金 ユーザ 管理 監視 運用 営業 PR マーケティ ング BizDev パートナー シップ 売上 コスト 利益 継続率 競合 アルゴリズム 短時間で成果を 出すよりも、 継続的な活動が 重要 ビジネスモデル、 アーキテクチャや エンジニア次第 必ず時間を要する 時間を要するが、 GPUや実験計画 次第では 短時間で可能
12. 集
 め
 る
 整
 理
 す る
 使
 う

13. 使うだけなら簡単 データ 社内に溜まったデータを 見上げて立ち尽くす私
14. 課題 データ 社内に溜まったデータを 見上げて立ち尽くす私 社内に欲しいデータが 見つからないから 新たに収集してきた データがどこにあるか わからないから 発掘する ストレージコスト 社内に大量のデータがあっても、 見つけられない、使えないデータは コストでしかない JPG PNG JSON Parquet 同じデータが異なる フォーマットで存在 tar zip JSONL
15. 使えるデータを用意する手順を考える 収集 整理 拡張 保存 検索 集計 取得 データの 要件定義 データを作る パイプライン データを使う 必要なデータを 定義する ライセンスチェッ ク 既存データとの 差異 コスト 期限 ・・・ データソース から収集 ネットワークや IOバウンド 多様な収集 方法をサポート する必要がある データを解析し 保存したい形式 に変換 データの説明 （README） 検索・抽出の メタデータ定義 IO, CPU, メモリ バウンド キャプション等 生成AIで重要な データを付与 テキストの トークン変換 CPU, GPU 取得条件に応じ て整理して保存 ストレージ、 DWH、検索等 利便性、規模、コ スト ヒアリン グ データViewer & 検索システム VS データ圧縮
16. 要件と制限を整理しつつ、実験する 収集 整理 拡張 保存 検索 集計 取得 データの 要件定義 データを作る パイプライン データを使う ヒアリン グ 必要なデータは 学習・評価して みないと わからない 　　　↓ 理想： 既存のデータを 集計して不足の 仮説を立てる 状態を作る 並列化・自動化し て効率的に 収集したい 　　　↓ データソースや リソースの課題 　　　↓ フォーマットの 定義とAI活用 検索するための メタデータや 文書化 　　　↓ 共通のREADME とメタデータの定 義 生成AIに必要な 不足情報 　　　↓ AI等を用いて 補足 ストレージ コスト！ 　　　↓ Intelligent Tierを 活用しつつ、 不要なデータを 定期的に削除 　　　↓ DWHや検索 システムの 同期的更新 データポイント 位置Indexで tarファイルから 抽出
17. データの要件定義 • 確実だけど時間を要する方法 ◦ 既存のデータで学習する → 評価する → 弱点を分析する → 不足データを定義して集める • 課題：学習回数が増えるほどエッジケースが判明し、データ収集の時間が足りなくなる。 • 理想的だけど不確実性の高い方法 ◦ 既存のデータを分析する → 不足する種類を抽出する → 集める → 学習する • 課題：汎用的な生成 AI開発だとunknown unknownに陥りやすい。 • 結局、DevOps同様にPlanとDoを繰り返しつつ、プロセスをブラッシュアップしていくしかない。
18. データ収集 • 課題：意外と自動化することが難しい • 主なデータソースと入手難易度（経験則） ◦ HuggingFaceのデータセット　・・・　超簡単 ◦ GitHub等で公開されているデータ収集コード　・・・　まだ簡単 ◦ 独自のデータ提供サイト　・・・　多少難易度が上がる ◦ その他　・・・　独自に収集プログラムを書く • 共通する課題 ◦ 各データソースでデータフォーマットは異なるため、学習で使う共通の形式に変換する ◦ 巨大なデータを取得してみるまで有用性がわからない ◦ 並列で一気にダウンロードできるとは限らない • よくある失敗例 ◦ データソースのデータソースまで調べたらライセンス的にNG ◦ 同じデータセットを違うチームで違う形式で集めてる
19. • データセット：データのまとまり。データエンジニアが管理しやすく、利用者が見つけやすい 名称とまとめ方が望ましい。 ◦ データソース名（例： Wikipedia）で命名するのが簡単だが、データセット間の重複排除や、 サブセットの管理が課題になる。 • データポイント：1つのデータ。画像データであれば画像ファイルとそのメタデータで構成。 IDを割り振り、複数システム間で共通の IDで一意に特定する。 ◦ データポイントは1つのデータセットに所属する。 ◦ データポイントはメタデータとして複数の属性が定義される。 データの整理 データセットA データポイント1 データポイント2 データポイント3 ファイルそのもの メタデータ |-ID |-ファイルパス |-データソース |-被写体 |-サイズ |・・・
20. 実際のプロジェクト 生成AI モデル 事前学習データ 生成AI モデル Fine-tuning データ 評価と分析 足りない データ収集 生成AI モデル Fine-tuning データ 評価と分析 足りない データ収集 生成AI モデル Fine-tuning データ 評価と分析 足りない データ収集 続く Feedback loop Feedback loop Feedback loop
21. 実際のプロジェクト データの一部をOpt-out する必要性を確認 → フ ラグを追加 高解像度の写真が 不足していることを発見 → データ収集 社内の類似画像を 収集する課題 → 検索システムの プロトタイプを構築 複数システムで利用さ れるデータの 同一性を担保 → データにIDを振る 生成AI モデル 事前学習データ 生成AI モデル Fine-tuning データ 評価と分析 足りない データ収集 生成AI モデル Fine-tuning データ 評価と分析 足りない データ収集 生成AI モデル Fine-tuning データ 評価と分析 足りない データ収集 続く
22. （これからやっていくこと） 大規模マルチモーダルデータの検索とフィルタリング • 検索目的に応じて検索方法を用意 • メタデータをDWHに入れてクエリで検索 ◦ メリット：管理が楽、確実性が高い • 全文検索にキャプションを入れて検索 ◦ メリット：自然言語で検索可能 • ベクトル検索 ◦ メリット：データそのもので検索可能 • 実用ではこれらの組み合わせになる • そのため、各データ基盤でデータを 一意に特定しJOINするデータのIDが必要 Unum USearch 構造化データ◯ 全文検索△　コストの課題 ベクトル検索は今後に期待 全文検索は強いが 基盤運用が課題 大量のファイルを走査する 用途では強力だが、 使い勝手とクラスター運用が課題 ベクトル検索 早いし軽いがまだ発展途上 大量のファイルを走査する 用途では強力だが、 使い勝手が課題 収集 整理 拡張 保存 パイプライン 並列処理が有効 IOバウンド ミニバッチ処理 並列処理が有効 IOバウンド データに応じて修正 CPU/RAMバウンド 再実行を想定 コスト懸念 用途に応じて選定 マイグレーションを 想定して作る
23. まとめ
24. まとめ • テーブルデータのように構造化されない、ファイル単位のデータソースによる大規模データ管理 • データの要件定義 ↔ 収集 ↔ 整理を繰り返しつつ、 DevOps的に過程を修正
25. Stability AIではデータエンジニア を募集しています！