meowの覚え書き

write to think, create to understand

『PyData.Tokyo Meetup #23 MLOps〜AIを社会に届ける技術』 聴講メモ

MLOps

f:id:meow_memow:20210708213552j:plain

目次

5月にPyData.Tokyo Meetup #23 MLOps〜AIを社会に届ける技術がオンラインで開催されました。
https://pydatatokyo.connpass.com/event/210654/

PyData.TokyoがテーマにMLOpsを扱うのは2年ぶり1で、個人的に期待が高かったです。

今回はサイバーエージェント(CA社)のMLOpsにまつわるご発表2件でした。 トピックはML実験管理基盤、プロダクト化にあたってのパフォーマンス向上やトラブルシューティングでした。
Ops関係の直接的な話題はなかったものの、現場ならではのノウハウが豊富にふくまれていました。

私は勉強のために、スピーカーごとにメモ(個人的所感含む)を取っていました。 スライドや動画が公開されているので、そちらをご覧いただいた方がいいというのは百も承知の上、以下で共有します。


スポンサードリンク

1人目『CyberAgent AI Labを支えるCloud実験環境』

スピーカー: 岩崎 祐貴 (Yuki Iwasaki)

概要: CyberAgent AI Labでは、Computer Vision・NLP・経済学・ハイパーパラメータ最適化・Human Computer Interactionなど分野の異なるResearcherが広く在籍しています。このような分野違いのデータや実験を一元管理するために、AI Labで開発・運用しているデータローダーやモデルサーバーを通じて、高速かつパワフルなCloud実験環境をご紹介します。

スライド: CyberAgent AI Labを支えるCloud実験環境 - Speaker Deck https://speakerdeck.com/chck/cyberagent-ai-labwozhi-erucloudshi-yan-huan-jing

動画: https://www.youtube.com/watch?v=E2s5NP6B8cs

本題

  • 所属組織であるAI Lab
    • 人数35人。Researcher 31名、Research Engineer 4名(岩崎さんはこちら)。リサーチャーが多い。
    • OKR: 学会発表がメイン。
    • プロダクト側ではないので、顧客データを貯めていない。しかし実験で使用したい時はプロダクト側と連携する。
  • AI Labのエコシステム
    1. 課題、仮説、アイディア
    2. データ選定し、収集する
    3. 前処理
    4. 解きたいタスクに対するモデリング
    5. 評価(実験結果のレポート作成)
    6. 論文、プロダクション化
  • 研究生産性にまつわる課題
    • 使うライブラリは、リサーチャーや分野によってばらつく。
      • → そこで岩崎さんはR&Dを加速させるために、実験の共通部分を洗い出して実験サポートツールを作った。
  • 今回の報告内容は、エコシステムにおけるサポートツール3つの紹介
    1. (ideaに関するものは無し)
    2. データ収集支援→ ailab-datasets
    3. (前処理: numpy, tfrecord, pandas, beam)
    4. モデリング支援→ ailab-model-zoo
    5. 実験支援→ ailab-mlflow
    6. (論文: overleaf, GCP, AWS)

データ選択: ailab-datasets

  • 前提知識: tensorflow-datasets
    • publicなデータセットを一元管理してくれるOSSのdata loader
      • データセット名 を指定し、ロードするだけですぐに使える。
        • 226のデータセットが提供されている。mnistとかの軽いものだけでなく Celeb AやMS COCOなどの大容量のものもカバーしている
        • 画像だけでなくテキストや音声データもカバーしている
    • 分析データを扱うためのインタフェースを統一
      • tensorflowとついているが、numpy, pandas形式で出力できる。pytorch派でも使える。
        • ただしdfはiterableではないので、メモリに展開されてしまうことに注意。
    • オリジナルのデータセットの定義方法
      • tfds cliという専用のCLIがあるので、それ経由でpythonのテンプレートを生成する。
        • テンプレート
          • メタデータにデータの型やdescription
            • データ参照時に型チェック可能
          • _info()に、データ本体ののURLや、train/val/test といったデータセットの分割方法を定義
          • _generate_example()
            • 参照したデータに対する処理を書くジェネレータ関数
        • データセット用のテストケースも書くことができる。
    • 動画のような入力データサイズが巨大な場合はapache beamの形式で並列分散も処理可能
      • もとのテンプレートをちょっとapache beam用に変えるだけで動かすことができる。
      • apache beamのおかげでクラウドでスケールしやすい
  • private(社内)なデータを扱う上での課題
    1. データの管理にルールがない
      • CA社のプロダクトは並列に大量に立ち上がるため、データ管理が難しい
        • プロダクトサイドのデータ集約基盤はリサーチャー向けではない
      • → リサーチャーごとのオレオレJupyterlab上で実験コードやデータを管理している
    2. リーダビリティの低いSQL、冪等性の無い前処理のため、リサーチャー間の再現が困難
    3. privateデータは使うのにドメイン知識が必要で、プロジェクト新規参入者の学習コストが高い
  • この課題を解決するのがailab-datasetsという社内ツール
    • 説明: private データを前処理ごと管理できるDataloader。前述のtensorflow-datasetsのラッパー
    • 利点
      • Data追加が簡単
      • プロダクトやタスクごとにデータをバージョニングできる
      • apache beamのランナーを使うことにより、高速に前処理が可能
    • post-process(共通の前処理の後の処理)を選択可能
      • 特徴としては、TensorflowTransform(TFデータのapache beam実装)が選択可能。前処理-後処理で分散処理のパイプを組める。

モデリング部分でのサポート: ailab-model-zoo

  • privateなmodelにおける課題
    • 異なるタスクで似たようなモデルの再発明が起きている
    • リサーチャー間でpretrain済みモデルのシェアしたい場合がある
      • 社内データでpretrainした重みがほしい。
      • しかし、誰がどんなモデルを作成しているか把握しづらい
  • ailab-model-zoo(WIP)
    • AI hub(GCPのマネジド版tensorflow-hub)を使用
    • 次の3つをprivateに管理可能: kubeflowパイプライン, jupyter notebook, 学習済みモデル
    • 名にtensorflowと関しているが、オブジェクトストレージとしても使える
      • メタデータやタグを打っておけば、所定のリソースをテキスト検索できて、探しやすい
    • (個人メモ; 単純にAI hub使うのと何が異なるのだろうか)

実験管理部分でのサポート: ailab-mlflow

  • 実験管理ツールにおける課題
    • MLflowはサーバ構築が面倒。セキュリティのことを考える必要がある。
    • SaaS(Nepture.ai, Comet.mlなど)は無料枠を越えると高コスト
  • MLflowでの実験管理
    • 1つの共用のMLflowサーバをたててチームで利用という案はやりたくない
      • アクセス制御ができない
      • 個人の実験管理を制限してしまう
    • ailab-mlflow
      • AILab内で共通で使えるMLflow ClusterをGCP上にGKEで構築
        • ユーザごとにMLflowのPodが立っている。podのurlをユーザに教える。urlにアクセスしたリサーチャーからは個人のMLflowのように見える。
        • アクセス制御はgoogleアカウント単位(Cloud IAP)。共同研究者はgmailをもっていればokなので楽。
        • MLflowのバックエンドDBやオブジェクトストレージは共通のものを指定
          • 区分けはテーブルやprefixで行い、ユーザごとの保存場所を用意
      • 実験バッチからどう、MLflowサーバへログを飛ばすのか
        • リサーチャーがMLflowの使用申請をailab-mlflow管理者に出す。管理者は新しいMLflow podを立ち上げる。
        • リサーチャーは予め持っているクライアントidをキーに、MLflowへアクセスするためのOAuth Tokenを発行する
        • 環境変数MLFLOW_TRACKING_TOKENにTokenをセットすると、MLflowクライアントはこれをつかって、MLFlowサーバにアクセスしてくれる。
        • あとは、普通のMLflowの使い方と一緒
      • 構築方法はAIlabのテックブログにて公開予定

おわりに

  • 今後の課題
    • 論文執筆後のコード、デモページのジェネレータの開発
  • ツールをリサーチャーにどう布教させるか
    • ツールのチュートリアルを開催
    • 地道に一人ひとり使用者を増やしていく
    • 共著で入るときに、こっそりツールが使える環境を用意してしまう
  • 研究の仕組み全体を支援するpipelineよりも、要所要所で使えるモジュールを開発をし、リサーチャーに使うモジュールを取捨選択してもらったほうがよい

質疑

  • privateなデータセットの認証周りはどうしているのか
    • private githubで管理しているため、github上で行っている
    • BigQueryからロードする場合は、BQのread権限も必要
  • ailab-model-zooをリサーチャーに使ってもらう時のインセンティブはあるか
    • ない。強いて言うならば、ailab-model-zooで実験負荷を軽減できたり、モデルを公開したことで思わぬバグを発見できたという成功体験をしてもらうこと。
  • ailab-mlflowのインフラ管理は誰が行っているのか
    • 岩崎さん+もう1名
  • ailabの研究成果をCA社のプロダクト内で使用することはあるか。使用するならば、どこの部隊がMLコードを運用管理するか。
    • 使用する。プロダクト側が実運用を担当する。理由は、AIlabの目的が研究なので、プロダクトの目的(売上を伸ばす)とギャップがあるため。

個人メモ

  • 基盤の設計。あまり意識されない部分にしっかり生産性を上げる機能を提供しているという印象でした。
    • 環境と成果の切り分け
      • 実験は個人専用の環境で、成果は全員が使えるようになっていて、研究者のニーズが考慮されています。
    • 計算資源のスケールが容易
    • 共同研究に対応した基盤
      • 外部の人がnotebookにアクセスできるようにしているのは便利。
  • 実験ツールの標準化 と 研究の自由 のトレードオフ
    • 岩崎さんは以前会社ブログやPyConJPで『小さく始めて大きく育てるMLOps2020』 https://cyberagent.ai/blog/research/12898/という発表をしていましたが、私はこれを読んだ当時これに沿って社内の実験手順を統一しているのかと思ってました。しかし、実際には研究者の個人のやりかたは自由ということでした。
    • 社内ツールを開発しても、使ってもらえないということは私にもあるので、いかに相手に使用を強制させずに普及させていくかは参考になりました。
  • プロダクト側への実験成果物(モデルなど)の引き継ぎはどのように行っているのだろう
    • 関数I/Oは共通化できるものの、内部ロジックはリサーチャーが実装しているはず。そこはおそらく実験のコードのままだと思うのでプロダクト側にわたすとき、どう品質を担保するのか、誰が今後メンテを行うのかというのは気になりました。

スポンサードリンク

2人目 『サイバーエージェントにおけるMLOpsに関する取り組み』

スピーカー: 芝田 将(Masashi Shibata)

概要: サイバーエージェント社内の3つのプロダクトのMLシステム構成を紹介しながら、そのプロダクトで行ってきたMLOps周りの取り組みをお話します。

スライド https://www.slideshare.net/c-bata/mlops-248545368

動画 https://www.youtube.com/watch?v=oluIfLSsq8w

芝田さんは社内の(高度な)技術サポートの仕事を行っており、今回は社内プロダクトの改良やトラブルシューティングに関して3点報告されました。

  1. DynalystにおけるMLモデルの推論の高速化
  2. AirTrackにおけるMLモデル学習の高速化
  3. AI Messanger Voicebotにおいてシステムが固まる問題の調査

1. Dynalystにおける機械学習

  • Dynalyst:CA社のプロダクト。スマートフォンアプリに特化したダイナミックリターゲティング広告をしてくれるDemand Side Platform。
    • スマホユーザの行動ログを元に、提示する広告を決める。ユーザに広告を提示した時、コンバージョン(広告主の期待する行動をとること; 商品を購買、アプリのインストールなど)する確率を予測するのにMLを使っている。
    • 使用しているCVR予測アルゴリズム: field-aware Factorization Machine
  • C++実装でCLIのみを提供している。 そのままだとPythonで実行できない。サードパーティのpythonバインディングもあるが、自前でpythonバインディングを実装した。
    • 自前のpythonバインディング 理由1
      • libffmに予測性能を上げるためのパッチを当てたいため。具体的には損失関数をカスタマイズしたかった。
      • カスタマイズすると、サードパーティのpythonバインディングが想定するlibffmと違ってしまう。そのため、自前でバインディングを実装する必要がある。
    • 自前のpythonバインディング 理由2
      • 予測速度の高速化したかった。
      • ユーザに提示する広告をリアルタイムに決める。リアルタイム性が求められる。広告の表示のレスポンスタイム(100ms以内)。

以下では高速化したlibffmのpythonバインディングを開発した際のtipsを説明する。

Cythonによる推論サーバの高速化

  • Cython
    • Pythonライクなコードを書くとCの最適化したコードを生成してくれるプログラミング言語
      • Pythonのスーパセットなので、CythonのコードとPythonのコードが混ざっていてもいい
    • 変数に明示的にデータ型を与えるほど高速化する
      • 手書きのCコードより高速になることも珍しくないとのこと
      • コードアノテーションが用意されており、ハイライトされている場所(Python/C APIを読んでしまってる遅い箇所)をCythonのコードに書き直すことで処理が速くなっていく。
    • C/C++とPythonのインタフェースとしても利用可能で、バインディングを作る際にも使える
  • CythonにおけるGILの解放
    • C言語のコード部分(Python/C APIを読んでいない部分)はGILの解放が可能で、マルチスレッドの恩恵を受けられる。
  • 安全性を犠牲にした高速化もおこなっている
    • CとPythonで異なる部分に対してPython/C APIがチェックが呼ばれてしまう
      • 例えばゼロ除算チェック、配列に負値のインデックス-1を与えることなど
    • 高速化のために、Compiler directivesの設定でチェックを切る
  • 推論処理をCythonに直した効果
    • 推論時間が改善前の10%に短縮
    • 推論サーバの全体のレスポンスが元の60%に短縮
    • スループットが1.35倍なったため、稼働させておくサーバを減らしコスト削減にもつながる。

LIBFFMバインディングの実装 参照カウントとNumPy C-API

Pythonコードの高速化をしたいだけならば、Cythonに書き直せばOK。これはお手軽。しかし、Cythonを使ってPythonバインディングを作るにはCython, C/C++の深い理解が必要。その一例としてメモリ管理にまつわる話をする。

  • Cライブラリをラップするには
    • Cython側から参照したいCの関数や構造体の宣言をする
    • 関数の引数に与えるオブジェクトを生成する
      • やってることは構造体のメモリ領域の確保
    • 関数の呼び出し
    • 使用したメモリ領域の解放
  • Pythonと連動したメモリ管理がしたい
    • Cで確保したメモリ領域をPythonで触りたいというケースがある。
      • libffmの例だと、メモリ領域内にモデルの重みがあり、その重みで推論がしたい。
    • その場合、Cでメモリ領域確保→Cythonのラッパーがメモリ領域をラップしPythonで参照できるようにするnumpyオブジェクトにする
    • 問題なのは、numpyオブジェクトを破棄しても、cで定義したメモリ領域は自動的には解放されない(Cにはガーベージコレクタがない)
    • したがって自分で開放する必要があるが面倒。
    • numpyオブジェクトを破棄したら連動してメモリ領域が解放されるようにしたい。
  • CPythonのメモリ管理機構は参照カウント
    • 参照カウントが0になるとPythonオブジェクトのメモリ領域は解放される
  • どうやって連動させるか
    • ラップしたNumpy配列に対してBaseObjectを指定する
      • このBaseObjectは、Numpy配列の実体となるCの配列のポインタを所有するオブジェクト。雛形のクラスには__dealloc__メソッドを定義し、このクラスのオブジェクトが破棄されたときは、実体となるCの配列のメモリ領域を解放する処理を書く。
    • これにより、Numpy配列が破棄されると、連動してBaseObjectも破棄され、BaseObjectが破棄されるときにCの領域が解放される。
  • 以上のように、Cで確保したメモリ領域をPythonで触れるようにするのは一苦労。pythonで操作する必要がない (Cython内でメモリ領域の操作が閉じている場合は型付きメモリビューを使うことを推奨する。

2. AirTrackの事例紹介 OptunaとMLflowを使ったハイパーパラメータ最適化の転移学習

  • AirTrackとは
    • 位置情報を活用した来店計測や広告配信を行うCA社製SDK
    • ユーザやエリアの属性推定、店舗への来店予測に機械学習技術を利用
  • MLモデル学習のパイプライン
    • メトリクス、アーティファクトの管理にMLflowを利用
    • ハイパーパラメータの探索にはOptunaを使用
      • 学習バッチを実行するごとに毎回ハイパパラメータも探索しているとのこと
      • この時、ハイパラ探索の工夫をしている。それについて説明する。

Optunaの基礎知識とWarm Starting CMA-ES

  • Optunaの強み
    • 使える探索アルゴリズムが豊富
      • ただし、芝田さんの印象では殆どのユーザはデフォルトのアルゴリズムしか使っていないと思っている
  • Optunaのデフォルトのアルゴリズム: 単変量TPE
    • 欠点: ハイパラ間の相関関係を考慮しない
  • Optunaで使える、相関関係を考慮した探索アルゴリズム
    • 多変量TPE
    • CMA Evolution Strategy(CMA-ES)
      • AirTrackのモデル学習で使用
  • Warm Starting CMA-ES でハイパラ探索を高速化

3. AI Messanger Voicebotの事例紹介 軽量スレッドとWebSocket

  • AI Messanger Voicebot
    • AIによる電話自動応対サービス
  • システム構成
    • twillioを経由して、websocketで音声データをやり取り
    • エンドポイントとなる部分(WebSocketサーバ)が送られてきた音声を
      1. Google CloudのSpeech-to-Textで音声認識し、
      2. 音声認識結果を元に対話エンジンが応答内容を生成し、
      3. Google Cloud Text-to-Speechで応答内容を音声合成する
  • トラブル
    • 開発初期、WebSocketサーバ(Flaskで実装)が特定の条件下で固まって動かなくなるという相談が芝田さんに寄せられたので原因を調査した

WSGIと軽量スレッド

  • PythonでWebsocketを扱うことについて
    • WSGIに則ったデータのやり取りだと、そのままでは不可能。
    • WSGIであってもwebsocketで通信するには何らかの工夫が必要
      • 工夫の例 WSGIのcallableなオブジェクトにWebsocketオブジェクトをわたす
        • Flask-socketsを用いると、このようにしてWebsocket通信ができるようになる。
  • 工夫してWebsockets通信を行おうとする方式の問題点(WSGIの制限について)
    • WSGIアプリケーションを呼び出したスレッドは、そのアプリケーションの処理が終わるまで別の処理を行えないこと。Websocketのコネクションが張られているうちは処理を離せない。
    • 対応策としてはマルチスレッドが考えられるが、OSが管理するスレッド(threading.Thread)を使うのは避けたい
      • 理由はパフォーマンスが悪いため
        1. コンテキストスイッチが重たい
          • スレッドの切り替わりのタイミングで、レジスタの内容をメモリにダンプし別のスレッドの状態をメモリからレジスタに読み出して処理を再開する。切り替える度にこれが発生してしまう。
        2. スレッドのスタックサイズが大きく(2MBなど)、1つスレッドを作るだけでもコストがかかる
      • したがって、user landで動作するスレッドのようなもの(軽量スレッド)を使ってマルチスレッドを実現する
        • (個人メモ: アプリケーション側で生成した仮想的なスレッドだから生成が早いということだろうか)
    • 先述のFlask-socketsはGevent-websocketを内部で使用しており、これが軽量スレッドを用いたマルチスレッド処理を実現してくれる

Gevent-websocketの仕組み

  • Geventのmonkeyというモジュール
    • monkey.patch_all()を 呼び出すとPythonの標準ライブラリに対してモンキーパッチを当てる。通常ならばスレッドをブロックするような操作をGevent用のものに置き換える。置き換えると軽量スレッドベースで動作させることができる。
    • この状態でthreading.Thread(本来は、OS経由でのスレッド生成)を呼び出すと、内部的にはGeventの軽量スレッドを生成する操作(gevent.Greenlet)に置き換わっており、シングルスレッドでありながら仮想的に並列処理を行うことができる。
    • Flask-socketsはGevent-websocketを利用して1つのスレッドで複数のWebSocketのコネクションをさばいている
  • ただし、monkey.patch_all()が置換できないものがコードの中に含まれていて、そこを呼び出してしまうとブロックが発生。 Gevent(イベント駆動)のイベントループがそこで止まってしまうためプログラム全体が固まってしまう
    • 置換できないコードの例としては、サードパーティが独自実装した通信部分など。
    • CA社の例だと、GCPのText-to-SpeechAPIのSDKが内部でgRPC双方向ストリーミングを呼び出してブロックが発生
      • gRPC通信部分はC++実装のため、Geventが置き換えられなかった。
  • 【余談】ASGI(Asynchronous Server Gateway Interface)
    • 上の問題は同期処理を想定しているWSGIで無理やりWebsocket通信と非同期処理をやろうとしたことが起因
    • WebSocketもサポートできるような非同期インタフェースの仕様を策定(中)

質疑

  • Cythonのコードアノテーションのハイライト(Python/C API呼び出し)部分はどうやっているのか
    • コードアノテーションはCythonが提供している機能。コンパイルコマンドにオプションをつけるとコードハイライトしたhtmlファイルを吐いてくれる。
  • メモリ確保したい時、PyMem_Mallocで確保するのとC++のスマートポインタで確保するのでは何が違うか
    • メモリをどこで管理したいかの違い。PyMem_MallocはCythonでメモリ管理したい場合に使う。
  • (コメント) Cythonを使った実装のパートについて、話は理解できるけど自分で実装できる気がしない
    • CA社のMLエンジニアもCythonに苦手意識がある。Cythonは実際難しい。デバッグ時オブジェクトファイルにデバッグコード埋め込んでgdb起動しないといけなかったり、ハマると大変。そのあたりは頑張ってください。
  • Optunaに関して、ハイパラ探索時、過去のbestハイパラより悪くなることはないか。
    • 悪くなる場合がある。それを見越して、探索パラメータ候補に過去のbestハイパラを追加しておくことで精度の下界を保証する。
  • Warm Starting CMA-ESによって、どれだけ学習効率が上がったか
    • オフライン性能検証の結果では、単変量TPEに比べて評価回数が半減した
      • 単変量TPEだと100回評価してたどり着けるハイパパラメータがあるとして、Warm Starting CMA-ESだと50回でたどり着ける。
  • SageMakerではなくMLflowを使っている理由は
    • 自分はサポートとしてぱっと入っただけで、プロダクトの設計には関わっていない。したがってMLflowを選定した細かい背景はわからない。
    • 他のプロダクトでシステム設計のディスカッションをした時の話になるが、MLflowがむかないケースが結構あると思っている。メトリクス集めたい時、MLflowのTracking APIを使うせいで柔軟性が減ることがある。
  • AI Messanger Voicebotに関してpythonで非同期処理を扱うのは大変そうだが、何でPythonで実装したのか。
    • あくまで推察だが、対話エンジンがPythonで実装されている手前、Pythonで統一しないとシステムの複雑さがあがるからというのがあったのではないかと思う。
      • また、Webscocket通信周りを実装していたのもMLエンジニアだったというのもあるかもしれない。
    • 自分がやるとすれば、Websocketの部分はPythonより得意な言語、例えばGo langを使うだろう
      • Goにはgoroutinesという優れた軽量スレッドの実装がある

個人メモ

  • Dynalystの事例紹介に関して
    • 速度要件の求められるアドテクで、Pythonを使うことはかなりディスアドバンテージのはず。そこを技術でカバーしたのはすごい。
    • Pythonのバインディング書ける人は尊敬します2。
  • AirTrackの事例紹介に関して
    • 岩崎さんの方はGCPを利用していたが、こちらはAWSを利用しているようだ。どういう基準でクラウドベンダを選定しているのだろう。
    • アーキテクチャを見ると、Client(エンドユーザ)がMLflow serverにリクエストを送っているように見える。推論サーバとしてMLflowサーバが使えるのだろうかと気になりました。
  • AI Messanger Voicebotの事例紹介に関して
    • 問題は複雑。
      • 強いエンジニアが高度な技術的課題を解決して現場を救ったという見方はできるものの、最下流で尻ぬぐいした感じもする。もう少し設計段階で芝田さんが加わっていた方がトラブル解決にかかった工数が少なかったかもしれない。
        • とはいえ、GeventとgRPCの相性が起因であると予見するのはさすがに難しいか。
      • そもそもの問題はPythonでプロダクトを開発しようとしたことだが、MLエンジニアがプロダクトを全部設計しようとすると技術選定がPython中心になってしまうのは仕方がない。
        • 別にMLエンジニアもスキル不足というわけではないだろう。MLエンジニアはGoも実装できるようにならないといけないかというと違うわけで。
      • 未来に同じようなことが起きたときにまた強いエンジニアが必要になってしまう事態をどう避けるか。結論出ない。MLOpsの責任境界問題の議論のケーススタディとしては面白い。
  • その他
    • 内容が高度だった。発表内容を理解するために、数多くの参考文献にあたる必要があったが、いい勉強になった。
    • 岩崎さんはAI Labはプロダクト部隊ではないと言っていたが、今回の芝田さんの取り組みはどのような位置づけなのだろう
    • スペルを大文字含めて正確に書いていて丁寧なスライド。
      • 私は面倒なので、pythonのように 表記の正確さを若干サボって書くのですが、スライドを見る限り、全て正確だったので驚きました。

おわりに

最後になりますが、改めてPyData.Tokyoの運営の皆様、会をアレンジしていただきありがとうございました。
おかげ様でまた1つ勉強になりました。

参考文献


スポンサードリンク

  1. MLOpsという名前が定着していなかった頃だったので、SysMLというカテゴリ名でした。↩

  2. 私はバインディングを書けないので過去にsubprocessでrubyバインディングを実行するというなんちゃってPythonラッパーを作っていました…↩