ソフトウェア化と成果物の公開 AI Lab スキルアップ研修 研究コードの公開 [発展編]

CyberAgent AI Labのスキルアップ研修にて発表した研究コード公開の作法についての発展編です。

Transcript

1. 研究コード公開 発展編 ソフトウェア化と成果物の公開 CyberAgent AI Lab 研修 20241218 Kazuhiro Ota 1
2. 論文に加えて研究コードを公開する流れがありますね > Our code, data and trained models are available at this http URL. 研究コードがGitHubで公開されてる！ 2 基礎編再掲
3. なぜ研究コードを公開するの？ メリットたくさん！ プロダクト所属のエンジニアと連携しや すくなり、AI Lab発の技術を事業に繋げ やすくなるといったところも 研究者流コーディングの極意 from 言語処理学会第19回年次大会 3 基礎編再掲
4. この研修資料で目指す状態 • 研究で書いたコードを外に出しても恥ずかしくない状態でGitHub公開できる ようになる • コードだけでなくその成果物によって適切な公開手段を選択し、必要であれ ばリサーチエンジニアと連携して公開できるようになる 論文同様、コードも他人が利用する・読むものであることを意識して、受け手に とって優しい状態でのコード提供ができるようになりましょう 4 基礎編再掲
5. 対象者 コード公開について自信がないAI Labリサーチサイエンティスト GitHubでの実験・分析コード公開（基礎編） • 研究コード書いたのは良いけど、そのまま公開して良いのかどうか迷っている • 公開といってもJupyterNotebookの分析コードだけなんですが • セキュリティとか大丈夫なんだっけ？ ソフトウェア化と成果物の公開（本編） • 皆に pip install して使ってもらいたい • 最近よく聞くHugging Faceって？ • 手軽にモデルを試すことのできるデモアプリも作ったんだけど 5 基礎編再掲
6. 目次 • 実験コードとソフトウェアの違い ◦ ソフトウェア化する上で考慮すべきこと ◦ ソフトウェア化の指針 • ソフトウェアのパッケージングと公開 ◦ GitHubとパッケージリポジトリ ◦ パッケージングとは ◦ TestPyPIへの公開チュートリアル • その他成果物の公開 ◦ デモサービス ◦ 学習済みモデル・データセット 6
7. 実験・分析コードとソフトウェアの違い 7
8. 研究コードはプロダクトで動く？ 研究で書いてた実験・分析 コードはすべてGitHubで公 開したし、これで世の中の 人々に使ってもらえるなー 動かなくはなさそうだけ ど、プロダクトコードから 利用しにくそう…自分なり に改修しなきゃダメか… 研究者 プロダクト開発者 公開 参照 8
9. 実験・分析コードとソフトウェア 🧪実験・分析コード 💻ソフトウェア 実装対象 解かれていない問題 研究終了まで全体像は定まらない 要件に基づく機能・仕様 目的 アイデア検証 手法の透明性・再現性の確保 汎用性のあるツールの提供 技術の社会実装 閲覧者 利用者 共著者など主に研究者 非研究者を含む一般ユーザ 研究で書いたコードはそのままでは広く利用される状態ではない 9
10. ソフトウェア化とは 各種プログラミング言語から利用されるライブラリや、何らかのユーザイン ターフェイスを持ったツール・サービスを作成し、利用者に価値を提供する こと 特定の機能・処理に焦点を当ててプロ グラミングを支援 • NumPy • PyTorch • scikit-learn • pandas • OpenCV • etc. ライブラリ 仕事や研究などの作業そのものを支援 • Jupyter Lab • MLflow • ChilmAI • etc. ツール・サービス 両方の側面をもつソフトウェアも多いです 研究におけるソフトウェア化の作業は、提案手法・モデ ルを上記のものに昇華すること！ 10
11. ソフトウェア化を行う前に… そもそも研究内容をソフトウェア化すべきか・できるかを考えましょう 下記について自信を持てる状態を目指します • 競合の存在 ◦ すでに似たようなソフトウェアが存在する場合、何らかの面で優位性をつくれそうか ◦ 提案手法に短所がある場合、それをカバーする機能などを実装できそうか • 研究とは異なる評価軸 ◦ 提案手法とは異なるところでその良さが伝わらない可能性も ◦ 使い方が分からない、実装のパフォーマンスが悪い、など • ドキュメンテーション・メンテナンス ◦ ユースケースを想定しつつわかりやすく網羅的なドキュメントをまとめられるか ◦ バグ報告やPull Requestを受けた際に応対が可能か 11
12. ターゲットユーザとユースケース ソフトウェアを使用するユーザーのニーズを理解しましょう（技術的なスキルレ ベルや職種・業務内容など） ユーザーがソフトウェアをどのように使用するか、ユースケースとなる大まかな シナリオを固めます MLエンジニアや研究者が Pythonで深層学習モデルを 実装・利用することができ る 自治体職員がマッチングア ルゴリズムで保育所の入所 選考作業を行える 例 https://chilmai.cyberagent.ai/ 12
13. ソフトウェア名 ターゲットとなるユーザや利用シナリオが見えたら、ソフトウェアを命名しましょう 目的や主要な機能を反映する名前にすることで、ユーザーがそのソフトウェアの用途を直感 的に理解できるようにします • シンプル ◦ 短くて覚えやすいか、発音しやすくスペルミスが起こりにくいか • ユニーク ◦ 他のソフトウェア、企業名、商標と重複しないか • ドメインが確保可能か ◦ 将来ソフトウェア配布ウェブサイトを独自に立ち上げた場合にそのドメインもソフトウェア 名に沿っていると見栄えが良い • 文化的・言語的配慮 ◦ 日本語以外の言語・文化で不適切な意味を持たないか • ブランドイメージ ◦ CyberAgentのイメージ・AI Labのビジョンについて一貫性があるか 13
14. 実装要件 ソフトウェアで提供する機能を定義します 機能要件・非機能要件とわけて考えるとエンジニアと連携しやすくなります • 機能要件 ◦ ソフトウェアが本質的に提供したい・満たしておくべき要件 • 非機能要件 ◦ パフォーマンス、セキュリティ、対応デバイスなどの品質面の要件 ◦ 難しい場合はリサーチエンジニアと連携しましょう 例 • テンソルデータに対する一般的な計算を行える • MLモデルをPythonのクラスとして表現できる • GPU上での処理も可能 • マッチングアルゴリズムで児童データ・保育所データ間の最適マッチングを導出できる • バリデーション処理で入力データのエラー箇所を明らかにできる • マッチングはN分以内で完了する 14
15. 入出力の形式 入出力形式はソフトウェアの使い勝手に大きく影響します 実装要件を踏まえ、なるべく標準的な形式をサポートするようにしましょう 競合ソフトウェアや標準ライブラリをチェックして下記について検討します データタイプとフォーマット • テーブルデータ、テキスト、画像、音声 • CSV、JSON、XML、PNG ユーザーインターフェース • ユーザーが入力を行うためのインターフェース • ライブラリであれば関数などのAPI、ツールであればコマンドライン（CUI）やGUI バリデーションとエラーハンドリング • 入力データの検証方法と、無効なデータが入力された場合の処理を決めます 15
16. 実装とリファクタリング 研究で書いたコードをより信頼性が高く、メンテナンスしやすいソフトウェアにす るために、下記のことに気を配りましょう • 可読性・メンテナンス性 • モジュール化・再利用性 • 依存関係の管理 • テストと検証 • 関数・クラスへのドキュメンテーションコメント ここで説明するには奥が深すぎるので各種書籍やネット情報を参考にしつつ、リ サーチエンジニアに相談してください 16
17. ライセンス設定 ソフトウェアについての著作権および閲覧者・利用者が行えること（再配布・改変 等）をライセンスとして明示しましょう ライセンスをつけないとどうなるの？ #GitHub - Qiita 本研修でもライセンスに関する講義が ありますので、より詳しくはそちらを ご確認ください OSSライセンス入門 by 吉村さん ノーライセンスはこんな可能性も… 17
18. ドキュメント整備 ユーザー向けドキュメント • ソフトウェアのインストール方法、基本的な使い方、設定方法 などを記載したユーザードキュメントを用意します • Sphinxなどのドキュメントビルダーを利用するとdocstringから HTMLを自動で生成してくれます 開発者向けドキュメント コードの構造やAPIの使い方、Issue/Pull Requestの上げ方、開 発環境の構築手順などを記載した開発者向けドキュメントも整 備すると世のエンジニアの協力を得やすいでしょう Flask ユーザドキュメント Flask 開発者ドキュメント 18
19. 確認 最後に共著者や周りのメンバーに協力してもらい、利用確認を行ってもらいましょう READMEやその他ドキュメントに従って想定するユースケースに則った作業が可能 か、その使いやすさや有用性について意見をもらい、フィードバックを反映してくだ さい 19
20. ソフトウェアのパッケージングと公開 20
21. ソフトウェア公開場所 ソフトウェアを公開する場所には下記のようなものがあります GitHub：ソースコードを主体とした公開方式 • Gitのリモートリポジトリによってソースコードをホスト • Issue/Pull RequestといったSNS機能を有しており、コミュニケーションが 取りやすい パッケージリポジトリ：ソフトウェアのパッケージを公開 • ライブラリ・ツールをインストール可能な状態でホスト • より簡単にソフトウェアを利用してもらえるようになります 21
22. ソフトウェアをソースコードから直接参照・利用してもらう場合にGitHubで公開できます 公開方法とそのポリシーは基礎編のGitHubでの実験・分析コード公開と同様ですので、ぜひ一 読ください GitHubでの公開 この資料では主にパッケージというソフトウェア公開形式について説明していきます 22
23. ソフトウェア（ライブラリ）のパッケージ化 各プログラミング言語向けに代表的なパッケージを公開・配布するリポジトリが公式・非公式問 わず存在しているほか、OSディストリビューターが公開しているリポジトリもあります Python: PyPI Node.js: npm 代表的なパッケージリポジトリ R: CRAN ソフトウェアをユーザーが簡単にインストール、使用、管理できるよう にするためのプロセス 23
24. パッケージ化すると何が嬉しいの？ 主に下記の点について簡略化がなされ、ユーザがソフトウェアをインストール・ 利用しやすくなります • 依存関係の解決 ◦ ソフトウェアに必要なライブラリを明示的に指定することで、インストール時に自動的に依 存関係が解決・追加インストールされ、動作環境がコマンド一発で整います • バージョン指定でのインストール ◦ ソフトウェアの特定のバージョンを指定してインストールすることができ、互換性の問題を 回避できます • 便利なスクリプト・バイナリの提供 ◦ 自前のプログラムコードからライブラリを呼び出すことなく、特定のタスクをこなすための コマンドを提供できます 24
25. PythonとPyPI https://pypi.org/ 公開自体は特に難しい ところはないので実際 にやってみましょう 25
26. PyPIでのPythonパッケージ公開 Python のプロジェクトをパッケージングする by PyPA (Python Packaging Authority) 基本的には上記チュートリアル記事を読めばOKなのですが、このチュートリアルを進める うえでの流れやつまづきやすいポイントを簡単に記しておきます 1. pyproject.tomlファイルの記述・設置 2. ディレクトリ構造 3. パッケージビルド 4. テストインストール 5. TestPyPIアップロード 6. TestPyPIからのインストール 26
27. pyproject.tomlファイルの記述・設置 Pythonパッケージに関する設定ファイルとして pyproject.tomlがあります パッケージに関する下記のような基礎情報および依存関 係をこのファイルに記載することでパッケージングプロ セスを定義します • パッケージ名 • バージョン • 作者 • 対象Pythonバージョン • 依存ライブラリとそのバージョン • プロジェクトページURL より詳細な記法とその意味は下記を参照してください Python のプロジェクトをパッケージングする#メタ データを設定する 27
28. ディレクトリ構造 ファイル配置およびディレクトリ構造は下記のようにしておくのが無難です （srcレイアウトといいます; フラットレイアウトというのもあるのですがここでは割愛） この構造に従う限り、設定をあまり気にかけずパッケージルート内のソースコードを対象として パッケージングが行われます コードリポジトリルート （パッケージ名とは異なる名前でもOK） pyproject.toml パッケージルート この中にソフトウェアコードを配置 （パッケージ名と名前を合わせる） ソフトウェアコード 28
29. PyPIパッケージビルド パッケージビルドにはbuildというモジュールをインストールして利用します 上記コマンドを実行するとdistディレクトリが作成され、中に2種類のファイルが出力されます これらがPyPIパッケージの実態です 29
30. インストール・実行テスト distディレクトリ内に作成されたwheelファイルからインストールを試してみておくとTestPyPIへのアップロー ド前にインストールして利用できるかを確認できます pyproject.tomlに依存関係として指定していた外部ライブラリが自動でインストールされ、自作した関数・クラ スをimportして利用できればOKです NumPyへの依存関係が 自動解決されてる！ 実行をローカルで確認 30
31. TestPyPIアップロード 次はビルドされたパッケージをPyPIにアップロードしていくのですが、PyPIではTest PyPIという試 験環境が準備されており、今回のようなお試しでパッケージをアップロードするのに適しています TestPyPIにアカウント作成後、下記記事のとおりにAPIキーを作成・把握しておいてください Python のプロジェクトをパッケージングする#配布物アーカイブをアップロードする 31
32. TestPyPIアップロード あとはtwineというモジュールを利用してdist内のパッケージファイルをアップロードします 作成したAPIキーはホームディレクトリ直下に.pypircというファイルを作成しその中に記述しておきましょう .pypircで設定した名前を指定 32
33. TestPyPIアップロード 出力されたURLにアクセスし、下図のような表示になればOK これでTestPyPIにパッケージが公開されました🎉 33
34. TestPyPIからのインストール あとはインストールを行うだけですが、その際 --no-deps というオプションを 忘れずに（TestPyPIのみ、本家PyPIでは不要です） TestPyPIで依存関係を解決しよ うとしてエラー 依存関係解決を無視して実行 TestPyPIで表示されたコマンド をそのまま打っても… 34
35. PyPIへのリリースおよび宣伝 TestPyPIからのインストールまで問題なく終わったら、本家PyPIでも同様のフローを踏めばOK です（もちろんリポジトリURLやオプションは変えてください） リリースできたらあとはもうより広く使ってもらうために、SNSなどでユースケースの紹介や宣 伝を行いましょう（ pip install [ソフトウェア名] という一文は意外と強いです） GitHubで上がってきたバグ報告・Issueへの対応も忘れずに 35
36. その他成果物の公開 36
37. 研究の成果物 研究成果として出来上がるものはソフトウェアパッケージ以外にも下記のような ものがあげられます • デモサービス • データセット • 学習済みモデル これらの公開方法・公開場所についても軽く見ていきます 37
38. デモサービス 提案手法やモデルを手軽に利用してもらうために、Webフロントエンドライブラ リやGUIフレームワークによってインタラクティブなユーザインターフェイスを 搭載したものです 自作フロントエンド Streamlitでお手軽GUI 38
39. GCP Cloud Run 公開場所としてはWebサーバになるのですが、GCP Cloud Runを利用すること で、下記のような利点を活かしつつサービスを提供できます • ゼロスケール ◦ アイドル状態のときには完全にスケールダウンし、リソースを消費しないため、コスト効率 が高いです • 簡単デプロイ ◦ Dockerコンテナイメージをデプロイするだけで、アプリケーションを実行できます 39
40. 学習済みモデル・データセット ファイルあたり100MBまでであれば、Gitリポジトリに含めてGitHubで公開可能 です（が、リポジトリのcloneが重くはなります…） 大容量ファイルの場合は、下記のようなオンラインストレージを用いて公開しま しょう • GitHub Release • GitHub LFS • Hugging Face Hub • GCP GCS / AWS S3 40
41. Hugging Face Hub 特にHugging Face Hubはモデル・データセットのみならず、モデルの簡単なデモ アプリもデプロイできます Gradioというツールを使ったアプリケーションをデプロイできるので、モデルの 入出力についてデータセットからのデータを参照しつつ直感的な理解を促すのに 使えるでしょう 41
42. まとめ 基礎編よりエンジニアと協力しなければならない範囲がぐっと増えたと思います 慣れないところもあると思いますが、ソフトウェア化の機運を感じたらお近くの リサーチエンジニアまで！ 42
43. 参考 • 研究者流コーディングの極意 • 研究で開発したコードの公開 • 研究のプログラミングにおける悲劇を無くすためのGitとテスト - Kesinの知 見置き場 43