$30 off During Our Annual Pro Sale. View Details »

ハッピーになる機械学習モデル開発 〜なるべく手間をかけずにコードの品質向上を目指す 〜

ハッピーになる機械学習モデル開発 〜なるべく手間をかけずにコードの品質向上を目指す 〜

techtekt

May 17, 2024
Tweet

More Decks by techtekt

Other Decks in Technology

Transcript

  1. 写真 3 自己紹介 名前 浦山昌生 所属 パーソルキャリア株式会社 呼称 シニアデータアナリスト 好きなこと

    育児、音楽、IoT、強化学習、数学 キャリア 業種 職種 ネットワークベンダー エンジニア(ネットワーク) 情報セキュリティベンダー エンジニア(セキュリティー) 医療、健康 鍼灸師 学校 エンジニア(ひとり情シス) 受託 AI 開発ベンダー データサイエンティスト 人材サービス データサイエンティスト
  2. 11 目指す世界観:背景 • 背景 – 機械学習システムの導入ニーズの高まり • 求人需要の増加、データ活用の加速 • ボトルネックは手作業

    • 幅広い業務からのニーズ – メンバーのスキルやバックグラウンドの拡大 • 組織拡大、機械学習システム開発業務の分業化 – システムの急拡大による稼働環境の多様化 • マルチクラウド • モデル開発環境とシステム稼働環境の分離
  3. 12 目指す世界観:課題と目的 • 課題 – 機械学習モデル開発時の成果物が明確に定義されていない • コードの品質がボトルネックとなりシステム実装時の工数が読みにくい • コードの変更管理等が弱くシステム変更の工数が読みにくい

    • モデル開発担当の変更時に引継ぎが大変 – 再現性や再利用性を高めるモデル開発には追加の工数が必要 – チームでモデルを開発したりレビューすることが難しい • 目的 – なるべく手間を掛けずにモデル開発の品質(≒モデルの品質)を上げたい
  4. 14 目指す世界観:モデル開発工程での主な管理対象 性能 品質 コスト 予測精度 汎化性能 処理速度 再現性 バグ含有量

    モデル開発 • 良質なデータ • 良い前処理 • 良いモデル • 要件に合った精度評価 • 交差検証 • データ分割 • コードバージョン管理 • 実験ログ管理の自動化 • 適度な構造化 • データと実行環境の明確化 • フォーマッタ利用 • フォルダテンプレートの利用 • 様々なテクニック → (保守性低下?) • 開発工数、計算機資源 システム実装 • 引継ぎ工数、開発工数 その他)機能要件(解釈性等)、非機能要件(環境負荷性能等)
  5. 16 取り組み:概要 • 「機械学習モデル開発ガイドライン」を策定 – 標準的なモデル開発工程を定義 – モデル開発時の成果物と品質(コード、データ、ドキュメント) – 機械学習モデル開発プロセスでの推奨ツールを策定

    – データ保存と授受に関する取り決め – 成果物のピアレビュー • 布教活動 – ガイドライン推進チームの組成 – ガイドライン社内公開 – 教育(新卒、中途) – 推奨ツールの浸透(利用方法の資料作成、レクチャー実施) – 定期的なガイドラインの見直し
  6. 工程 PJT実施事項 実施事項 17 取り組み:機械学習モデル開発の工程と実施事項 企画 分析要件定義、EDA •分析環境構築 •データ取得 •データ確認(可視化等)

    モデル開発、分析 •ベースラインモデル開発 •精度評価ソフトウェア開発 •モデル開発 精度評価 レポーティング 情報共有方法の定義 関係者で合意 企画資料を作成 レポジトリ作成 スタブコード作成 環境構築 EDA(探索的データ分析)を 実施 分析設計 実験管理環境を構築(MLflow) 開発ワークフロー構築(Linter、make) 分析設計を共有 精度評価コードの開発 モデル開発(データ分析)を実施 精度評価 レポート作成 (実施事項、精度) 関係者へ報告 バグ対応
  7. 18 取り組み:成果物と品質のガイドライン策定 • モデル開発時の成果物と品質 – コード • 開発言語:Python3 • 含める内容:実行サンプル、学習推論処理、学習推論以外の処理

    • コード記述方法 – スクリプト形式を推奨(Notebook 形式は非推奨) – コードと矛盾しないコメントを記載 – 処理に不要なコードを削除 – PEP8 準拠(flake8 または autopep8 のテストをパスすること) • 環境設定ファイル(Dockerfile、requirements.txt、pyproject.toml 等) • モデル生成コード等の動作設定ファイル
  8. 19 取り組み:成果物と品質のガイドライン策定 • モデル開発時の成果物と品質 – データ • 学習データ、評価データ • 学習済みモデルバイナリ

    – ドキュメント • モデルの目的、動作概要、入出力データ仕様 • 動作設定ファイルの記述方法、利用方法 • 動作環境の構築方法 • データ取得方法 • 実行サンプルの動作方法 • 予測精度を含む動作結果
  9. 20 取り組み:推奨ツール(ターゲットは Python3) # 目的 機能 ツール例 1 コードの再現性を確保 コードのバージョン管理、ブランチ管理

    リリースバージョン管理 git 2 コードに関する情報共有 リポジトリ管理、タスク管理、Wiki、情報共有 GitLab、Code Commit 等 3 コードの可読性向上 実行前のコードのバグ検知 自動的なコード整形、コードの問題検知 ※ 未定義変数の参照などの単純なバグを減らす。書式を統一する ことで可読性を上げ、メンテナンスコストを下げる。 black、flake8、isort 4 実験の再現性を確保 実験記録の自動的な保存 ※ 実行時オプション、git コミット ID、データ、実行結果を自動 的に記録。 MLflow 5 フォルダ構成の標準化 コードの可読性向上 ディレクトリ構造のテンプレート導入 ※ ファイルを保存するディレクトリ構造をテンプレート化しする。 リポジトリ間で共通部分を増やし、可読性を上げメンテナンスコ ストを下げる。 cookiecutter (Cookiecutter Data Science) 6 データの再現性を確保 実行の再現性を確保 パイプライン定義、データバージョン管理 DVC
  10. 21 取り組み:推奨ツール 実験管理 • 実験管理:MLflow Tracking – 目的 • 実験の再現性を確保

    – 機能 • 実験記録の自動的な保存 – git コミット ID、実行時オプション、エラー有無、実行コード名 – モデルパラメーター、精度等の実行結果 – モデルバイナリ、任意のファイル • ビューワによる閲覧と実験間の比較
  11. 22 取り組み:推奨ツール 実験管理 • 実験管理:MLflow Tracking – メリット • 過去の実験の記録が自動的に保存される

    • ビューワで過去の実験の一覧を閲覧できる(絞り込みやソートも可能) • 複数の実験記録を比較することができる • 実験の記録をCSVエクスポートできる • 実験の詳細情報を取得できる • サーバー不要 – デメリット • 学習コスト、実施コストがかかる(めんどくさい) – コードに mlflow の命令を入れる必要がある • 添付ファイル(artifact)を増やすとストレージを消費する
  12. 26 取り組み:推奨ツール データバージョン管理 • データバージョン管理:DVC – 目的 • データの再現性を確保 •

    実行の再現性を確保 – 機能 • バイナリデータのバージョンを管理できる • 実行パイプラインを定義し、最小限の計算でパイプラインを完遂する – メリット • データの再現性が確保できる → あのときどのデータで実験したのか? • 実行手順のミスが減らせる – デメリット • 学習コスト、実施コストがかかる(めんどくさい) • 消費ストレージが増える(各バージョンのデータを保持する)
  13. 29 結果 • まだ模索中だけど幸せになれそうな気がする – 取り組みを実施中 – まだ明確な結果は得られていない – しいて言えば・・・(苦情は減ったかも✨)

    • 推進はしているが全面的な導入には至っていない – モデル開発者の「めんどくさい」が緩和できてない – ツールの利用法レクチャーが進んでない – モデル開発者は困っていないかも・・・
  14. 31 最近の取り組み:LLM • 大規模言語モデルの応用を模索中 – 用途 • マッチング、ターゲティング、時系列予測、生成(求人票、広告、職務経歴書、推薦文書等) – 利用規定

    • インターネットサービス利用には規定あり • LLM 用の規定は無く個別にコンプライアンス部門と相談 – 利用方法 • ファインチューニングして色々と・・・ • サービス利用 – Azure OpenAI Service、 OpenAI API、 GCP PaLM • インハウス – ライブラリ » RWKV、Cerebras-GPT、Dolly 2.0 – コンピューティング » クラウド、オンプレ
  15. 37 取り組み:推奨ツール バージョン管理 • バージョン管理:git – 目的 • コードの再現性を確保 –

    機能 • コードのバージョン管理、ブランチ管理、タグ管理 – メリット • コードや設定ファイル等のテキストファイルの修正履歴が残る • 各バージョンの差分が確認できる • リリースバージョンが管理できる • 複数の開発者が別の環境で更新できる – デメリット • 学習コスト、実施コストがかかる(めんどくさい) • Jupyter Notebook と相性が悪い
  16. 38 取り組み:推奨ツール リポジトリサービス • リポジトリサービス:GitHub、GitLab、AWS CodeCommit 等 – 目的 •

    コードに関する情報共有 – 機能 • コードの共有(git リポジトリの共有) • タスク管理、Wiki 管理 – メリット • 安全に git リポジトリを共有できる • タスクの一覧と進捗を管理できる • Wiki 等で情報共有できる – デメリット • 学習コスト、実施コスト、管理コストがかかる(めんどくさい) • 利用料がかかる
  17. 39 取り組み:推奨ツール リンタ&フォーマッタ • リンタ&フォーマッタ:black、flake8、isort – 目的 • コードの可読性向上 •

    実行前のコードのバグ検知 – 機能 • 自動的なコード整形 • 未定義変数の参照など明らかなエラーを実行前に検知する – メリット • 実行せずにエラーを検知することで時間と計算コストが節約できる • コードの可読性が高まることでバグを発見しやすくできる • フォーマットを統一することで動作に影響が無い差分を削減できる – デメリット • 学習コスト、実施コストがかかる(めんどくさい)
  18. 40 取り組み:推奨ツール フォルダテンプレート • フォルダテンプレート:cookiecutter – 目的 • フォルダ構成の標準化 •

    コードの可読性向上 – 機能 • フォルダ構成のテンプレート利用 • 基本的なファイルのテンプレート利用(Makefile 等) – メリット • 複数のプロジェクトやリポジトリの共通性を高める • 可読性が上がる → レビューが楽になる – デメリット • 学習コスト、実施コストがかかる(めんどくさい) • フォルダやファイルが増える