こんにちは。ウォンテッドリーでソフトウェアエンジニアをしているnasaです。

本記事では、ウォンテッドリーの機械学習ジョブ向けの共有ライブラリについて説明します。

課題感

はじめになぜ共有ライブラリが必要になったか説明します。

ウォンテッドリーの推薦システム用の機械学習ジョブはその用途ごとにリポジトリを分けて運用しています。例えば、画面Aのキーワード検索時、画面Bの非キーワード検索時、通知Cのように分かれています。今後、推薦箇所や状況に合わせた推薦を行っていくことを考えるとリポジトリ数は更に増えていくことになります。

このような状況で幾つか問題が発生していたのでそれを倒す事を目的として共有ライブラリの開発を行いました。

課題1. 「似ているがどこか違う処理」が点在しており認知負荷が高い

機械学習ジョブはそれぞれが固有のビジネスロジックを持ちますが、共通かつ汎用的な処理も多く存在しています。

例えば下記のような処理はどのジョブでも行っており重複した実装が存在します。

• 機械学習の学習データをDWHから取得する
• 機械学習の推論結果をDWHに書き出す

重複した実装といいましたが、微妙にインターフェース(引数や返り値)や挙動が異なり正しく使うための認知負荷が高い状態でした。

DWHとの読み書きを例に上げましたが他にも多くの処理が重複して存在していました。

課題2. 実装コストが重い

２つ目の課題は実装コストが重いことです。例えばバグ修正を行う際には全てのリポジトリのコードを変更して回ることが大変でした。

当時ジョブの高速化に力を入れていたこともあり全てのジョブに手をいれる必要性が高まっていました。

ちなみにジョブの高速化については同僚が記事を書いているのでこちらを参照して下さい！

機械学習ジョブの高速化による開発効率の向上 | Wantedly Engineer Blog

こんにちは、ウォンテッドリーでデータサイエンティストをしている林 (@python_walker)です。私は普段、Wantedly Visitの推薦システムの開発に携わっています。この記事では、...

https://www.wantedly.com/companies/wantedly/post_articles/880049

これらの問題を倒すために共有ライブラリの開発・運用を行っています。

運用してみて発生した課題

この共有ライブラリを運用し始めてから発生した課題を紹介します。

不要なライブラリに依存することになった

運用の初期は共有ライブラリのすべての機能を利用側で取り込んでいました。このときライブラリ利用側は共有ライブラリが必要とするパッケージに依存することになります。しかしながら、利用側は必ずしもライブラリの全機能が必要ではありません。多くのライブラリに依存するのは共有ライブラリのインストールコスト的にもメンテナンスコスト的にも問題になっていました。　

例えばmecabのようにpythonライブラリの他にも依存するソフトウェアをインストールしなければならないが、mecabに依存する機能は使っていないといったことが発生していました。

この問題は「poetryのextract機能」を使い必要な機能に絞り取り込むようにしました。

# pyproject.toml
[tool.poetry.extras]
embedding_maker = ["numpy"]
tokenizer = ["mecab-python3"]

まとめ

• 「似ているがどこか違う処理」が点在しており認知不可が高い
• 実装コストが重い

今回はこれらの問題を倒すために機械学習ジョブの処理を共通化し共有ライブラリとして提供した話をしました。ライブラリ活用によって良いコードを横展開するスピードが改善でき、バグの早期修正、開発効率向上などの恩恵が得られています。