Stimulator

機械学習とか好きな技術話とかエンジニア的な話とかを書く

Rustによる機械学習概覧を技術書典11に寄稿するまでの軌跡

Rust 機械学習 雑記

f:id:vaaaaaanquish:20210709094552p:plain

- はじめに -

今回、技術書典11に「Rustによる機械学習概覧」というタイトルで、所属企業であるエムスリー株式会社の執筆チームより出る「エムスリーテックブック3」に文章を寄稿した。

執筆チームからの熱いコメントは以下。

販売ページは以下。
techbookfest.org

本ブログは、エムスリーテックブック3を企画して立ち上げてから、自分で同人誌を書くまでのお気持ちを綴った、所謂ポエムである。

- Rustによる機械学習への想い -

ポエムといえば自分語り、自分語りといえばポエム。まず思い出に浸ろう。

私が機械学習を初めて実装したのは高専の頃。あの時はC/C++とJava、C#なんかを使って、何とかアルゴリズムを理解して実験していた。VisualStudioの起動に悠久の時が必要だったので、朝研究室に寄ってPCとVisualStudioを起動するボタンだけ押して授業に行ったものだ。遺伝的アルゴリズムでゲーム攻略したり、音楽作ったり、ニューラルネットでどうでも良いネットの動画の再生数とかを回帰で解いて遊んでいた。大学に入って、MatlabやLispを触ったが、何より初めて触って衝撃的だったのはPythonだったと思う。当時は、OpenCVが驚異的に簡単に扱えてNumpyで演算が出来て、OpenMPやCUDAといった資産も扱えるすごいFFIを備えたやつという感動があった。当時のDeep Learningのライブラリといば、cudaないしドライバのinstall battleに始まり、激しいPythonのインターフェースとバージョン差異との戦いの連続だった。そして、prototxtオジサンと呼ばれる（私が勝手に呼んでいる）「昔はprototxtでネットワークを定義してたんだよ…」と若者に言って回る人を大量に生み出していった。私もだ。この時は想像もしなかったが、後に出るChainerは偉大なのである。その前後、何故か縁があり、アルバイトもはじめてPythonでCNNやらを実装してワイワイしていた。いつの間にかPythonを沢山書いて、研究でも利用するまでに至っていた。Pythonだけとは言わず、一時期Juliaを使って更に良いとなってコンペに出て入賞したり、Julia Tokyoにも登壇した。就職して最初の会社はC#の会社だった。画像認識をやっている部署だったが、OpenCVSharpの開発者が居たのが大きい。C#は好きな言語の1つ。その会社にPythonのAPIを初めて導入する役割もやった。ライブラリなど様々な事情でPython2で実装したのを今でもたまに悔やみ心の中で謝っている。一度転職を経てからはPythonがメインになった。転職先は大きい企業だったので、Rが得意なおかしな人が沢山居てRの講義なんかも受けた。R悪くない。この頃にはもうPythonにおけるDeep Learningのフレームワークというやつは概ね今の基盤が出来上がっていたように思う。破壊的変更で死んだり、supportが終わったり色々あったものの、分散化やタスクの複雑化、モデルの巨大化を見れたのは楽しかった。次の転職先、つまり現職では本当にPythonだけになった。速度の遅いPythonが機械学習というタスクで好まれる訳がないと言っていた私もあの人達も、みんなwrapper言語としてのPythonを業務で書くただの人になっていった。

はてさて、雑に今までのプログラミング言語と機械学習の思い出を振り返ってみた。
私と同世代くらいの人は頷く場面もあるかもしれない。

私自身、ここまで、様々なプログラミング言語を使って、機械学習アルゴリズムを書いたり使ったりしてきた訳だが、現状それらは概ねPythonとRに収束しつつある。例外を除けば、一部C/C++を書く場合があるといったイメージだと認識している。

そんな中で、私は1年ほど前にRustと出会った。Rustは、非常に良いプログラミング言語であり、私は機械学習分野にもパラダイムシフトを与えてくれると思っている。

お気持ちだけじゃなく、実際Rustで形態素解析から機械学習モデルを使った分類タスクを解くExampleになるようなブログを趣味で書いたりしている。
vaaaaaanquish.hatenablog.com

それをwasmにして実際にWebサービスにしたりして遊んでいる。
vaaaaaanquish.hatenablog.com
このサービスはなんやかんや2万強のアクセスがあるので、Rust × MLなWebサービスでも結構多いユーザだったのではと思うが、いかんせん他の事例が無さ過ぎて分からないままである。

他にもRustによる機械学習実装、ブログ、動画、本、事例、実装例をまとめたRepositoryを作ったりしている。あんまり更新してないけどStarして欲しい。
github.com

LightGBMのRust bindingsも作っている。最近LightGBM本家のREADMEに載って、Microsoftの人からGreat的なメールを貰って嬉しかった。褒めて欲しい。
github.com


大体これくらいやっていると「Rustで機械学習する価値って何？」「Rustは何が良いの？」「PythonやRはなくなるの？」という声が必ず聞こえてくる。

なんと、それに答える気持ちを全部乗せて書いたのがこのエムスリーテックブック3だ。是非読んで欲しい。
techbookfest.org


中身から少しだけ抜粋するが、Rustユーザ、機械学習ユーザの意見は概ねどのディスカッションや事例でも一致している。機械学習をやる上でのRustの良さは速度と既存の資産との相性、wasmの存在になる。どのディスカッションもC/C++で書かれた一部が置き換わる、wasm利用例が増える、エッジデバイスや高速化などが必要なピンポイントでの利用が増える、という所に落ち着いていて、PythonやRのエコシステムは残るし、むしろそれらと協業してやっていく良い形が探られるだろうというものになっている。

かつて色々な言語を乗り越えて、Pythonという言語が今機械学習やデータサイエンス業界で使われている。今度は、乗り越える対象ではなく、その屋台骨の一つとしてRustがくるぞという話なのだから、これはエムスリーテックブック3を買って未来に想いを馳せる他無いだろう。

　

- エムスリーテックブック3の立ち上げ -

今回、技術書典に出すにあたって私が「やりましょう！」と言い出して、社内説明会を開いて、人を集めて、Re:VIEWやCIを整備して、レビューして、最後TeXでフォーマットを直して出稿するところまでを主導した。

エムスリーとして技術書典に出るのは私自身は2回目で、前回エムスリーテックブック2でも執筆した。
エムスリーテックブック#2：エムスリーエンジニアリンググループ執筆部
この時は、同僚の@mikesoraeが主導していたが、コロナ禍でオンラインになり勢いが弱まっていたので、手を挙げた。

大して書きたい気持ちが強かった訳でもネタがあったわけでもないが、技術書典のような業界内でも著名なイベントに少しでも多くの若く優秀な同僚を出して市場価値を上げて欲しい気持ちがあった。本を書くのは大変なので、経験しておくだけでも良いし、ブログより長い文章で公開できる技術書にするまでの工程は、自身の知識の整理と技術説明力の向上に役に立つ。会社の広報が難しいオンラインの時期だからこそ、PDF以外に「後から配送」による物理本を送れる技術書典は、良い広報にもなると何となく思っていた。

f:id:vaaaaaanquish:20210708000004p:plain:w400
説明会のよびかけ
f:id:vaaaaaanquish:20210708000038p:plainf:id:vaaaaaanquish:20210708000045p:plain
説明会の資料の一部

そういう想いや過去の売上から会場、打ち上げの様子、大変な部分をスライドにまとめて、社内説明会を開いた。テックブログの平均文字数と比較して「ね？簡単でしょ！」と言おうと思ったけど、同人誌とはいえ普通にちゃんとした本を書くのは大変だという事もわかった。

こんな感じで調子良くやってたが、書くのはめっちゃ大変で結果出来上がったのは7月入ってからだった。申し訳ねえ。

でも実際エムスリーテックブック3は、私が読み返しても結構面白い多様な分野と専門性のある仕上がりになっているし、後は皆さんに買ってもらうだけだ。少しでもエムスリーテックブック3の良さが伝わればと想い、今こうしてポエムまで書いている訳なので、是非とも手に取って頂きたい。

今は、社内向けのRe:VIEWテンプレートを作って、Confluenceに技術書典に出るまでの手順書、過去の経歴のまとめを作っている。いずれ、私が居なくなったとしてもこの文化が続いて欲しいと強く思うし、この書籍でエムスリーを知る人、またこの書籍でエムスリーの優秀な若手のエンジニアが採用したくなっちゃう人が続々出てきて欲しい。

　

- おわりに -

久々にポエムを書いた。

ちなみに他の寄稿者良いです…

買ってね。
techbookfest.org

　
　
P.S.

自分が書こうと思った時、既に良い本が世の中にはあるものだ。

　
　

pipとpipenvとpoetryの技術的・歴史的背景とその展望

Python

- はじめに -

Pythonのパッケージ管理ツールは、長らく乱世にあると言える。

特にpip、pipenv、poetryというツールの登場シーン前後では、多くの変革がもたらされた。

本記事は、Pythonパッケージ管理ツールであるpip、pipenv、poetryの3つに着目し、それぞれのツールに対してフラットな背景、技術的な説明を示しながら、所属企業内にてpoetry移行大臣として1年活動した上での経験、移行の意図について綴り、今後のPythonパッケージ管理の展望について妄想するものである。

注意：本記事はPythonパッケージ管理のベストプラクティスを主張する記事ではありません。背景を理解し自らの開発環境や状態に応じて適切に技術選定できるソフトウェアエンジニアこそ良いソフトウェアエンジニアであると筆者は考えています。

重要なポイントのみ把握したい場合は、各章の最後のまとめを読んで頂ければと思います

　


　

- Pythonのパッケージ管理ツール概論 -

まずはじめに、2020年3月現在、主に「Python　パッケージ管理」等のワードでググると出てくる3つの大きなツール、pip、pipenv、poetryについて概論的に説明する。

最も表面的な概要だけ把握するために、私が社内向けに作成した資料を以下に引用する。

f:id:vaaaaaanquish:20210321112826p:plain
社内LT向けに作成した資料より加筆の上抜粋

多くは後述するが、ここでスライドが主張している重要な点を文字におこしておくと以下のようになる。

  • pipenvはPyPAが開発しているツールで同じくPyPAが開発するpipの機能を補っている
  • pipenvとpoetryの大きな"機能"の違いはパッケージのbuild・publishをサポートしているかどうか
  • pipenv、poetry以外に他にも多くのパッケージ管理ツールが存在する

本記事のタイトルを解消する上で重要な点は上2つであり、これらについてpip、pipenv、poetryの概要を示しながら本章で触れていく。本記事においては、Anacondaや他ツールについては本筋ではないため、本章の最後に簡単にまとめて触れる。

pip

pipは、最も基本的なPythonのパッケージ管理ツール、より正確にはパッケージインストーラである。PyPI*1より、Pythonモジュールをインストールするためのツールであり、Pythonの拡充提案、プロセス、設計、標準を決める文書群であるPEP内の、PEP 453によって、Pythonが公式にサポートするツールとなっている。Python3.4からは、Pythonに内包されデフォルトでインストールされる。
github.com


パッケージ管理の側面から見た場合は、以下のようなrequirements.txtというファイルを記述し、そのファイルで利用するモジュールのバージョンを管理する形式を取る。

numpy<=1.0.0
pandas==1.1.5
jupyterlab>=2.0.0
...

pipは具体的に依存treeを生成するような依存解決は行わず、順番にインストールしていき、サブモジュールの依存関係に問題があった場合は上書きする事で解決する。上記であればpandasやjupyter labによってnumpyはバージョンアップしたものが入る事になる。

pipと後述するpipenvの関係において、上記を背景とし一般的なプログラミング言語がプロダクト開発でそれを必要とするのと同様に「依存関係を解決する」「lockファイルを生成しサブモジュールを含む全てのモジュールバージョンをhashで管理する」事が求められた結果pipenvが開発された、という認識は間違いではない。実際、上記のrequirements.txtだけではパッケージングを行う事は出来ない事は想像できるだろう。
長らくユーザはsetup.pyやsetup.cfgを書き、PyPAが別途作成するwheel、setuptoolsといったツールでパッケージング、また別途PyPAが作成するtwinを用いてパッケージレジストリであるPyPIにアップロードするというライフサイクルに倣っており、バージョン固定や開発環境管理は各ユーザに委ねられていた。pipenvやそれら以外のツールについて具体的には後述するが、pip自体が手続き的なバージョン管理方法やパッケージングの方法を持っていないが故に、別ツールとしてパッケージングツールが作られていった結果として、今多くのパッケージング管理関連ツールが生まれ続けるPythonの環境になっているとも言える*2。

　
2021年においては、パッケージ管理の側面で、上記の前提に加えてpipの2つの大きな変更を把握しておく必要がある。それがpyproject.tomlと2020-resolverである。

　

pyproject.toml (PEP 518)

1つ目に、PEP 518で制定されたpyptoject.tomlというフォーマットがある。後述のpoetryで利用されている事は広く知られているが、pipもまたpyproject.toml対応しているという点が重要になる。

pyptoject.tomlは、以下のような単一のtomlファイルをrequirements.txtやそれらを参照するsetup.pyの代替とする事が出来るようになっている*3。

[install_requires]
pandas = "*"

[build-system]
requires = ["setuptools", "wheel", "toml"]

これはpip単体では大きな旨味はないが、pyproject.tomlが単一のファイルでパッケージのメタデータや依存ライブラリ、フォーマッタやenv環境、buildの設定を記述できる事を踏まえ、後述のpoetryのようなPEP 518対応のパッケージングツールと組み合わせる事で、ファイル及びツールを小さく集約する事が可能になっている*4。

かなり簡単に言えば、これだけ書いとけば開発関連の設定はオールオッケーなsettings.tomlである。

pyproject.tomlについてより詳しくは後述するが、現在最も注目される仕様の1つであり、把握しておくと良い。

　

2020-resolver

pipにおける重要な変更として、2つ目に、現在テスト段階にある依存解決を行うリゾルバ、2020-resolverのリリースがある。

先述の通り、pipは強い依存解決を行わないツールだった。故にpip単体では、依存モジュールのバージョンの違いと、それらのインストールの前後関係によって問題が発生してしまう*5。対して2020-resolverは、シンプルなbacktrackingを利用した依存解決リゾルバであり、強い依存解決を事前に行う事で、pipのインストールの前後関係による課題を解消するものである。

リリースブログより各リンクを追う形で、多くの議論が追える。
pyfound.blogspot.com
　
　

さて、ここで本記事で最も重要な比較の話をするため、依存解決というテーマに触れておく。

多くのパッケージ管理ツールが行う重要な機能の1つに依存解決がある。パッケージの依存解決を行うリゾルバ(resolver)が、非常に難しい問題に挑んでいる事は、dependency hellという言葉と共によく知られている通りである。

en.wikipedia.org

依存解決リゾルバのアルゴリズムでは、SAT*6における教科書的なbacktrackingアルゴリズム*7を利用した解決方法が知られている*8。有名所では、RubyのBundlerが依存解決のために利用しているMolinilloというライブラリがそのresolverのbacktrackingロジックを持っていたり、RustにおけるCargoのコアロジックにあたるrust-semverでもDFS(深さ優先探索)とbacktrackingが利用されている。言語系の依存解決リゾルバが〜〜〜という話ではなくOpenSUSEのLibzyppでもminiSATベースのライブラリであるlibsolvが利用されている。
　
また、近年では2018年にGoogleのNatalie Weizenbaum(@nex3)がDartのパッケージ管理ツールのために提案したPubGrub*9というアルゴリズムが話題になっている。PubGrubは、backtrackingの拡張アルゴリズムであり*10、非互換性のあるパッケージを見つけた時に効率的に探索を行うUnit Propagation*11を組み合わせる形で実現されている。PubGrubは効率的かつ解釈可能な非互換性を見つけられる点でより優れたロジックで、SwiftPMにマージされていたり、先に登場したCargo内でも議論があったり、RubyにもPubGrubベースのgel-rbという新しいパッケージ管理ツールが出てきていたり、Elm版の開発等も進んでおり、後述するpoetryでもPubGrubが利用されている。

PubGrubの提案者による解説記事。Dart側のドキュメントと照らし合わせながら読むと、Unit Propagation、Conflict Resolution、Decision Makingの対応が頭に入りやすく分かりやすい。
medium.com

　
本題のpip 2020-resolverでは、シンプルなbacktrackingが採用されている。このロジックは以下で議論されている。
github.com

ここでは、PubGrubベースのMixology*12やbacktrackingベースのResolveLib、Zazo、他にも先述したlibsolvやMicrosoft Researchが提案したZ3などを比較し検討している。途中でpoetryのメンテナである@sdispaterがpoetryのリゾルバ部分を書き出したrepoを提示していたり依存解決リゾルバのアドバイスを行っている所も面白い。
　
議論の結果、APIインターフェースやコミュニティ、開発速度の観点から、PyPAメンバーである@uranusjrが作成していたbacktrackingベースのresolvelibが使われる事になった事がわかる。解説は以下のブログ。
pradyunsg.me

ここでの選定理由として、ピュアPythonありコミュニティないし支援企業がついている中で開発速度にとって嬉しい事が大きい要素になっている。
pip 2020-resolverのプロジェクトにはCZI社*13とMozilla社*14による金銭的なサポートが入っており、PyPAにとっても重要なテーマであったことから開発速度が得られるに越したことはない背景があった。
pyfound.blogspot.com
（PyPAのメンバーであるソフトウェアエンジニアらが仕事の傍らボランティアで行ってきたpipの開発について、この2020-resolverの開発終了まで金銭面でサポートする内容になっている）

　
この2020-resolverで、pipは強い依存解決を行うようになり、長らくpipで言われていた

“Why does pip download multiple versions of the same package over and over again during an install?”.
(なぜpipは同じパッケージの複数のバージョンを何回もダウンロードするのか？)

という大きな課題が解消し、速度も向上する事になる。この背景について、PyPAのユーザガイドにも長文で綴られているので、見ておくと良い。
pip.pypa.io
（Python2もサポート終了で早く止めろと言われており各位には早く止めてもらいたい）

　
　
更に少し横道に逸れるが、2020-resolverへの変更によってpip installで依存解決が失敗したらResolution Impossible エラーを出すようになる。これにより、多くのCI/CDが止まってしまったり、OSSに「あなたのパッケージpipでインストールできないんだけど」というissueが増えるのではといった懸念が思い付く。これらは、2020-resolverの展開方法として以下のissue等で議論されている。
github.com
大きな問題があればissueを追うか、ユーザガイドが示す通り、『How do I ask a good question?』を読んだ上で以下のコミュニティの何れかで質疑すると良い。

　

2020-resolverは2020年10月からデフォルトになっており、21.0には完全に古いリゾルバを使えなくなる*15。今までpipenv等が依存解決を行っていた所にパッケージインストーラーだったpipが依存解決を行うようになるわけなので、全体に影響する大きな変化の1つであると言える。

　

pipenv

pipenvは、pipに対して、依存解決およびlockファイル生成、env環境制御機能の提供を行う、PyPAが開発するパッケージ管理ツールである。依存解決およびlockファイル生成にはpip-tools、env管理はvirtualenvを利用しており、それらを1つのPipfileと呼ばれる独自フォーマットで管理できるツールとなっている。
github.com

Pipfileは以下のようなフォーマットになっている。

[dev-packages]
coverage = "*"
yapf = "*"
mypy = "==0.580"

[packages]
numpy = "<=1.0.0"
pandas = "==1.1.5"

[requires]
python_version = "3.9"

ここでは、開発用のパッケージ、モジュールが利用するパッケージ、envの設定を記述する事ができる。

pipとの大きな違いは、先に挙げた依存解決、lockファイル生成、env環境の制御である。

依存解決アルゴリズムでは、pip-tools内で先程の2020-resolverと同様のbacktrackingを利用している*16。
github.com
pipenvは、pip-toolsが持つlockファイル生成の機能をwrapしている状態であると言える。

env環境については、同じくPyPAが開発するvirtualenvの機能をwrapし、env環境を提供する形となっている。
github.com
先に示した通り、pipが依存解決を行わない動作をしていた頃に、依存解決の機能に加え、一般的なソフトウェア開発に必要なenv環境の提供を可能にしたツールである。

　
pipenvはpip同様、パッケージングについては完全に別で処理する思想を持っている。setup.pyやsetup.cfgを記述し、それぞれ別のツール(wheelやtwin)を利用してbuild, publishを行いPyPIに公開するライフサイクルとなっている。publishに関連したそれぞれのツールもまたPyPAが開発しており、このような目的毎に分割されたツールを組み合わせたりwarpしたりしてパッケージングすることが、PyPAが示すPythonパッケージングのライフサイクルの主たる形であると言える*17。

　

poetry

poetryは、pipenvに対して先のpyproject.tomlの仕様を拡張を利用し、依存解決からlockファイル生成、env環境管理、パッケージングまでを行えるようにしたパッケージ管理ツールである。先のPipenvと違い、PyPAではなく、1ユーザである@sdispaterが主導し開発されている。
github.com

READMEには『Why?』という章がありそこでは、pipenvに対する課題とpoetryを作成した経緯が書かれている。要約すると以下の3点になる。

  • setup.pyやrequirements.txt、Pipfileを導入せずcargoやcomposerのようにbuildしpublishしたい
  • pipenvの意思決定のいくつかが好みでなかった
  • より良い依存解決リゾルバの導入

　
まず、1つ目の課題を解決したのが、先にも紹介したpyproject.tomlである。pyproject.tomlには以下のようなセクションを記載する事で、パッケージングに関する情報を付与でき、poetryがこの情報を読む事でbuild、publishが出来るようになっている。

[tool.poetry.dependencies]
python = "^3.6.2"
pandas = "*"

[tool.poetry.dev-dependencies]
coverage = "*"
yapf = "*"
mypy = "==0.580"

[tool.poetry]
name = "sample"
description = "This is sample"
authors = ["author"]
version = "1.0.0"
readme = "README.md"
homepage = "https://github.com/author/sample"
repository =  "https://github.com/author/sample"
documentation = ""
keywords = ["Example"]

[build-system]
requires = ["poetry"]
build-backend = "poetry.masonry.api"

[tool.poetry]となっている箇所は、poetry独自の拡張セクションである。pyproject.tomlとしてフォーマットが決まっている事で、拡張セクションを追加出来るようになっており、そちらを上手く利用した形になる。

　　
依存解決については、先述の通り、backtrackingを採用せず、PubGrubを最初から採用している。これによって、依存解決を高速に行えるだけでなく、backtrackingが依存ツリーを戻る量で制限しているような枝を探索する事ができるようになっている。具体的には、READMEに書いてある以下のような例でpipenvが失敗する依存解決を遂行できるようになっている。

pipenv install oslo.utils==1.4.0

実際はpipenvが利用するpip-toolsのリゾルバとの比較になるが、このリゾルバの違いによる問題については、pipenvとpoetryの違いに関する章で後述する。

　

Anacondaなど他ツール

少し記事タイトルと逸れるが、現状を知る意味で概論として他のツールにも触れておく。

　
ここまで書いてきたように、Pythonのパッケージ管理エコシステムは、常々PyPAという団体によって整備され、PEPを通して制定され、PyPAが、インストーラとなるpipを代表にパッケージングであるsetuptoolsやwheel、PyPIへのアップロードはtwine、仮想環境はvirtualenv、依存固定はpipenvとそれぞれ作ってきた経緯がある。

そんな中で、PyPA以外の全く別のツールや似通ったシステムが栄枯盛衰を繰り返しているのは、常々人が作るソフトウェアの難しさに触れる事に近しい。最初から誰もが満足するツールなど作れないし、Python自体のユーザが増えた事によるOSS界隈の情勢の変化、影響範囲の拡大、速度、文化など様々な要素がひしめき合った結果、poetryやその他多くのツールが生まれたと言える。


中でもAnacondaは、pipがまだ多くのライブラリのインストールに失敗しバージョンやenvを管理する方法が定まって無かった中で、挑戦的な方法を取ることで出てきたパッケージング管理ツールである。

Anacondaは、Anaconda,Incという企業が開発、運用している点やその他GUIやenv提供の機能を持つ特徴こそあるが、パッケージ管理の側面でも他ツールとは少し違う独特なツールである。
www.anaconda.com

Anacondaは、Anacondaリポジトリ*18なるpypiのミラーサーバから、「環境に応じた最も良いもの」をインストールする機能を持ったパッケージ管理ツールである*19。最も象徴的な例として、Pythonに近い界隈では「numpyが利用するBLASの違い」についての話題が毎年2,3度バズっている。Anacondaがインストールしたnumpyが早いというものだ。Google検索「numpy anaconda 早い」と検索し上から記事を見ていけば概ね把握できるだろう。
www.google.co.jp
他にもCUDAとDeep Learning関連ライブラリのバージョンを照合する機能など、手元の環境とライブラリの依存関係を照合する知識がなくとも構築出来るのが1つの"売り"であると言える。

反面、過去何度も多くの開発者やツールが「環境に応じた最も良い物を提供する」事に挑戦した結果と同様に、依存関係の差異に苦しんだり環境を破壊する結果になることもある。特にpipと併用する事がHardlinkによって困難な点が最も大きい*20。技術的なメリット・デメリットについては以下の記事には目を通しておくと良い。
www.anaconda.com

大きな企業単位であれば十二分な基盤やVMを上手く組み合わせAnacondaを利用した理想の環境で開発できる企業もあるだろうが、その破壊的な機能や近年企業規模に応じて有償化するようになり、導入におけるデメリットも存在するし、もちろん逆に良いこともある。

Anacondaは、過去pipのインストールがまだ不安定だった時期に登場し、依存解決や独自のpackage registryの提供で大きく貢献した。また依存解決リゾルバの改修にも積極的かつ、ミニマムなAnacondaにあたるminicondaも存在しており、大きな一つの勢力であると言える。

　
他ツールでは、先程から出てきているpip-toolsを利用する方法、rustで書かれたpyptoject.tomlで管理可能なpyflow等が現状の選択肢に入る。海外ではflitも人気があるようだ。


　
pip-toolsは、pipenvやpoetryと違い、env管理は別のツールで実施するという思想で作られているツールに当たる。その概念は、公式の以下の図が明確に表している。

f:id:vaaaaaanquish:20210320225037p:plain:w350
pip-tools公式repoより

ユーザはrequirements.inというrequirements.txtと同様のformatで、自身が利用したいモジュールのバージョンを記載する。pip-toolsが提供するpip-compileコマンドは、inファイルから依存する全てのモジュールのバージョンが固定された状態で記載されたrequirements.txtを生成するジェネレータの役割を果たす。また、hashを利用した固定にも対応している。ここで生成されたrequirements.txtファイルを利用してpip-syncコマンドでenv環境に流すという構想である。この思想に則りさえすれば、env環境と切り離せるため、複数人での開発等を考えた時、個々に手慣れたenv系のツールを使ってもらえば済むというメリットがある。

　

pyflowは、rustで書かれたPythonパッケージ管理ツールである。
github.com
機能としてもpoetryが採用するPEP 518、pyproject.tomlによる管理方法に加え、PEP 582にあたるカレントディレクトリに__pypackages__というディレクトリを作り仮想環境のように扱う方針に対応している*21。PEP 582はpythonlocやflit、pdmといったパッケージ管理ツールで採用されている新しい方針である。これによってユーザは、ほぼenvについて意識する事無く複数のPythonや開発環境を切り替える事ができるようになる。このようなPEP 582の採用も目新しいpyflowであるが、私自身はパッケージ管理ツールがPythonで書かれている理由はほぼないと考えており、依存解決やインストーラ含めて、より高速な言語で書かれて欲しいという気持ちもあり一目置いている。新興のツールという事もあり、現状では未対応のissueを見てpoetryと比較し利用していないが、挑戦的な選択肢として強く推せるツールとなる。

　
また他にも、pyproject.tomlを利用せずsetup.pyを含めて良い管理を目指すhatchや、オープンソースのソフトウェア構築ツールであるSConsに則り作成されているenscons、RedHatが作成したpipenvとpoetryのいいとこ取りをしたminipipenv等も存在し、小さく機能を収める方向にいくか、理想の依存解決、複合ツールとして大きくなっていくか、どの仕様を採用するのか、違いが見え隠れする状態である。何度も言うが、これらの選択は、その場その場の要件次第でもあると思うので、利用用途の多くなったPythonという言語にとって、これらのツールが多く出てくる事自体は喜ばしい事である*22。

　

まとめ

ここで一度話をまとめる。冒頭で示した主張には以下のような詳細に分かれる。

  • pipenvはPyPAが開発しているツールで同じくPyPAが開発するpipの機能を補っている
    • pipenvは依存解決器の機能を持つが、pipにもその機能が搭載されつつある
    • pipenvはvertualenvやwheel、twine含めてPyPAが作るエコシステムの一部である
    • pipenvはresolverとしてpip-tools内のbacktrackingを利用している
  • pipenvとpoetryの大きな"機能"の違いはパッケージのbuild・publishをサポートしているかどうか
    • poetryは基本的な機能はpipenvと同じ
    • poetry独自の機能はpyprojcet.tomlの拡張セクションによるもの
    • pyproject.tomlには各種設定を詰め込む事ができる
    • poetryはresolverとしてはpipenvと違いPubGrubを利用している
  • pipenv、poetry以外に他にも多くのパッケージ管理ツールが存在する
    • pip-tools、Anaconda 、flit辺りが人気
    • envやパッケージングなどの機能をどこまでをサポートするかの違い
    • package registryの違い、pyprojcet.toml(PEP 518)やPEP 582の採用の違い、リゾルバの違い


ここで、パッケージング管理を取り巻く重要なPEPを以下にまとめておく。

  • PEP 453 : pipをPythonが公式サポート
  • PEP 518、PEP 517 : pyproject.tomlおよびbuildシステムの制定
  • PEP 582 : __pypackages__を利用した仮想開発環境の提案


PyPAが作っているか否か、小さく機能を収める方向にいくか、理想の依存解決、複合ツールとして大きくなっていくか、どの仕様、PEP、どのリゾルバを採用するのに各ツールの違いがある。

　　

- pipenvとpoetryの技術的・歴史的背景 -

本章では、ネット上に多くあるpipenvとpoetryに関する議論で出てきがちな疑問、不満を以下の通りに分類し、それらに対してそれぞれ背景を追う形で紐解く。

  • パッケージングについて
  • lock生成までの速度
  • pipenvは開発がここ2年滞っていた件
  • pipenvのissue対応
  • PyPAの開発フロー
  • 活動や対応に関するゴシップ

上記を追う中で、poetryがどのような技術を採用し、pipenvが何故そうしないのか、逆にpipenvのどこが良いのかを詳しく見る。

パッケージングについて

poetryはpipenvと違い、pyproject.tomlを利用する事で、指定のbuild systemないし、独自のセクションを利用して、pyproject.tomlのみでパッケージング出来るという話がある。pipenvとpoetryの機能の違いで最もよく挙げられる点である。
「pipenvもpyproject.toml採用して」という意見も多い。

　

自系列を追うと、PEP 517が2017年9月、pipenv 1stリリースは2017年1月であり、前後関係としてPyPAがPipfileについて検討している間はpyproject.tomlのPEPのacceptに至っていない事がわかる。

また、pyproject.tomlを使えば全てのパターンのbuildが行えるかと言われると、元々setup.pyを書いていた事を考えれば当然そんな事はない。setup.pyでC言語で書いたサブモジュールをbuildしたり、外部のライブラリとリンクする実装などが代表的である。PyPAとしては、そういった問題の解決のためにwheelやsetuptoolsも作っている訳なので、役割を考えればsetup.pyやrequirements.txtが担っていた役割とpipenvが持つ依存解決、バージョン固定、env管理という問題は別であるという認識になるのは自然である。

実際、poetryはそういったユースケースに対してbuildを提供する方法として、build = "build.py"のような機能を一応持っている。ただ以下issueの通り、ドキュメントには未だ記載はなく機能として安定、サポートされている状態ではない。
github.com
build scriptを柔軟に書けるというのは、wrapperとしての立ち位置を取る事が多いPythonという言語において非常に重要であるし、tomlだけで管理できるものはないだろう。またbuild scriptの実行もPyPAが長年かけてPEPで制定、整備、開発してきた部分であるので、それらへの対応を新しい開発者やツールが対応するのは相当な熱量がないと難しい部分もある。

pyproject.tomlに集約されたり、パッケージングまで行える事で差別化が図られる一方で、こういった多くのbuildにどこまで対応するかがツールによって変わってくるよという話になる*23。

　

lock生成までの速度

「pipenv lockが遅い」「poetry lockが早い」というのは、よく挙げられる話題の1つである。

lockファイル生成速度に関してpipenvのissueが乱立していたり、Slack、Discode、SNS各所で議論されている。
#356、#1785、#1886、#1896、#1914、#2284、#2873、#3827、#4260、#4430、#4457、…


まず、先にpipenvとpoetryの依存解決リゾルバのアルゴリズムの違いがある事を挙げた。そうすると「pipenvもpoetryの実装を真似すれば？」「pipenvもpoetryのようにPubGrubをベースとした依存解決を行えば良いのではないか？」という意見を思い付くのは自然だろう。

この意見を述べる前には、PubGrubアルゴリズムの特性と、その裏側で利用するhash値の生成方法の違いを知る必要がある。

　
一般的に依存解決を行いhash値によって利用モジュールのバージョンを固定する方法として、package registryがパッケージに対して返すhashを利用する方法がある。Node.jsのnpmやrubyのrubygemsも同様の方法を取っている。Pythonにおけるpackage registryはPyPIになるが、PyPIのAPIがjson-apiへ移行したこと、またその内容にセキュリティ上の懸念がある事が、pipenvとpoetryの依存解決方法のアルゴリズム、そして実装の違いに影響している。
　

まず前提として、PyPIは2017年12月にそれまでのHTMLを利用したAPIエンドポイントをLegacy APIとし、json-apiの提供を開始した。これは、他のpackage registry同様の内容で、特定パッケージのhash値を含めて返してくれるというものである。
warehouse.pypa.io
json-api提供開始時期の問題もあって、poetryははじめからこのjson-apiが返す結果の多くを信頼し、依存解決を行っている。一方pipenvはこのAPIの結果を使わず自前でhash値を計算している。ここがpipenvとpoetryの根本的なlockファイル生成速度の差に繋がっていると言える。


さて、このjson-apiはpipenv開発開始以降に提供開始されたものではあるものの、pipenvに対しても「このjson-apiの結果を信頼し依存解決を行い、バージョンをlockするように変更すれば良い」という意見に繋がる。これにもいくつかの問題がある。

json-apiの1つ目の問題として、このjson-apiがPEPによって標準化されていないという点がある。先程のjson-apiのドキュメントからLegacy APIのページに行くと以下のような文言がある

The Simple API implements the HTML-based package index API as specified in PEP 503.

Legacy APIについてはPEP 503、その内容については、メタデータのバージョン2.0にあたるPEP 426に書かれており、メタデータのjson互換オブジェクトを定義した2.1にあたるPEP 566もあるが、json-apiについて記載されたPEPは現状存在しない。PyPAとしてpipenvにこのAPIの結果を利用できない1つ目の理由になる。一方この問題は既にdiscuss.python.orgで起案されているので、こちらをウォッチすると良いだろう。
discuss.python.org


json-apiの2つ目の問題として、PyPI(正確にはhttps://pypi.org/)のartifact hashの一部が一度インストールしてみないと分からないという点がある。PyPIは、一度アップロードしたバージョンを同じバージョンで上書きする事はもちろんできない。一方、build済みのパッケージをtar.gzにdumpしたwheel形式以外に、buildスクリプト含めたsdist形式をアップロードできる。後者は、そこに正しくメタデータが設定されていない限り、特定バージョンのartifact hash自体は一度インストールしてsetup.pyを動かすまで未知になる。この未知のhashが厄介者になる。

PyPIは、一時的なhashを返してはくれるので、全幅の信頼を置いて依存解決の情報として使う事もできるし、全く信頼せず依存解決に必要な各バージョンのbuildスクリプトをダウンロードして手元でbuildしてhash値を計算するという事もできる。poetryは一部をjson-apiとし一部を手元でbuildする方針を取っており、pipenvは先述のPEP問題を含めて後者のように完全に手元で全てのパッケージをbuildする方針になっていた。これだけでも、pipenvが遅い理由が容易に想像付くはずだ。

　

この違いはあるものの、pipenvは、buildしたパッケージを出来る限りキャッシュして高速化する改修を過去何度も行っているだけでなく、2020年5月のReleaseではJSON-APIではなくURLフラグメントからhashを計算する形で依存解決の高速化を行っている。
github.com
これでかなり早くなった事が実感できるはずである。他にも #2618、#1816、#1785 #2075辺りの議論を追うと良い。

そしてもちろん、poetryも一部のパッケージを手元でbuildしている訳なので、そのパッケージを挙げて「lockが遅い」と指摘するissueが存在するし、poetryのドキュメントにも記載がある。
github.com
python-poetry.org
要は、実装の問題というより、思想としてartifact hashをどう考えるか、どう処理するのかの違いにlockファイル生成の速度の差があると言える。

そして先に出てきた、依存解決リゾルバのアルゴリズムの違いも、この問題に起因している。手元で多くのパッケージをbuildする方針の場合、PubGrubが、依存解決を行いながら、その場に応じてパッケージをbuildする機能を持つ必要がある。PubGrubは、そのアルゴリズムの特性上、途中でbuild処理をしながらその結果を比較するロジックを実装する事に向いていない。これについては、先程のpipの2020-resolverの議論でもpoetryの作者が指摘しており、poetryの作者がMixologyとして依存解決リゾルバのロジックをpoetryから切り出したにも関わらず、2020-resolverのロジックとして採用されなかったという背景にもつながっている。ここで、適切にbuildしながら依存解決を行うPythonによるPubGrub実装があれば話が進む可能性はもちろんあり、pipgrip等のOSS実装が出始めてはいるといった状況である。

　
さて、この非決定的なartifact hashについては、PyPIメンテナが書いた以下のブログに理由を含めて記載されている。
dustingram.com
より過去のhash自体の議論については以下を追うと良い。

　
この問題が完全に解消されるには、「下位互換を完全に切ったPyPIのミラーが作られる」だとか「setup.pyを捨て全てがpyproject.tomlになる良い方法が提案される」だとか「PyPIサーバ内でbuildが走る」だとか複数の道があるわけだが、歴史の長いPythonパッケージングの問題やbuildスクリプトが走る事でのセキュリティの懸念、サーバの金銭面などを全て解決されるには時間がかかるのは当然と言える。

　

pipenvは開発がここ2年滞っていた件

pipenvには「開発が滞っている」「2年更新のない死んだプロジェクト」などの指摘が多くある。実際、2018年11月（v2018.11.26）から2020年5月までReleaseがなかった。2020年5月のReleaseも、当初予定していた2020年3月から4月21日に延期され、4月29日に延期、その後5月にReleaseされたという背景があり、この辺りを挙げ開発が滞っているとする指摘も多い。

これらは、2020年のRelease Noteやtracking issueを見るのが良い。
discuss.python.org
tracking issue: https://github.com/pypa/pipenv/issues/3369

ここまで示した通り、pipenvはPyPAが開発する多くの他プロジェクト、pipやvirtualenv、setuptoolsに強く依存しているし、その意思決定の多くがPEPという大きなプロセスを通して行われている。空白の2年間の如くpipenvが止まっていたように見えるだけで、関連度が高く、依存した多くのプロジェクトの改修を行っていた訳で、開発が滞っているという指摘自体が間違っていると言える。

なによりPyPAはNumFOCUSといった支援団体があるとはいえ全員ボランティアであるし、Release Noteを書いているDan Ryanは仕事をしながら20%ルールの範囲で開発を行っていると書いてあるしで、外から多くを求めるだけというのは間違いだろう。またこのRelease Noteには「Other changes in the project」という章がある。それはProcess changes、Communications changes、Release cadence & financial supportの3つに分かれており、PyPIへの貢献のプロセス、コミュニケーションを変える事を約束し、別の形で「パッケージングエコシステムに対して」貢献できる形を提供すると発表している。

議論やcommitmentに至る程の背景知識がないが、このパッケージング問題に金銭面で貢献したいといった場合は、以下を読みdonate.pypi.orgに行くと良いだろう。
pyfound.blogspot.com

　

pipenvのissue対応

poetryが個人開発から始まっているのに対して、pipenvがPyPA主導である事から、issueへの対応の違いが指摘される事がある。「pipenvはissue対応が遅い」といった意見だ。これは、PyPAが元々issueを多く使っていない事に起因しているが、pipenvでたまに返信があるissueもあったり、ツールも分散しているので一見ではissue利用の思想について把握しづらいとも言える。

さて、先にpipの2020-resolverの問題の相談先として以下を挙げた。

これに加えてパッケージングに関しては、以下のような場所の議論を追う必要がある。


他PyPA関連のプロジェクトの多くの議論場所は以下のページにまとめられており、Slackからメーリングリスト、freenodeをチェックする事が求められる。
packaging.python.org

一見混乱するかもしれないが、開発者からしてみれば、接触確認アプリCOCOAがissueを利用していないにも関わらず未対応であった事を指摘していた人と何ら変わらないので、正しく議論したい場合は念入りに読み込んで、適切な場所に意見を投稿すべき、という話になる。

　

PyPAの開発フロー

PyPAの開発フローしんどい問題も少しだけある。もちろん影響範囲が大きいし、PEPや歴史的背景を持つ大きなプロダクトなので当然ではある。

例えば、実際「pipenvに一度貢献したがもうやりたくない」といった意見もある。
github.com
フローと歴史的背景を多く要求されるだけでなく、交渉の末MRを出すもcloseになる事がある。実際に私も過去python devのSlackでパッケージング管理問題に触れた時、多くの回答とフローを用意され尻込みしてしまった経験を持っている。

　
また、PyPAのツールにおいて少し特殊なのは、Vendoringという開発手法を用いている事が挙げられる。
これはRustやGo等ではgit submoduleのような形でよく使われる手法で、利用するモジュールを依存関係として取るのではなく、同一のRepository内に含めてpatchを当てて開発していく手法である。日本語であれば以下が詳しい。
qiita.com

pipenvのrepogitoryの以下ディレクトリを見ると、vendoringされたツールが多くあるのが分かる。
https://github.com/pypa/pipenv/tree/master/pipenv/vendor
これは、LICENSEやネストといった既知の問題こそあるものの、PyPAが作るツールのような「ある依存モジュールが突然PyPIから消えて動かなくなったら困る」といった再現性が必要な場面で有用な手法である。

一方で、ことPythonにおいてはvendoringに関連した文化やツールがそもそもないので、pipenvにその問題を指摘するissueが立ったり、vendor先のツールに「このrepoメンテする意味ある？」といったissueが立ったりしている。
github.com
github.com
当然upstreamとして機能し取り込まれる可能性があるので意味はあるのだが、Pythonという言語内でのvendoringの文化として浸透していない証拠とも言える。


ただ、開発フローに関しては、個々時々に応じて対処していけば良い問題であって本質的ではない。貢献する気概を持って貢献するだけだろう。そして何より、先述の2020年5月のRelease Noteを使って体制を改善するとまで言っていることからも、PyPAが真摯にこの課題に向き合っているのが分かるので、期待する所でもある。

　

活動や対応に関するゴシップ

issue対応や開発フローも技術的な背景から遠いが、pipenvやpoetryの議論の歴史も存在しており、それらを知る事で適切にコミュニティとコミュニケーションが取れると思うので、短くまとめておく。

昔々、当然PyPAメンバーはpipenvを推していて、メインメンテナであったKenneth ReitzがPyCon2018で発表するなどしていた。一時期pipenvのドキュメントのトップには以下のような文言が存在した。

the officially recommended Python packaging tool from Python.org, free (as in freedom)

冒頭のtheを含めて直訳すると「Python.orgが公式に推奨する唯一のPython パッケージングツール」というニュアンスになる。「PyPAは公式に推奨されているのか」「唯一のツールなのか」等、文言やその他の活動に対して揚げ足を取るような形で、機能や対応に不満を持っていたユーザの意見が噴出した。十分でない機能をREADMEで揶揄するプロジェクトが出たり、ブログやSNSでも話題になっていた。

以下のようなタイトルのissueもあり、コメントやリアクションを見るになかなか殺伐としているのが伺える。
If this project is dead, just tell us · Issue #4058 · pypa/pipenv · GitHub

そんな最中、作者のKenneth Reitzが「Python.orgが公式に推奨する唯一のPython パッケージングツール」の文言をmaster commitで削除したりした*24事や、攻撃的な意見が辛く精神的に病を抱えている事を告白する記事を公開した。

そしてredditやissueで、全ての不満と共にKenneth Reitzのパフォーマンス説を唱える人が出たり、そういった人達と本当に技術について議論したい人が入り混じり炎上、PyPAメンバーやPythonメンテナが対応する事になった。

これらについてはPyPA、Pythonそれぞれから回答があり、以下を参照すると良い。
github.com
github.com


誤解を招かないため、更に書くと、pipenvやpoetryの不仲などと言った事もなく、上記redditスレ内でもpoetry作者とも話した上で設計思想の違いを認識している事が書かれているし、pipの2020-resolverを決定する際には両メンテナ、Pythonメンテナがそれぞれのリゾルバについてや依存解決のコツを投稿しているので、決して悪い方向に進んでいるような話ではない。
実際、現在のPythonのパッケージングに関するチュートリアルには、pipenvやAnaconda 、poetryを適切に選定する事が良いとされている。
packaging.python.org
技術的には本質ではないものの、知っておく事で、コミュニティがこういった攻撃的な投稿に関する話題に敏感である事を鑑みながら、丁寧に投稿できるようになればと思う程度の話である。

　

まとめ

本章のpipenvとpoetryの違いについて、以下にまとめる。

  • build/publishの機能の違いはpyproject.toml誕生の前後関係とPyPAのエコシステムの思想からくるもの
  • lockファイル生成速度は、PyPIのjson-apiの結果をどこまで信頼し、どこまでパッケージを自分でbuildするかに関係
    • 依存解決リゾルバの違いもここに縛られている側面がある
    • 解決するにはいくつかの方法こそあるが、下位互換やセキュリティ、金銭的な側面の課題もある
  • Pipenvはissueではなくメーリングリストを利用して開発が進んでいる
    • 徐々にissueでの議論も進んでおり開発フローの改善も進む
    • poetryの方が開発体制が良いという訳では必ずしもない
  • それぞれゴシップ的な炎上を経験しておりディスカッションに参加する場合は丁寧な理解をしておくと良い

念の為フェアに補足しておくと、pipenvには、PyPIにアップロードされたパッケージが変更されていないか等の脆弱性を確認するPEP 508に則ったpipenv checkの機能もある*25。ある意味特徴的な機能の1つだ。
pipenv.pypa.io
これらを加味しながら、適切にツールを選ぶ事が良いと考えられる。

　

- poetry大臣としての活動記録 -

ここまで、Pythonのパッケージング管理ツールについて取り扱ってきた。そして、私が所属する企業、チームでも、実際にpipenvによるパッケージ管理とデプロイ、CI/CDが使われていた。しかし、運用する中で前述のようなパッケージング管理ツールの違いを踏まえて、社内の課題と見比べ、poetryへの移行を行う形となった。本章は、その移行作業の目的や判断基準、感想を綴るものである。

重要な分岐点になった、以下の3つのセクションについて書いていく。

  • VPN必須なpipenv lockがかなり遅かった
  • 乱立するファイルと管理場所
  • gokartなどOSSとの管理方法統一

　

VPN必須なpipenv lockがかなり遅かった

私が所属する企業では、社内のPyPIを通してpipによるインストールを行っている。そして、社内PyPIへの接続にはVPNが必須であった。

ちょうどコロナで全社でのリモート化が進み、在宅勤務が増えた事でVPNの負荷が増大、それに伴ってpipenv lockに膨大な時間がかかるようになっていた。基本的に1時間以上は基本、大きなrepoでは2,3時間を要して、途中で接続がタイムアウトしてしまうような事もあった。実際、深夜の障害対応中に「hot fixでバージョン戻してReleaseしましょう」「では、lockします」「・・・(終わりは3時だな)」といった会話が発生するなど、本当にあった怖い話もいくつか体験しており、流石にlockファイル生成速度の問題を看過できなくなっていた。


先述した通り、pipenvの設計思想の課題の1つである、has値確認のためのbuild実装に起因するもので、根本的な解決が難しいことも考慮し、別ツールへの移行を考える必要があった。検討したのは、pip-tools、poetry、flitであった。中でもpip-toolsは強く検討したが、各々がenvを設定するコストやpyproject.tomlが今後主流になるだろうという憶測から、poetryとflitに絞って検証を行った。

移行当初、flitが抱えていた課題として、パッケージのバージョニング機能が不十分であるという課題が存在した。具体的には、gitタグやVERSION.txtを通してパッケージのバージョンを決める方法の有無で、これによってCIによるバージョンやpublishを行う所作が、所属チーム内では広く行われていた。

poetryには、poetry-dynamc-versioningという拡張が存在し、こちらを利用する事で、上記問題が解決できる事が分かったため、以降先としてpoetryを利用していく運びとなった。
github.com

　

乱立するファイルと管理場所

所属チームでは、基本1人1プロジェクトで開発を進めており、そのプロジェクト数は大小や稼働率、廃止撤退様々あれど36個にも登る*26。

私が入社当初、プロジェクトテンプレート等はなく、各々自らが知るツールを使ってRepositoryを作っていた。その後、私がcookiecutterによるプロジェクトテンプレートを作ったものの、そういうった背景を鑑みないrepoは増え、プロジェクト管理は以下のようなファイルに分散していた。

  • requirements.txt
  • setup.cfg
  • setup.py
  • VERSION.txt
  • Pipfile
  • Pipfile.lock
  • pip.conf
  • code_analysis.conf
  • yapf.ini
  • MANIFEST.in

中にはバージョン情報がrequirements.txtとPipfileに分かれて書かれており、初見ではどこで指定されているモジュールがproductionで使われているのか分からないようなプロジェクトも存在した。poetryとpoetry-dynamc-versioning、toxというテストを統一的に管理するツールを導入する事で、以下の3つに全てのファイルを集約できる事が大きな後押しになった。

  • pyproject.toml
  • poetry.lock
  • tox.ini

github.com

これは、最近Preferred Networks社のブログでも語られたような内容なので、普遍的に多くの企業で課題になっているだろう。
tech.preferred.jp
（PFNはそういった課題に対してpysenのようなツールを公開するにまで至っているのだから流石である）

私の所属企業では、poetry、poetry-dynamc-versioning、toxを利用する事によって既存のメンバーだけでなく、新しいメンバーに対しても混乱を産まず、いくつかの設定の場所と使い方を覚えるだけで開発に専念できるようになり、多くの問題を解消することができた。企業によっては、インフラやCI、要件の関係で他ツールを選ぶこともあるだろうとは感じるが、横串でツールの要件が決まっている事での開発速度の差は何より大きい。

　

gokartなどOSSとの管理方法統一

私の所属企業として内部で使われるツールを外向けのOSSとして公開しているが、チームメンバー全員が使うにも関わらずメンテナが一部のメンバーに偏ってしまっていた課題があった。様々な理由こそあったが、日頃使っているツールとの差異が大きく、パッケージングやフォーマッタのツールに社内との微妙な違いがあり、またbuildやpublishをメンバー個人ができない状況で、新規に開発に参入しづらいという課題が大きく存在した。

そういった背景から、社内でpoetryを推進した後、外部のOSSをpoetryに移行する運びで解消する事にした。
github.com

　

活動全体の結果

先述のような前提を踏まえ、私が2020年4月にpoetry移行をスタート。

f:id:vaaaaaanquish:20210326164741p:plain
2020年4月に自己宣言

1年かけて、コツコツと様々なプロジェクトにPull requestを出し、先日稼働中のプロジェクト全てがpoetryに移行した形になった。

f:id:vaaaaaanquish:20210329002427p:plain
ROI勘定


Pipfileからpyproject.tomlの移行は、toml形式を互いに採用しているところからもほぼ困難なく移行する事ができた。

移行時は、pyproject.tomlがデファクトスタンダードにならなかった場合にpyproject.tomlに多くの設定が集約される事でロックインされてしまうのではという懸念を持っていたが、現状多くのフォーマッタやlinter、testツールがpyproject.tomlをサポートする流れになっており、良い選択だったと言える。

poetry-dynamic-versioningを利用した、pythonパッケージ用のrepoの設定の仕方の記事を書くなどした。
vaaaaaanquish.hatenablog.com

また、同僚の @SassaHero がyapfをpyproject.tomlの対応をするなどした。

チーム管理のOSSであるgokartには、poetryやtoxが導入、かなり少ないツールと設定ファイルで多くの処理が行えるようになった。結果社内外からのコミッターも増えて万歳という結果になった。

　

まとめ

pipenvからpoetryへの移行を行った。要点としては以下のようになる。

  • 社のVPN起因でpipenvのlock速度に課題があり技術的解決も困難であったため乗り換えを決意した
  • 乗り換え先の選定においてはversioning等の既存のCI、OSSの移植の簡易さを考慮した
  • 数十のプロジェクトで1年単位での移行となった
  • 結果として課題が解決するだけでなくpyproject.tomlへの情報集約、OSSの盛り上がり等の副次的効果も得られた

poetry移行により、この先少なくとも5年は持つ開発環境が作れただろう。何よりlockやinstall速度が改善した事が成功の証と言える。

しかし、再三記述した通り、あくまでパッケージツールであって、かつ安定した状態とも言えないため、今後どうなるかは定かではない。移行作業も多くの時間がかかるし、新しいツールも続々出てくる。ベストプラクティスといった言葉に惑わされず、より丁寧な技術選定の上で今の自分たちにあった選択が出来るようにすべき、ということがよく分かる。
　
　

- おわりに -

本記事では、pip、pipenv、poetryという3つのパッケージ管理ツールについて、技術的、歴史的背景をまとめ、それらを元にpoetry移行を行った経験を綴った。

そもそもパッケージ管理が最初から全て上手くいっているプログラミング言語などない。フロントエンド系だって、様々な設定ファイルやメタプログラミングを通してpackage.jsonやtsconfig.jsonに行き着いているし、JVM系のようにhash照合の概念がなくpackage registryをSpringが立てているようなところもある。package registryを捨て、gitのコードベースに依存解決を行っている言語もあれば、RustのCargoを見れば、fmtからtest、doctest、build、パッケージ依存解決、パッケージングを行えるたった1つのツールをメンテしている。それぞれ見れば、それぞれに課題がある。

各ツールを組み合わせ、自分の最強のbuild環境を作る上では、ある意味Pythonの体制は良く出来ていて、動的言語との相性も良い。一方で、出てくる不満についてもよく分かる。

　
私個人の本音を言えば、PythonにもCargoくらい全ての事が詰まったツールは欲しい。


特にpyproject.tomlベースでPEP 582も扱いたいし、できればtestやlinterも1つのツールに収まっていて、スクリプトで管理するのはごく一部でロックインされず気軽に乗り換えられるのが嬉しいが、そんなモンスターのようなツールのメンテは想像するだけで骨が折れる。PyPIのjson-apiがPEPを通るか、Anacondaのようにpackage registoryを構える偉大な団体が出てくるかといった依存解決についての解消も必要だろう。

一方で、これは作ってない人のお気持ちであって、pyproject.tomlとbuild script以外にPythonを書くツールも出てきており、pyproject.toml以外の選択肢がパッケージングという観点以外のlinterやapi config、その他設定を起因に出てきた時移行できるよう、ロックインを避けるようにしていくのがベターだろう。

PythonがC/C++のwrapperとして多くの機能を持っている事も加味すれば、今後もbuild scriptは必須になるだろうし、元来、パッケージ管理ツールといった代物はプロダクトコードとは別のレイヤーに居るのだから、あとはプロジェクトのサイズ感や運用状況と相談し、ベストプラクティス等と言わず、そういったツールに固執せず、粛々と運用し、適切に時期をみてツールを変更していくだけという話である。

　
何より私はPyPAのコアメンバーでもなければ、パッケージ管理ツールの主要なコミッターでもないので、大きく発言する資格はないし、donate.pypi.orgやNumFORCUSを支援するか、issueやcommitやコメントを重ねるか、自分で理想のパッケージを作るかをやっていかないといけない。それがソフトウェアエンジニアとしての常である。頑張りましょう。

　
かなり長くなってしまったので、整合性が取れていなかったり誤認に基づく間違いがあるかもしれない。
できれば、Twitterかはてブに書いて頂ければ幸いです。
ちゃんと議論したい場合は、文中の通り適切な場所にどうぞ。


// -- 2021/03/29　追記 --

GitHubがpackage registoryに成り得るサービスを展開していて、Pythonもfuture workに入っている。ここにindexされ、常用が始まるのを機に後方互換が一気に変わって、依存解決が超簡単になって、管理もGitHubないしMSがやってくれるというコースもワンチャンあると思っている。その場合、ユーザが利用するツールがどう転ぶかは未知数だ。などとGitHub Packagesが出てから思い続けて、future workになって2年経つので、いつになるかはよくわからない。一応future workになった時点で2021年の3月以降とされているから、今後なにかある可能性は高い。

　

- 参考文献 -


脚注や文章内リンク外で参考にしたもの・本記事を理解する上で読むと良いもの

f:id:vaaaaaanquish:20210329011401p:plain:w0

*1:サードパーティのPythonモジュールがアップロードされているリポジトリ

*2:統一的でない事に対する悪い意味合いではなく目的に応じてツールが分離されたエコシステムであるという意

*3:pip install -r pyproject.toml出来ないよねといった議論はあるがsetuptoolsと共に徐々に対応されていくだろう https://github.com/pypa/pip/issues/8049

*4:PyPAが出すチュートリアルにはsetup.pyやsetup.cfgも適切に使えとは書いてある https://packaging.python.org/tutorials/packaging-projects

*5:何かを入れた後にサブモジュールをインストールしなおすと治るといった現象にPythonユーザであれば当たった事があるはず

*6:充足可能性問題 - Wikipedia

*7:バックトラッキング - Wikipedia

*8:私は高専時代Knuth先生のThe Art of Computer Programmingで挫折したことがあり教科書的と言える知識量ではないかもしれない…

*9:Dart開発者向けのドキュメントはここ pub/solver.md at master · dart-lang/pub · GitHub

*10:のように私は見える

*11:Unit propagation - Wikipedia

*12:poetryが採用している

*13:Chan Zuckerberg Initiative - マーク・ザッカーバーグと妻のPriscillaChanが持つ投資会社

*14:言わずもがなfirefox作ってる会社

*15:今はまだ--use-deprecated=legacy-resolverで古いリゾルバを利用できる

*16:自系列的にはpipenvの方が先に依存解決をはじめている

*17:主たる形であってPyPAは他の方法を否定はしていない

*18:Anaconda Cloudやその他のリポジトリが存在するがここでは総称する

*19:より具体的にはwheelを選んでくれる

*20:もちろんenv毎に容量が節約される等のメリットもある

*21:poetryでも議論されておりメンテナも好意的 PEP 582 support · Issue #3691 · python-poetry/poetry · GitHub

*22:乱立しているだろうという観点はさておき

*23:私も手前xonshのxontrib等はpoetry化できないし、逆にsetup.pyのメンテを引き剥がす作業も行っている

*24:「他に適切な表現があるため」としており間違った行為ではない

*25:依存解決とは別の意味でセキュリティ関連の解説が必要なため、どうしても誤解を招かず書くことが難しかったので後述する形となった

*26:A~Zで偉人の名前でプロジェクトを管理していたが、今は一周し花の名前で2週目になっている

Rustで扱える機械学習関連のクレート2021

Rust 機械学習 自然言語処理 画像認識 WebAssenbly

- はじめに -

本記事では、Rustで扱える機械学習関連クレートをまとめる。

普段Pythonで機械学習プロジェクトを遂行する人がRustに移行する事を想定して書くメモ書きになるが、もしかすると長らくRustでMLをやっていた人と視点の違いがあるかもしれない。


追記：2021/02/24

repositoryにしました。こちらを随時更新します
github.com


追記；2021/07/26

GitHub Pagesでウェブサイトにしました
vaaaaanquish.github.io

- 全体感 -

Rustで書かれた（もしくはwrapされた）クレートは、かなり充実しつつある段階。

特に流行しているNeural NetworkないしDeep Learning関連のクレートは更新が盛んである。TensorFlowやPyTorchのRust bindingsもあれば、ゼロからRustで全て書こうというプロジェクトもある。

Numpy、Pandasを目指すプロジェクトも既に存在しているし、元々C/C++で書かれているライブラリであれば、rust-bindgenを使ってRust bindingを簡単に作れるようになってきている。
GitHub - rust-lang/rust-bindgen: Automatically generates Rust FFI bindings to C (and some C++) libraries.

古典的な画像処理やテキスト処理（例えばshift特徴量が欲しいだとかTF-IDFを計算したいだとか）で色々と物足りないクレートを使うことになる場合もありそうだが、画像はimage-rsという大きなクレートが存在し入出力を握っているし、形態素解析器などのクレートも多いので、アルゴリズム部分を自分でガッと書けば良いだけであると言えそう。
　
　

「物足りないクレート」と言ったが、2016~2018年から更新のないクレート、C++ライブラリのリンクが上手くいっていないクレート、Cargo.tomlだけのクレート(crates.ioにアップロードされ名前空間汚染になっている)などがあるという話で、その辺りを踏まえるとまだ（Pythonに比べたら）とっつきにくさがある。

Pythonであれば様々な機械学習モデルへの入力の多くをNumpyを使った行列で記述するが、Rustでの同等のプロジェクトではndarrayがあるものの安定し始めたのはちょうど1年前くらいからで、クレートによって入出力がrustのvectorだったりndarrayだったり、また別のnalgebraというクレートを使っている場合もあるといった状態である。

あとは機械学習の実験時に必要な物事をどうするかという問題も殆ど定まっていない。パラメータ管理はJSONを使うのか、設定時はRustらしくメソッドチェーンを使うのか、どう結果を保存するのか、パイプラインを作っていけるのか、など解決していない（デファクトスタンダードが定まっていない）課題は山積みである。

まあでも似たような問題はJulia langが流行り始めた頃にもあったように記憶していて、参入者が多くなるにつれて、自然とデファクトスタンダードは決まっていくだろう、と感じている。


ここでは、個人的にこれが残っていくんじゃないかと考えているものを優先的に書く。

　

- 機械学習足回り関連のクレート -

jupyterとかnumpy、pandasとか画像、テキスト処理などの機械学習前処理関連のもの
　

Jupyter Notebook

Pythonで機械学習関連の物を作る人の多くがJupyterを使っているだろう（と思っている）。googleプロジェクトの配下にあるEvcxrが便利。
github.com
Notebookカーネル、REPLがあるので、普段Rustの小さな挙動を確認したい時はこれを起動するかシェルから叩いている。私としてはかなり開発速度が上がったツールの1つ。

類似のものとしてはrustdefとかを見てみたが、Evcxrの方が使い勝手がPythonカーネルに近い。


matplotlibやseabornとまではいかないが、vectorであればグラフ描画にplottersのjupyter-integrationが使いやすいなと思って入れてはいるものの、データ分析、EDAにおいてはやはり型にうるさくないPythonがやりやすいので結局Pythonカーネルを起動してる。
GitHub - 38/plotters: A rust drawing library for high quality data plotting for both WASM and native, statically and realtimely 🦀 📈🚀

plotlyのRust bindingsもあって、Pythonくらい柔軟になればあるいはとも思っている。EvcxrをSupportしたのが6ヶ月前にReleaseされた0.6.0（現行最新バージョン）であるのでこれからという感じ。
GitHub - igiagkiozis/plotly: Plotly for Rust

　

Numpy/Scipy

ndarrayというクレートとnalgebraというクレートが2大巨頭で争っている。
redditの議論: ndarray vs nalgebra : rust

解決したい課題がnalgebraは線形代数特化な様相もあって、Pythonのように動的によしなに行列をスライスしたり変形させる機構ではなく、コンパイル時に行列の大きさを推定しメモリを確保してそこを使う実装になっている。ピュアRustという事もあるし、ndarrayのような柔軟さが欲しい場合はRustを使う意義があまりないと私は思っている。機械学習で扱う行列演算で曖昧な処理をしてバグを生むことも多いので、機械学習で使う側面から見てもnalgebraが幅をきかせていくと思っているがndarrayという名前に勝てず皆使っているのはndarrayという感じ。

github.com
github.com


(ちなみに私が作っているライブラリでは決めかねてvec![]を使っているごめんなさい)

Pandas

polars一択だと思う。polarsはpythonバインディングもあり、pandasより早い事を謳うライブラリの1つでもある。
github.com
applyやgroupby、aggを使う限りでは、殆どpandasと遜色なく扱える。

参考になる: Rustのデータフレームcrateのpolarsとpandasの比較
　

Queryを扱うという点ではarrowを使う事でデータの処理が行えるが、オンメモリでpythonのDataframeのようにとは少し違ってくる。
https://github.com/apache/arrow/tree/master/rustgithub.com


他にblack-jackというめっちゃかっこいい名前のクレートやrust-dataframe、utahといったpandasを意識したクレートがあるが、開発は滞っている。
　

画像処理

image-rs配下のプロジェクトが一番の選択肢になると思う。
github.com
ImageBufferがfrom_vec, to_vecを持っているのでvectorとのやり取りも難しくない。特徴量抽出など、少し複雑な処理を行う場合はimageprocに実装されていってる感じなので、こちらを見ていくと良さそう。
GitHub - image-rs/imageproc: Image processing operations
　

前述のnalgebraを使う前提であれば、cgmathでGPU、SIMD最適化などのオプションを付けて多くの線形な処理が行えるので、画像処理のみを目的にするならこちらも選択肢に入る。
github.com
近年の画像処理 * 機械学習観点だとここまで必要になる事は、そう多くはないのかなと思ったりもする。リゾルバを書いて何か解決したい場合とかだろうか。
　

次点でopencv-rsustというクレートがあるのだが、私は結局opencvへのリンクを上手くやってbuildして動かした所で力尽きて終わってしまった。OpenCVインストールバトルやcv::Matの扱いに慣れている場合は選択肢に入るかもしれない。ndarray-imageというndarrayで扱おうというrust-cvなるプロジェクトもあるが、開発が盛んとは言えない（AkazeやBrute forceみたいな古典的な画像処理アルゴリズムを熱心に実装しているのはrust-cv）。

形態素解析/tokenize

lindera になりそう。
github.com
mecabやneologdのような既存の資産も扱えるし、ピュアRustである点も含めて扱いやすい

linderaメンテナのブログ：Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみた - Qiita
私も過去に使ったブログを書きサンプル実装を公開している：Rustによるlindera、neologd、fasttext、XGBoostを用いたテキスト分類 - Stimulator

その他には、sudachi.rs や yoin 、 awabi のような実装もあるがメンテは止まっている様子である。

　
英語のTokenzeであればPythonでもおなじみのhuggingfaceのtokenizersがRust実装なのでそのまま扱う事ができる。
github.com

　

- scikit-learn的なやつ -

scikit-learnみたいに色んなアルゴリズムが入ったクレートは有象無象にある。
大体どれも以下のアルゴリズムはサポートしている。

  • Linear Regression
  • Logistic Regression
  • K-Means Clustering
  • Neural Networks
  • Gaussian Process Regression
  • Support Vector Machines
  • Gaussian Mixture Models
  • Naive Bayes Classifiers
  • DBSCAN
  • k-Nearest Neighbor Classifiers
  • Principal Component Analysis
  • Decision Tree
  • Support Vector Machines
  • Naive Bayes
  • Elastic Net

各ライブラリと特徴比較

流石に全部使って見るという事ができていない上に、更新が止まっているものも多いので、最終commit日と一緒にリストアップする

  • rusty-machine (Star: 1.1k, updated: 2020/2/15)
    • 一番よく記事等を見るやつ。最終更新は1年前だが、アルゴリズムよりsrc/analysis配下のConfusion Matrix、Cross Varidation、Accuracy、F1 Score、MSEの実装が参考になるのでよく見に行く。iris等簡易データセットの読み込みもあるがデータだけなら下記のlinfa datasetが良いと思う。
    • Generalized Linear Modelを広くサポートしているのはちょっと特徴的
  • linfra (Star: 658, updated: 2021/1/21)
    • InterfaceもPythonっぽいし、完全にsklearn意識で開発も盛りあがっていてSponsorもいる。特にsklearnと違って各アルゴリズム毎にクレート化されてるのが嬉しい。
    • 上記以外にGaussian Mixture Model ClusteringやAgglomerative Hierarchical Clustering、Elastic Net、ICAをサポートしている
  • SmartCore (Star: 66, updated: 2021/1/22)
  • rustlearn (Star: 470, updated: 2020/6/21)
    • 古いライブラリだがPure Rustでinterfaceもわかりやすいので実装が参考になる
    • レコメンドでよく使うfactorization machinesや多くのmetric、k-fold cross-validation、shuffle splitのようにかなりピンポイントで重要なアルゴリズムを採用している

sckit-learnの立ち位置になっていきそうなのは、Sponsorもついているlinfaか開発者の勢いがあるsmartcoreというイメージ。
github.com
github.com

　

- Gradient Boosting -

主に使われているXGBoost、LightGBM、CatboostにRust bindingsが存在するが、現状modelのtrainまで出来るのはXGBoostとLightGBMのみ。

XGBoost

公式のXGBoostのC++実装をbindgenでbuildしてwrapした実装がある。
github.com
wrapperなので、PythonのXGBoostと同じイメージで使える。開発はほぼ止まっていて、submoduleとして使っているXGBoostのバージョンが少し古かったり、GPU等のSupportがないのがネックではある。

XGBoostで学習したデータを読み込んで推論できる、gbtree実装を使うという手もあるが、まだ上記のwrapperの方がとっつきやすいとは思う。
github.com
　

LightGBM

手前味噌ではあるが私がwrapperを書いている。上記のXGBoostと同様、C++実装をcmakeしてbindgenでbuildしてwrapしたもの。
github.com

parameter configをserde_jsonにしていたり入出力がvectorだったりして本当にこれで良いのか議論したいし、まだサポートしていないc_apiやWindowsやGPUを作る必要もあるので皆さんのcommitを待っている。

　

CatBoost

Catboostは公式に「一応」Rust bindingsが入っている。
以下のPRを見ての通り、適当なレビューはされておらずドキュメントはない…。
github.com
実装も怪しいが、私が手元で動かしてみた所、ライブラリへのリンクが上手く通っておらずそもそも動かなかった。

XGBoostやLightGBMと同様の方法でbindingsを作れば良いという話でもあるのだが、厄介な所として、Makefileではなくyandexの社内のモノリスで動いていたyamakeというビルドシステムを使ってビルドしている（普通にbuildすると謎のバイナリをダウンロードしてきて動かされる）。
それはやめようよというissueが立ち、catboost/makeディレクトリにMakefileが用意されるようになったが、このMakefileもyandex社内のArcadiaというシステムがジェネレートしたものでかなりヤンチャ（OSごとにファイルが分かれているにも関わらずドキュメントがそれに追い付いてなかったりもする）。
Ya script sources · Issue #131 · catboost/catboost · GitHub

masterが動かなかったのでコードを読む限りだが、現状は学習済みのバイナリを読み込んでpredictする形式しかサポートしていない。これはtrain周りのc_apiがwrapされていないからで、その部分を自前で書く必要もある。

一応私はここ最近Makefileとbuild.rsを作ることに挑戦していて、とりあえずmakeが通ってlibcatboostが生成される所まで来たが、心が折れるかもしれない（折れそうだったのでこの記事を書いて気を紛らわせている）。

　

- Deep Neaural Network -


現状はPytorch、TensorFlowの公式bindingsの2強の状態と言える。

系譜を以下の記事から引用する。

私の知る限りではRust界隈のディープラーニングのフレームワーク事情は以下のとおりです。

primitiv-rustでディープラーニングする - Qiita

この記事で紹介されているprimitiv-rustやdynet-rsも更新は止まっている。

Tensorflow/PyTorch

公式Bindingsが使える。

github.com

github.com

私はTensorFlow 2.xやKerasが入ってAPIがもう追えなくなったのでPyTorchを使ってるが、tch-rsは不満なく使えている。pretrained modelによる学習もすぐ始められるし、後述するようなBERT、Transformerの実装もあるのでほとんどPythonと遜色ない。GPUにも載る（私は試せていないが）らしい。
　

BERT

最近Transformerの実装の参考に触り始めたtch-rsをベースにしたrust-bertというクレートがあり、難しくなく扱える。
github.com

日本語のPretrainモデルをコンバートしてくる必要があるので、そこが少し面倒だが、みんな大好きHugging Faceのライブラリ群がかなり巻き取ってくれているので、Pythonで書いている時とあまり変わらない印象。
　

- Natural Language Processing -

TF-IDF

ほとんど簡易な実装だが、下記がある。
github.com

sckit-learnのようにTF-IDF Vectorizerみたいな使い方は、issueを見る限りあまりサポートされなさそうなので、その場合は自前で書けば良さそう。

fasttext

公式のFastTextの実装をbindgenでbuildしてwrapしたものがある。

github.com

私も過去に使ったブログを書きサンプル実装を公開している：Rustによるlindera、neologd、fasttext、XGBoostを用いたテキスト分類 - Stimulator
開発としては止まっていて、submoduleとして使っているFastTextのバージョンが遅れているのがネック。
　

- Recommendation -

Collaborative Filtering/Matrix Factorization

協調フィルタリングで多分一番実装がまともなものがquackinになる。もう4年更新がないが、実装自体がシンプルなのでフォークすれば良さそう。
github.com

他にもrecommenderが一応クレートとして見られるけど、ここまでなら自前で作っても良い。
より古典的なVowpalWabbitのRustバインディングも選択肢に入る。
github.com

　

Matrix Factorizationであれば、先述のrustlearnを使うのが良さそう。

non negative matrix factorizationの実装のクレートがあるが、試してみた所精度が出なかったので難しいところ。
GitHub - snd/onmf: fast rust implementation of online nonnegative matrix factorization as laid out in the paper "detect and track latent factors with online nonnegative matrix factorization"

- Information Retrieval -

Full Text Search

Apache Solr入門や先の形態素解析のLinderaをメンテしているMinoru OSUKA(@mosuka)さんが作っているgRPCで通信して検索するbayardが全文検索エンジンとしての出来が良い。
github.com
（というよりまともに動くのはこれくらいな気がする）

作者の解説記事：Rust初心者がRustで全文検索サーバを作ってみた - Qiita
初心者が形態素解析器と全文検索エンジンを作っている。謎。
　

フロントでは、WebAssemblyでメモリ効率良く設計されたTinysearchがかなり気になる（使えていない）
github.com
フロントエンド側で検索できて、gzipにすると51KBしかないとか。
公式のブログがかなり参考になる：A Tiny, Static, Full-Text Search Engine using Rust and WebAssembly | Matthias Endler
作者はTrivagoの検索のバックエンドを作っている人らしい。

WebAssemblyでフロントで検索するのは熱く、StripeのengineerからもRustでwasmを介したStrokが出てる。
github.com
　

より一般的なものであれば、Elasticsearchが公式のクライアントとしてElasticsearch-rsを出しているので、裏側にESが既に立っているとかならこれで良さそう。
GitHub - elastic/elasticsearch-rs: Official Elasticsearch Rust Client

　

近傍探索ではFaissのc_apiをwrapしたRust bindingsがある。使い勝手はほぼPythonと同じ。

github.com

他の選択肢としては、HNSWやHNSW graphsをベースにしたgranneがあるので要検討。Pure Rustな所がかなり嬉しいと思う。
github.com

github.com

もうちょっと古典的なものだとVP木をつかったvpsearchがある。kd-treeの実装もあるのでkd-tree版も作れなくはなさそう。

- Reinforcement Learning -

強化学習であれば、rurelというクレートがあるが、流石に私も触りきれていない。
github.com

gymのRust bindings作ってる人もいる。すごい。まだ触れてないけど使えるかも。
github.com

　

おわりに

結局の所「wrapするだけならPython（ないしCython）が便利じゃない？」という所とどう折り合いつけるのかというのはある。

ただ、分散処理するほどではない大規模データ、型のないPythonでは扱いの難しいデータ、wasmによるフロントエンドでの高速処理など、今まで機械学習の社会実装で苦労していたニッチな所に刺さると思うので良いとも思う。
　

他にもこれオススメだよってやつあったら触りに行くので、はてブかツイートしてください。

　f:id:vaaaaaanquish:20210123234057p:plain:w0

【参考】

crates.ioでMachine Learning等で調べた。


　

3ヶ月くらいフロントエンドやったのでやったこと一旦まとめ

Node.js Web開発 雑記

- はじめに -

9月くらいから趣味でフロントエンド周りをやっていたので、その勉強過程のまとめ。

何が良かった悪かったとか、こうすればよかったとか、所感とか。

　

- 前提 -

前提として9月頭くらいの私のフロントエンドに対する理解と技術的な知識はこんな感じ。

これくらいのレベルからこうやって学んでいったぞという記録になる。


　

- どんな感じで進めたか -

4つWebアプリを作った。3つは友人の手伝い、1つは以下のWebAssenblyを組み合わせたWebアプリで、これは1人で作成した。

vaaaaaanquish.hatenablog.com


　　

最初の開発

最初、ElasticSearchを使ったデータ検索系のサービスを趣味開発チームのメンバーが作ろうとしていたので、並び替えやランキングに機械学習が必要だろうという事でバックエンドのElasticCloudや機械学習モデル作成を手伝った。その過程で検索フォームやサジェストが必要になって既存のReact部分を触らせてもらった。

この時は、そもそもComponentという概念が全く理解できておらず、なんかclass作ってStateとPropsでやり取りするらしいくらいの感じでコードを書いていた。友人にFluxかReduxを使ってと言われたので、オススメの本を聞いたら「本でもブログでもなく公式のチュートリアルを見てやれ」「本ならとにかく新しい本を買え」との事だった。

今にして思えば、このアドバイスは神だった。

　
最初はこれを2日程かけてやった。
ja.reactjs.org
react-redux.js.org
React Devtoolsが便利だとか、Reduxが何故必要なのかがよく分かった。
他のブログ記事の野良チュートリアル的なのも見たは見たけど、公式が最新のバージョンでコードを上からコピペしていけば動くのでどこよりも良い。アドバイス通りだ、当たり前だけど。

　
非同期処理なんかもjQueryで適当に書いていた頃とは勝手が違っていて苦労したが、何故かTwitterで回答が得れたりした。


mizchiさんただのOSSタダ乗りおじさんだと思ってたごめんね。

　
頭のおかしい友人は「前時代から入ってきた人はまずはこれでしょ」と言ってAtomic Designを薦めて来たが、この時はマジでよく分からなかった。
atomicdesign.bradfrost.com

後述するが、後々にWebアプリ2,3個作った辺りで「あーなるほど」と思う事があった。


実際に作ってみてから読むと、良いコンポーネント設計が出来るようになる感じはするので時間が空いたら、開発手法を学ぶ的な意味合いでAtomic Designはオススメできる。本家が難しければググれば解釈がいくつか出てくるのでそちらでも。

　
その辺りで、もうちょっと体系的に学べないかと思って調べて、アドバイス通り「新しめの本」ということで以下を読んでみたが、これもなかなか良かった。

フロントエンド開発入門 プロフェッショナルな開発ツールと設計・実装

フロントエンド開発入門 プロフェッショナルな開発ツールと設計・実装

Web上のチュートリアルと違って動かせるコードは少ないが、Vue、Angular、Reactの違いとか、何となく書いていたBabel、webpackが何をやっているか、ReduxやFulxがなぜ必要かが体系的に書いてあって、本当に助かった。後半ユニットテストや実際のサービス開発フロー、Sentryやスクラムの話が出てくるがあまり読めてないのでまた読みたい。

これ読んだ辺りから、Qiitaやはてな、Zennで流れてくるフロントエンドエンジニアの間で話題の記事をかなり難なく読めるようになったので、チュートリアルとこの本は結構効いた。


　
理解できてきて記事のシェアが増えてきた

他にもこの辺りでのReduxとの出会い、TypeScriptの学びは大きかった。

Reduxの機構を見た時、「本当にこんな壮大な仕組み必要か？」と思ったが、実際使ってみると簡単で便利だった。後にReact Hooksで多くの機能が代替できる事を知って移行していったが、状態というものが何なのか意識できるようになったのはRedux使った後からだったように思う。最初からHooksでも良い部分が多いけど、Componentやnode.js周りの開発がどれだけ良いか体験できるのも良い。例えばFluxなプロジェクトをReduxに書き換える、Hooksに書き換えることを経験したが、状態管理が1ライブラリで切り離されているので、移行の労力がかなり小さかった。これがいわゆる近年のnode.js開発の良さの1つなのだろう。

TypeScriptへの移行もやった。この辺りにもnode.js開発プラクティスの恩恵があるんだなと感じる体験で、Componentで分かれているのでComponentごとに1つ1つ変えていけば良いし、何よりTypes書けば推論してくれる便利さ、ビルド時のチェック、エディタの補完の進歩が最高だった。以下の本も読んだら良かった。

実践TypeScript

実践TypeScript

フォロワーが書いてるからと思って読んだが、この書籍でNext.jsと組み合わせた時の強力さも知れた。書いてある内容がちょっと古いけど、筆者が追加で最新分に対応した解説しているのでこちらも見ると良い。
Nuxt.js TypeScript - 実践TypeScript アップデート - - Qiita


　
最初のアプリの小話だが、友人はElasticCloudのオススメ設定みたいなので進めていて全盛りプランでお金掛かりまくる感じになっていてヤバと思った。流石フルマネージド。結局まるっと構成を変えてインデックスも機械学習モデル入れやすいように貼り直したりして大変だった。


　　

TypeScriptとNext.jsを使った開発

次のWebサービスも辞書のようなサービスを手伝う形だったが、途中まで書かれたサンプルがwebpackだけ使ったCSRだったので「いやこれTwitterでシェアされたりすること考えるとSSR必要じゃないか」という話になってNext.jsをやった。

Google検索やTwitterに出たかったらSSRだNextをやれと最初に知りたかった気もちょっとした。

　
この辺りまでwebpack.config.jsをダラダラ書きまくっていたが、どうやらNext.jsではpackage.json、tsconfig.json（あるいは.babelrc）の簡易なフォーマットを書けば良く、ルーティングもディレクトリ、ファイル名でよしなにできる。Routerの分岐をコツコツ書かなくて良い（すごい）。静的なファイルの配信もクライアントサイドのレンダリングも簡単で、ほとんど何も考えずComponentを書いていけば開発できる事がわかった。すごい。

（最初はなんでGoogleクローラやTwitterのOGPなんかのために頭良い人達がSSRだの何とかRだのに振り回されてんのと思った正直）

　
これも出来るだけ公式のチュートリアルをなぞった方が良い。
nextjs.org

野良のやってみた、ベストプラクティスみたいな記事は半年以内くらいじゃないと若干古かったりDeprecatedだったりする。


コンポーネントやライブラリの使い方がちょっと違うくらいならいいが、特にディレクトリ構成が変わる系（publicとかsrcとか）は後から変更するのが大変な場合もあるのでちゃんと最新バージョンの情報を見たほうが良い（大変だった）。


この辺りでMaterial-UI: A popular React UI frameworkとかのドキュメントをひたすら上から試したり、About splash-screens - AppscopeやFavicon Generator for perfect icons on all browsersでfaviconやスマフォ向けの画像作ったり、Google Analytics、OGPなんかを一通りやった。

f:id:vaaaaaanquish:20201227210125p:plain:w500
material-uiのドキュメント全部読んだ時の

Tailwind CSSやSemantic UIも比較のために触った（Web上の記事も読んだがあんまり良い悪いの比較が理解出来ずmaterial-uiで良いんじゃないという気がするが理解が足りていない気もする）。


　

アプリ手伝いから自分のアプリ開発まで

3つ目はNuxt.jsなアプリをちょっとだけ手伝った。あんまりNextとやってる事は変わらないと感じたけど、逆に変わらないのがすごいなと思った。外枠変わっても書いてるTypeScriptのコード変わらないのすごい。まあでもつまりNext.jsとTypeScriptができれば結構いろんな事に対応できそうだという事もここでわかった。

　
この辺りで、WebAssenbly nightというイベントを聴講して、「あ、こりゃ面白いな」と思って自分のサービス作ってみようとなった。
emsn.connpass.com

　
Rustで機械学習がどれくらいできるか試して
vaaaaaanquish.hatenablog.com
その機能がwasm-packやEmscriptenでバイナリにしてNext.jsで配信できるか試して


できてた


前のブログに書いた通り、wasm周りは結構大変だったが、技術的に面白いものが何だかんだで1万人強に使ってもらえていて、楽しい気持ちになった。


この辺りは本心で、かなり大変な上に「機械学習エンジニアにとってwasmでサービス展開したいモチベーションが薄いので量子化やホスティングまでを考える人が少なくPythonやAPIがソリューションになる」「逆にフロントエンドエンジニアやバックエンドエンジニアが機械学習モデルの量子化をやるのかと言うとそれはそれでとなる」という状況で、一部のエンジニアを除いて多く人にとってはちょっとしんどい気もした。

こういうWebサービスやりたいよという会社があったら呼んで下さい。

　
御託はさておき、GAEやFirebaseであまり考えずにNext.jsでWebサービス展開ができるようになった。


　

- できてないこと -

趣味で3ヶ月やってみたものの、まだ出来てない事、分かってない事がいくつかある。

  • ツールチェインのベストプラクティス

先に挙げた「Material UI、Tailwind CSS、Semantic UI」もそうだし、「Express、Parcel、Deno、Gatsby...ないし任意の技術は良いぞ」というのが飛び交っていてまだまだ試す事が多い

  • Babelが何をやってるか

これ結構わからない人多いと思うけど私だけなのかな。使い方は出てくるけど、ES構文とは何なのかとかを知らないと把握できなさそうだなと思う。
こういう所が、こんなツイートにも繋がっている。

これマジでわからん。ESLintどの粒度で書くのが正解なのか、気付いたらNext.js含む回帰テストみたいになってしまう。これを読めみたいなやつないのかな。

わからん。デザインツールから出てきたscssを適応するのも、既存のCSSを改修するのも1日以上かかったし、css-loaderやscss-loaderがCSS Moduleになったからなんぼのもんじゃいって気持ち。PostCSSになっても適切にdisplayやpositionを適切に一発で設定できたことなし。これを使えみたいなやつないのかな。

  • パフォーマンス最適化

この書き方がどういう理由でパフォーマンスが良い、高速であるというのをあまり把握できていない。これを読めみたいなやつないのかな。

  • 複数人での継続的な開発

アトミックデザインなりのnode.jsなり良いところはこの辺にあるんだろうと体感していて、複数人が手を入れても、モジュールのバージョンアップデートも変更もこりゃやりやすいだろうと思うんだけど如何せん仕事じゃないので機会が訪れなさそう。


　

- 所感 -

たしかにnode.js開発しやすい。jQueryをゴリゴリ書いていた時を思うと、Releaseまでの速度も改修のしやすさも、他人のコードの読みやすさも段違いに良い。Railsとの比較が近年多いけど、私はまだRails書きまくってるわけじゃないから何か機能の比較は難しい。それでも大きなフレームワークとは違った、色んな開発の概念を学べてよかったので色んな人がやると良いと思う。

情報の古さみたいなのがヤバいので公式を見に行く精神を忘れるとしんどい。ライブラリの開発がやりやすいこと、早いことが起因しているのだろうけど、ついていけている開発者も少ないのではとちょっと思った。

自分の作ったサービスが使われるのを見るのは楽しい。
機械学習エンジニアの悩みどころの1つに「小さいサービスではやることがない問題」というのがあって、最初から機械学習を前提としていたりしない限り、データやユーザが小さかったり需要がないために（概ね習熟した問題に対して改善フェーズじゃなければ）機械学習モデリングは実は簡単に終わってしまって分析屋かPdMになっていくという事象はよくあるのだが、私は開発に比べたらあんまりという気持ちなので、もうちょっと開発の範囲を広げる方向で何か考えていた。バックエンドやフロントエンドをやってみるのは楽しかったので今後も継続したい。

Rustも書けるWebサービスのアイデアもっと出したい。


　

- おわりに -

あんまりこういうまとめ書く気はなかったけど、最近「初心者のうちに初心者な記事を書かないと、初心者の読者と乖離した記事しか書けない」みたいなツイートを見て「それもそうだ」と思ったので書いてみた（元ツイート見つけられなかったごめんなさい）。


結構楽しかったので普段フロントエンド触ってない皆さんも年末のお供にどうぞ。



　

- 追記 -

2020/12/28　

分からなかった事が分かりそうなgistが作られてました。

めちゃくちゃありがたい。やっていきます。
　

WebAssemblyで機械学習Webアプリ「俺か俺以外か」をつくった

機械学習 自然言語処理 Web開発 WebAssenbly Rust Node.js JavaScript Twitter

- はじめに -

文章がローランド(@roland_0fficial)様っぽいか判定するサービスをつくった。

学習済みモデルをダウンロードし、WebAssemblyで形態素解析、機械学習モデルによる判定を全てブラウザ上で処理する。

この記事は、そこに至るまでメモ。

- 技術的な概要 -

何が面白いのか簡易図

f:id:vaaaaaanquish:20201226031341p:plain:w500
なんか適当な図

学習済みの機械学習モデルをダウンロードして、手元のブラウザ上で動くjavascriptだけで、テキストの処理や判定をするというもの。WebAssembly(以下wasm)自体はまだ出始めの技術ではあるものの、面白い試みが近年増えて来ているので興味もあって作った。

- データの収集 -

我らがローランド様のTwitter、Instagramのテキスト部分をクロールした。

twitter.com
https://www.instagram.com/roland_0fficial

思ったよりツイートしていなかったので、ローランド名言bot、名言集のようなものを探したり、著書から文章を集めて、4106件のローランド様の語録データを作成した。

ローランド様以外のデータは、偶然ダジャレを判定する - Stimulatorで収集した1916747件のツイートデータが手元にあったので、そちらからサンプリングして不正解のデータとした。

　

- 技術的な構成 -

使ったものを端的に挙げていく。


形態素解析や機械学習モデルに関しては、以下の記事に書いたものを利用した。

vaaaaaanquish.hatenablog.com

以下repo内にrust製の形態素解析器であるlinderaをwasm-packでwasmに変換し、webpack、Next.jsを経由して動かすExampleを公開しているのですぐ再現できるはず。

github.com


自然言語のベクトル化は、上の記事内でもサーベイした通りPyTorchなどを使う幾つかの方法があるが、再現実装が伴ったものが少なかったので、大人しくFastTextを利用した。判定のコアとなる機械学習モデルの部分はXGBoostやLightGBMなど概ねのモデルがC++で書かれているので、Emscriptenでwasmに変換して利用した。これらの詳細は後述する。

フロントはNext.js、ホスティングにGAE、モデルファイルの配信にGCSを利用した。以下のような構成になった。

f:id:vaaaaaanquish:20201226035644p:plain:w500
構成図

最初S3だけで機械学習Webサービスホスティングと銘打って楽しんだりFierbaseを使って遊んでいたが、不便さと通信量に対する料金が怖くなってこの構成になった。

- モデル周りの話 -

FastTextが0.9.2からWebAssenblyのbindingを配信している。

fasttext.cc

元よりFASTTEXT.ZIPの論文*1などモデルの圧縮を頑張ってたのは知っていたのもあって、ちょうど良く試そうとなった。

FastText含むモデルのC++コードをwasmにするにあたっては、Emscriptenを使う。

github.com

普通にgcc、g++やclangのバージョン、リンクなどハマり所があるので、素直に公式のDockerを使うと良い（ハマった）。

$ docker pull emscripten/emsdk
$ docker run -it emscripten/emsdk bash
$ em++ --version
emcc (Emscripten gcc/clang-like replacement) 2.0.11 (6e28e4fa4fa1bc50d58b9ddbbb9603a3cf21ea9e)
Copyright (C) 2014 the Emscripten authors (see AUTHORS.txt)
This is free and open source software under the MIT license.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

基本的にはC++のMakefileをそのまま追記してgccをemmに変更し、利用したい関数をEXPORTED_FUNCTIONSに入れてbuildすれば動く。最も参考になるFastTextのEmscriptenのbuild用のMakefileがかなり参考になる。一方masterのMakefileじゃ動かない*2ので、Emscriptenのバージョンを下げてbuildする必要もある。

　
実際にwasmができても単純にwasm-loaderとwebpackを介するとロードできなかった。

github.com

これは、Emscriptenがwasmとのグルーコードとして吐き出すjsがかなりヤンチャな事と関係している。hoge_wasm.js内のimport.meta.urlをdirnameに書き換えた*3上でhoge_wasm.wasmへのpathを書き換え、hoge_wasm.wasmをNext.jsの静的配信に切り替えた。その上でグルーコードをまるっと書き換えてDynamic Importで読み込めるように書き換えた（別途公開します）。

LightGBMのバイナリもPython bindingで学習したものをwasmから読み込もうとした際に、全ての結果が0になる謎の現象に当たったので、一旦C++でtrainスクリプトを動かしてloadすると上手くいった。学習中にLGBMのコード読んだがこれはイマイチ原因がわからなかった（LGBMのissueに唯一あるwasm関連のissueも「wasm対応出来てるか知らんけどcloseで」となっているので誰も分からない説がある*4）。

　
最初、全てのモデルファイルを合計して雑なフロントから読み出してみると、1266MBをロードしていた。犯罪級だ。

FastTextに量子化の機能が付いているのは事前にF&Qで見ていたので、それを試した。
FAQ · fastText

How can I reduce the size of my fastText models?
fastText uses a hashtable for either word or character ngrams. The size of the hashtable directly impacts the size of a model. To reduce the size of the model, it is possible to reduce the size of this table with the option '-hash'. For example a good value is 20000. Another option that greatly impacts the size of a model is the size of the vectors (-dim). This dimension can be reduced to save space but this can significantly impact performance. If that still produce a model that is too big, one can further reduce the size of a trained model with the quantization option.

元の論文と照らし合わせながら、パラメータを変更して何度かtestしてみて、精度が落ちなさそうな所で以下に落ち着いた。

./fasttext supervised -input ../train_ft.csv -output ft_min -bucket 40000 -epoch 25 -wordNgrams 2 -cutoff 10000 -retrain -qnorm -qout

gbdtもpruningやcompressingみたいな単語でググれば何か先行事例あるだろと思って探して、ちらほらあるものの、目ぼしい物を見つけられなかった。「Lossless (and Lossy) Compression of Random Forests*5」みたく、最小の表現モデルを探したり寄与の低い枝を切ったり面白い分野だと思うが、まあでも今はDNNとかの方が圧縮できるしあまりという感じなのだろうか…

これらは一旦愚直に「木の深さ」「木の数」を制限していき、モデルサイズをやりくりする方法を取った*6。

最終的に全体で241MB までダイエットした。あと1桁落としたかったが、精度が犠牲になるならまあ同意を取ろうという事で今回は妥協した。

同意を取る画面で私がローランド様のツイート全部見た上で厳選したツイートが見れるのでそれで我慢してもらう。

　

- おわりに -

12月頭にWebAssenbly nightというイベントがあって面白かったので、なんかコツコツ勉強していたら出来ていた。ありがとうWebAssenbly night。

emsn.connpass.com

Webサービスのアイデアは20秒くらい、フロントエンドも最近慣れてきて1日かからずできたが、wasm buildして配信するまで結局1週間くらい唸った。まともな情報もないし、育児くらいしんどかった。

信頼できるのは以下だけで、後の情報は絶対古いか動かないかが入ってくるので無視した方が良いと思う・

とりあえずこのチュートリアルをなぞるだけにして頼むから。
この記事の内容も最悪誤情報になるなと思った所は削った。

　
次はPyTorch WebAssenblyを試すのと、最近やっているフロントエンド周りの勉強のまとめを書ければと思う。


　f:id:vaaaaaanquish:20201226051027p:plain:w0

*1:JOULIN, Armand, et al. Fasttext. zip: Compressing text classification models. arXiv preprint arXiv:1612.03651, 2016. https://arxiv.org/abs/1612.03651

*2:https://github.com/facebookresearch/fastText/issues/1166

*3:https://stackoverflow.com/questions/60936495/module-parse-failed-unexpected-token-937-with-babel-loader

*4:https://github.com/microsoft/LightGBM/issues/641

*5:PAINSKY, Amichai; ROSSET, Saharon. Lossless (and lossy) compression of random forests. arXiv preprint arXiv:1810.11197, 2018. https://arxiv.org/abs/1810.11197

*6:How to Tune the Number and Size of Decision Trees with XGBoost in Python https://machinelearningmastery.com/tune-number-size-decision-trees-xgboost-python/

Rustによるlindera、neologd、fasttext、XGBoostを用いたテキスト分類

Rust 機械学習 自然言語処理 スクリプト

- はじめに -

RustでNLP、機械学習どこまでできるのか試した時のメモ。

Pythonどこまで脱却できるのか見るのも兼ねて。

コードは以下に全部置いてある。
GitHub - vaaaaanquish/rust-text-analysis: rust-text-analysis

- 形態素解析 -

Rustの形態素解析実装を調べると、lindera-morphology/lindera を使うのが有力候補となりそうである。sorami/sudachi.rs や agatan/yoin 、 nakagami/awabi のような実装もあるがメンテは止まっている様子である。

linderaメンテナのブログ。
Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみた - Qiita

neologd

linderaはipadic-neologd含む辞書作成ツール等もRustプロジェクト内で作成されている。まず、ipadic-neologd辞書を取得し、linderaで扱えるようにする。

以下ツールを使う。
github.com

READMEの通りに進める。

# neologdの辞書をlindera用に
$ cargo install lindera-ipadic-neologd-builder
$ curl -L https://github.com/neologd/mecab-ipadic-neologd/archive/master.zip > ./mecab-ipadic-neologd-master.zip
$ unzip -o mecab-ipadic-neologd-master.zip
$ ./mecab-ipadic-neologd-master/bin/install-mecab-ipadic-neologd --create_user_dic -p $(pwd)/mecab-ipadic-neologd-master/tmp -y
$ IPADIC_VERSION=$(find ./mecab-ipadic-neologd-master/build/mecab-ipadic-*-neologd-* -type d | awk -F "-" '{print $6"-"$7}')
$ NEOLOGD_VERSION=$(find ./mecab-ipadic-neologd-master/build/mecab-ipadic-*-neologd-* -type d | awk -F "-" '{print $NF}')
$ lindera-ipadic-neologd ./mecab-ipadic-neologd-master/build/mecab-ipadic-${IPADIC_VERSION}-neologd-${NEOLOGD_VERSION} lindera-ipadic-${IPADIC_VERSION}-neologd-${NEOLOGD_VERSION}

# lindera-cli で検証
$ cargo install lindera-cli
$ echo "すもももももももものうち" | lindera
すもも	名詞,一般,*,*,*,*,すもも,スモモ,スモモ
も	助詞,係助詞,*,*,*,*,も,モ,モ
もも	名詞,一般,*,*,*,*,もも,モモ,モモ
も	助詞,係助詞,*,*,*,*,も,モ,モ
もも	名詞,一般,*,*,*,*,もも,モモ,モモ
の	助詞,連体化,*,*,*,*,の,ノ,ノ
うち	名詞,非自立,副詞可能,*,*,*,うち,ウチ,ウチ
EOS
$ echo "すもももももももものうち" | lindera -d ./lindera-ipadic-2.7.0-20070801-neologd-20200910
すもももももももものうち	名詞,固有名詞,一般,*,*,*,すもももももももものうち,スモモモモモモモモノウチ,スモモモモモモモモノウチ
EOS

neologdが利用可能な状態になっている。ここで作成した./lindera-ipadic-2.7.0-20070801-neologd-20200910なる辞書データは、後でRustスクリプト上で使う。

lindera

CLIではなくRustからneologdを呼ぶ。本体は以下のrepoになる。
github.com

linderaのREADMEに先程作成したneologdの辞書を流す例。

use lindera::tokenizer::Tokenizer;
use lindera_core::core::viterbi::Mode;

fn main() -> std::io::Result<()> {
    let mut tokenizer = Tokenizer::new(Mode::Normal, "./lindera-ipadic-2.7.0-20070801-neologd-20200910");
    let tokens = tokenizer.tokenize("すもももももももものうち");
    for token in tokens {
        println!("{}", token.text);
    }
    Ok(())
}

$ cargo run
すもももももももものうち

形態素解析はこれで一旦良さそう。トークナイズ結果は、mecabフォーマット等でも出力できるので、自然にPythonから移行したりできそうである。

- Text Processing、Embedding -

NLPでよく使うような特徴量、Count Vector、TF-IDF、fasttext、BERT、…辺りを扱いたい。

PyTorchのRust Bindingが一番活発に開発されていて、候補として最も良さそう。
github.com

tch-rsに依存した、guillaume-be/rust-bertなどもある。


TF-IDFは、 ferristseng/rust-tfidf や afshinm/tf-idf など野良の実装が見つかるが、メンテも止まっていてあまり使いやすい実装のクレートは現状見当たらなかった。


今回は、facebookresearch/fastTextの公式実装のRust Bindingを実装している以下を使う。
github.com

fasttextの実装も含むのでbuildにcmake必須。macならbrewで入れておく。

$ brew install cmake
extern crate csv;
use lindera::tokenizer::Tokenizer;
use lindera_core::core::viterbi::Mode;
use fasttext::FastText;
use fasttext::Args;

...

    // 一度csvに書き込む
    let mut tokenizer = Tokenizer::new(Mode::Normal, "./lindera-ipadic-2.7.0-20070801-neologd-20200910");
    let mut file = File::create("./data/train_fasttext.csv")?;
    for (sentence, label) in zip(&train_sentences, &train_labels){
        let row = tokenizer.tokenize(&sentence).iter().map(|x| x.text).collect::<Vec<&str>>().join(" ");
        write!(file, "__label__{}, {}\n", label, row)?;
    }
    file.flush()?;

    // 先程作成した __label__1, bar の形式のcsvを入力としてbinを生成
    let mut fasttext_args = Args::default();
    fasttext_args.set_input("./data/train_fasttext.csv");
    let mut model = FastText::default();
    let _ = model.train(&fasttext_args);
    let _ = model.save_model("./data/fasttext.bin");

公式実装のBindingなので、パラメータは以下を見れば良い。
List of options · fastText

このfasttext model自体supervisedに分類を解いてtrainさせれば、この時点でテキスト分類のpredictはできる。

- XGBoost -

一般的にfasttextだけで問題が解ける場合は少ないので、特徴量を追加してxgboostのようなモデルを挟む事になる。

gbdtに関連したものだと、以下が最も更新されていて良さそう。
github.com

今回は、公式実装のRust Bindingなのでこちらを選ぶ（最終更新が2年前でxgboost 0.8を使っていて作者も音沙汰がない様子ではあるが、PythonやC++から触っている馴染みのxgboostのパラメータやAPIを使いたい）。
github.com

先程のfasttextモデルで文字列をEmbeddingして、DMatrixを作成しBoosterに入れる。更新がなくREADMEに書かれたExampleは動かないので、実装を見比べるか、repo内のExamplesを参考にする。

extern crate xgboost;
use xgboost::{DMatrix, Booster};
use xgboost::parameters::{self, tree, learning::Objective};

...

    // python binding同様にDMatrixを作る
    let train_data_size = train_sentences.len();
    let test_data_size = test_sentences.len();
    let mut train_dmat = DMatrix::from_dense(train_ft_vector_flatten, train_data_size).unwrap();
    train_dmat.set_labels(&train_labels).unwrap();
    let mut test_dmat = DMatrix::from_dense(test_ft_vector_flatten, test_data_size).unwrap();
    test_dmat.set_labels(&test_labels).unwrap();

    // parameter群を設定し多クラス分類でtrain
    let uniq_label = train_labels.unique().len() as u32;
    let eval_sets = &[(&train_dmat, "train"), (&test_dmat, "test")];
    let learning_params = parameters::learning::LearningTaskParametersBuilder::default().objective(Objective::MultiSoftmax(uniq_label)).build().unwrap();
    let tree_params = tree::TreeBoosterParametersBuilder::default().eta(0.1).max_depth(6).build().unwrap();
    let booster_params = parameters::BoosterParametersBuilder::default().booster_type(parameters::BoosterType::Tree(tree_params)).learning_params(learning_params).build().unwrap();
    let training_params = parameters::TrainingParametersBuilder::default().dtrain(&train_dmat).booster_params(booster_params).boost_rounds(5).evaluation_sets(Some(eval_sets)).build().unwrap();
    let bst = Booster::train(&training_params).unwrap();

    // predict
    let mut preds = bst.predict(&test_dmat).unwrap();

特徴量化からmodelによるpredictまでができた。

- 実験 -

実際にlivedoorニュースコーパスに対して、ニュース本文からメディアを分類するタスクを実施する。

以下からデータをダウンロードした。
ダウンロード - 株式会社ロンウイット

RUN wget https://www.rondhuit.com/download/ldcc-20140209.tar.gz
RUN tar -zxvf ldcc-20140209.tar.gz

このデータを以下スクリプトで雑にtrain、testデータに分割した。
https://github.com/vaaaaanquish/rust-text-analysis

Dockerに収めたので、以下をbuildすれば、上記データがダウンロードされtrain、testデータが作成される。
github.com


実際にlinderaで形態素解析し、fasttextでtrain、embedding、XGBoostで分類タスクを実施した。

testに対するclassification_reportは以下のようになった。

              precision    recall  f1-score   support

           0       0.73      0.72      0.72       251
           1       0.73      0.58      0.64       147
           2       0.91      0.94      0.93       251
           3       0.91      0.92      0.92       283
           4       0.80      0.77      0.79       251
           5       0.84      0.80      0.82       232
           6       0.82      0.94      0.88       254
           7       0.78      0.78      0.78       263
           8       0.81      0.83      0.82       278

   micro avg       0.82      0.82      0.82      2210
   macro avg       0.81      0.81      0.81      2210
weighted avg       0.82      0.82      0.82      2210
 samples avg       0.82      0.82      0.82      2210

悪くないので一旦ここまで。

- おわりに -

割と悪くない所までできた。

LightGBMもcoreのBindingを書いてあげれば使えそうだし、もう少しmetricとかpreprocessingのML関連クレート書いていけば良さそう。

fasttexやPyTorchがWebAssenblyに対応しているので、次の記事ではその検証を書く。
WebAssembly module · fastText
WebAssemblyでの機械学習モデルデプロイの動向 · tkat0.github.io

Python脱却にはまだまだ遠い（クレートやメンテナの数が違いすぎるし、EDAなど型なしでやりたい作業も多い）が、期待した結果が得られたので良かった。

　

機械学習パイプライン構築を楽にするgokart-pipelinerを作った

Python 機械学習

- はじめに -

luigi、gokartで作ったtaskのパイプライン構築をちょっと楽にする（かもしれない）管理するためのツールを作った。

github.com

近年、MLOpsの一部である機械学習のためのパイプラインを構築するためのツールは飽和状態にあるけどそれらと比較してどうなのという話も書く。

gokart-pipelinerを使ってみる

gokartはエムスリー株式会社が開発している機械学習パイプラインOSSである。gokart自体、使った事がないし興味もないという人も居るかもしれないが、一度以下に提示するgokart-pipelinerの例を見てほしい。

# pip install gokart_pipeliner
import luigi
import gokart
from gokart_pipeliner import GokartPipeliner

# taskを定義する
class TaskA(gokart.TaskOnKart):
    def run(self):
        self.dump(['foo'])

class TaskB(gokart.TaskOnKart):
    before_task = gokart.TaskInstanceParameter()
    text = luigi.Parameter()

    def run(self):
        x = self.load('before_task')
        self.dump(x + [self.text])

# パラメータとパイプラインを書く
params = {'TaskB': {'text': 'bar'}}
pipeline = [TaskA, TaskB]

# run
gp = GokartPipeliner()
gp.run(pipeline, params)

luigiやgokartでは、1つのタスクを1classで表現する。TaskAは ["foo"] を保存するだけのタスク。TaskBはparameterに設定したbefore_taskを読み込んで、同じくparameterに設定した text を末尾に追加するタスク。GokartPipelinerがその2つのタスクをよしなに接続し、パラメータと共に実行している。

gokartの良さ

手前味噌にgokartの宣伝をするならば、この時以下のようなメリットがある

  • それぞれのTaskの以下データが別々にハッシュ値付きでpklファイルに保存される
    • self.dumpしたデータ
    • importした全てのmoduleのversion
    • Taskの処理時間
    • Task内で使われた全てのrandom_seed
    • 出力されるログ
    • Taskのクラス変数として設定された全てのparameterの値
  • TaskBのparameterを変えて実行した時は別のハッシュ値で上記ファイルが生成される
  • TaskAに新たにparameterを追加した場合はTaskBのハッシュ値も変わり依存関係を考慮して両方rerunされる
  • TaskA、TaskB間は上記の出力を中間ファイルとしてやり取りされるためメモリに優しい
  • dumpの出力ファイル形式を拡張できる(デフォルトでもcsv、zip、feather、png、…などをサポート)
  • 入出力時のpandas.DataFrameの型、columnチェック機能がある
  • 保存ファイルのディレクトリ構成がPythonスクリプトの構成から自動的に決まる
  • 基本的なnumpy、randomのシードは自動で固定化される
  • SOLID原則をなるべく守りながらコーディングできる
  • 保存された出力データとparameter、hashの管理はthunderboltなる別ライブラリでPython上で行える
  • 並列にタスクが動作してもredis経由でTaskがロックされる

機械学習モデリングにおいて、何をロードして、何を出力し、どのように繋げるか以外の殆どを自動的に決定し保存する仕組みになっている。また、その上でクラス単位でTaskを作る事によるソフトウェア開発における単一責任の原則などを守りやすくなっている。

近年は、機械学習パイプラインツールの戦国時代でもある。他の多種多様なライブラリと比較しても、モデリング時やproductionの再現性のための中間出力が多いし、Pythonコード上で見た時、デコレータや謎のメソッドがチェーンされまくったコードよりは保守性が高くなるはずだ（gokartを学ぶコストさえ払えば）。

例えば「pandas.DataFrameのtext columnから文字列の長さのcolumnを生成する」という処理は、無闇に大きな関数やスクリプトにせず、1つのファイルに1つのTaskとして考えて以下のように書いていく。

class CalcTextLengthTask(gokart.TaskOnKart):
    target = gokart.TaskInstanceParameter()
    __version = luigi.IntParameter(default=1)

    def run(self):
        df = self.load_data_frame('target', required_columns={'id', 'text'}, drop_columns=True)
        df['text_length'] = df['text'].str.len()
        self.dump(df[['id', 'text_length']])

gokartにおいては、1Taskの規模感さえ一致すれば、この書き方以外でコードを書くのは難しく、コードレビューや保守が行いやすい。また、このCalcTextLengthTaskの入力となるtarget taskを変える事で、hash値等のメリットを享受しながら使い回す事ができる。例えば機械学習モデルの汎用的なTrainタスクを書いておいてTaskInstanceParameterのみ変えるといった具合に。

また、parameterで中間ファイルのhash値が変わる事を利用して、__versionのようなパラメータを雑に付けてあげれば、「長さを測る前にstripしてからという処理に変更」した時にversion=2としてcommitしておくことで、あとからgitのlogをblameしたり、出力されるhash値付きのpklファイルを見比べる事でデバッグが行いやすくなる。


加えて、wrapしているluigiとの比較は以下のスライドを参考に。
gokartの運用と課題について - Speaker Deck
何もないluigiを書くよりも書きやすいと思えるはずである。

　

gokart-pipelinerの意義

gokartでモデリングしたり、コンペに出たり、会社での本番運用を重ねていく中でいくつか課題になってきた以下のような点を解決しようとしたのがgokart-pipelinerである。

  • パラメータとパイプラインが密結合しすぎ
  • パイプラインライブラリなのにやればやるほどrequiresメソッドが複雑になる
  • jupyter notebookと行き来するのがダルい
パラメータとパイプラインが密結合しすぎ

パラメータとTaskの動作が分離しているパイプラインは、近年の流行となりつつある。

特にFacebook社の公開したHydraはかなり大きな転機だったように感じる。yamlとデコレータを軸としたパラメータ管理で、yamlファイルさえ管理していればどんなパイプラインを書いても良いし、かなり管理も楽である。

一方でデコレータは闇魔法を生みやすいし、デコレートした謎の巨大な関数を見るのはツライので、もう少しコーディングに制約を持たせた形のパイプラインを作りたいと思っていた。（他人の書いたHydra+mlflowのコード見るのしんどすぎない？）

luigiにもconfigParserを使ったiniやyamlファイルを読んでパラメータとする機能はある。しかし、gokartにもTaskInstanceParameterというやつが居る。これ自体はtaskを依存関係の一部と捉えられる良い機構ではあるものの、Parameterという扱いとしてyamlのように一箇所で管理できないネックがあった。

gokart-pipelinerの場合を見てみる。

from gokart_pipeliner import GokartPipeliner
from ExampleTasks import *

pipeline = [TaskA, {'task_b': TaskB, 'task_c': TaskC}, TaskD]
params = {'TaskA': {'param1':0.1, 'param2': 'sample'}, 'TaskD': {'param1': 'foo'}}

gp = GokartPipeliner()
gp.run(predict, params=params)

pipelineは「Task同士のTaskInstanceParameterによる依存関係のみい」を表し、paramsは「各タスクのそれぞれのluigi.Parameter」を表していて、切り分けられている。元々のluigiのconfig形式にも対応しているので、configファイル、pipeline、paramsをそれぞれ考えつつ、この構成だけ保存しておけば一元管理もできる。

パイプラインライブラリなのにやればやるほどrequiresメソッドが複雑になる

gokartの機能としてrequiresというクラスメソッドがある。これは、読み込むデータを指定するメソッドで、requiresが返す値でluigiが依存タスクを決めている。

先程のタスクをgokart-pipelinerを考えず書いた場合は以下のようになる

class CalcTextLengthTask(gokart.TaskOnKart):
    target = gokart.TaskInstanceParameter()

    def requires(self):
        return self.target

    def run(self):
        df = self.load_data_frame('target', required_columns={'id', 'text'}, drop_columns=True)
        df['text_length'] = df['text'].str.len()
        self.dump(df[['id', 'text_length']])

このrequiresは以下のようにlistやdictを返したりもできる。

    def requires(self):
        return {'target': self.target, 'model': self.clone(MakeModelTask)}

更に複雑に、依存関係やパラメータ、分岐を書く事もできる。

    def requires(self):
        data = TrainTestSplit(data=MakeData(path='/'), split)
        if self.parameter_a == 'var':
            task = MakeModelTask(data=data, param_a=0.1, param_b='foo')
        else:
            task= MakeModelTask(data=self.data)
        return {
            'data': data,
            'model': self.clone(task)}

この状態では、コンペのような実験とコーディングを繰り返す時に、依存関係がどうなってるか把握するのがどんどんしんどくなる。gokartに依存関係Treeを出力する機能があるが、流石にしんどい。こういった複雑なrequiresを集約するエンドポイントになるTaskを作ったりするが、次はそのエンドポイントからしか全体が実行できなくなったりしていくし、エンドポイントが増えれば増えるほど、どのファイルを見て回ればいいか分からなくなる。その上で途中にTaskを挿入したいとなったら、と考えるとただただ辛くなる。

なので、そもそもrequiresを書かない制約を付ければ良い。


例えば、gokart-pipelineでの先程の例を考える。

pipeline = [TaskA, {'task_b': TaskB, 'task_c': TaskC}, TaskD]
params = {'TaskA': {'param1':0.1, 'param2': 'sample'}, 'TaskD': {'param1': 'foo'}}

ここでTaskDは、リストの1つ前のdictを引数にするように、以下のように書いたクラスである。

class TaskD(gokart.TaskOnKart):
    task_b = gokart.TaskInstanceParameter()
    task_c = gokart.TaskInstanceParameter()
    param1 = luigi.Parameter()

    def run(self):
        b = self.load('task_b')    # list
        c = self.load('task_c')    # list
        data = b + c + [self.param1]
        self.dump(data)

requiresメソッドは、TaskInstanceParameterのパラメータ名から、gokart-pipelineが生成する。この制約によって複雑なrequiresを書かれる事もなく、pipelineのlistだけを変数やdictを使って上手く書いてやれば良いだけになる。

jupyter notebookと行き来するのがダルい

gokart自体をjupyter notebookで動かす方法はあるものの、かなりハックじみた方法となる*1。

gokart-pipelinerはjupyter notebook上で動く。
gokart-pipeliner/Example.ipynb at main · vaaaaanquish/gokart-pipeliner · GitHub

Task同士は中間ファイルでやり取りされるのでメモリをバカ食いしないし、classである事さえ意識して一般的なソフトウェア開発の心得に沿って書けば、ここで書いたコードをそのままproductionコードにするのも容易になる。

もちろんタスクを動かした後、thunderboltを使って出力ファイルをメモリに読み込むなどして、jupyter上で触っても良い。
github.com

future work

今後上手く使えてきたらできそうなこと

  • pipelineのリストの書き方のベストプラクティスを探る
  • runの返り値として出力データを返したりできるようにする
  • pipelineを決めたら並列化できる所を自動で並列に動作させたりする
  • jupyter notebookからも別のプロセスとして動かす（Taskが動く最中もnotebookが実行できる）

おわりに

試しに作ってみた段階なので、これからコンペに出たり本番運用に使ってみたりして調整していきたい。

gokartは良いぞという話を散々書いたが、gokartは中間ファイルを経由するだけにDataFrameを良く使うテーブルデータでは使いやすく、画像コンペのような所では全然良さを発揮できなかったりする。いやいや画像音声テーブルなんでも自分のツールは共通化しておきたいわ、という人に不向きという所をなんとか改善できればと思ってはいる。

なんとなく形になったら、gokartにマージしてもらって、gokartの定番となっても良い気もする。

がんばろう。

　

*1:機械学習プロジェクト向けPipelineライブラリgokartを用いた開発と運用 - エムスリーテックブログ https://www.m3tech.blog/entry/2019/09/30/120229 を参照すると良い